Menu options shouldn't lie!
-
@tudoreleuu (View Post)
I get 61 with empty, but when I add newtonian graviry it's 21 and even one pixel with newt. on fps is 2. -
Where's the lines in the C code that control the total screen size? I know someone who programs in C, and maybe I can have them change those lines to make the actual play area contain 1024x768 pixels, or even 1600x1200.
jenn4:
@tudoreleuu (View Post)
I get 61 with empty, but when I add newtonian graviry it's 21 and even one pixel with newt. on fps is 2.
LOL. Your problem isn't that you don't happen to have the absolute latest computer. Your problem is you must have an absolutely ANCIENT computer.abaabaabaaba4:
@tudoreleuu (View Post)Just wondering, I have an i7-2600k (not bragging) and comparing it to an old dell I used to use, the fps in tpt was night and day. I know tpt dosent use multiple threads but the old dell ran at 3ghz and my i7 runs at 3.8ghz so my question is that does cache size effect speed and does ram affect speed or is it just the 0.8 ghz that made the difference?
Well then that's another speed optimization that should be added. Someone needs to have it detect the number of cores your CPU has, and then use that many threads to process the data. That would add MASSIVE speed increases. -
Videogamer555:
maybe I can have them change those lines to make the actual play area contain 1024x768 pixels, or even 1600x1200.
For f*** sake. Can't you read?jacksonmj:
@Videogamer555
One of the previous times a resizable workspace was suggested, I was not in favour of it because just making resize possible slows the game down. See here: https://powdertoy.co.uk/Discussions/Thread/View.html?Thread=6611&PageNum=1#Message=103262
In the 'See here:', it says:
"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.
I don't think making Powder Toy slower just to give the option of resizing is a good idea. Not to mention how much work would be involved in coding it..." -
@Videogamer555 (View Post)
includes/defines.h, XRES and YRES
However, note that:
Width and height are stored in single bytes in the save format, so stamping and saving won't work properly if the width or height are made any bigger than 1020 (unless you also change the save format).
If the screen size is increased a lot, the game may crash due to too much recursion. Probably in grav_mask_r (a function to detect areas enclosed by gravity wall), or in one of the flood fill functions in powder.c.
As for multithreading, the problem is how to split up the data processing without synchronisation between threads slowing it down so much that it isn't any faster than a single thread. me4502 attempted multithreading recently, but I don't think he has succeeded yet.
@cctvdude99 (View Post)
Please read Videogamer555's post before raging. He was asking how to change the screen size in the source code, not demanding that it is done in the official version. And I don't think he was talking about a resizable workspace, so the things you have quoted are not relevant. -
@jacksonmj
I was going to suggest that the screen could be sided by the amount of threads but like you said I though that if a pixel was in say the thread 1 area (which was running faster than the thread 2 area) than moved to the thread 2 area the particle would slow down. There would be no true fps as they would always run differently. There's no way of only letting tpt use those cores except going into the task manager and manually setting the core usage of each application. Even then the cores would run at different speeds.
Ive always wanted tpt to use multiple threads but I guess it wont happen until someone figures out how to slow down the other threads to the speed of the slowest which I don't think is poossible to code :( .EDIT: sorry for the necro but there isn't much activity in the forums at this time so it shouldn't harm and the necro was accidental.
