I like It! it's cool!
150 fps too... ( PIV 2.8 Intel graphics integrated 1Go RAM )
Good Work!
Saucer - PB4 Game test
-
lethalpolux
- Enthusiast
- Posts: 171
- Joined: Sun Jun 08, 2003 10:50 pm
- Location: France
- Contact:
amd64 3000 gforce 6600gt 150 fps
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )
Re: Saucer - PB4 Game test
If you went with multi-threading, you'll probably get better results.
Things that would kill your perf on a 2D game:
1) the fillrate. for example, the more you draw, the more you must process. (Have a fallback method, if the FPS' go under XX, start lowering the graphics quality... For example, the particle emmiters, etc).
2) bits per pixel! (same as before, the more colors you use, the more memory you're "wasting"). So if you can, stick with 8bpp (at least on low end systems you'll notice a heuge speed increase, since theres much less data to move, its faster).
Hope that helps. Go with multi-threading, it wont bite!.
Thread 0 (main program thread) .. Have it run at about 10fps, at there you will just check the window's events and minimal things such as that (also check if the window is active, else, fall into a sleepy loop until its active).
Thread 1 : Graphics rendering (no limit on speed here, also set maxfps to 1000 if you want. For keeping things smooth a frame tweening system would do, instead of limiting your framerate -both do a great job though-).
Thread 2 : I/O (20fps would do, but depends on what you need for your game).
Notice: if you're going to pause your game (say you went out of focus and the game went into pause/sleep/idle mode) You will have to pause your threads as well!. Have a struct where you share info among the threads, this will help you.
Usualy you should have a struct with main program data.. This is, window sizes, desktop sizes, window handle, quit variable, thread variables, etc. (quit variable, this is quit=1 then you quit the threads, dont forget it, clean code makes wonders, dont rely on "automatic ending" that PB would give you, if your thread is doing something, chances are it wont quit until its done).
-
About the BPP... This also depends if you're using PNGs with an alpha channel or not ...
Things that would kill your perf on a 2D game:
1) the fillrate. for example, the more you draw, the more you must process. (Have a fallback method, if the FPS' go under XX, start lowering the graphics quality... For example, the particle emmiters, etc).
2) bits per pixel! (same as before, the more colors you use, the more memory you're "wasting"). So if you can, stick with 8bpp (at least on low end systems you'll notice a heuge speed increase, since theres much less data to move, its faster).
Hope that helps. Go with multi-threading, it wont bite!.
Thread 0 (main program thread) .. Have it run at about 10fps, at there you will just check the window's events and minimal things such as that (also check if the window is active, else, fall into a sleepy loop until its active).
Thread 1 : Graphics rendering (no limit on speed here, also set maxfps to 1000 if you want. For keeping things smooth a frame tweening system would do, instead of limiting your framerate -both do a great job though-).
Thread 2 : I/O (20fps would do, but depends on what you need for your game).
Notice: if you're going to pause your game (say you went out of focus and the game went into pause/sleep/idle mode) You will have to pause your threads as well!. Have a struct where you share info among the threads, this will help you.
Usualy you should have a struct with main program data.. This is, window sizes, desktop sizes, window handle, quit variable, thread variables, etc. (quit variable, this is quit=1 then you quit the threads, dont forget it, clean code makes wonders, dont rely on "automatic ending" that PB would give you, if your thread is doing something, chances are it wont quit until its done).
-
About the BPP... This also depends if you're using PNGs with an alpha channel or not ...
Tested your "game" on ancient hardware (seems that you wanted this kind of tests?).
P2Xeon 350mhz | NVvantaXL : 35FPS constant
*gets wet wip out*
One thing I noticed, against the 150fps that I was getting here.. You're not using frame tweening.
*slaps hard*
You're moving based on fixed floating point values! This is wrong!. When designing a game, if you really want to make things work smooth on any framerate, you must move by time / tweening and not by framerate.
*slaps harder and puts the wip away*
Hope you get this nailed for the next release. Its got some fun potential, just take care on the perf here.. dont go too wild until you've got the perf issues solved!.
P2Xeon 350mhz | NVvantaXL : 35FPS constant
*gets wet wip out*
One thing I noticed, against the 150fps that I was getting here.. You're not using frame tweening.
*slaps hard*
You're moving based on fixed floating point values! This is wrong!. When designing a game, if you really want to make things work smooth on any framerate, you must move by time / tweening and not by framerate.
*slaps harder and puts the wip away*
Hope you get this nailed for the next release. Its got some fun potential, just take care on the perf here.. dont go too wild until you've got the perf issues solved!.
Thanks for the constructive suggestions Dagcrack.dagcrack wrote:You're moving based on fixed floating point values! This is wrong!. When designing a game, if you really want to make things work smooth on any framerate, you must move by time / tweening and not by framerate.
*slaps harder and puts the wip away*
Hope you get this nailed for the next release. Its got some fun potential, just take care on the perf here.. dont go too wild until you've got the perf issues solved!.
Got it adjusted to time based movement now, and made some other tweaks. And you are right, better get the basics perfect before moving on. Hope to come with the improvements in a week or so.
-
NoahPhense
- Addict
- Posts: 1999
- Joined: Thu Oct 16, 2003 8:30 pm
- Location: North Florida
Re: Saucer - PB4 Game test
That's tight! ...
-
SoulReaper
- Enthusiast
- Posts: 372
- Joined: Sun Apr 03, 2005 2:14 am
- Location: England
It's mostly the same thing.SoulReaper wrote:can anyone supply a small sample of time / tweening as i am still left wonderering how this can be done to some effect...
any info would be welcome
can it be used in 3d as well as 2d
Regards
Kevin
What you're doing is first of all moving entities or sprites by time means and not by fixed values like 0.01 directly, I believe this is easy to understand, now, it might be harder to implement for some people.
If you move by time, as you know, even though its been said that "time can be stretched" (I believe so, not the case -mostly- so lets not go offtopic here!) - Time is constantly moving and it will move the same here than on your office. Anyway, the time we are refering here is the elapsed milliseconds since your PC booted up. You can go the GetTickCount() way or use your own timer system based on a high res timer.
We'll refer to this as delta-time movement (or delta timing if you want) from now on, just to make things "more clear"...
So, I posted a class and an example here:
http://www.purebasic.fr/english/viewtopic.php?p=136648
I hope it helps.
-
SoulReaper
- Enthusiast
- Posts: 372
- Joined: Sun Apr 03, 2005 2:14 am
- Location: England
