what else is there besides double buffer???
Author
I'm not sure if this es the right forum, but since is game related, what the heck....
The thing is..., I'm starting win32 game programming, I installed Allegro, and started to do some tests..., everything look great, except for the fact that everything moves slow..., and the more sprites I put in there, the slower everything get..., what's really annoying, is that I'm using a resolution of 640x480 and a color depth of 16bits...
I'm using double buffer to show thing in screen.., but I think there has to be other techniques that improve speed......
By the way, my computer is a AMD K6-2 450Mhz, 128Mb RAM, I now it's not much, but it has to be more than enough to run the game I'm making.....
So, any ideas???
How are you drawing the sprites? Some hardware acceleration through OpenGL could do wonders. IIRC, alegro has OpenGL support (alegroGL?).
1) Write a faster sprite routine, faster screen swap, etc.
2) Use hardware.
3) And for the sake of completeness, you could use 'n' buffers to even the rendering time needed to draw a frame (but forget that).
That said, only 1) and 2) are of interest. On a K6-2@450 depending on your graphic card do not except to draw more than 10 sprites fullscreen with a software renderer at this resolution, that's even maybe a bit of an optimistic estimation.
2) Use hardware.
3) And for the sake of completeness, you could use 'n' buffers to even the rendering time needed to draw a frame (but forget that).
That said, only 1) and 2) are of interest. On a K6-2@450 depending on your graphic card do not except to draw more than 10 sprites fullscreen with a software renderer at this resolution, that's even maybe a bit of an optimistic estimation.
Are you timing when you do everything? If you do everything in the message loop or WM_PAINT Message, your rendering will be based on the speed of your processor and that can be fast or slow. (i know this from rendering spinning and rotating Sphere on my home computer (fast) and then running it on a school computer. The school computer had like a Pentium 1 and the Spheres went incredibly slow(but WITHOUT choppyness)).
Also, if you use GetMessage() to test for Windows Messages your rendering will usually stop when you move the mouse or something else happens.(this only applies if you're rendering with the WM_PAINT message).
Also, if you use GetMessage() to test for Windows Messages your rendering will usually stop when you move the mouse or something else happens.(this only applies if you're rendering with the WM_PAINT message).
Author
nefthy: I'm just using Allegro, don't know if it has or not OpenGL support, I guess I could look into that....
b34r:I could try doing 1 and 2..., but the thing is..., other games like "Starcraft" to name one..., use this same resolution, and they run extremely well on my computer..., I don't think my computer is so slow that 10 sprites will slow it down THAT much....
SumDude: I'm not programming like I would a Win32 application..., I do it like a simple DOS c` program, and then allegro does the rest....
Well, thank you for the answers..., I guess I'll keep looking..., any other ideas???
Thanks!
Haora
b34r:I could try doing 1 and 2..., but the thing is..., other games like "Starcraft" to name one..., use this same resolution, and they run extremely well on my computer..., I don't think my computer is so slow that 10 sprites will slow it down THAT much....
SumDude: I'm not programming like I would a Win32 application..., I do it like a simple DOS c` program, and then allegro does the rest....
Well, thank you for the answers..., I guess I'll keep looking..., any other ideas???
Thanks!
Haora
I don't know Allegro. Could it be running in some kind of compatilibity mode?
What size are those sprites? If they are half the screen large, it's not the same thing as if they were 64x64 :)
Are you using an alpha-blended or alpha-enabled blits, these are slower, but still you should be able to blit 10 small sprites without seeing a hit.
Are you blitting a background?
Are you using vsync?
Is it the DOS version of allegro with a DOS compiler or a windows version?
Just some ideas.
What size are those sprites? If they are half the screen large, it's not the same thing as if they were 64x64 :)
Are you using an alpha-blended or alpha-enabled blits, these are slower, but still you should be able to blit 10 small sprites without seeing a hit.
Are you blitting a background?
Are you using vsync?
Is it the DOS version of allegro with a DOS compiler or a windows version?
Just some ideas.
Author
I'm using a windows versión of Allegro, and what I do is, I use double buffer, to show the background and the sprites (which are 96x96 pixels by the way)...
I have 2 buffers, one the screen, and a temp one..., every frame I:
1) put background into temp buffer
2) draw sprites into temp buffer
3) blit temp buffer into screen...
that's it...
I have 2 buffers, one the screen, and a temp one..., every frame I:
1) put background into temp buffer
2) draw sprites into temp buffer
3) blit temp buffer into screen...
that's it...
You really don't want to lose your double buffer. Doubly so if you're not getting great performance. If you do be prepared for seeing some very...erm...interesting rendering artifacts...
Author
Quote:
You really don't want to lose your double buffer. Doubly so if you're not getting great performance. If you do be prepared for seeing some very...erm...interesting rendering artifacts...
What is that suppose to mean?????
I'm sorry, but my english is not very good...., what are your trying to say???
Haora
Right. Very old games used single buffering. Essentially the gameflow went like this:
Unfortunately because you are drawing directly to the displayed surface, the effect was a horrible flickery mess, as every frame you would see the screen being cleared, if only for a very short time.
The backbuffer solves this by displaying what is essentially the previous frame to the user, whilst the current frame is assembled offscreen, then the offscreen surface is swapped with (or copied onto) the surface currently displayed: all changes are made in one go - so no flickering:
The user never sees the clearing/drawing, because whilst all this is happening they are still viewing the last frame.
Don't know if all that helped or not
Quote:
----> start of loop
> clear screen
> draw Item A
> draw Item B
> do game logic/input/etc
----> goto start of loop
Unfortunately because you are drawing directly to the displayed surface, the effect was a horrible flickery mess, as every frame you would see the screen being cleared, if only for a very short time.
The backbuffer solves this by displaying what is essentially the previous frame to the user, whilst the current frame is assembled offscreen, then the offscreen surface is swapped with (or copied onto) the surface currently displayed: all changes are made in one go - so no flickering:
Quote:
----> start of loop
> clear offscreen target
> draw Item A to offscreen target
> draw Item B to offscreen target
> FLIP offscreen surface with displayed surface
> do game logic/input/etc
----> goto start of loop
The user never sees the clearing/drawing, because whilst all this is happening they are still viewing the last frame.
Don't know if all that helped or not
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
