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

Drawing a player on my tiles...

This topic is 6383 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

Seeing as i finally decided to do something in DOS (while I await Visual C++), you may have seen in another post I wanted to make a tile rendering program... I finally did so (it scrolls smoothly too - Sorry, but this is one of my first ever projects, and i''m proud). While that''s all fine, I was interested in adding a foreground bitmap, that moves (i.e a player ). Of course, I have no idea to do this... if i simply blit it, and then redraw the tiles, they ''overwrite'' each other on the screen bitmap, so if i update all the time they just flicker... I''m sure I can use layers... er, or something, but i''d much appreciate how to do this, considering I want this foreground layer (if indeed that''s how you do it) to move around... Cheers all! Nick - Head Designer, -- Visit our website... Games, goodies and ingenuity

Share this post

Link to post
Share on other sites
So you got the colors to come out correctly then? Good. I believe this will work, but it's not a very good solution though (I'm too tired to think ):

1. Draw tiles to a buffer.
2. Draw player (at the correct position of course) to the same buffer.
3. Call vsync().
4. Blit buffer to screen.

That's double buffering by the way.

/. Muzzafarath
Mad House Software

Edited by - Muzzafarath on June 20, 2000 5:05:37 PM

Share this post

Link to post
Share on other sites
Cheers Muzzafarath, you really have helped alot with this, and the pallete issue . This seems to work, for the time being, i can see why too.. cheers
it has a few detrimental affects, but hey, for now, thanks alot !

Nick - Head Designer,

Visit our website...
Games, goodies and ingenuity

Share this post

Link to post
Share on other sites
First of all, you might need to re-work your tile blit system. If you are blitting straight to the screen from your tile/map generator you have limited a few things. If you have ever used or looked into how Direct Draw works, what it has is a series of "surfaces" or in other words "big chunks of memory". Your entire screen should be "compiled" (tiles, sprites, ect.) onto a back buffer that can''t be seen, then when it is done and ready to show the world, you move the backbuffer memory to the screen. Direct Draw fullscreen exclusive mode does this really easily, it simply switches the address of the pointer so that the backbuffer becomes the primary and what used to be the primary (front buffer) becomes the back. It is called buffer flipping.

Anyway, it is just something to think about, in any case. The way you will probably need to draw a sprite on top of a tile is place the sprite inside your tile/map generation function. This has a few problems, first of which is "how do you know which tile the sprite should be blit to?".

The next problem is kind of tricky, especially if you hadn''t created the tile blitter with sprites in mind in the first place (sometimes major re-programming), you need to blit the sprite right after the tile he is standing on has been blitted, then continue blitting the rest of the tiles. This is probably the simplest way, there are others, but they are a lot more complicated, however, this type of blit makes it nice if you have a tile in the foreground which is taller than the tile which the sprite is standing on since it gives depth and makes it look like the sprite is standing "behind" things (like trees, rocks, ect).

The last problem with this type of blit is that, on certain occasions when moving from tile to tile, part of your sprite will be blit over by the tile next to it which causes your sprite to lose an arm, leg, or sometimes a head. For some games, this isn''t a big deal, I have seen it in a few professional games, and in most cases the look is not that detrimental.

Another way you could try it is like it said "much more complicated". This is the way most Sierra adventure games (ie: kings quest, heros quest, ect.) are done. Although they aren''t using a tile based map system, they have unseen maps for things such as: Where the sprite can walk without running into something, which objects are in the foreground so the sprite is blit behind them (or in front depending on his location), ect. This way would probably too complex for a scrolling system.

And last but not least, you could do it the Star Craft way. This way is the easiest by far, but the problem is that the angle in which you are looking at your map has to be an overhead style. If this is the case, just blit the tile/map first then blit your sprites on top. Star Crafts is (of course more complicated than that, but only slightly, they do have a blit order in their map system in case of "raised tiles" such as those with trees and hills, but you could simulate this effect by making trees and such "sprites" also and blit them from back to front so the trees are in front of your sprite when he is behind them, ect. the only problem I see with this is large amounts of data to store locations for trees and such.

Hope that helped, that is a lot of text, I almost wrote a freakin'' book.

Share this post

Link to post
Share on other sites