TPT "Megabuilds" Suggestion
-
From an old post of mine (http://tpt.io/.103262):
Keeping the workspace size constant makes Powder Toy run faster. Turning XRES and YRES into variables (even with no possibility of changing them) decreases the frame rate by about 15% (this varied between 10% and 30% on the saves I tested, but 15% was the typical value). Even if you keep the workspace the same size, just making resize possible makes Powder Toy run significantly slower.
Unless this has changed in the past 2 years? Anyone have any more recent tests to share?
You could set XRES=800 and YRES=600 (constants) and change just a few of the bounds checks to fake a smaller sim size, then it should run faster than it would with XRES and YRES as variables. But still slower than it would if it was actually that smaller size.
So if you really need a larger sim area, it's probably better to just make it that large all the time rather than attempt to make the size variable. But in my opinion, TPT is quite slow enough already without making the sim area bigger.
Looking at https://en.wikipedia.org/wiki/Comparison_of_Android_devices , the current size of 612x384 should fit onto the screens of larger Android devices, and I think it would be nice to maintain compatibility between the desktop and any mobile versions where possible. Larger sizes might not fit so well.
Making a separate build with a larger sim size is perfectly possible, there's an old one by me (very out of date and using the C version not TPT++) in another thread somewhere. But as others have said, saves from larger size builds aren't compatible with the normal version, so shouldn't really be published on the same server.
-
When XRES and YRES are static, compiler substitutes values into all code parts, so CPU doesn't need to do any additional work. In contrary, when they are variables, CPU has to lookup values in memory every time, which makes computations slower (TPT uses XRES and YRES quite often).
And what about your previous suggestions, TPT saves field size even now so if you found a way of making field size variable without loosing FPS we would have "Megabuild" as topic starter suggested :-)
-
I'm well aware that the computer needs to read memory when you want to use variables, but a 10-30% decrease in framerate? That can not be right, never in my programming experience have I ever seen such a dramatic performance drop just by changing a #define to a variable. There must be an optimization issue happening there.
I'm guessing he ran the game as a debugging build instead of an optimized release build. Even then, a 30% drop makes no sense. So long as the variable isn't being changed, the compiler should have that number stored in CPU cache if it's being used for many calculations.
-
@ief015 (View Post)
XRES and YRES are checked on every particle in the main update loop to make sure it's not out of bounds (2 checks), then it's checked up to 25 more times each (50 checks) in any element that does a loop around itself (to make sure it's checking a location not out of bounds either). Also any time a particle is created and deleted it needs to be checked, and I think in the graphics function it's also checked too.
This is probably what's creating the lag. After looking at this, it did make me realize that I just recently removed the 50 out of bounds checks for each particle because it was redundant and would never be possible (because we have that 4 pixel buffer where particles are already deleted). There might be a significant change, but i'm not sure. I'm guessing it would be a few fps slower as a variable, and tpt++ is already a few fps slower than the old tpt was.
