Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

C++ Freak

Question about Making DirectDraw Game Engine

This topic is 6786 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 am starting to make a game engine that uses DirectDraw. It will be sort of like the BOB game engine but better. It will have more features and will be faster. I was wondering how to load the sprite with bitmap images. The BOB game engine creates a DirectDraw Surface for every picture. I was wondering if this made his engine go slower. I also wanted to if there are any better alternatives to doing this.

Share this post


Link to post
Share on other sites
Advertisement
I don''t know if there is any other way to handle sprites if not to make a surface for each one.
But if you for example have two soldiers that should look exactly the same you ofcourse don''t create one surface for each of them, you can use the same surface and blit from it twice.
One thing that I didn''t like with Andre Lamothes BOB engine
is that he creates one surface for each frame in an animation. I prefer to put all frames in one surfcae and then blit from different parts of it.

HTH.

Share this post


Link to post
Share on other sites
Silly d00dz, you don''t need to have a separate surface for every sprite.. the DD blit function allows you to specify the source rectangle to blit from, so you can have lots of sprites on one big surface and blit from that (I think that''s a more effective way to use video memory). Of course, if you''re going to use D3D for blits, having a separate surface for every sprite (or "texture") might be better.

Share this post


Link to post
Share on other sites
It is actually more beneficial to have miltiple surfaces (dont ask me why).

DD stores each surface side by side anyway, so it doesn''t make it go any slower.

Painless: how the hell do you blit in D3D? all surface management is handeled by diretdraw

MENTAL

Share this post


Link to post
Share on other sites
There are two good alternatives that I know of.

The first is Run Length Encoding(RLE) which is a lot faster for transparency.

The other method is compiled sprites, where you actually write the code for each sprite explicitly. (or write a quick program to output code for you). I have heard that this is faster than DDraw blitting, but it would not work well for a library.

Mike

Share this post


Link to post
Share on other sites
"It is actually more beneficial to have miltiple surfaces (dont ask me why)."

MENTAL, even though you say you don''t know why, I''d still like to say that I don''t think so, unless the surface is really big. The DD surfaces contains other data than just the actual image data, that would mean more data to store the more surfaces you have.



============================
Daniel Netz, Sentinel Design
"I'm not stupid, I'm from Sweden" - Unknown

Share this post


Link to post
Share on other sites
Spiff

I didn''t mean that it saved memory, i meant that DD can access them quicker if there are multiple smaller surfaces.

MENTAL

Share this post


Link to post
Share on other sites
Earlier in this thread, Mike said...
The first is Run Length Encoding(RLE) which is a lot faster for transparency.

Can anyone explain why this is so? Also, what exactly is RLE in terms of storing sprite data?

Thanks,
--
Russ

Share this post


Link to post
Share on other sites
you can''t just say big/small surfaces are more effective, but to generalise, smalLER surfaces are often better. surfaces bigger than the primary surface should be avoided, and ddraw CAN store smaller surfaces more effective. just imagine either one 640x480 surface opposed to two 640x240 surfaces if the user has only space in vidmem for one 640x240 surface. the result is clear.

i would also be interested in how RLE would increase alpha blitting...

Share this post


Link to post
Share on other sites

  • 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!