Jump to content

  • Log In with Google      Sign In   
  • Create Account

direct draw


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
10 replies to this topic

#1 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 18 October 1999 - 05:58 AM

hello, I am planning to make a scrolling platform game for the computer.. but I can't figure out how other games like Jazz Jackrabbit are so fast. If anyone could give me some tips for maximum speed out of direct draw I would really appreciate it.

Sponsor:

#2 Splat   Members   -  Reputation: 122

Like
Likes
Like

Posted 11 October 1999 - 01:09 PM

I think what might help you the most, assuming you are proficient at C++, would be a book like "Windows Game Programming for Dummies". Not that you are a dummy but this book takes the sting out of reading the MSDN DirectX docs (which is what I did) and will also help you with more than just DirectDraw. I believe by the end of the book you have completed a small game engine.

However, if you need to learn C++ as well, you might want to settle for a slightly (read: much) less advanced project than a game. The scope of a game is quite large by the time you are complete.

But, to answer your question more directly, I think once you actually make a simple game loop, you will realize that it's fast enough without ANY need for optimization.

Also, if I'm completely underestimating your experience feel free to take a jab hehe


#3 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 14 October 1999 - 06:05 PM

thanks for your reply. I do know how to make a game. I've been making 68k assembly games for the ti89 but that became boring. anyways, I know all about optimizing software routines, but directx uses hardware. even when I write 32bit assembly code it's not faster than the hardware. so I'm trying to figure out if I should do everything in system memory onto a sytem memory buffer and then copy that to the back buffer in video mem before I flip the pages if there is some tricks to faster techniques
I'm probably not making any sense because I'm rambling on and on...

#4 Splat   Members   -  Reputation: 122

Like
Likes
Like

Posted 15 October 1999 - 12:55 PM

Actually, after a second read your response made perfect sense! You definately have to keep in mind that hardware operations are going to be MUCH faster in most cases that CPU operations because of proximity to the actually video memory. However, there are a few considerations you must keep in mind. Basically, video->video blits are the fastest, then comes system->system blits, and last comes system->video blits (leaving out AGP stuff). So basically, if your game wants to display 1,000 different sprites, you have two options:

1) Leave the sprites in system memory, use a backbuffer in system memory, create your frame, then with one mighty blit copy it to the video card's backbuffer and Flip(). This is ideal when you can't/won't place your sprites in video memory.

2) Put your sprites in video memory, use the hardware blitter to blit to the video backbuffer, then Flip()

All of this makes little difference however if you are blitting maybe 30-50 times a frame. Or if you have a P2 350+!

Also, large blitting counts may make you want to simply Lock() the backbuffer and memcpy() or use a custom software blitter to copy the data in. This is because every blit in DirectX requires a Lock()/Unlock() sequence (hidden to the programmer) that locks the memory completely using a Win16 mutex (i believe).

Anyway, have fun with that. I hope I was helpful. This week has kinda been my introduction to programming forums, so my teaching skills may not be up to par yet.

- Splat


#5 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 15 October 1999 - 06:52 PM

thanks, that helps. I was thinking that I could check the amount of video memory the user has and if he doesn't have enough I can set a flag that activates software blitting throughout the game. Also, when I blit large surfaces that are in vram it's a lot faster than blitting smaller areas. I need to draw tiled map data onto the screen. 32x32 pixels per tile. You mentioned locking the surfaces before doing the blits but I don't think that would work in video memory because memcpy would probably pull data from vram into a register on the cpu and then send it back down to vram, wouldn't it?

#6 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 15 October 1999 - 07:59 PM


Sorry to interrupt, but what do you suggest about this?

I have a lot a bitmaps to blit to the screen. All available
video memory is filled up with bitmaps (the ones that are most used),
and the remaining bitmaps are created in system memory.

So I got both kinds.

I don't keep track of what bitmaps are in video and what are in system.
(Hmmm...maybe I should?)

And I have one flippable back buffer and one primary surface.
(I would think that these two are both video memory by default, but I
do nothing to specific it when creating them).

Right now, I blit everything (both video and system bitmaps) to the
flippable back buffer and then flip it, so nothing out of the ordinary.

Would you suggest I create an additional back buffer, however, this
one will be specified as system memory? And try to separate the
blits according to video (bitmap)->video (buffer), and
system (bitmap)->system (buffer)?

I don't know if this would be faster, since I would have to do an
additional blitting of this new system memory back buffer to the
flippable back buffer (video).

Does this makes sense?


#7 CGameProgrammer   Members   -  Reputation: 640

Like
Likes
Like

Posted 15 October 1999 - 08:16 PM

One common mistake people make is in thinking that if they're using DirectDraw, every image must be a DirectDraw surface. If you're simply going to Lock/Unlock your sprite's surface to read/write it, why use the surface at all? Surfaces are only useful for primary/buffer surfaces, or if you're planning to use DirectDraw functions like Blt. Otherwise, simply store a string array of the bits of your sprite. This way you'll never have to lock or unlock it.

------------------
~CGameProgrammer( );


#8 Niels   Members   -  Reputation: 122

Like
Likes
Like

Posted 16 October 1999 - 04:31 AM

Dead on!!

That's how I do alpha blending - since DD doesn't support Alpha channels, all my gfx is stored in a proprietary format, and then copied to the backbuffer (Except for a few things that I use "blit" for)

/Niels


#9 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 16 October 1999 - 06:25 PM

So let me get this straight... I should keep my bitmap data in system memory, not on a surface. and then use my own code to blit them onto other system mem surfaces. then when I'm done rendering my surface, I lock the back buffer and copy my system buffer to the back buffer. Does locking and unlocking take a long time? also, when I try to read bitmaps in they are sometimes twisted and distorted when I try to display them, depending on their dimensions. I need to know why that is also if I must manually read in bitmaps.
thanks,
matt t

#10 Facehat   Members   -  Reputation: 696

Like
Likes
Like

Posted 17 October 1999 - 06:03 AM

Whether you use DirectDraw's blitter or your own depends on your needs. If you need to use alpha blending and other special effects you might store your stuff in your own block of memory and write your own blitter. But if you don't need fancy special effects then youll probably want to save your image in a surface and use DirectDraw's blitter (which is hardware accelerated).

Of course, another idea is to use Direct3D in a 2d game so that you have access to the users 3D hardware and therefore have access to a whole bunch of neat features. Of course this probably isn't the best approach if your just learning directdraw.

--TheGoop


#11 mhkrause   Members   -  Reputation: 122

Like
Likes
Like

Posted 18 October 1999 - 05:58 AM

The only real reason to store a sprite in a video memory surface is to take advantage of hardware-accelerated VidMem-VidMem blts.

Reading from video memory is a very bad idea, it is incredibly slow.

Writing to video memory is a bad idea also, it is incredibly slow (though not as slow as reading.)

If you want to write, read, and modify a sprite, and at the same time use blt, then you should use a system memory surface.

If you don't want to use blt, and just read or modify, then you should just use your own system memory buffer to avoid the lock()/Unlock() penatlies. If your hardware accelerates sysmem-vidmem blts (doubtful) you may want to then lock and copy into a system memory surface, then blt, otherwise lock the back buffer and copy your data in.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS