progress on 32bpp?

[bobingabout]

i know this isn't suposed to be for questions, but its just got my itching...

did anyone finalise how the company colours are going to work? are we going for tri-remap (3 company colours)?
if so, have you finalised the formula yet?

[Alltaken]

afaik nobody has worked on it since.

all those ideas are just concepts created by me. afaik OGL would be needed for lots of those adnaved things.

we may be able to go with a greyscale/alpha overlay system. 3 colours was to much cpu usage to recolour on the fly (from what i was told)

Alltaken

[bobingabout]

imo, 3 colours wouldn't be a problem, the problem was the way we were trying to do it. if you want i can look at it again and do some comparisons, try to cut down the processing power requirement. maybe look into some other way of doing it.

from what i've read, the current plans are to load the sprites into memory upon launch, as with the current sprites. if this is done, then they wouldn't need rendering on the fly, mearly rendering once upon load. however, the part about the base colour of the image effecting the final remap outcolour would need to be scraped, and have the base image simply represent a greyscale "Tone" and the remap layer give a true or false for each company colour. simply by doing this i estimate the rendering processing power could be cut into a quater, and on the fly processing power minimised.

[Alltaken]

feel free to give it a try and yes not mixing with the base colour would be best, however we also need to have alpha edges, i don't want jaggy edges particularly.

and a way to deal with overlay pixels that have both Red, green or blue vlaues in them... are these mixed, is one channel the dominant....

if they are mixed then gradient effects could be achived (depending on how they are mixed of course) if they are not mixed then i would say the brightest channel in the pixel would get priority, if they are equal then the first company colour channel would get priority.

i determined that most of the effort i think was in the HSV colourspace (for company colours) with a greyscale image being altered by Hue, Saturation and Value rather than RGB calculations.

if that helps with things.

Alltaken

[bobingabout]

for reference, http://www.tt-forums.net/viewtopic.php?t=19302

also, the HSB program i helped write (I made the formulae, PD converted my MS-DOS Boreland C++ program into a windows Delphi(i think) program, however, he didn't use the same roundings as me, so theres an error if you use hue 128 which when converting creates blue=256=0 instead of 255 making green instead of cyan.) for figuring out TS/FS/RA2/YR:HSB remap colour codes.(which i understand is pretty simular to what we plan to use for tri-remap company colours)
http://bobingabout.gamemod.net/Files/rgb2hsb.exe

1. if part of the sprite is remapable, do i bleach off the original colour(in that part) and apply only remapable colour?
2. do i take brightness of the remapable layer into account, or do i go for a true/false system to determine if that section is remapable?
3. can an area be effected by more than 1 remapable colour?

1. no, do not bleach.
2. yes, brightness effects it.
3. yes with a but.

* is R, G, or B, where R is red, G is green and B is blue
CC#* = Company colour #'s * componant (Players CC settings)
B* is base images * componant
R* is remap images * componant, where the remap image is the 1 containing the CC overlays.

if (RR+RG+RB>127)
{

R= min(255,(CC1R*RR/255 + CC2R*RG/255 + CC3R*RB/255) *(BR+BG+BB)/765 + max(0,(255-RR-RG-RB))*BR/255); //765=3*255
G= min(255,(CC1G*RR/255 + CC2G*RG/255 + CC3G*RB/255) *(BR+BG+BB)/765 + max(0,(255-RR-RG-RB))*BG/255);
B= min(255,(CC1B*RR/255 + CC2B*RG/255 + CC3B*RB/255) *(BR+BG+BB)/765 + max(0,(255-RR-RG-RB))*BB/255);

else
{
R=BR;
G=BG;
B=BB;
}

if i take each of those criteria as seperate, and do a version of each for each, we determine which will use less processing power. i beleave that the oposite to last time will give the quickest results.

1. yes, bleach.
2. no, it's true/false.
3. no, if more than 1 is there only the strongest(brightest on the remap layer, or if they are the same the domanant will be used(R is most domanant, then G) will be use.

[bobingabout]

the current way.
This assumes all parts of the image are loaded into RAM already, simply decoded into BMP format. this will take 64 bits per pixel. 24 for the RGB values of the base image, another 8 for its alpha layer, which is left untouched by these calculations. another 24 bits for the company colours, and a final 8 bits for the shadows layer.


the new way

this will be in 2 sections, the first section while loading graphics(semi-processing the data while loading the game helps save processing power required while rending), the second sections while rendering.
this method will not require as much RAM. it will require a total of 42 bits. well, 48, since we work in bytes, however, it will require loading and decoding each sprite as 64bits(remember its 3 images, a 32 bit base image, containing Alpha+RGB, a 24 bit RGB remap image, and an 8bit shadow image) before being processed and stored as 48. it will require a configuration byte, which determines what the pixel will be drawn as. base image, CC1, CC2, or CC3, which requires a total of 2 bits, 0 for base, 1 for CC1, 2 for CC2 and 3 for CC3.
another 3 bytes (24bits) will be required for the base image, however, if this is a CC, only 8 of the bits will be required. theres also 2 bytes required for Alpha and Shadow layers. (i supose processing the sprite could be done while GRFing(or equivalant) to save loading up processing power required.)
This can probably be stored in a giant array, assigning a number to each of BR,BG,BB,Remap,Alpha and Shadow layers, deciding how to store it isn't my job.

THIS CODE DOES NOT TOUCH THE ALPHA OR SHADOW LAYERS. ITS UPTO YOU TO ADD IN THE CODE TO DO THIS.

remember, this is on a per pixel basis
DB* is the RAW decoded base images * componant
DR* is the RAW decoded remap images * componant, where the remap image is the 1 containing the CC overlays.
B* is the processed base images * componant
* is the processed R, G, or B for rendering, where R is red, G is green and B is blue
Remap is the processed remap configuration byte.

CC[#,*] is the Company colour #'s * componant (Players RGB CC settings) set in a single Company Colour Array.
where CC1 is stored as 0, CC2 as 1 and CC3 as 2 in the first part of the array.
and Red is stored as byte 2, G as byte 1 and B as byte 0 in the second part.



Section 1 loading/GRF processing.

this causes the base image to use only 1 byte of RAM if there is a CC, since, if there is a company colour we bleach off the colour to get a greyscale base.

assuming we store the colour in the byte desegnated for red(BR):

if (DRR+DRG+DRB>127)// simple "is remap?" check
{
BR=(DBR+DBG+DBB)/3; //Bleaching
BG=BR;
BB=BR; //BR because, well, they are unused, makes it greyscale
if (DRB>DRG && DRB>DRR) Remap=3; //is it blue?(least domanant)
else
{
if (DRG>DRR) Remap=2; //is it green?
else Remap=1; // its red(most Dominant)
}
}
else
{
Remap=0; //not remapable
BR=DBR; //save base images RGB values.
BG=DBG;
BB=DBB;
}


Section 2.

if (Remap==0)
{
R=BR;
G=BG; //As you can see, bytes BG and BB are only used if you do not have remaps.
B=BB;
}
else
{
R=CC[Remap-1,2]*BR/255; // you can probably cut this down in processing time by doing some bit manipulation code instead.
G=CC[Remap-1,1]*BR/255;
B=CC[Remap-1,0]*BR/255;
}

[Alltaken]

another 24 bits for the company colours, and a final 8 bits for the shadows layer.

no shadows layer, that was scraped ages ago it will be part of the base layer, i am sure i have told you that before.

we can easily proivde 2x images per sprite.

Base sprite (includes shadows now)
CC overlay (either 256 greyscale, or 32b PNG (could be taken down to ~ 10b if run through a pre processing software and turned into a palleted (and 8bit alpha) sprite with 256x3 colour combinations, i am all for pre-processing)

BTW the CC overlay will also be pre-processed to take into consideration things such as lighting, shadows, blemishes....

then you can start with the in game calculations. you can use a lookup table, or somthing similar now that its 3x256 colours and alpha channel for the overlay.

Alltaken

[Alltaken]

does that make your calculations easier bobingabout?

far less work to be done by the computer, (even preloading is gone i think). but i don't know how the actual calculations would be, i would just assume this would be the easiest way for it to be done.

Alltaken

[bobingabout]

no shadows layer, that was scraped ages ago it will be part of the base layer, i am sure i have told you that before.

well, i'd be assuming you decided to go for an all black shadow, where the brightness of the shadow is controled by the alpha layer, if this is true, i'm sure it will still work fine.

we can easily proivde 2x images per sprite.

Base sprite (includes shadows now)
CC overlay (either 256 greyscale, or 32b PNG (could be taken down to ~ 10b if run through a pre processing software and turned into a palleted (and 8bit alpha) sprite with 256x3 colour combinations, i am all for pre-processing)

well, pre-processing is good. still makes for 24 bit base +8 alpha +2 CC. i think the point of 32bpp is to maintain 32bpp for the whole thing. however, if you do want to make each vehicle a palleted image, with its own unique pallete, thats also fine... but i'd prefer 32bpp, or 34bpp as i tihnk it is, we could probably steal 2 bits from somewhere else, such as the alpha layer to save that extra byte if you wanted. note, unless we do a palleted image, where the pallete colour number would represent if it was remap or not, then we still need +1 bit for 1 CC, +2 bits for 3CC or +3 bits for 7CC, 7 would be too complicated to designate them all anyway.

(if i simply make the least 2 significant bits of the aplha layer the remap settings, then all that does is reduce the accuracy of the alpha to a quater. making 64 shades. the drift caused (such as 252 instead of 255) can then be corrected when checking the remap status of the bit. this will keep 32bpp for the entire image.)

BTW the CC overlay will also be pre-processed to take into consideration things such as lighting, shadows, blemishes....

not sure exactly what you mean. if the base image has a blemish, the remap will have a blemish, even doing it my previously stated method. the pre-processing just turns the base greyscale, then tells it that it is a company colour. shadows, wouldn't need to be pre-processed if they are part of the base anyway...

then you can start with the in game calculations. you can use a lookup table, or somthing similar now that its 3x256 colours and alpha channel for the overlay.

Alltaken

what exactly does the alpha channel do? incame i'm getting confused?

[Sacro]

Alpha channel is transparency.

[Alltaken]

Bobbign about, the base sprite does not need to be pre-processed i don't think. it would be 32bpp without being changed (white colour scheme i would imagine).

R= 8b
G= 8b
B= 8b
A= 8b
=32b

the overlayed CC image would (could) be palletised easily. this would mean when overlaying with the base sprite you don't actually need to do any calculations between the base sprite and the overlayed sprite. its simply sitting on top. (only calculation would be transparency)

cc1= 256 colours
cc2= 256 colours
cc3= 256 colours
A= 8b
=768 colours + 8b


this means the cc overlay contains the greyscale info (avoiding that being an ingame or preloading calculation)

this way the base colour could be any colour we wanted, the overlay would just cover it up.

hope that helps clarify things

Alltaken

[bobingabout]

well, in a way, what i did earlier would change the CC Remap layer to be a 4 colour palleted image, stored in the remap byte. where remap=0 is black(or tranparant) remap=1 is red (CC1) remap=2 is green(CC2) and remap=3 is blue(CC3) alpha is ignored, and if remap = 1, 2 or 3, there is a calculation done.

however, when pre-processing, you don't know what those colours are going to be, only that they are re-mapable, so, the easiest was to do it, with minimal on the fly calculations was to greyscale it while pre-processing, then all you have to do is multiply the company colour by the greyscaled base(for brigtness) then devide by 255(to make the range 0-255 again, instead of 0-65025)


so, what i wrote before does is:
when pre-processing:
create a 4 colour palleted remap image
if the remap is black, store the base image, else store the greyscale of the base image
(not shown, but assume we also store transparancy in both cases)

when running:
check the remap
if the remap is black, buffer the base image, else buffer the greyscale of base multiplied by the remap colour's active colour.(the correct colour of the selected player)
(it also doesn't show anything to do with the alpha, but lets assume that it draws the now buffered sprite using the transparancy of the alpha layer.)


the only reason why we MUST do the final CC calculation while drawing is because we don't know what it is at the pre-processing stage.

there is an alternate solution, and that would be to buffer every single brightness of all 3 company colours in RAM, then instead of calculating it when drawing, you calculate all 256x3 possabilities, store those in RAM, then simply select the correct 1 while drawing.

Example:
R=CC[Remap-1,2,BR];
G=CC[Remap-1,1,BR];
B=CC[Remap-1,0,BR];

where, the first value in the array specifies which colour, the second value specifies which componant of the colour(Red, green or blue) and the 3rd value the brightness of each colour(BR being the Base Red value, still pre-processed to be greyscale, but meaning the brigtness)

this would mean that every time the player saves a company colour, there would be 768 brigtness calculations done.

some very quick Example:
for (int i;i<255;i++)
{
CC[tempCC1[0],0,i]=tempCC1[0]*i/255;
CC[tempCC1[1],1,i]=tempCC1[1]*i/255;
CC[tempCC1[2],2,i]=tempCC1[2]*i/255;
}

not to mention the Hue, Sat, Bri values probably also stored for re-editing.

kinda makes you want to have preset comany colours to select from doesn't it?

EDIT: come to think of it, the CC would probably also include what player the CC is for.

CC[Player, CompanyColour , ColourChannel(R,G,B), BRightness]

CC[player,Remap-1,2,BR]

[Alltaken]

what is the proc and memory difference between doing these calculations you suggest (768* per sprite) every time the company colours are changed. Vs using a lookup table containing 768 colours?

just curious.

i don't actually know anything about coding

i am trying to work out the most efficient way to have it all done? tron seemed to think a lookup table was the way to go.

Alltaken

[bobingabout]

i actually did mean a table...


well, the difference being:

Pre-Processed Table:
a slight lag (few mili seconds) while tabling the brightness when saving the company colour, also taking a lot more RAM required for the company colours. 3x3x256= 9x256=2304 for RGB + 3x3=9 bytes for HSB 2304+9=2313 bytes per player for company colours.
(for 8 players its 18k bytes +72 bytes for HSB)

Processing while rendering:
few microseconds lag while rendering, with minimal RAM, however, when rendering an entire sprite, let alone frame, the lag can definitly build up.(This is why we have GPUs) 3x3=9 bytes per player for RGB + 3x3=9 bytes for a HSB 9+9=18 bytes per player for company colours.


18kb or lag... Hmmmm....

[bobingabout]

Bobbign about, the base sprite does not need to be pre-processed i don't think. it would be 32bpp without being changed

R= 8b
G= 8b
B= 8b
A= 8b
=32b

the overlayed CC

cc1= 256 colours
cc2= 256 colours
cc3= 256 colours
A= 8b
=768 colours + 8b


this means the cc overlay contains the greyscale info (avoiding that being an ingame or preloading calculation)

currently formula basicly states that the CC Overlay is a 2 bit image.
4 colours
black=no CC
red=CC1
green=CC2
blue=CC3

if its black, the base image is left un-processed.
if its a company colour, the base image is processed into greyscale, which is then turned into a colour when drawing. as previously stated, the actual colour can be generated when you select your company colour saving a hell of a lot of processing time while drawing.

using this method, the CC layer has no used Alpha layer. the company colour is either there or it isn't... anything else would require extra processing, which we clearly want to avoid. i think this way would turn out fine anyway.




i still need an opinion!
is this a good plan?

[Brianetta]

The logic's sound. The only hit would be the time required to (re)generate the sprites when a player changes thier company colour(s). The trade off is extra storage (each company needs a copy of each loco and wagon that they use) but it's a very small price to pay, in my opinion. Good idea.

[bobingabout]

actually, the sprites are not redone when you select a new CC, they are pre-encoded and loaded to RAM on startup, pretty much like a grf in 34bpp (32bpp for RGB+Alpha +2 bit 4 colour company colours(3 and a blank for no CC)) the game simply reads them, then will apply the company colour using a lookup table, only the company colour in the table will change when someone changes it.

memory used is 3(CC)x3(RGB)x256(value)=2304(per player)x8(players)=18432 byte, which is exactly 18k. it basicly needs to do that many multiplications and devisions to get from RGB to draw the table. if the original is HSB(or HSL) whichever we decide to go for when selecting, there will be a bit of extra calculation for that, and probably+72 bytes to store HSB values(3(CC)x3(HSB)x8(players))

[prissi]

Well, in Simutrans we have a dynamic caching. Since most of the vehicles are not used by all players, I have three caches. The frist one contains the sprite in the current size. The next two ones are the sprite in company color 1 (same as non-company sprite, more than 80% of the sprites) and the next cache is the one for another player. Rendering is done on demand; thus when looking at a big station without busses etc. no bus will be rendered. Or if I look at a straight track, I can skip 6 of the 8 view ...

But than, in simutrans nightfall and other things occurs, making rerendering quite frequent. Thus the dydnamic system.

[bobingabout]

is it just me not explaining what i mean very well, because there is very little processing required in my method....

basicly, the base image only gets pre-processed if there is a remap colour, on that pixel, in which case it only gets turned to greyscale.
(I'd prefer to have the base processed while doing our GRF equivalant process, however, it would also work while the game is loading.)

when someone selects a company colour, no sprites are changed, only the table containing a the company colour, and a pre-prosessed table for every possable brightness of each colour for that player. no, very little processing.

when drawing, it checks the CC setting of each pixel, if the CC is 0(black) then it draws the raw base, which is stored, if its non-zero then the base will have a greyscale stored, the greyscale is used as the brightness value in the look up table, and the RGB stored in the CC table is then used instead.



so, there is 1 pre-processed set of sprites.
1 CC table containing 3(CC)*3(CC's RGB)*8(players)*256(brightness settings) + 3(CC)*3(CC's HSB)*8(players) bytes of information that gets processed when someone changes their CCs.

i havn't even mentioned the CC's HSB formulae here, we might not even go with the HSB method of selecting a colour.

[dmh_mac]

Would there be a way to preserve coloured sky light on the remapped parts?
Maybe we could render the remapable parts of the model with a standardized white material so any rgb discrepansies on those pixels would be caused by lights. That way they can be taken into account when remapping.