Ah, this explains it. But like my original, its about getting the textures cached. Although, if a computer doesnt have a video card, it has to use the computer's RAM. Either way, both types of RAM should be about the same, they actively hold stuff thats loaded from memory.

I hear ya about the SSDs, I do know those are about the fastest you can get today, but they are still damned expensive, or at least they were just 2 years ago when I was looking at how much it would cost to have a computer with a SSD.

My computer is pretty bad by modern standards, but it's not that old or rubbish by any standards. It has 2.87GB RAM and a NVidia something GT with 512MB memory (it's actually broken at the moment so I can't check the name of the card, which isn't exactly aiding my cause :blush: ). Anyway, I haven't done any scientific test but I used to use a load of texture replacers, most 512. They had slowly built up over time, so it was hard to say what the effect on my FPS was, but I had had to slowly decrease my MGE settings. Anyway, one day I decided to get rid of the lot to get a more vannila feel, but I also noticed a massive increase in FPS. I'll do some tests when I get my computer back, but in the meantime it's worth considering that older computers can struggle with too many high-res textures in MW.

It's all about the access times. Because there's no physical head seek, data anywhere on the disk is available many orders of magnitude faster than a magnetic hard disk.

You only need to buy limited capacity, enough to store your OS and your most-used apps ideally - you're not looking to replace hundreds of Gigs of rarely accessed files or media storage where magnetic disks are fine. That means most people can get away with 60-80GB or less, and you can get a 60GB Corsair Force or an 80GB Intel X25-M for $135 to $190 (just checked on Newegg), or ￡105 to ￡135 in the UK (Scan). Get a copy of http://www.acronis.com/homecomputing/products/trueimage/ to clone your OS partition and it's a pretty cheap and very effective upgrade.

Your comment on the difference between a dedicated graphics card and an onboard graphics chip applies just as much to sound.
I've seen replacing a cheap onboard sound chip with a dedicated sound card add 5-10 fps in Balmora.

it's a mac book. fairly old one too.
i'm running bootcamp on it.

The SSD idea is correct, I just spent the weekend playing Oblivion at a friends PC that has a 32 Gig slate drive for the OS and a couple of games an it cuts load times and stuttering by at least half than a good hard disk. It would definetly help morrowind too

Updated the first post some to be more correct.

Just a bump to give this more attention and to remind me to add a part on MGE.

While a good idea in general, a lot of this info isn't quite accurate, or can still depend a lot.


Hardly, at least in hardware. MW uses fixed function lighting, which is trivial (per vertex, max of 8 lights). The software-side sorting may be somewhat slower, but that depends greatly on the cell, position and how the engine's handling it. Gamebryo has always had excellent culling, but whether this applies to MW's lights, I cannot say.


I'd like to see evidence for playing sounds hurting framerate. I'd think that loading from disk and CPU-side MP3 processing would have a much greater effect, but that could vary greatly. DirectSound typically spawns one or two threads for its own use, and may benefit from multicore systems, and not too many things are loaded from disk during the game, far less than modern drives choke on.


Not necessarily. Newer model GMA chipsets are a hair less atrocious than their predecessors, and can handle some simple shader models.


No.

Polycount isn't a flat number you can judge anything by. I threw together a minecraft clone that could push 3 million polys (17+ million voxels) at 300 FPS on respectable hardware, and an even 60 on crap. With shaders.

The makeup of the model, the amount of processing done before render, the number of fragment (not just polys) that pass the render tests, and approximately 732.943 bazillion other factors make straight polycount an iffy measure, at best.

The only thing you can say is that a 3 poly model should render fast. But even that may not always hold true.

On top of that, the system, drivers and how things are set up may change speeds a good bit. Memory management and how video memory is being handled, or if its shared (which can happen on dedicated cards) will. Running a thin DX8.9 layer (the underlying tech for MGE) can avoid some thunks and may improve performance slightly on newer systems, particularly Vista/7 (MGE itself is unlikely to do so).

A guide of general gotchas will be valuable, but needs to be very generic and gone over many times to assure accuracy.

Anybody try Pyffi-ing MW meshes for optimization? Read about it in OB forum http://forums.uesp.net/viewtopic.php?f=10&t=19300

ST

I know this to be fact because I have seen a slow down with tons of light. Looking in the direction of a ton of light will slow you down whether or not you can see it. I was editing a mod where there had been a ton of lights placed. After taking many of them out, my framerate improved, I am going by first hand experience here. Now, like I have repeatedly said, it will depend on your computer's power as to how much it can take.



Well ask the guy who left a post in this thread about how adding a good soundcard increased his framerate. I originally thought no it didnt but changed it due to first hand experience.



Well things are always improving, but if you can site someone who can use MGE to significant effect without a video card, then I will change it.(and I mean have distance view of 3 or more cells)



Oh please, now this is one thing I know I am not wrong on. Poly count is something you can get an estimate from. You can not tell me that professional game makers limit poly count just for fun otherwise there would be no need to ever smooth anything in MW.(well higher number of polys does get more difficult to work with but you still get tradeoffs even today between poly count and detail) In fact I thought I had made it clear that an estimate is all you can get and I already know that a definitive amount is almost impossible, you can only get a range.
That said, yes I do realize that there is more to it then poly count but wieghing all things together, poly number by far counts the most in most cases. You can not say that a 20,000 poly model takes more processing power then a 100,000 poly version of that model under normal circumstances. In fact you said it yourself, "I threw together a minecraft clone that could push 3 million polys (17+ million voxels) at 300 FPS on respectable hardware, and an even 60 on crap." More polys will decrease your framerate depending on your hardware.(keeping this in mind, I thought I made it very clear that your hardware matters a great deal) With model make up, I am not assuming anything crazy for morrowind, the models are no more complicated then those in any other game ad in fact are probably a bit less complicated in many cases.
There is another thing that can slow you down and thats the painting of the actual textures onto the polys. Trying to paint a large texture onto very few polys can cause a slow down and I forget the reason for this but it can happen. I beleive I read this in regards to a gambryo model in fact, about how someone was getting a slow down despite a very simple model.



Well in most cases, things are going to be more or less the same(dont take this as a litteral statement) There are standard ways in which architecture and pipelines and such are set up and while I do have limited knowledge, I know that if there was anything that significantly increased speed, it would be in use and widespread. Smaller differences in speed of things are out there but for the most part, most people will have either an AMD or an Intel processor and either a Radeon or Nvidia graphics card; sure there are different motherboard layouts and harddrives and such. etc This means there are not very many different software architectures for running chips and such. There are even only a few major harddrive brands you will encounter(athough definitly a few more then chipsets).


I thought I was being rather general or at least making sure to mention repeatedly that it will depend on a few things and I beleive I stated this as the first statement.

All that said, if you can indeed prove that I am completely wrong I will change things to reflect correctness. I hope I have countered everything effectively.

I'm not sure there's really any debate about sound being an FPS hit, if you are using Software sound.

This was especially true in 2003 when I was first playing MW. I had to buy a soundcard as I couldn't get 10FPS on my P4 Alienware with Software...plopped in an Audigy 2 and it was at 40.

Today, I don't know if it makes nearly as much a difference....but if it made a big difference 7 years ago, its certainly having some impact today.

That sounds to be light culling, which may (or may not) have a linear effect. Many lights in a small area might hurt FPS, but it depends on their ratio and how easily the engine can exclude them, as well as how exactly the engine chooses to sort them. Lights with larger radii have a somewhat different effect, but are harder to cull and more likely to appear in the light list.


If your onboard sound was using the CPU to decode the audio, which some chipsets may and some may not, that may have an effect, depending on how DirectSound is handling itself and what it chooses to use the threads for. Depending on the size, bitrate or compression ratio of the file, or even the hard drive its stored on and when it's loaded, there could be a slight difference.

If you were using a soundcard, the new issue would be memory speed downloading to it, which should not be an issue (in most cases).


I've run slightly older versions (rev116 or so) on onboard (GMA7xx, I think it was) with ~13 cells and a few ps1.4 post shaders. MGE does not innately limit based on GPU; some features may (although shader model, Intel's primary weak point, is specific to a single shader) and some may not. Turning on AA or AS can, if your card doesn't like it, or may not. SM3.0 shaders can have more of a hit than 1.4, but it depends on the shader. The depth/menu saving and reflective water will (usually) have a hit, because of the caching they perform and increased draw count.



You can get an estimate, but it's very rough. The main cause is that there are too many potential bottlenecks, but which you'll hit depends on hardware and game location. In a exceptionally broad statement, more polys is slower.

Edit: Oh, and in the case of my minecraft clone, rendering no polys at all (nothing, blank screen) ran at about 900 FPS on crappy systems and 2000-6000 on good ones. However, it (as expected) dropped as the viewport increased. Drawing the same number of polys but doing each cube separately yielded 0.1-0.02 FPS, where as drawing them in 512-block chunks was ~120x faster (draw calls vs polys per draw).

However, if you were to compare similar models from Morrowind and NWN for example, you'll see one of the potential issues. NWN does some skinning in software, which provides a second bottleneck. MW uses the fixed function pipeline, which has its own limitations. In general, pixel throughput will be the issue until you hit a significant number of polys (which can be as many as a few million).

If every object in a cell was physiqued, the hit would be far greater than if you had 10 times the number of still polys (take the BB bodies, for example). Because of this, there very well can be occasions where 20k polys is more expensive than 100k (and these are very normal circumstances). Morrowind's typically low polycount, even with tons of high-res models, tend not to become so great as to overtake pixel throughput in limiting speed.

The same thing can happens when draw call overhead begins to overtake per-draw cost, which is covered in the DX docs for at least a few pages. Many small objects with fewer polys can be slower than a single much larger object. Vertex ordering and stripping also comes into play, since one model may have numerous strips, or could be a single one. With Gamebryo's culling and additional handling (covered in the engine documentation, in the artist's guide section), the exact opposite can occur and many small objects can offer improved culling and less clipping. Morrowind appears to have additional issues not mentioned by the API or engine docs, and can choke on objects with certain types of collision that are concave and surrounding the player (it seems Gamebryo's portal culling is not enabled, probably due to how MW uses placeable objects to create the world).

In typical cases, however, neither of those comes into effect; the AI and script routines are the final speed limit. With poor graphics cards, vertex/pixel throughput may limit you. With any kind of modern card and vanilla, the CPU is the issue. Collision can be expensive, depending on the present model's collision flags and whether the player (or any other creatures) are within the surrounding bounding box (the engine may, or may not, be able to cull).


Larger textures are always slower than small ones, and depending on the filtering mode and scaling involved, it can become more or less so. This is the general reason why 8x AF can effect speed.

This is also another example of what can introduce another choke point. Cards with small amounts of VRAM (say a 512 card) may be forced to swap to system RAM, which kills speed. Typically that won't happen because Morrowind usually doesn't fill VRAM, but there are cases where (with texture replacers, high poly models, or larger areas), more memory will be used. If some data has to be stored in the system memory pool, speed drops off sharply.


Of course, and there's no magic fix, nor is one really possible without rewriting the core render code. The Gamebryo render code, for the Morrowind-era version, is pretty solid and well written, and typically fast.


Read the DirectX 8.1 and 9.0c SDK documentation, it has a more thorough treatment of some of these things than I could type.

While the general idea of your guide is sound, too general a treatment isn't helpful, and it's very difficult to get specific without getting very specific. I'm sure my post contradicts itself at least a few times and is highly uncertain, mostly because there's no simple answer here (which is my whole point). There are a few things (get a better CPU, SSD drives, etc) that can have some effect sometimes, but none of the issues you may face are simple.

Don't get me wrong, I like the idea of such a guide, but I'm not sure it's possible to do effectively, or without confusing people. If it is, I think it will take a lot of benchmarking across systems to figure out which of the possible issues are popping up and why. If you do chose to set up a test suite and run some, I should be able to contribute a system or three and provide statistics for a small variety of hardware.

Well, I was going to reply to this topic with a rahter lengthy post- but I feel that Peachy here has beaten me to the punchline (and as he knows a lot more then I do that is entirely appropriate.


A few extra points I wish to make. First in response to the OP. SW Galaxies skies do not have a significant performance impact for one simple reason- the limited number of draw calls that the engine needs to make with the sky textures. A high res texture is not in of itself a performance killer- but the more a texture is used the more of a performance impact it has- conversely however it is optimal to use as few different textures as possible. For reasons that I admittedly have forgotten adding more variety to the textures increases the load. I have indeed benchmarked with FRAPS before, the difference between textures mostly in the 256x256- 512x512 range as compared with bloated texture files at 4096x4096 (please note that I remember reading something about texture size being capped at 2048x2048- I believe they may be internally scaled by the engine down to this point- but 4096 textures do "technically" work. Anyways- going from 512- 4096 had a significant performance impact on the rig I had at the time (One Geforce 7950GX2, 2.5 gigs of DDR RAM, 5600 RPM Hard Drive- 2.3 GHz Processor, etc...) The Performance impact was sometimes as much as 25 FPS in Seyda Neen/ Bitter Coast (Where every single ground texture was at that maximum resolution- and many other textures were also at very high res. Combined with a high MGE Draw Call and Demanding shaders I had unplayable FPS (around 5). BTW The so called Benchmark thread that has been referenced in this thread is not a good indicator- I have already debunked it in the past. In that thread the OP states for instance that Resolution has no impact on FPS- that is very, very wrong- higher resolutions require a significant increase in draw calls.

On the subject of Higher Poly Meshes- I haven't tested this with a benchmark yet- but I have been making a high poly replacement of all static objects in the game (but making sure they are optimized) and I haven't noticed a significant drop in FPS- maybe 2 or 3 with a significant increase in Geometric complexity. IMO most developers err too much on the conservative side with polygons.

Oh and on the subject of HD/ SSDs- I have to concur with that poster that they are an excellent idea- however I don't agree with his assesment that you should get one based off of price instead of performance. SSDs range in performance from twice as fast as a 7200 RPM HD all the way up to 20 times faster. my personal recommendation- and the one I have in my new rig is the Crucial Real SSD C300 (256 GB). It runs about 15 times faster then a 7200 RPM Drive. I also have a 10,000 RPM Western Digital Velociraptor (600 GB) for stuff that I don't need the best performance from. The best companies for SSD Drives are Generally Crucial, OCZ and Patriot. Avoid anything made by Kingston as they are the slowest- intel is also pretty slow (except oddly enough for their X25 line which are the fastest- and most expensive SSDs you can get).

I will help you with the list of performance heavy mods in the next few months- once I get back to the United States and have my new rig infront of me I can do some very accurate benchmarking.

Oh and great idea for a thread OP. Thumbs Up!

I'd absolutely have to disagree. There is considerable concern in the tech community about OCZ and their drives. Their rate of failure is the worst in the SSD industry, much worse than the Intels, which are proven the most reliable from long-term RMA statistics, and they have been caught out changing the internal specifications of their drives while keeping the same model number, effectively selling something underperforming compared to what purchasers were supposed to get. The Intel drives most certainly are NOT the most expensive. They are, dollar or pound per Gigabyte, the cheapest. Currently the range has just been substantially refreshed, and the new line will come down in price as stock numbers settle at retailers.

Note http://www.scan.co.uk/shop/computer-hardware/all/hard-drives-ssd/ssd-18-25-sata-ii-%2880gb-600gb%29 from a major UK etailer. Unlike Newegg's US prices, this does not fluctuate dynamically by demand and stock. At every capacity point in this list, the new Intel drives are certainly the cheapest, and that is compared to other brands' last generation tech.

While there are very great differences in benchmark performance between the brands, those benchmark results rarely relate directly to real world performance. The reason is that in normal usage a drive is almost never put under the consistent strain of the benchmark activity. Most normal use consists of small random file reads (especially for OS booting and app loading) not sustained sequential transfers, so the 4K random read result, not the impressive sequential transfer result, is the most important metric to compare to make any comparison in "normal" use. The Intel drives have consistently outperformed or matched most other controller types on this random 4K read activity, and this is why in real world usage tests there is no significant difference between them and other brands. While the Intel drives do have lower write speeds, sustained writing is (apart from OS or application installation) never a significant part of normal usage.

The other major factor to be considered is the Intel SSD Toolbox, their management software that only works with Intel drives. Many users here may still be using XP, which unlike Windows 7 does not send TRIM information to an SSD. Apart from automatically configuring Win7 to work properly with SSDs (which is not the default setup), the Toolbox allows XP users to manually TRIM their Intel drive and keep it in top working condition. No other brand allows this.

So the Intels are "fast enough" in comparison with other drives (especially the high-cost Sandforce ones, which only perform at rated speeds with data that's compressible, since the drive compresses it when writing), they are cheaper per Gigabyte and the most reliable. In any rational brand comparison they have to be the outstanding recommendation, unless you are doing something unusual that requires frequent, significant sustained throughput or you are putting the drives in a server, which is not the intended usage of these user-class items.

Having said all that, your Crucial C300 is a very good choice indeed, if people can afford it. That and its new replacement, the M4, are probably the best performers available, matching the Sandforce drives closely. But for most users, the Intel drives will be "good enough" and not noticably slower in normal use, plus they will have spent less for their storage and will have peace of mind about the long-term reliability.

Ultimately, peachykeen explained it best. The bottleneck once you've installed an SSD is the CPU. SSDs return data so fast to memory that if the CPU cannot keep up in processing it, it does not matter if your model is twice as fast or not. Having a low-end CPU means you will see little or no benefit from wasting money on a supposedly fast, expensve SSD, and the lower-end and more reliable brand must surely be the winner.

You should have posted a WIP thread then, just what objects have you done so far? because I have already been doing this exact thing, in fact I called it Better Meshes plus Optimization and in fact I posted a WIP thread. Actually I am planning on making my first release today.

I will respond to the rest later.

I know- I have seen yours. And while I appreciate the route you have taken, mine operates in a different fashion. I am focusing on the AC and Telvanni Tilesets and their related meshes at the moment. I don't necessarily feel the need to make a WIP thread because I don't know that I will actually release mine. If I do then I will update my WIP thread over at fliggs. Some of the differences- I am making flora meshes very high poly- trying to optimize them as much as possible whilst still maintaining the smoothest edge possible. Performance is no longer a huge concern for me- as I bought a relatively decent GPU from Nvidia that handles geometry rendering far more efficiently. Mine also includes such things as tree meshes (yes- I actually do still use the Vanilla trees), which have been "fixed". I don't just slap a subsurf on the meshes and call them done however (not suggesting that is what you do in the least btw), I fix any doubled vertices, run a little polygon optimization on it, and often play with the vertex lighting, etc... My future plans include adding detail maps to all of the rock meshes in the game (was that your mod that did that?). But again I am going a different route with that one. I am going to treat the detail map as I would a decal map from any other game. I.E. It will be used for blending a seperate randomized texture onto those rocks. Example forthcoming sometime in the future (seperated from my game files atm and won't be able to do much modding until I get home). I am also playing with some bumpmapping and gloss mapping on a number of surfaces, but I find that what is being done with it recently is IMO way too [censored] strong. I will make the bumpmapping barely perceptible for the most part. I hate that new overalhual mod for instance (I apologize to it's creator- I realise a lot of work went into putting it together- but IMO the choice of assets used is very poor). Also I think bumpmapping should only be applied selectively- not on all rocks. On the other hand- when I add detail maps I may make versions that show off a little shine wherever the "details" show up. Another idea I have had brewing for a while is adding "underwater versions of each rock mesh. That is- bumpmapping and gloss maps on the lower part of the mesh- fading to non shiny at the top- as gloss maps allow you to control that.

Mesh tilesets I have done in full or in part. All of the BC, AC, GL, AI rock meshes. The Flora meshes from the BC set, the stump meshes from the BC set. Some of the AI Flora. Most of the AC flora (all of the AC trees and EMP Parasols- (in which I have added collision where I felt appropriate- you can now jump on top of all of the mushroom trees without falling through- this is something that always bothered me), most of the exterior Telvanni meshes, AL Ash log meshes (still trying to iron those out as they have an insane number of detached or doubled vertices). I have also done a very large number of furniture meshes. One major difference between my replacer and others is that I am also increasing the tile count of textures on the meshes in a lot of cases. Especially on the furniture- Morrowinds default wood textures actually look pretty good when the tile count is increased enough- eliminating the need for massive wood textures.

I could go on and on about my little mod. But as I don't want to drag things off topic too much I think I will stop.

Oh and about SSDs- well I haven't bought one since last year so I guess things have changed since then. On the subject of Intel Drives though, they were (as of earlier this year) extremely poor performance wise in a number of operations. The thing that I feel should be of most concern for Morrowind players is how each drive handles very large data blocks. As our assets get bigger and bigger all the time. As I recall the Intel drives on the benchmarks I saw (put out by Toms Hardware and one other benchmarker) had extremely poor performance with those data blocks. On the other hand I remember seeing that the Intel x25s were the fastest of all, and at the time I built my new rig earlier this year they were still the most expensive). Also I didn't know that about OCZ. But lets not drag things off topic any further.

I seem to recall there was a mod that added pockets of fog over the BC swamps- that was one mod that had a large performance impact. Will look up the name of it later.

Tom's isn't the hardware site it used to be... :whisper: The major breakthroughs in benchmarking SSDs accurately and uncovering of the ramifications of the way the various controllers operate have been made by Anand Lal Shimpi of http://www.anandtech.com/tag/storage. And even more detailed anolysis and comparison has been going on in the http://www.xtremesystems.org/forums/forumdisplay.php?f=62 of XtremeSystems.

The significant information people need to be aware of is that Intel and Micron have a recent partnership where they make their own NAND Flash on a bigger bulk scale and at a new much smaller node size than previously. While Intel then uses its own Flash for its SSDs, this is also the source for many other companies own supply. Bluntly, they can't compete on price where the Flash chips are the major cost factor they have to buy in. And this is set to drive prices downwards (at last) as the new fabs ramp up and increase yield and supply. You can see this most impressively in the price listing I linked in the previous post. The larger new Intel drives are, dollar or pound per Gigabyte, about 75% of the price of the models they are replacing (compare old X25-M 160GB still listed with new 160GB 320-Series).

The only Intel drive that would ever have been more expensive per Gigabyte than the competition was the long-discontinued X25-E, and that was a high-performance server-class drive using SLC NAND, not a mainstream end-user MLC product. And thanks largely to Intel, these ARE now mainstream, affordable hard-drive replacement products, not elite geek items needing careful installation (ever had to change your OS drive's sector alignment :rofl: ) and continual firmware updates.

OK, enough SSD evangelism. The links above will keep anyone interested informed.

For loading times and stuttering, more RAM+superfetch+defrag or an SSD.

For FPS, better CPU. I made a survey and people with CPUs over 3.2 GHz(3.2 is not enough) were getting amazing performance universally. Number of cores doesn't matter. Other things(resolution,lights, textures, polygons...) scale normally and don't become a problem.

Not always true, i was using morrowind overhaul, MGE XE and a few other mods, SSAO, Bloom, HDR, the whole nine yards at 1900x1200 res. Running on a Sandy Bridge i7 2600k OC to 4.7ghz, 128GB C300 SSD, NVIDIA 560ti, and 8GB of ram, and i was getting 20FPS in the heavily wooded/grassy ascadian isles region, switched to 560ti in SLI and am up to 30's in that area and 50's to 60's FPS in most others. So graphics card does affect performance.

Luckily Yacoby's http://www.yacoby.net/es/forum/12/8778811221001800.html still has it, it's old now but interesting.

There was also a thread by Fliggerty asking about mods that hit frame rates; sadly that's been pruned and isn't in the Archive.

Ok, yet again that benchmark thread comes up. I have stated this in the past and I will state it again. While that thread is of some utility in getting a very broad overview, I must stress that you should use extreme caution when drawing any specific conclusions from it. Particularly suspect in that thread is the OP's assertion that changing resolution has no effect on framerate. That is absolutely incorrect, for reasons which I can expound upon if necessary. IMO changing resolution will almost always have the biggest impact on framerate.

Actually- after rereading that OP in it's entirely I have to say that I think it is more misleadind then it is useful. Psyringe helped perpetuate the myth that highres textures have no impact on performance. My own benchmarking with Fraps just doesn't back that up. However in the name of fairness I will try- to the best of my ability to replicate his testing conditions when I get back to the US. Will go to the same locations and use his testing procedures. I'll even whip up a few batches of textures for the occasion- testing tga vs dds versions of each at three seperate texture resolutions.

Yeah, I know it's weird. I guess ThePal started the whole thing http://www.etherealsoftware.com.au/textpacks/.

Still, any more detailed information would be nice.

From my own experience (anecdote ahoy!) the game stops being graphics card limited fairly quickly after adding mods so that screen resolution and/or texture packs don't have the FPS effect that other mods do, particularly NPC-adding and script-adelic mods. Um, ignoring MGE.

That's because you were running SSAO/HDR and high res. Morrowind doesn't use the shader processors at all (with the possible exception of the shiny water). Adding MGE shaders in completely changes where the load is. In that case, it was probably shaders/blitting or pixels slowing things down.

Vanilla, and with most mods (that don't change the code), you're going to see more of what vtastek said with heavy CPU focus.