Jump to content
  • Advertisement
Sign in to follow this  
haora

what else is there besides double buffer???

This topic is 4833 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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???

Share this post


Link to post
Share on other sites
Advertisement
How are you drawing the sprites? Some hardware acceleration through OpenGL could do wonders. IIRC, alegro has OpenGL support (alegroGL?).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Right. Very old games used single buffering. Essentially the gameflow went like this:

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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!