Tile based background in Real-Time Strategy

Java 2D
#1

My real-time strategy runs way slower than it whould for as simple as it is. All I have so far is a scrolling background with 400 tiles. Each tile has a random Image so every map is different. Even if you load a preset game map it has a random tileset to choose images from and a random background soil pattern.

I was wondering if it was better to create 400 Tile objects with an image each or to put 400 Images through a filter that makes one image out of all 400 images and create 1 BitmapSprite with that Image. Right now I am using 400 Tile objects and they run verrrrry slowly on a 333 MHz system. This isn’t a huge problem since the game is intended to be played by hardcore gamers, who will almost always have a 1 GHz or higher processor, I just wanted to see if there was a way to significantly cut processor requirements on the game.

#2

I use a palette of separate images and each map cell points one of them. My MapDisplayExample is using a map with 2500 cells (displaying about 300 of them at a time) and it is very fast.

I am working on a new game where each map (level in this case) contains 28,620 cells and haven’t seen a speed problem. Now understand I’m working on a 1.2Ghz system.

I would like to know what your 333Mhz does with the MapDisplayExample. Please give it a try and let me know how it performs.

http://www.java-gaming.org/cgi-bin/JGOForums/YaBB.cgi?board=share;action=display;num=1036252001;start=15

Check this thread, the first message describes how to run the example and the last a link to the latest code.

Edit: Looking at your post again I’m wondering why if you have a map of 400 tile cells you use 400 different images? Is every cell different in appearance? If not then loading a single image for the map would seem to be more efficient. Perhaps this is because of the random requirement you have. In that case I would still create a single map image (as a VolatileImage from the cell images) and blit that to the screen. That should be a lot faster than making 400 drawImage calls.