best way to have team colouring in an RTS

Java 2D
#1

ok,

us peeps working on the JOSRTS project have come across a rather contentious issue, and, me having the out-voiced opinion thought getting the opinions of some of you peeps would be a good idea ;D

The issue, is how the depiction of different teams/armies/factions should be implemented in an RTS game.

By this, I mean how should the clothing of each side be coloured.

The 3 methods so far are :-

  1. create a copy of every single game sprite for use by each player, (colorizing appropriately to depict the teams color)

  2. each player has their own set of masks (1 for each frame of each sprite) the colorless sprite is drawn, thent he player specific mask is drawn over it. (basically draw the sprite, then drawing the clothing)

  3. use an indexed color model for the sprite images, and give each player a different palette. (the palette being altered slightly so it reflects the color of the team)

im in favour of approach 3, but no-one else seems to be ???
my only conclusion… they’re all mad :-/

what do you all think?

abu,

#2

If the sprites are 2d images,for me, and if indexed palette is hardware supported, that would be the better solution.

  • It does not require to double the bandwidth for blitting
  • Any color can be represented immediatly
  • You are not limited in the number of teams or number of sprites because of memory use. (that can be a very sensitive problem if you use volatile images, and you certainly will. imagine having one hundred sprites and four teams… )
  • Uses way less RAM and storage

my two cents

#3

Option 1 please :slight_smile:

Generate all sprites with a red color - then at runtime generate other sprites by repainting onto a new sprite with a new color used for the old red color.

One thing to note though - if the sprite has shifting shadows over its teamcolor you might be in for a bit of work - and in that case I would render them ahead of time.

You want to use as little of your cpu time as possible, since the game itself will be busy enough - in this case I’d rather use memory than cpu.

#4

As for the solution I gave, that and the above solution (yours and pepe’s) also suffer from the shadows over color problem - you can’t just substitute 0xff0000 with since a teamcolor might be 3-5 colors, because of shadows and whatnot.

#5

how many units are there per team and how many teams can be playing at any given time?

You’d probably be looking at ~ 1.5-2.0 MB of v/ram per team

#6

[quote]As for the solution I gave, that and the above solution (yours and pepe’s) also suffer from the shadows over color problem
[/quote]
Huh??
Having the clothing using many tones of same color is absolutly no problem in paletized sprites. It’s even the easiest (and fastest provided that it is hardware accelerated) method for such things.

[quote]you can’t just substitute 0xff0000 with since a teamcolor might be 3-5 colors, because of shadows and whatnot
[/quote]
Seems that you have some misunderstanding on the paletized sprites subject.
paletized sprites are memory zones where pixels are indices in a color table. the sprite is attached to its palette, and representation is dependent of it. change the palette, and your sprite changes its colors, immediatly and without any cpu use.(when accelerated)
That was (and is certainly still ) very used on old machines and consoles that had no truecolor modes.
Thus, changing the team of the sprite is only 1 move by color.
Do you have any inexpensive method, in any domain? I don’t and there aren’t.

#7

Wouldn’t you still have to have X number of copies of the image in memory with the palette method? I will preface this by saying that I know close to absolutely nothing about palette-based images, but if you’re painting for example units of three different teams on the screen at a given frame, could you use the same image in memory of the infantry units of all the different teams? I mean, if the palette were changed, wouldn’t it be changed for all units with that image, regardless of team?

#8

No, the operation would be to change the palette, blit, change the palette, blit, change the palette, blit, change the palette, blit, … until everything is drawn.
Normally, the video card should know how to blit paletized sprite onto a truecolor image without having to create a duplicate truecolor image.
This, with the fact that a 8 bits sprite takes 4 times less memory than a truecolor one makes lots of good points for paletized sprites.
Bad point is that paletized sprites have no alpha channel. At least i’ve seen no paletized system taking care of it… maybe it works, because, in fact, it is possible when blitting over truecolor.

#9

Moreover, if the sprites don’t have colour animations, and only changing clothing color, that is only changing the reference to backstored palette, so only one move.
Can’t be faster and easier.

#10

Knowing if this accelerated, is an other problem.
I’ve insisted that it has benefit only if the video card can do it itself. The reason is that blitting a paletized sprite is more costy than blitting a truecolor image. (you have to read the pixel color value (shifting, masking involved for 8 bits sprites), then copy to the screen the value at the index of the palette given by the pixel value. Makes way more operations than just copying a value to an other place. A graphic card can have that operation wired so it would cost nothing, but doing this by hand is something totally different)
Only a guy from the java2d team can give us insight on those operations. ( hint hint ;))

#11

It’s got to be indexed palette every time. Don’t worry about the speed of palette lookups; you’ll find that it fits in the L1 cache and is lightning fast to blit from 8->16/24 bits.

Besides if you use LWJGL then practically every 3D card available does this for you in hardware with EXT_paletted_texture.

Cas :slight_smile:

#12

Hmm - Yeah you’re right - never did any paletized sprites in Java…
How does one use paletized sprites in Java using volatile images?

#13

It’s a trick involving smoke and mirrors.

Cas :slight_smile:

#14

ohh bugger then - I quit smoking some years ago - no palette for me then :-/

#15

Maybe you can start by creating a proper TYPE_BYTE_INDEXED BufferedImage.
Until Trembovetski drops a word about acceleration in this field, the only thing that can be done is a little benchmark.
Anyone? ;D

#16

[quote] Bad point is that paletized sprites have no alpha channel. At least i’ve seen no paletized system taking care of it… maybe it works, because, in fact, it is possible when blitting over truecolor.
[/quote]
Okay, corercting myself. the IndexColorModel gives you the possibility to specify RGBA values for each index. Thus, you can have paletized sprites and transparencies, shadow on ground, or fading effects. ( really not sure it will be accelerated, then)

#17

Went to the josrts.org pages and saw that you will be using LWJGL as opengl binding. The topic and forum section misguided me, as i thought you were about to do that under java2D.
If so, you don’t have to bother with all that paletized stuff.
The mappings of the clothes would have to be black and white, and mapped over the character polygon using a second polygon. You can change and finetune the colorization of the clothes very easily by changing the color of the polygon. (or two stage pipelines)
I did that kind of trick under java3D to colorize my lanscape, and it works very well.
That will eat fillrate, but unless you have hundred characters you should not notice any slowdown under even the lowest configuration.

#18

You can use the above approach with GL.COLOR_MATERIAL and do it in a single pass to save precious fill-rate ;D

#19

We accomplish the effect by creating our own filter that prerenders the images with a colorfilter that looks for any color that is dominately blue (or index color). Then we filter that color to that the team color (keeping shading values intact). We recreate the new image and we gain hardware accleration. In most cased for our game the opponent would have different units anyway, because they would be a different race so we lose nothing if this is the case. If they are the same race then we would benefit (memory wise) by using the color palette.

I also see problems with people who already have their sprite art created. They might find it difficult to come up with a normalized palette for all of their sprites. I guess each sprite could have its own palette but my experience with using color palettes is limited at this time. I’ll play around with it and test things out and report back on speed changes and memory improvements.

#20

is there any way to do palette type operations in 24bit? i.e. not using a 256 color image with a palette but making something yourself that can work. I’ve never seen an example and what ive read it doesnt seem possible?