Archived

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

Prime

Stars for DirectDraw Scrolling Background

Recommended Posts

Hey, I am looking at doing a starfield scrolling (in X and Y directions, approx. 100 stars) background, and I am wondering what the best options are. I have thought of a few ways, but I was hoping for some input as to what might be the most efficent. Some ideas might be: 1. Lock my backbuffer and set a bunch of pixels. 2. Have a star sprite and Blt that a bunch of times. 3. Have a tile with a few stars on it and Blt that a few times. Now, I know locking surfaces is supposed to be slow, but is it slower than Blting a small sprite 100 or so times? And using a tile seems to be a waste since there is so much empty space. Anyway, I''d appreciate any advice. Thanks. Prime.

Share this post


Link to post
Share on other sites
I am no expert but I think a Blit of a single pixel or array of 100 pixels would be much faster than Blitting a square tile (bitmap). Hell, if the tile is 50x50 the your are drawing 250 pixels, imagine doing 50 tiles of 250 pixels.

Go with an array of 100 points and translate them from right to left across the screen.

Share this post


Link to post
Share on other sites
If you want a nice "warp" effect. You can draw lines too. You just have to remember the last postition of the pixel (last frame) and draw a line between them. The really fun part about it is making paralax scrolling stars. The closer ones that move faster have longer lines, so it gives a very nice "warp" effect.

Always remember, you''''re unique. Just like everyone else.

Share this post


Link to post
Share on other sites
If all you do in the app is to plot stars, then i think locking the surface and draw will be the fastest way. If the starfield is just a "background" effect in a game where you use blitting, you should blit the stars too.

Locking the surface is only slow if you lock it several times before flipping. But locking it only once and then plot thousands of stars in a nice short loop, is much faster than using blit.

I believe that most non-accellerated demos use surface locking.

Share this post


Link to post
Share on other sites
Yeah, the scrolling stars are to be the background for my game, which will have a ship flying around, with a bunch of enemies, lasers, etc. So I will be blitting all that stuff. The stars, whether pixels or bitmaps, will be drawn on the backbuffer first before everything else. If I use pixels, I will be locking, then drawing all the stars, unlocking, then blting everything else on top.

Why should I blt the stars when I am blting other things, and use locks and pixels if I''m not?

Prime

Share this post


Link to post
Share on other sites
the simple answer to your query is:

Lock() the back buffer, draw the stars, Unlock() then do your blits IF you dont need the stars too big in size. NEVER read from the vidmem surface unless you want a VERY VERY low framerate. though you dont seem to need to read form the buffer so you ok.

btw, i cant decipher this question at all:
quote:

Why should I blt the stars when I am blting other things, and use locks and pixels if I''m not?



you can blit ir lock() to draw the stars, it dont matter how you are drawing everything else (however, you should group ALL things drawn using a Lock() into a single lock() of the buffer). so this question really makes no sense, unless i am missing what you are try to ask.

the NEST way to determine which is faster is to actully implement each method (should not be too hard), and see which is faster for your needs. because depending on how the stars must look, it may be better to use the tiled approach (for galaxies and such). though you may like the aspect of keep bandwidth down by using single pixel stars. a per star sprtite is probally stupid, mainly because the size of the sprite will have to show enough detail to warrent using a sprite and all the calls to blit. the lock() methdo on the other hand is best of the stars are very small in size (4x4 at for the largest star) since everything goes over the agp bus and you will be accessing the vram in a semi random pattern 9depending on how you oragnize your stars). though the lock() methdo gives the added bonus of being able to easily darken certain stars or have them "twinkle" depending on depth and or just the star. this is because you are actually drawing the pixels yourself and dont rely on having a pre drawn sprite to handle the look of the star.

Share this post


Link to post
Share on other sites
quote:

Why should I blt the stars when I am blting other things, and use locks and pixels if I''m not?


Because when you Lock() your surface, you force the graphics pipeline to be flushed, and all the Blt()''s get done. This totally destroys parallelism between the video cards blitter and the CPU, thus slowing everything down.

quote:

I am no expert but I think a Blit of a single pixel or array of 100 pixels would be much faster than Blitting a square tile (bitmap). Hell, if the tile is 50x50 the your are drawing 250 pixels, imagine doing 50 tiles of 250 pixels.


Not really; the blitter is much faster, and runs in parallel with the CPU, so drawing 50 tiles of 250 pixels may be faster that 100 blits of 1 pixel.

I''m sure this isn''t what you want to hear, but you''d be best using D3D, then you can just draw 100 points using D3DPT_POINTLIST, and you can do all kinds of other funky effects that you can''t do in 2D with DDraw.

You might be fastest with an offscreen surface the size of your backbuffer, and Lock()ing that to draw 100 pixels, and then blitting that surface to the backbuffer. This way you wouldn''t need to clear your backbuffer either, since you''d just overwrite what was there last frame with the start of the new frame.

To be safest, you should try all of the above (it shouldn''t take long at all, they''re all very similar), and profile.

HTH, Steve

Share this post


Link to post
Share on other sites
Just in case anyone is interested, I tried my little background in two ways. First, I did the pixel approach. I had an array of 120 points, and each frame I Blt filled the backbuffer to clear it and then locked it. I looped through all my points, setting the appropriate pixels, and then unlocked. This proved to be pretty fast, even on my non-3D accelerated card (my old Voodoo3 died).

Then, I took those same points and used them to plot a star sprite that was 3x3 pixels. This time, of course, not locking the buffer, but still Blting to clear it first. This turned out to be slightly slower. I was using GetTickCount(), which I suppose isn''t particilarly accurate, to determine how much time each method took.

It appears that either method (and I''m sure the others mentioned as well) is easily fast enough for what I am doing. So for me it comes down to which looks better. Now that''s the kind of problem I like to have Anyways, thanks for all your responses and insights, you guys have been really helpful.

P.S. Sorry about the wording of my "Why should I Blt the stars when I''m blting other things, and use locks and pixels when I''m not?" question. I guess that''s what happens when I think out loud. Sometimes me speaks sweet English...

Share this post


Link to post
Share on other sites
Just a suggestion-

Whichever method you use, just create a seperate surface for the background at the beggining and blit the entire thing as one piece each loop, so you minimize blit calls. You could keep the surfacerlatively small, say twice the size of the screen, scrool it durring the game, and tile it at an edge.

Share this post


Link to post
Share on other sites