Dynamic team colors

[i-NoD]

Dynamic team coloring (using mask).

Usage:

• Every pie file that wants to use the new team coloring have to update its pieflag with 0x10000 value (sample: TYPE 10200), there is no need in 'anidata' structure for new tc style. Just set the pieflag correctly and make a new tcmask.

All standard pies will be rendered using old method without any changes.

• There should be a mask file (base texture variant, where opaque area designates team coloration and completely(!) translucent area is not altered) in a corresponding 'vidmem*.wrf' file. Mask filename should begin with the same page-X pattern as in pie TEXTURE field (sample: file TCMASK "page-16_tcmask.png").

• Base texture should be gray (decimal 128+-64) where team coloring would occur. This feature was designed in the way that you could take 3-rd old team coloration frame (which is gray) from the base texture of every current unit and get all other frames automatically.

There is sample global TCMask.wz mod: a factory, a lab from elio's mod and all wheeled, tracked and half-tracked propulsions were hastily converted to the new tc rendered. Plus a high-poly truck by Orlox.

Todo:

• Team masks should be loaded dynamically for every TEXPAGE so a .wrf system will be simplified. I guess a TEXPAGE resources itself could be loaded dynamically when an IMD object is loaded - less conflicting mods in the long run.

[i-NoD]

Renderer is depends on loader :)

[Per]

I suppose the merging of REND_GOURAUD_TEX and REND_FLAT into REND_SIMPLE is merely a cosmetic change?

I guess the team colours should be defined in lib/ivis_opengl/piepalette.c

Why did you put the mask in a separate texpage? It will cause more texture swapping on the GPU, since we load and bind them as they are defined on the disk. Not sure if this is a relevant concern here, though.

[i-NoD]

Replying to Per:

I suppose the merging of REND_GOURAUD_TEX and REND_FLAT into REND_SIMPLE is merely a cosmetic change?

True. As i wrote there is no meaning now in REND_MODE enums and should be converted to BLEND_MODE. While REND_GOURAUD_TEX and REND_FLAT were different by nature in 1.xx they are now simply turn off the blending.

I guess the team colours should be defined in lib/ivis_opengl/piepalette.c

Can do for predefined colors. So how about true dynamics - a user selectable colors?

Why did you put the mask in a separate texpage? It will cause more texture swapping on the GPU, since we load and bind them as they are defined on the disk. Not sure if this is a relevant concern here, though.

I'm not sure if understood your question. Separated from what? Are you referring to the TCMASK or some other thing?

[Per]

The team colour mask for a texture is in a different file than the texture itself, right? Or did I misunderstand something?

I do not think user defined colours is a good idea. Can't think of any games that do it this way. The selected colours too easily end up being too similar (which can also be a way to cheat).

[i-NoD]

Replying to Per:

The team colour mask for a texture is in a different file than the texture itself, right? Or did I misunderstand something?

Yes, it's a different file. Umm, do you have any other ideas on how to specify the mask?

I do not think user defined colours is a good idea. Can't think of any games that do it this way. The selected colours too easily end up being too similar (which can also be a way to cheat).

Let it be in that way for now. It's not hard to implement it later if need be.

[Zarel]

I still think the best implementation is to just designate a group of colors as "team colors" (e.g. light pink, darker pink, darker pink), and have them replaced with the corresponding color for each team.

This would eliminate the need for a mask entirely.

[i-NoD]

Possible, but then there will up to 8 different copies of every masked texture in gfx memory, while my method gives 2x coefficient. I remember similar technique like you'd described from the very first C&C and it have a serious limitation: without a mask you cant use selected color region(there should be some color range or how you will get gradation in team coloring?) for anything other that team coloring on WHOLE texpage.

[Zarel]

? If you're not caching the 8 copies in the first place (which you should be; performance is important), you can just convert my single-texture into a texture and a mask, for an identical effect on memory.

It's right that you can't use the selected color region, but it should be narrow enough that you can just use a color right next to it (say #FFFF00 is in the color region; you just use #FFFE00 instead).

Remember, color space is three dimensional; the selected color region should only be one-dimensional (or two-dimensional at most). You only have to move one unnoticeable step in a different dimension to leave the color space. Especially if the color is bright pink, a color that otherwise shouldn't appear in Warzone textures very often, anyway.

I suggest this mainly because having a single texture with a designated "team color" is a lot easier on texturers than having a base texture and a mask.

[Per]

Zarel, that is a horrible hack. It is much less flexible and I really doubt that artists want it.

[Zarel]

Really? As mentioned earlier, it's the way Wesnoth does it, and it does make it easier on the texturer.

[Zarel]

The flexibility isn't that much worse. It would also take half as much space, and as an artist, I'd say it'd be a lot easier to work with.

Think about if you need to change a texture. You'd have to edit both the texture and the mask, while with my system, you'd just need to edit the texture.

[Zarel]

I remember changing my mind about this. There's really no longer any disagreement about this.

[Per]

See ​http://forums.wz2100.net/viewtopic.php?f=33&t=2156 for more discussion about this feature.

[i-NoD]

Attached shader preview for TCMask.

[Per]

I think you forgot to add the shader files.

[i-NoD]

Here is a trunk-based ​Shadered-TCMask snapshot for Windows. Disclaimer: built on a Windows machine, so as popular belief on this project says it will burn your hard drive and monitor for sure.

[Zarel]

...what are we using shaders for? Didn't the old version work just fine without shaders?

[i-NoD]

Shader version (part 2)

[i-NoD]

Shader version (part 1)

[i-NoD]

• Cleaned-up shader functions.

• Teamcolors are now inside external palette.txt file

• Updated shader to match "Grain merge" function and mix with vertex color (burn-down simulation)

...what are we using shaders for? Didn't the old version work just fine without shaders?

The main problem with non-shader version: it's too limited in color range, either there will be no black units or much less details on colored texture area. Plus shaders will give much more in future...

[Buginator]

You forgot to add shaders/test.frag and shaders/tcmask.frag

I also see that you make it so openGL 2.0 is required. (Not that I have a problem with this.)

[i-NoD]

Shaders are included within TCMask.wz.

OpenGL 2.0 it is. Should be available on any modern (2005-20XX) gpu. There is a more detailed description from NVidia (​http://developer.nvidia.com/object/nv_ogl2_support.html).

Any earlier OpenGL version is too vendor specific to support. And there is OpenGL 3.2 already at the door...

[i-NoD]

Guys, I think its time to start review/commit process for this feature. The mask texture loading code is stable for a long time, so it will be the first part. I'll post details on shaders/FF part and detailed instructions for modders later today.

[i-NoD]

Shadered TCMask sample mod

[i-NoD]

Here goes a small description:

• A small shaders infrastructure based on Per's sample (based on OpenGL 2.0 specs). All shaders are hardcoded, so you can't add much without modifying source code. If a single shader fails to load/compile/link or there is no OGL 2.0 then all shaders are off and you shouldn't use them. You can check pie_GetShadersStatus for status... and fallback to FF routines if its the case...

• Shaders(provided that they were successfully loaded) and lighting can be dynamically toggled on debug option form. lighting routine is no longer dependent from shadows status. This will allow to test specular/bump mapping during development, without forcing lighting on.

• There is shadered and non-shader version for TCMask. FF version requires OGl 1.4 to run. I think we can hard-limit trunk with this level. FF version can be ported to 2.3/2.4 as optional feature, without forcing OGL level, and if there is OGL < 1.4 some weird but working TCMask can be emulated on such old gfx.. although, I'm not sure if this is needed.

[Per]

You should remove my test shader before merging.

[cybersphinx]

Replying to i-NoD:

OpenGL 2.0 it is. Should be available on any modern (2005-20XX) gpu.

On Linux, it's also a driver problem, the open source Ati drivers support only OpenGL 1.5 (and I don't think support for 2.0 will hit mainstream this year). But as long as there's a fallback that runs on the open drivers, I have no objections.

[i-NoD]

This supposed to be a commit patch, built both on MSVC and MinGW and verified to work on Radeon Mobility HD4650.

[i-NoD]

Replying to cybersphinx:

On Linux, it's also a driver problem, the open source Ati drivers support only OpenGL 1.5 (and I don't think support for 2.0 will hit mainstream this year). But as long as there's a fallback that runs on the open drivers, I have no objections.

Sometime ago I read somewhere that there are OpenGL 2.0 drivers for ATi on Linux. Well, it was ​there, but I didn't notice it was only a few months back, so could someone check the patch on Linux? just in case...

[cybersphinx]

Replying to i-NoD:

Sometime ago I read somewhere that there are OpenGL 2.0 drivers for ATi on Linux. Well, it was ​there, but I didn't notice it was only a few months back, so could someone check the patch on Linux? just in case...

It's still work in progress, not sure about r600+, but r500- supports 1.5 in current, 1.4 in older Mesa releases.

I've tried the shaders branch on Linux, that works ok.

[i-NoD]

Shaders/TCMask has been committed in [10178] and [10179]. This ticket will stay open for sometime, so I could check for possible bug reports. Feel free to fill ones... :)

[dak180]

[10179] adds the following warnings to the mac build:

CompileC build/Warzone.build/Release/Warzone.build/Objects-normal/i386/piestate-490252108B551643.o ../lib/ivis_opengl/piestate.c normal i386 c com.apple.compilers.gcc.4_0
cd /Users/dak180/Applications/Build/wz2100/trunk/macosx
setenv LANG en_US.US-ASCII
/Developer/usr/bin/gcc-4.0 -x c -arch i386 -fmessage-length=0 -pipe -std=gnu99 -Wno-trigraphs -fpascal-strings -fasm-blocks -O2 -mdynamic-no-pic -Wmissing-field-initializers -Wreturn-type -Wunused-function -Wunused-label -Wunused-variable -Wunused-value -DVORBIS_NEEDS_HACK -D__MACOSX__ -isysroot /Developer/SDKs/MacOSX10.4u.sdk -ftree-vectorize -fvisibility=hidden -mmacosx-version-min=10.4 -I/Users/dak180/Applications/Build/wz2100/trunk/macosx/build/Warzone.build/Release/Warzone.build/Warzone.hmap -Wall -Wno-unused-label -Wno-format-security -Wno-strict-aliasing -Wmissing-field-initializers -Wcast-align -Wwrite-strings -Wpointer-arith -F/Users/dak180/Applications/Build/wz2100/trunk/macosx/build/Release -F/Users/dak180/Applications/Build/wz2100/trunk/macosx/external/SDL -F/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks -F/Users/dak180/Applications/Build/wz2100/trunk/macosx/build/Release -F/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks -F/Users/dak180/Applications/Build/wz2100/trunk/macosx/external/SDL -I/Users/dak180/Applications/Build/wz2100/trunk/macosx/build/Release/include -I.. -I/Users/dak180/Applications/Build/wz2100/trunk/macosx/external/SDL/SDL.framework/Headers -I/Users/dak180/Applications/Build/wz2100/trunk/macosx/build/Warzone.build/Release/Warzone.build/DerivedSources/i386 -I/Users/dak180/Applications/Build/wz2100/trunk/macosx/build/Warzone.build/Release/Warzone.build/DerivedSources -Wno-pointer-to-int-cast -Wmissing-declarations -Wstrict-prototypes -Wdeclaration-after-statement -c /Users/dak180/Applications/Build/wz2100/trunk/macosx/../lib/ivis_opengl/piestate.c -o /Users/dak180/Applications/Build/wz2100/trunk/macosx/build/Warzone.build/Release/Warzone.build/Objects-normal/i386/piestate-490252108B551643.o

/Users/dak180/Applications/Build/wz2100/trunk/macosx/../lib/ivis_opengl/piestate.c: In function 'printShaderInfoLog':
/Users/dak180/Applications/Build/wz2100/trunk/macosx/../lib/ivis_opengl/piestate.c:83: warning: passing argument 3 of 'glGetShaderiv' from incompatible pointer type
/Users/dak180/Applications/Build/wz2100/trunk/macosx/../lib/ivis_opengl/piestate.c:89: warning: passing argument 3 of 'glGetShaderInfoLog' from incompatible pointer type
/Users/dak180/Applications/Build/wz2100/trunk/macosx/../lib/ivis_opengl/piestate.c: In function 'printProgramInfoLog':
/Users/dak180/Applications/Build/wz2100/trunk/macosx/../lib/ivis_opengl/piestate.c:100: warning: passing argument 3 of 'glGetProgramiv' from incompatible pointer type
/Users/dak180/Applications/Build/wz2100/trunk/macosx/../lib/ivis_opengl/piestate.c:106: warning: passing argument 3 of 'glGetProgramInfoLog' from incompatible pointer type

CompileC build/Warzone.build/Release/Warzone.build/Objects-normal/i386/screen.o ../lib/ivis_opengl/screen.c normal i386 c com.apple.compilers.gcc.4_0
cd /Users/dak180/Applications/Build/wz2100/trunk/macosx
setenv LANG en_US.US-ASCII
/Developer/usr/bin/gcc-4.0 -x c -arch i386 -fmessage-length=0 -pipe -std=gnu99 -Wno-trigraphs -fpascal-strings -fasm-blocks -O2 -mdynamic-no-pic -Wmissing-field-initializers -Wreturn-type -Wunused-function -Wunused-label -Wunused-variable -Wunused-value -DVORBIS_NEEDS_HACK -D__MACOSX__ -isysroot /Developer/SDKs/MacOSX10.4u.sdk -ftree-vectorize -fvisibility=hidden -mmacosx-version-min=10.4 -I/Users/dak180/Applications/Build/wz2100/trunk/macosx/build/Warzone.build/Release/Warzone.build/Warzone.hmap -Wall -Wno-unused-label -Wno-format-security -Wno-strict-aliasing -Wmissing-field-initializers -Wcast-align -Wwrite-strings -Wpointer-arith -F/Users/dak180/Applications/Build/wz2100/trunk/macosx/build/Release -F/Users/dak180/Applications/Build/wz2100/trunk/macosx/external/SDL -F/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks -F/Users/dak180/Applications/Build/wz2100/trunk/macosx/build/Release -F/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks -F/Users/dak180/Applications/Build/wz2100/trunk/macosx/external/SDL -I/Users/dak180/Applications/Build/wz2100/trunk/macosx/build/Release/include -I.. -I/Users/dak180/Applications/Build/wz2100/trunk/macosx/external/SDL/SDL.framework/Headers -I/Users/dak180/Applications/Build/wz2100/trunk/macosx/build/Warzone.build/Release/Warzone.build/DerivedSources/i386 -I/Users/dak180/Applications/Build/wz2100/trunk/macosx/build/Warzone.build/Release/Warzone.build/DerivedSources -Wno-pointer-to-int-cast -Wmissing-declarations -Wstrict-prototypes -Wdeclaration-after-statement -c /Users/dak180/Applications/Build/wz2100/trunk/macosx/../lib/ivis_opengl/screen.c -o /Users/dak180/Applications/Build/wz2100/trunk/macosx/build/Warzone.build/Release/Warzone.build/Objects-normal/i386/screen.o

/Users/dak180/Applications/Build/wz2100/trunk/macosx/../lib/ivis_opengl/screen.c: In function 'screenInitialise':
/Users/dak180/Applications/Build/wz2100/trunk/macosx/../lib/ivis_opengl/screen.c:202: warning: format '%d' expects type 'int', but argument 4 has type 'GLint'
/Users/dak180/Applications/Build/wz2100/trunk/macosx/../lib/ivis_opengl/screen.c:243: warning: format '%d' expects type 'int', but argument 4 has type 'GLint'

[i-NoD]

Has been fixed. I hope for...

[dak180]

2 more warnings left:

CompileC build/Warzone.build/Release/Warzone.build/Objects-normal/i386/piestate-490252108B551643.o ../lib/ivis_opengl/piestate.c normal i386 c com.apple.compilers.gcc.4_0
cd /Users/dak180/Applications/Build/wz2100/trunk/macosx
setenv LANG en_US.US-ASCII
/Developer/usr/bin/gcc-4.0 -x c -arch i386 -fmessage-length=0 -pipe -std=gnu99 -Wno-trigraphs -fpascal-strings -fasm-blocks -O2 -mdynamic-no-pic -Wmissing-field-initializers -Wreturn-type -Wunused-function -Wunused-label -Wunused-variable -Wunused-value -DVORBIS_NEEDS_HACK -D__MACOSX__ -isysroot /Developer/SDKs/MacOSX10.4u.sdk -ftree-vectorize -fvisibility=hidden -mmacosx-version-min=10.4 -I/Users/dak180/Applications/Build/wz2100/trunk/macosx/build/Warzone.build/Release/Warzone.build/Warzone.hmap -Wall -Wno-unused-label -Wno-format-security -Wno-strict-aliasing -Wmissing-field-initializers -Wcast-align -Wwrite-strings -Wpointer-arith -F/Users/dak180/Applications/Build/wz2100/trunk/macosx/build/Release -F/Users/dak180/Applications/Build/wz2100/trunk/macosx/external/SDL -F/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks -F/Users/dak180/Applications/Build/wz2100/trunk/macosx/build/Release -F/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks -F/Users/dak180/Applications/Build/wz2100/trunk/macosx/external/SDL -I/Users/dak180/Applications/Build/wz2100/trunk/macosx/build/Release/include -I.. -I/Users/dak180/Applications/Build/wz2100/trunk/macosx/external/SDL/SDL.framework/Headers -I/Users/dak180/Applications/Build/wz2100/trunk/macosx/build/Warzone.build/Release/Warzone.build/DerivedSources/i386 -I/Users/dak180/Applications/Build/wz2100/trunk/macosx/build/Warzone.build/Release/Warzone.build/DerivedSources -Wno-pointer-to-int-cast -Wmissing-declarations -Wstrict-prototypes -Wdeclaration-after-statement -c /Users/dak180/Applications/Build/wz2100/trunk/macosx/../lib/ivis_opengl/piestate.c -o /Users/dak180/Applications/Build/wz2100/trunk/macosx/build/Warzone.build/Release/Warzone.build/Objects-normal/i386/piestate-490252108B551643.o

/Users/dak180/Applications/Build/wz2100/trunk/macosx/../lib/ivis_opengl/piestate.c: In function 'printShaderInfoLog':
/Users/dak180/Applications/Build/wz2100/trunk/macosx/../lib/ivis_opengl/piestate.c:89: warning: passing argument 3 of 'glGetShaderInfoLog' from incompatible pointer type
/Users/dak180/Applications/Build/wz2100/trunk/macosx/../lib/ivis_opengl/piestate.c: In function 'printProgramInfoLog':
/Users/dak180/Applications/Build/wz2100/trunk/macosx/../lib/ivis_opengl/piestate.c:106: warning: passing argument 3 of 'glGetProgramInfoLog' from incompatible pointer type

[Buginator]

On linux machine (32bit debian + ATI Radeon 9600 w/open source drivers) it works. On windows, it works.

I am more or less curious on how we will handle the models now? Would we start to import on a model by model basis or would we wait until they are all done?

I think it would be best to start replacing them ASAP, that way, when people play the game, they might just have enough motives to finish the crappier looking models.

[i-NoD]

I'd say we should take all we have now, what's the point in waiting? They will never cease to appear, which is a good thing btw. And I'm a bit tired to stick with those cool trunk wheels and that high-poly truck :)

[Buginator]

Replying to i-NoD:

I'd say we should take all we have now, what's the point in waiting? They will never cease to appear, which is a good thing btw. And I'm a bit tired to stick with those cool trunk wheels and that high-poly truck :)

You want to make a forum post about this then? Make it into a sticky, and people with finished work (which is license correctly) we can start to move things into trunk.

[i-NoD]

Replying to Buginator:

You want to make a forum post about this then?

I will. Tomorrow. No more commits after 2AM :)

Make it into a sticky, and people with finished work (which is license correctly) we can start to move things into trunk.

I'm normal user and I don't have such powers ​*evil laugh*

Replying to Buginator:

On linux machine (32bit debian + ATI Radeon 9600 w/open source drivers) it works. On windows, it works.

9600 is able run trunk? Funny thing is I do have access to another laptop with GoForce 7300 (HW OpenGL 2.0, reports 2.1) and it's crashing instantly with trunk as long as I'm able to build trunk... Plus long ago i've tried to run trunk on X3100 with the same results...

Anyway, could you please post a screenshot of TCMasked unit/structure from 9600? Preferable from both systems. I'd like to check color consistency...

[Buginator]

Replying to i-NoD:

Replying to Buginator:

You want to make a forum post about this then?

I will. Tomorrow. No more commits after 2AM :)

Make it into a sticky, and people with finished work (which is license correctly) we can start to move things into trunk.

I'm normal user and I don't have such powers ​*evil laugh*

Replying to Buginator:

On linux machine (32bit debian + ATI Radeon 9600 w/open source drivers) it works. On windows, it works.

9600 is able run trunk? Funny thing is I do have access to another laptop with GoForce 7300 (HW OpenGL 2.0, reports 2.1) and it's crashing instantly with trunk as long as I'm able to build trunk... Plus long ago i've tried to run trunk on X3100 with the same results...

Anyway, could you please post a screenshot of TCMasked unit/structure from 9600? Preferable from both systems. I'd like to check color consistency...

ok, here is the topic I made, you should be able to edit my *reserved* posts, and just include the info there. All developers can edit any posts and create a sticky.

​http://forums.wz2100.net/viewtopic.php?f=33&t=4951&p=50259

I have included some shots from my linux box.

[dak180]

Replying to i-NoD:

r10210: Enable or disable fog in TCMask shader depending on in-game state. Part of #851. Reviewed by Per.

2 more warnings:

/Users/dak180/Applications/Build/wz2100/trunk/macosx/../lib/ivis_opengl/piestate.c: In function 'pie_LoadShaders':
/Users/dak180/Applications/Build/wz2100/trunk/macosx/../lib/ivis_opengl/piestate.c:219: warning: passing argument 2 of 'loadShaders' discards qualifiers from pointer target type
/Users/dak180/Applications/Build/wz2100/trunk/macosx/../lib/ivis_opengl/piestate.c:225: warning: passing argument 2 of 'loadShaders' discards qualifiers from pointer target type