Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Author
Message
smerf
19
Years of Service
User Offline
Joined: 24th Feb 2005
Location: nm usa
Posted: 23rd Aug 2017 08:41
Im trying to make a rts game and the current method im using has a large overhead. im taking a 64x64 image and coloring each pixel. brown for dirt, green for grass ect. i load it into dbpro and turn it into a memblock then read the color data from each pixel and each pixel draws a 100 pixel wide texture to the screen.
the problem im having is a 64 pixel map x100 pixels equals 6400x6400 image that i have to past to the screen. would i be better of to split the map into quads and load it based upon the current map scroll position,,,, or tile constantly from a memblock. just wondering how i should go about a large map without sucking my memory dry
A child's dream never dies.





Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 1st Sep 2017 21:24 Edited at: 1st Sep 2017 21:27
I would use a 64x64 table of integers stored as a data file since the pixels only indicate which particular 100x100 tile you want to use. Then you could simply paste the images (or sprites perhaps?) you need to fill the screen at any point in the game.

A simple 16x16 example could be something like:

1111111111110000
1111111111111000
1111111222111110
1111122222211111
1111224442111111
1111222442211111
3311122422111113
3331112221111333
3331111211111133
3311111111111133
3111113133111330
1111133333311300
1111333133333000
1113331113330000
3111111113300000
3333333113330000

in which 0 - 4 represent mountains, grass, water, forest and dirt. I can see you might want to use an image instead - because you can simply paint your map in any Paint style program. In that case, just load your 64x64 image and read the colour values into an array and then use the array when you need to paint the screen. In fact that would probably be my preferred method . You can then define some colour dword variables and use them in a select/case block structure as follows:



Obviously you would need more than this but I hope you get the idea.
smerf
19
Years of Service
User Offline
Joined: 24th Feb 2005
Location: nm usa
Posted: 8th Sep 2017 04:41
thanks for the input green Gandalf. that is essentially what im doing at the moment. I have a 64x64 bitmap of several different colors. at the start of the program outside the loop it reads the image and creates a memblock from it then i simple read the byte data example " if byte1 =034 paste image x,y" then uses a less then or greater then based off a grid to only render what should be within the screen reading and writing the data efficiently is not the problem im having its figure out the method of which to use the image for the background. Should i use a large sprite, small sprites, or paste directly to screen cause i seem to get poor performance with 100- 200 sprites on the screen.
A child's dream never dies.





Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 8th Sep 2017 08:44 Edited at: 8th Sep 2017 09:30
It's hard to say without knowing more information about what you need to do with this background. Ideally you would get it down to as few sprites as possible.
I don't think a 6400x6400 image is a good idea for a sprite. You should check what kind of performance you can get by merely PASTE SPRITE tiling the visible sprites. This could also be made to handle transitions like scrolling the view across the map if you are clever with managing the tiling.

If this type of system is not good enough for performance then I suggest the following:

The fastest method possible: Full Screen Quad with U/V coordinate manipulation.
When loading a map area you will prepare a large texture 6400x6400 of the tiled map. I suggest PASTE SPRITE to one of the non visible BITMAP layers instead of the screen. Follow up with a GET IMAGE command to store it in a texture. Remember to restore the BITMAP settings so you can draw to screen. Then create a screen quad (a 3D Plain object perfectly aligned to the screen). Texture it with your mega texture, and change the U/V coords to make the texture aligned correctly to the screen/map position and to facilitate scrolling capability. Doing it this way might seem like a cheap hack but it has the benefit of only spending 1 draw call. Optimization! It would be the fastest method possible. You could set this up using a Sprite and changing sprite U/V coords but beware these have bugs that can cause them to be reset if another sprite is created elsewhere in the program. Also it's either the Image Kit v2 or Advanced 2D that allows you to paste images onto each other, so you could use them instead of the BITMAP to combine the images into a mega texture. I have not tested 6400x6400 and it might be too big for a Bitmap, so alternate methods are good to know. Or some lengthy, hard to read memblock method.

Look at the big picture metaphorically speaking. What this method does is converts the workload needed per frame (all those numerous tiles to be drawn) into extra work done during the initial loading and extra memory used. So it's really about shifting around your available resources, processing time and memory.

Here's an example of how to setup a proper screen quad, it was originally sourced from one of Evolved's shader demos:


What about the overall design of the game:
Stepping back even further, I think this whole approach limits the practical size of your maps too much. Assuming simple tiling is too slow, you might want to look at how you scroll or transition the map. Something like Zelda: A Link to the Past might be useful where you draw two adjacent screen areas and completely slide transition between the two. This method means you can work with smaller areas, images, and etc and have very large maps. Since right now a 6400x6400 image requirement is excessive. The Zelda method doesn't expand the image size when the overall map is made bigger. The transition effect would give you the opportunity to at that time build a smaller than 6400x6400 image to produce the slide effect and background. Then once the transition was done you could rebuild the texture one more time for just the visible map area. All using the full screen quad method.

Login to post a reply

Server time is: 2024-03-28 14:19:59
Your offset time is: 2024-03-28 14:19:59