• Advertisement

Archived

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

Softwareblitting in tile engines?

This topic is 5900 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 thinking about remaking my tile engine in software... Not using the the Direct Draw blitter but only its capabilities of direct vidmem access.. Writing my own blitting routines etc.. implement shadowmaps, particle effects.. the like. Is this a good idea? I want my game to aim for something like P200 mhz. Is it possible to fill a screen (640x480x16) with three layers of tiles and player and NPC graphics, fast enough, by using software blitting routines? I would like to hear your guys opinion about this :-)

Share this post


Link to post
Share on other sites
Advertisement
You can get about 20-25 fps if you fill the screen every update. Then you have to update the critters and play sounds. You could do it using 8 bit colour. Also remember by the time you finish coding there won''t be too many P200s left that are still working. My P166 died last year. It was a sad day.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
A P200 might be a bit slow but still doable. You need to pay very close attention to only updating that which has changed from one frame to the next. If you re-build the entire buffer every frame your performance will suffer badly!

good luck,
hebertjo

Share this post


Link to post
Share on other sites
You probably know this but: do it ALL in system memory, including the back buffer. Then only blit the backbuffer to the primary surface.
And yeah, you really might want to consider 8-bit graphics, especially as you can create cool effects by manipulating the palette.

Greetings,
JonnyQuest (the Tweedledee guy)

Share this post


Link to post
Share on other sites
thanks guys :-)

JohnnyQuest: but I dont like palettes, they''re a pain in you know where.. and yes i know but thanks anyway..
the area I need to focus the most on will probably be fast blitting routines :-)

Share this post


Link to post
Share on other sites
Actually I believe the most important factor in creating a solid software engine is probably figuring out how to do as little blitting as possible. How to update the smallest areas of the screen per frame, how to sort animating objects, scroll the screen single rows of tiles at a time, etc...

Just a thought.
Best of luck,
-m

mat williams
Lead Programmer, Designer
Zero Sum Software
www.zero-sum.com

Share this post


Link to post
Share on other sites
I can see the point in that.. but how do I do it? I mean I can''t scroll one tile a time.. its going to be a multiplayer action game, so I need smooth scrolling. Of course I only need to update the scrolling everytime the player character moves.. animations can be done by only updating the animated tiles.. but then other characters come into play.. my characters are larger than the tiles.. so to implement at dirty rectangle scheme I need to figure which tiles the character passes.. getting complicated :-)

Share this post


Link to post
Share on other sites
the software blitting works great so far.. but my fps drops 10 if I wait for vertical blank (using the WaitForVerticalBlank() function in directdraw).. why is that?.. not waiting is ugly due to tearing

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Hello,

I''m an exceptionally green with c++ but I made a little app that had a 2d scrolling scene that did not use the ddraw function WaitForVerticalBlank()

Like I said I''m real green and I was using Dx7sdk flipping the entire screen, I used some while(1) loop that waited for my drawing routine to finish, the loop checked for a WASSTILLDRAWING DD_ERR

lpDD->Flip(NULL,WAIT); Or something like that...

I''m not sure if this just tells Dx to use the WaitForVerticalBlank() so you can tell me...

I''m also not sure as to what my fps were, sorry.

Hope I didn''t waste too much of your time...

Mike

Share this post


Link to post
Share on other sites
To Mike:
Well obviously you are using hardware pageflipping with directdraw.. which is the best way to go.. the Flip() function waits for vertical blank unless you specify that it should not (using the DDFLIP_NOVSYNC flag).. my problem is that I am not using hardware flipping.. I am copying my backbuffer, which is nothing more than a malloc''ed buffer in sysmem, to the primary surface using a fast assembly routine.. therefore I have to wait for the Vertical blank.. using the WaitForVerticalBlank function.. you won''t have to.. but quit your while(1) loop and specify the DDFLIP_WAIT flag when your calling Flip().. that way the flip function only gives control back to your game when it has finished drawing.. and you do not need to check for the WASSTILLDRAWING error.. furthermore you waste CPU cycles using a while loop :-)

My problem is that I waste 10 frames per second waiting for the vertical blank.. perhaps it is about synchronization? should I rather use the GetVerticalBlank function, which returns a bool.. and about my Render_Screen() function if the screen is refreshing? How would that effect animation? damn.. :-)

Share this post


Link to post
Share on other sites
A while ago I made a tile engine that only updated the one line of tiles the guy was walking onto. For the rest of the screen I''d do a huge copy of
((NUMTILESX)*TILESIZE) by ((NUMTILESY)*TILESIZE).
On top of this there would be a pixel by pixel offset applied for smooth scrolling. If you make the buffer
NUMTILESX*TILESIZE+2 by NUMTILESY*TILESIZE+2,
you only have to add a few tiles per frame (3-4 max) (this depends on tile size... if you''re tiles are very tiny, you''ll have to increase this). I didn''t implement triple-buffering with this, so it might be a problem if you want that. If you''re interested I''ll hunker down and explain it in-depth. I also had to draw any tiles that concealed the players each frame. 4 max for each player. It would be slightly more complicated with lots of particle effects. With all you''re doing, I''m not sure if it would be possible on a 200mhz (my method that is). Mine ran fairly well on a 166mhz, but that was without particle effects, etc. I used Allegro, so you''re blitting routines should be up to speed with that.

Share this post


Link to post
Share on other sites

  • Advertisement