New graphics format

[bobingabout]

its not that i don't like the idea of an archive, the only problem with this is that unless it gets pre-processed into 34bit, the pre-processing, mainly the combining of the base image with the overlay CC image will have to be done for every file as they are loaded into OTTD, this would not only require a bit of extra loading time for the game, but also require the files to have some sort of naming convention, such as Train.png for the base, and Train_CC.png for the overlay.

[dmh_mac]

As long as we provide the processor (back and forth) with the game I don't think it should be a problem. (Maybe it could even be incorporated into the game-program itself.)

[Alltaken]

require the files to have some sort of naming convention, such as Train.png for the base, and Train_CC.png for the overlay.

yes this is what we WILL do.

this naming scheme will be increadibly easy to do in that all you need is the same named files, in different sub folders. i.e. CC/0001.png base/0001.png

we have worked through all these issues already. you seem to be trying to rehash already hashed ideas.

Alltaken

[DaleStan]

As long as we provide the processor (back and forth) with the game

grfcodec is not distributed with TTDPatch, but I don't think anyone who wants it has any difficulty finding it.
At least by my definition of "distributed with". Maybe your definition is different.

Maybe it could even be incorporated into the game-program itself.

Featuritis, IMO.

[bobingabout]

well, I'd go with having a seperate encoding EXE to build our GRF equivalants.
having the files in a renamed ZIP with a spacific directory structure is fine, and have the processing done when you load the game.

only thing is i'd rather encode it once, instead of every time you load the game. if you have several thousand sprites, think of how long it would take to process them all into 34bpp. you'd probably need some kind of "Please wait... Loading..." screen to prevent people from wondering "is it suposed to take this long to load... it never used to".

[egladil]

With this 34bpp format of yours, exactly what is the required preprocessing? Because as I see it, you could as well just have one 32bpp png file and one 2bpp png file for each sprite and load those two into memory. No need to make them sit together or something like that, just make sure the sprite has a pointer to both memory areas. Or did I miss a vital part of this 34bpp format?

Some pseudo code illustrating it:

Code: Select all

Sprite.data = LoadPng32bpp()
Sprite.mask = LoadPng2bpp()

...

for each pixel in Sprite and destination in TargetArea {
  if pixel.mask is 0 {
    destination = pixel.data
  } else {
    destination = gradient_table[pixel.mask][pixel.data]
  }
}

TargetArea would be the screen, or another sprite used to cache the company color specific sprites or whatever.

[bobingabout]

the only processing part is that in the GRF coding section, or loading section, it looks at the 2bpp CC overlay, and if it is a remap, it makes the base pixel greyscale for minimised use while rendering(because then it only has to use the brightness of the greyscale(value stored in red) as the look up table index). without this greyscalisation it would have to calculate this while rendering, which isn't a good idea.

how about we just see how it goes?

[egladil]

...it looks at the 2bpp CC overlay, and if it is a remap, it makes the base pixel greyscale for minimised use while rendering...

Thank you, this is what I was wondering.

[mexicoshanty]

With the overlays used for colour remapping wouldn't it be wiser to use a vector format like SVG? The reason i suggest this is there are 3 different zoom levels and while you could use a raster image and scale it appropriately, a vector image would just do it better.

[CobraA1]

Sounds good in theory, but a lot of work in practice. They'd have to create a XML parser (SVG is a XML format) and a SVG renderer, both of which are complex tasks.

[mexicoshanty]

Sounds good in theory, but a lot of work in practice. They'd have to create a XML parser (SVG is a XML format) and a SVG renderer, both of which are complex tasks.

I found these libraries http://cairographics.org/introduction and http://www.gnome.org/~mathieu/libart/libart.html. But i know practically zero about programming in c/c++ or how ottd works, so those library probably aren't appropriate. I know there are many XML parsers out there so that wouldn't be a problem.