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

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 :-/

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

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 <teamcolor> since a teamcolor might be 3-5 colors, because of shadows and whatnot.

As for the solution I gave, that and the above solution (yours and pepe's) also suffer from the shadows over color problem

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 <teamcolor> since a teamcolor might be 3-5 colors, because of shadows and whatnot

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.

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?

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.

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 )

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?

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.

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)

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.

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.

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?

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?

You can create sprites with some colors reserved for replacement, and filter them when blitting, but that is very expensive. You certainly want to do that if you want more than a few FPS.Advantage of paletized sprites is that they are a very common hardware feature (so common that i think everyone has it, even under very low configurations)

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org