Simple question(newbie)

Started by
5 comments, last by BlueFrog 22 years, 5 months ago
First, I wanna say hello..I''m a newbie to the game programming world...quite excited. Ok...here''s my question...I''ve written my first particle engine and was curious to know the FPS I was generating...so I set up a simple timer to trigger a call to some function every second that displays the FPS...when I let the code loose..meaning smack everything into a while loop...I get 45-50 FPS...this is using double buffering..blitting a background RGB BMP onto a buffer then using sprite blitting routines to whack the snowflakes as per the particle engine....res of buffer is 640x480x24...finally, I blit the buffer onto the screen...then instead of clearing the buffer....I leave it and next time round the background blit will reset it to the background saving a step.....is this FPS correct? 3D games at higher res gets more...Do they just use seriously complex optimisations and stuff, I''m a bit confused. One more thing....allegro has a rest function...so if I set up the "main loop" to occur as a timer trigger(say trigger 40 times a second) and rest...I get a higher framerate than if I replace the rest by a while 1 loop. Seems the while slows me down. Sorry, one more....There''s allegro, what other kits are there...SDL seems more multi-purpose whereas allegro is for games....I might be wrong..is allegro any good?
Advertisement
One more thing.....when I do a vsync just before the blit to the screen...so I wait for the vertical retrace before I blit to the screen...I get a lower frame rate....sorta from 24-25 to 18 or so....hmmm?
One more thing.....when I do a vsync just before the blit to the screen...so I wait for the vertical retrace before I blit to the screen...I get a lower frame rate....sorta from 24-25 to 18 or so....hmmm?
Ok, let''s see...

1) not clearing the background buffer in allegro is no problem, you don''t have to worry about it because anything you blit to the buffer will simply overdraw the previous content.

2) You bet they spend time optimizibng their code and they use apis like OpenGL or DirectX instead of allegro (allegro is quite nice and I like it a lot, but it''s intended for a DOS environment).

3) Using rest() as a timer won''t work well if you run your binaries on other machines.

4) The vertical sync may slow down you''re app because it makes the system wait for the next retrace before blitting.

I personally recommend DirectX as api although OpenGL is easier to learn if you want to create 3D-apps. Now they don''t have all the nice allegro features (like data-files, image loading routines etc.) but there''re lots of tutorials explaining how to achieve these things using the win32 sdk (almost forgot DirectX works only on windows platforms whereas OpenGL also works on several others).

Well, hope that helped a little.

------------------------------------------------------------
"To a computer, chaos is just another kind of order."
------------------------------------------------------------"To a computer, chaos is just another kind of order."
Thanks for the answers....I''m a Linux guy myself, so unfortunately DirectX is outta the question. I like Allegro as a starting point cause it is targeted at gaming, and is platform independant(well, sorta).

There is SDL, which seems to be more general purpose multimedia, and I guess I just wanted to use allegro as a starting point.

They both(SDL, allegro) can use openGL..but from what I understand...openGL is just a graphics API...and you need to use it with something like allegro, SDL to be able to service the other components of multimedia like CD-ROM, mouse, sound...although I think opengl does do some of it to a point.

Am I on the right track?

Thanks again
You are! I was in a little hurry when I wrote the first answer so I skipped a few less important things. OpenGL is just a GFX api and even worse a 3D GFX api (although you could use it for 2D GFX aswell) but it''s a really good (that''s fast and stable) platform independent api.

Apis like allegro make many things easier (build in GUI, file loaders etc.) so they''re the perfect starting point (I started with allegro and djgpp (gpp MSDOS port) myself) but the drawback is that they do not always provide the best solutions for your problems or they lack features you might need (e.g. you might want to play *.mp3 files in your game but unfortunately allegro can only handle wave files (just an example)) and that''s the point where you either have to find other apis (there''s no reason why you shouldn''t use various apis in one single project [e.g. OpenGL for 3D GFX, Allegro for mouse/keyboard input and bass-lib for sound] except for the additional compilation time) or learn how to do things on your own (e.g. load bitmaps into memory) or at the cost of platform independence use your OS''s api (win32 sdk, glibc etc...).

As before I hope it helps

------------------------------------------------------------
"To a computer, chaos is just another kind of order."
------------------------------------------------------------"To a computer, chaos is just another kind of order."
Yeah...I did some reading...it seems that even though Allegro is a "low level"-ish API, it''s not as low level as SDL(haven''t looked at DirectX, as I''ve said I''m Linux), which seems a better way to go...plus it is true platform independant....and has a closer working relationship with openGL than Allegro....since the whole SDL, openGL API "network" came from the Loki guys.

Also....SDL showcases some impressive games made with it plus of course all the games Loki port use SDL, openGL, openAL, etc.

Some of this is still way over my head...but hey I''m learning.


Thanks again guys

This topic is closed to new replies.

Advertisement