In my game i am using a backbuffer to do the "dirty" job(all the blt-ing stuff)and then i copy the backbuffer into the screen.The backbuffer i use is a DC on an empty(white) bitmap.I am using a map of 4000x4000 pixels and a visible area(game area)of 600x400 pixels.What i do is that i blt the whole map once on the backbuffer when the game starts and all the movements of the characters during the game and finally i copy the portion of the map i want to the screen(game area) so that i have flickerless movement.My problem is that i have to use a bitmap of the same size(4000x4000)with the map which is kind of huge in KB(MB actually).I tried to make a common pallete for all my tiles and the bitmap to reduce its size but the colors get screwed up unless it is in 16 million colors(24 bit).What can i do to reduce the colors of the bitmap?How can i make a DC to a jpg file?Is there any other way to have a backbuffer than this? *I am using Visual Basic 6 to make my game but i don''t mind if you use c++ code in your posts because i can translate it. Thanks

Wouldn''t that make for a really small world? (about 6.6 x 10 screens in size) And why aren''t you just using a tileset and blitting the appropriate tiles to a backbuffer the size of the screen, then blitting that in its entirety? I can''t really see any way to fix your problem so I am just asking why you are doing it this way, as I figure there must be a better way to achieve what you want.

Voodoo4,

I can''t seem to understand that also, normally when people write tile-based games, they group map cells to form a bigger map. By using this approach, you''re saving memory space, like for those repeated tiles, you need only to load a single image. And you gain more control over the map as well, just modify the map file data without redrawing everything on the map. (Can be of ''free size'' also)

It''s always a good idea to draw only the things you can see, for better performance. Oh yes, you can use 16bits colour instead, that saves one extra bytes per pixel (compared to 24bits). And even if you can save the files into JPEG format, the compression is done only to the file size, when you load it into the memory, it still takes up as much space as any bitmap files. (I doubt if anyone at all use JPEG format for their image storage)

As you can see most games around use tile-based extensively, so trust me, your approach isn''t the best one.

Good luck man.

First of all thanks for your answers.
Making map cells was my first option but i wanted to see if using an entire map is faster(the map size i give is only for test purposes,the real world is much much bigger) because i had to cut down my map in many smaller maps (36) and i thought this eats memory.
Anyway Baling ,i think you are right about JPEG images because when decompressed they take up the same size of memory.
Another question:How can i use the same bitmap as a backbuffer for every cell of the map without loosing the information of the other map cells(if you understand what i mean)?
Thanks

quote: Original post by Voodoo4
Making map cells was my first option but i wanted to see if using an entire map is faster(the map size i give is only for test purposes,the real world is much much bigger) because i had to cut down my map in many smaller maps (36) and i thought this eats memory.

I am sure your routine could technically be faster, and look more original, but since a tilebased engine saves memory by repeating sections, whereas your engine has no repeated sections, you are always gonna be needing immense amounts of memory. And when you factor in loading those large images from disk/cd, the performance benefits suddenly don''t seem so great...

quote:
Another question:How can i use the same bitmap as a backbuffer for every cell of the map without loosing the information of the other map cells(if you understand what i mean)?

Sorry, I can''t say I do Want to elaborate?

um, no, technically it couldn''t be faster. you''re blitting the same number of pixels, and tiles can be easier on the cache, not to mention the fact that they can be hardware accelerated.

-goltrpoat

If I understand you correctly, you want to make a surface with you tile-background on it. Then you want to add units, buildings, whatever... Then you blt this surface to the backbuffer, and you repeat that procedure for every tile. Right? I think (i''m not an expert though) you should blt the entire background (every tile) first, and add units when your background is finished. The units should be seperate surfaces. Don''t put anything else on your backgroundsurfaces. The directX7 documentation explains this very well. It can be downloaded at

http://msdn.microsoft.com/directx/downloads.asp

then follow "DirectX 7.0 SDK Documentation, Headers and Libraries"

it''s only about 5MB and it explains VB as well!

quote: Original post by Voodoo4
Another question:How can i use the same bitmap as a backbuffer for every cell of the map without loosing the information of the other map cells(if you understand what i mean)?
Thanks

I don''t get what you mean, but I''ll try to see if I get your point.

OK, by map cells I mean the smallest unit on the map, you might have map of size 60x60, that will end up with 3600 cells all together. OK? So let''s say you want the whole map to be dirt, and for simplicity you don''t mind every cell looks the same. What you do now is, to load a SINGLE image of dirt, and repeatedly draw them out to form your 60x60 map. This should be clear.

And now note that you represent your map by using a 2D array of tile ID, say, iMap[60][60]. So if you want to place a rock at the center of the map, you can simply change one element in that 2D array iMap[30][30] = ID_ROCK; And you load the rock image at the beginning. Now there you go, the rest of the map remains unaffected. See?

Hope I get your point :p

quote: Original post by Anonymous Poster

um, no, technically it couldn''t be faster. you''re blitting the same number of pixels, and tiles can be easier on the cache, not to mention the fact that they can be hardware accelerated.

Drawing a tile will often involve going up and down the target surface''s memory, whereas blitting 1 large bitmap is much more likely to be a linear access, and therefore far more prone to optimization. Example: a 32x32 tile may take 32 memset operations (or the equivalent) to draw it, and each one to a fairly different part of memory. Repeat that a couple of hundred times per screen, and that''s a lot of jumping about in memory, ie. not the best for caching or optimization. Not to mention more function overhead in calling the blit routine numerous times. On the other hand, drawing from 1 big bitmap only needs to move to a new location in memory for every horizontal line, therefore far less moving around and perhaps less cache thrashing. Of course, this may vary according to your hardware and cache size, but I can certainly see how there could be potential benefits from having it in one place.

Actually Baldur''s Gate is said to use one large bitmap. But in playing the demo you''d see that it''s not a large map. Tiling is a better way over all. For the size you want it is. But you''ve worked with one large bitmap, it''s a good tool for the right occasion

But Kylotan''s comment about one Large blit is accurate and useful. What I do is set up a separate surface from the backbuffer just for the current tileset. This is the background tiles that never change except when I want the whole screen to move. I setup the Surface at the start of the game/editing session and each frame I use one large blit to get the background onto the backbuffer and then put the objects on top of iteach frame.

ZoomBoy
See my 2D RPG game with Diary, Character and Tiles editor,
and Photoshop and 3D Art resources at
Check Out my web-site