GRFCodec feature discussion thread

DaleStan · Post by **DaleStan** » 15 Aug 2006 23:38

I've decided I need my own thread for this, so here it is.

It turns out that I failed to check some of my code in grfcodec and nforenum, resulting in subtly broken NFO file reading, so here's 0.9.10, to fix that.

PNG support is stalled, due to me spending too much time attempting to write Patch code, but rest assured that it is still on the TODO.

NOTE: GRFCodec is now being maintained by members of the OpenTTD project. A thread discussing the latest preview release (as of August 2010) can be found here.

Patchman · Post by **Patchman** » 16 Aug 2006 02:20

It's up on the patch site too now.

DaleStan · Post by **DaleStan** » 28 Nov 2006 20:56

I've implemented a new option that tells grfcodec to crop extraneous transparent blue out of real sprites. I think this works, but I'd to have some other people to test it too.

To enable, add -c to the command-line when encoding.

There are also several other changes since 0.9.10; see the the changelog for more details.

michael blunck · Post by **michael blunck** » 28 Nov 2006 21:28

> I've implemented a new option that tells grfcodec to crop extraneous transparent blue out of real sprites.

Does that mean it fits offsets depending on the cropped area(s)?

regards
Michael

DaleStan · Post by **DaleStan** » 28 Nov 2006 21:42

Yes. It adjusts the offsets as necessary when it crops from the top or left sides. Obviously (I hope), it does not adjust the offsets when cropping from the bottom or right sides.

michael blunck · Post by **michael blunck** » 28 Nov 2006 22:22

> Yes. It adjusts the offsets as necessary [...]

Very nice. I´ve thrown down ttdpbase.grf for it (which is a good candidate, *lots* of unnecessary blue, <arrgh>, (my own sets don´t have that)) and it reduced it from 310KB to 289KB.

Re-calculated offsets *seem* to be OK, but I´ve to test them more in-game (tram sprites). Do you like to check that file too?

regards
Michael

DaleStan · Post by **DaleStan** » 28 Nov 2006 22:58

Actually, no. Bad candidate. I tried that some time ago, and cropping the foundation sprites messed up the landscape drawing something awful.

DaleStan · Post by **DaleStan** » 29 Nov 2006 00:21

Lakie caught me in an off-by-one error that was causing crashes, so here's a new version with that fixed.

eis_os · Post by **eis_os** » 29 Nov 2006 08:02

Will it crop as well fully blue sprites?

At least erails should have two fully blue helper sprites, so actually the ttdpatch base graphic will work, but the sorting may change when you crop certain helper sprites... (In the way how certain things get overdrawn, when in time...)

So I am not sure if it's a really good idea for all grfs without testing all current grfs and see what happens spritesorting wise...

michael blunck · Post by **michael blunck** » 29 Nov 2006 08:48

eis_os wrote:Will it crop as well fully blue sprites?
At least erails should have two fully blue helper sprites, [...]

Yes, indeed. NewStations also uses 2 full blue helper sprites (for icon display). (Although there´s no need to "crop" its sprites.)

So I am not sure if it's a really good idea for all grfs without testing all current grfs and see what happens spritesorting wise...

Anyway. At least for the "official" ttdpbase.grf we should do some cropping of its sprites because the usage of "blue" is somewhat excessive with that file[*]. I always wanted to do that.

[ttdpatch.grf]

DaleStan wrote:I tried that some time ago, and cropping the foundation sprites messed up the landscape drawing something awful.

Possibly because of cropping such "all blue" helper sprites? (There´s one full blue sprite to be seen at the lower left corner in the screenshot). Other than that, it must be a bug. Don´t you think? I´ll do some testing today evening.

regards
Michael

DaleStan · Post by **DaleStan** » 29 Nov 2006 08:57

eis_os wrote:Will it crop as well fully blue sprites?

It crops fully blue sprites from the right and bottom -- xrel and yrel are left unchanged.

If that is a problem, fixing should be pretty easy.

michael blunck · Post by **michael blunck** » 29 Nov 2006 09:22

> It crops fully blue sprites from the right and bottom [...]

Leaving one pixel of blue. So far so good.

Question remains, whether for sprite sorting reasons full blue sprites have to keep their dimensions unchanged? I don´t think so, but I could be wrong.

regards
Michael

Patchman · Post by **Patchman** » 29 Nov 2006 15:00

The elrails block has two entirely blue sprites whose size must not be changed or the sprite sorter will have problems.

Maybe some way of marking sprites that should not be cropped would be nice? Somehow that would have to be stored in the .grf too or else decoding&re-encoding would break it again. Maybe bit 6 of the code?

eis_os · Post by **eis_os** » 29 Nov 2006 15:26

hmm, do we still have a bit free then? Maybe someday we want to allow spritestreams, or we create a fully new grf2 format for them, maybe after all better...

Patchman · Post by **Patchman** » 29 Nov 2006 15:39

Maybe one just has to be careful when using the flag with the ttdpbase graphics, I don't think regular sets would have problems.

michael blunck · Post by **michael blunck** » 29 Nov 2006 16:14

> Maybe some way of marking sprites that should not be cropped would be nice? [...] Maybe bit 6 of the code?

I don´t get what you mean with "code", but possibly you think of the sprite´s "compression byte"?

According to http://wiki.ttdpatch.net/tiki-index.php ... ompression it´s a byte but only bits 0, 1, and 3 are used ATM.

regards
Michael

Patchman · Post by **Patchman** » 29 Nov 2006 17:51

michael blunck wrote:> Maybe some way of marking sprites that should not be cropped would be nice? [...] Maybe bit 6 of the code?

I don´t get what you mean with "code", but possibly you think of the sprite´s "compression byte"?

Yes, sorry, I called it "code" internally.

DaleStan · Post by **DaleStan** » 13 Dec 2006 00:28

JGR just added two new operators to variational action 2, and I'm wondering what escape sequences to use for them.

Personally, I'm inclined to use '\2=' for operator 0E, and '\2,' for operator 0F, on the grounds that 0E, like '=', does assignment; and 0F, like ',', evaluates and discards its left-hand side, prior to returning its right-hand side.

Neither of these are perfect, though. The comma operator is rather obscure, and the store operation assigns left-value to right-location, not right-value to left-location. I also considered '\2->' for operator 0E, since the TI calculators' BASICs (well, at least the TI-83 and TI-92) use a right-arrow for an operation called "sto", which does take the value on the left and store it to the location on the right, but this suffers from the obscurity problem. It also looks a lot like the C's member-from-pointer operator, which is a completely unrelated operation.

Does anyone have any other suggestions?

minime · Post by **minime** » 13 Dec 2006 09:14

How about using letters, like something along the lines of \2s (as in store for 0E) and \2r (as in return for 0F)? I do realize it makes the codes language depended, but I think it's somewhat better than using an obscure operator (or one that usually functions differently).

DaleStan · Post by **DaleStan** » 13 Dec 2006 17:16

Somehow, \2s and \2r seem too short to me, but I can't really explain how they're worse than the \7g, \7G, \7gG, \7gg, \7GG, \7c, and \7C sequences. And I suppose it doesn't really matter what I think, what matters is what the people who will be using these think.

I can easily see allowing both those one-letter forms and the three-letter \2sto and \2ret forms.

Transport Tycoon Forums

GRFCodec feature discussion thread

GRFCodec feature discussion thread

Who is online