Page 10 of 10

Re: GRFCodec feature discussion thread

Posted: 22 Apr 2010 16:55
by minime
planetmaker wrote:There seems to happen some unwanted things, if I compile OpenGFX with the "-c" flag. See http://dev.openttdcoop.org/issues/903 and the attached screenshot. I'm not quite sure why the alignment of namely the track sprites (both some road, monorail and maglev) seems to fail. I tested with r413 (with -c) / r414 (without -c) of OpenGFX (anonymous checkout via hg clone http://mz.openttdcoop.org/hg/opengfx )
grfcodec readme wrote:-c
Enable sprite-shrinking optimizations. Note that these are not necessarily safe. In particular, sprites that will share their bounding box (as for some station sprites) must not have their upper-right hand corner moved, and the sprite defining the bounding box must not be shrunk smaller than any that will share with it.
Sprites with bit 6 of their compression byte set will never be shrunk.
i.e. some sprites in OpenGFX should have bit 6 set, but they don't -- not a GRFCodec bug

Re: GRFCodec feature discussion thread

Posted: 22 Apr 2010 18:14
by Ammler
minime wrote: i.e. some sprites in OpenGFX should have bit 6 set, but they don't -- not a GRFCodec bug
How do you find out, which sprites needs +40?
hmm, isn't bit6 +64?

http://wiki.ttdpatch.net/tiki-index.php ... ompression

Re: GRFCodec feature discussion thread

Posted: 22 Apr 2010 18:24
by Yexo
Ammler wrote:hmm, isn't bit6 +64?
+64decimal is +40hexadecimal.

Re: GRFCodec feature discussion thread

Posted: 22 Apr 2010 18:54
by michael blunck
Ammler wrote: How do you find out, which sprites needs +40?
grfcodec readme wrote: [...] sprites that will share their bounding box [...] must not have their upper-right hand corner moved, and the sprite defining the bounding box must not be shrunk smaller than any that will share with it.
IIRC, there are some more "special" sprites which may not be cropped (catenary, foundations, tunnels(?), ...).

regards
Michael

Re: GRFCodec feature discussion thread

Posted: 22 Apr 2010 21:37
by minime
Yes -- ttdpbase.grf would be a good place to inspect for those types of graphics that are common for both games - that GRF has this bit set where necessary AFAIK (catenary is certainly one of those troublesome things). Otherwise, going through the original data files from TTD should help uncover the rest (I recall at least one rail tile being special in this way) - basically any sprites there that have a transparent (blue) border on at least one complete side could be safely considered uncroppable. In the worst case you can err on the cautious side, and the resulting GRF will be negligibly bigger - not a big deal.

Re: GRFCodec feature discussion thread

Posted: 23 Apr 2010 20:08
by frosch
To give a rule of thumb: All sprites which get another sprite as overlay, but are no groundsprites.
So: Foundations, station roofs with transparency overlay (the glass), industries with animation (e.g. http://dev.openttdcoop.org/issues/779 but there are some more), the weird house with lift. Well, grep for "AddChildSpriteScreen" yourself :)

Re: GRFCodec feature discussion thread

Posted: 09 Aug 2010 12:33
by Rubidium
There's a new (preview) release at http://www.tt-forums.net/viewtopic.php?f=26&t=49611