32bpp progress

[egladil]

For all of you who have been waiting for this, I wanted to give you a progress report on the 32bpp branch of OpenTTD.
It currently features a blitter capable of alpha blending and hsv and rgb masking. In the picture below you can see both the alpha blending (the bridge) and hsv mapping (the train colour) at work. When converting old 8bpp sprites to 32bpp, it will use linear interpolation instead of pixel dropping (as is the current way of doing zoom outs) and this shows in the trees and the ground. It will also be able to load graphics from png files and use those ingame.

[MeusH]

It looks awesome!

I'm curious about the file system. You're making just the graphics engine, so the files are still loaded by grfs? Or you have invented some awesome quake-like system of loading graphics?


Would it be possible, to create an object (smoke puff), which will have some properties (like lifetime and maxlifetime, startalpha and endalpha, xvelocity, yvelocity, zvelocity), that will move and change during the game?
I think about the smoke puff that changes its transparency down to 0, then destroys itself when lifetime=maxlifetime

[LordOfThePigs]

How about a screenie with stronger zoom?

[MeusH]

Impossible. It's top-seekrut!

[DeletedUser21]

I already tought there was something with that picture, it looks splendid!

[Bjarni]

I wonder why nobody commented on the date in the screenshot (which just happens to be the same date as today, apart from the year)

[madman2003]

The improvements are nice, but current svn segfaults after a 6-12 months (backtrace didn't give anything usefull).

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46912515634624 (LWP 11625)]
0x00000000004666bb in error ()
(gdb) backtrace
#0  0x00000000004666bb in error ()
#1  0x000000000046664f in error ()
#2  0x0000000000444423 in error ()
#3  0x000000000049b701 in error ()
#4  0x00000000004438db in error ()
#5  0x000000000049c365 in error ()
#6  0x00002aaaab216674 in __libc_start_main () from /lib/tls/libc.so.6
#7  0x000000000040348a in ?? ()
#8  0x00007fffffc369a8 in ?? ()
#9  0x000000000000001c in ?? ()
#10 0x0000000000000001 in ?? ()
#11 0x00007fffffc384b0 in ?? ()
#12 0x0000000000000000 in ?? ()

[StarLite]

It still looks a bit outdateted

[egladil]

I'm curious about the file system. You're making just the graphics engine, so the files are still loaded by grfs? Or you have invented some awesome quake-like system of loading graphics?

The way of loading the graphics is not decided yet. But the png files will almost certainly be bundled in an archive of some kind. The format is yet to be decided, but personally I like tar(.gz) because it's easy to use programatically. If I understood things correctly there might be a problem with data size limits in grf files. (Could somebody please confirm or deny this?) Grf files could however still be used to specify what graphics to use for what and things like that. That, however, is a later problem.

Would it be possible, to create an object (smoke puff), which will have some properties (like lifetime and maxlifetime, startalpha and endalpha, xvelocity, yvelocity, zvelocity), that will move and change during the game?
I think about the smoke puff that changes its transparency down to 0, then destroys itself when lifetime=maxlifetime

Thats how almost how smoke puffs and such are done now if I understood the code correctly, so that shouldn't be a problem.

How about a screenie with stronger zoom?

That wouldn't really be that interesting as the only thing in fully zoomed in that doesn't look the same as normal OpenTTD is the vehicle colour.

The improvements are nice, but current svn segfaults after a 6-12 months (backtrace didn't give anything usefull).

I don't get this problem. Did you do anything special?
(From the bt I assume you use 64bit hardware?)

[DaleStan]

If I understood things correctly there might be a problem with data size limits in grf files. (Could somebody please confirm or deny this?)

Confirm: A 64K size limit on individual sprites in a GRF file.[0]
Deny: A maximum number of sprites per file.
Deny: A maximum total size of a GRF file.
Confirm: The possibility of splitting oversize logical sprites across multiple physical (GRF) sprites. (Pitfalls: Update to GRFCodec; Magic to keep actions 1/5/A/12, 7/9, and 11 from breaking.)
Confirm: The possibility of having the GRF contain the name of the file containing the sprite, rather than the sprite itself. (Pitfall: Well-defined behaviour when (Not "if". "when") the GRF gets split from its associated external data files.)

[0] More precisely, an uint16 contains the size of the sprite and its metadata. Pseudos have one byte of metadata, reals have eight (AIUI. It might be three and ten.) Binary includes (1 ** dir/filename.ext) are psuedo-sprites with an additional 3+strlen(filename.ext) bytes of metadata. (So 1 ** sprites/ding.wav has 11 bytes, plus the one or three inherent in being a pseudo sprite.)

Grf files could however still be used to specify what graphics to use for what and things like that. That, however, is a later problem.

You're designing a sprite loading system independent of the sprite usage system? Seems questionable to me, but it's your call.

[MeusH]

I'm curious about the file system. You're making just the graphics engine, so the files are still loaded by grfs? Or you have invented some awesome quake-like system of loading graphics?

The way of loading the graphics is not decided yet. But the png files will almost certainly be bundled in an archive of some kind. The format is yet to be decided, but personally I like tar(.gz) because it's easy to use programatically. If I understood things correctly there might be a problem with data size limits in grf files. (Could somebody please confirm or deny this?) Grf files could however still be used to specify what graphics to use for what and things like that. That, however, is a later problem.

I posted some time ago my ideas according "specyfying what graphics to use for what". Take a look at openttd.cfg.
Simply, each .gz with pngs would contain such a file looking like...

Code: Select all

[tgv] //uniquename
namestring = STR_TGV //full name
#namestring = "TGV Thalys" //other way
maxspeed = 300 //some stuff
tractiveeffort = 15 //some stuff
power = 200 //also some stuff
mass = 47 //more important stuff
dualheaded = 1 //vehicle property
wagonoverwrite = 1 //standard carriages would be overwritten by tgv-style wagons

OpenTTD should look for graphics in a specified directory, like graphics/$uniquename/, graphics/tgv. This directory would contain properly named graphics for front engine, back engine (because dualheaded = 1) and wagon overwrite graphics (because wagonoverwrite = 1)

Would it be possible, to create an object (smoke puff), which will have some properties (like lifetime and maxlifetime, startalpha and endalpha, xvelocity, yvelocity, zvelocity), that will move and change during the game?
I think about the smoke puff that changes its transparency down to 0, then destroys itself when lifetime=maxlifetime

Thats how almost how smoke puffs and such are done now if I understood the code correctly, so that shouldn't be a problem.

Currently, smoke puffs are just sequences of images.
I meant just one .png, which can be resized and changed transparency according to its lifetime

[DaleStan]

If I understood things correctly there might be a problem with data size limits in grf files. (Could somebody please confirm or deny this?)

Another possibility, although this is more questionable, is to make use of the fact that GRF files end with a 0-byte sprite, not "whenever the data runs out". It might, therefore, be possible to add data after that for any oversize sprites. This would also require an update to GRFCodec, but would fix the 1/5/A/12, 7/9, 11 problems, since the sprites that actually appear in the normal section would simply be an instruction to read sprite $foo from the oversize-sprite-space. Note again that this is an issue with the GRF container, not the NFO language.

Simply, each .gz with pngs would contain such a file looking like...

Code: Select all

<snip>

Great. Now how do I write "Power: 200 HP at 101 kph and below, 150 HP above 101 kph"? Or "Capacity: $foo if carrying passengers, $bar if carrying tourists, and as much as possible without exceeding $baz tons for all other cargo types"? Or: "engine is articulated; automatically build vehicle IDs $qux, $quux after building this vehicle"? Or: "Use color scheme(s) $corge for a human player and color scheme(s) $grault for an AI player."

wagon overwrite graphics (because wagonoverwrite = 1)

And it knows which wagons to overwrite ... how? (IOW, how does it know that it should not override coal wagons?)

It seems to me like there are really two options here:

1. Write a program that takes your "plain text" spec file and converts it to NFO, then use the already-(mostly-)working NFO support in OTTD and be done. [1]
2. Write a program that takes your "plain text" spec file and converts it to some other, yet-to-be-specified easily computer-readable format. Then start from scratch implementing this format (which for NFO took many, many months and won't be significantly faster no matter how nicely you design your new one), fixing bugs, redoing the specs because you find things you need to do that can't be done, restart coding yet again, fixing the limitations of specs. Deal with the headaches of supporting two incompatible formats internally (unless you want to drop support for all existing graphics). Repeat as necessary.

My point is, why not use a format that works, can do just about everything that needs to be done[2], that there are many people out there who know how it works, and that OTTD mostly supports already? Why bother making all the mistakes that TTDPatch made all over again in a new design?

I'm not saying NFO is perfect. It has warts, and some things aren't designed as cleverly or cleanly as they could've been (because it's a grown design that grew as artist's demands increased). However, it is very simple for doing simple things (you can make a new train with four or five lines of very simple "code". It can get very complex too, but only when complex things need to be done. You cannot remove the complexity without losing its power and sophistication. Any new design will need to be just as complex if it needs to be able to do what NFO can do[3].

If the hex-ness of NFO is the only thing that bothers you, then it's the only thing that needs fixing. This means either improving/fixing GRFMaker, or writing a "plain text"->NFO converter. A variation of the latter would need to be written even if you come up with your own format.

So why not NFO?

[1] Whether the graphics are 8bpp or 32bpp or 256bpp does not matter here. The way sprites are encoded in the file is irrelevant. NFO can work just as well no matter what type of sprites you have.
[2] And can relatively easily be extended to support new things.
[3] For example Locomotion has a very simple format. As a result it can only do simple things. No repainting of wagons after N years to show a new historical livery. No showing of dirt as vehicles get older. No random variations in colours. No seasonal cargo acceptance/production of industries. No sophisticated animation control. No sophisticated station designs. No simple support for trainsets, other than defining a new vehicle ID for each loco and each wagon in each train set. Etc...

[Moriarty]

Am I the only one who doesn't see anything special about that pic whatsoever (including colours)? It looks just like a regular screenshot. But maybe that's the point in which case it works perfectly.

[MeusH]

Simply, each .gz with pngs would contain such a file looking like...

Code: Select all

<snip>

Great. Now how do I write "Power: 200 HP at 101 kph and below, 150 HP above 101 kph"? Or "Capacity: $foo if carrying passengers, $bar if carrying tourists, and as much as possible without exceeding $baz tons for all other cargo types"? Or: "engine is articulated; automatically build vehicle IDs $qux, $quux after building this vehicle"? Or: "Use color scheme(s) $corge for a human player and color scheme(s) $grault for an AI player."

wagon overwrite graphics (because wagonoverwrite = 1)

And it knows which wagons to overwrite ... how? (IOW, how does it know that it should not override coal wagons?)

Allright, NFO has been already done and it is better for much more advanced properties.
Let's say power, cargo capacity, speed, etc would be coded in NFO format.

However, some things need to be changed. There will be no longer big .pcx containing $n sprites. This will get rid of $x and $y position properties in NFOs.
Also, this may get rid of most lines containing info of images. OpenTTD would just need a patch to directory containing graphics, so it can take appropriate images for engines, wagons, even wagon overwrittens.

But, for the overwritting wagons... NFO uses magic numbers for certain cargoes, so changing i.e. mail hex value would result in need to change most .grfs containing mail wagon overwrite

This way, OpenTTD will benefit from smaller and easier to do NFOs, while still using it's power.

[Alltaken]

However, some things need to be changed. There will be no longer big .pcx containing $n sprites. This will get rid of $x and $y position properties in NFOs.
Also, this may get rid of most lines containing info of images. OpenTTD would just need a patch to directory containing graphics, so it can take appropriate images for engines, wagons, even wagon overwrittens.

But, for the overwritting wagons... NFO uses magic numbers for certain cargoes, so changing i.e. mail hex value would result in need to change most .grfs containing mail wagon overwrite

This way, OpenTTD will benefit from smaller and easier to do NFOs, while still using it's power.

the info files AFAIK (from talking to egladil in the past) will be split into TWO parts.

Vehicle info (shared by all sprites.)
Sprite info.

the sprite info will specify Offsets, image names/locations, and overlay rules on a per-sprite/sprite group basis.

NFO, proprietry format.... it doesn't matter. as long as there is a human readable way of editing it (i.e. GUI software, or text or somthing)

Alltaken

[DaleStan]

However, some things need to be changed. There will be no longer big .pcx containing $n sprites. This will get rid of $x and $y position properties in NFOs.
Also, this may get rid of most lines containing info of images.

OK, so it would get rid of xpos, ypos, compression, ysize, and xsize. But what about xrel and yrel? (The location of the top-left corner, relative to the "center".) Are you going to force all sprites to have the same xrel/yrel, and if so, what happens when something like the A380 or the An-225 Mriya appears and needs to exceed the standard bounds? If not, where do they get stored?

But, for the overwritting wagons... NFO uses magic numbers for certain cargoes, so changing i.e. mail hex value would result in need to change most .grfs containing mail wagon overwrite

No, it wouldn't:
1) Overrides are done by vehicle ID, not by cargo. (And overriding a vehicle you didn't just define is simply Not Done.)
2) Even if you change that, the cargo translation table exists for a reason.
3) No sane person would ever change the default ID for mail. It's one of the TWO cargos that exist in all four climates.

This way, OpenTTD will benefit from smaller and easier to do NFOs

I have to object. The only way to make it easier is to remove complexity. Period.
The difficult part of NFO is not actually writing the code, it's figuring out how to Macgyver the information you what out of the information you have.
For example, slope data is a five-bit bitmask. The low four are set if the corresponding corner is higher than the lowest. (Bit 0: West; 1:S, 2:E, 3:N) The fifth is set if this is a steep slope. How do you use that, and the height of the lowest corner, to determine the height of the highest corner?
Write it in English.
Then code it in psuedocode based on your favourite programming language.
Which was easier?

[prissi]

I know I should be silent. But here are my 5ct, more in detail the definition of the files used for Simutrans. Nearly everybody can do it, this there are no "Code" and "Artist" division there but everybody code their images him-/herself.

Writing a program that semiautomatical converts NFO/PCX into this format and doing the alignment correct was also easy. Of course Simutrans uses other data fields. I am not saying to use the Simutrans coding; all I am say it to make it easy or only expert could contribute. Such a code here is much much easier to write (and maintain) than the nfo/pcx/grf one.

Finally, seeing ones egine running in the game with such an easy coding is a strong motivation for further contributions. And time spend on coding is better spend on drawing, isn't it?

DAT-file for simutrans
------------
obj=vehicle
name=SH30
copyright=TTD
waytype=track
engine_type=electric
speed=160
cost=8100000
weight=84
power=3600
RunningCost=270
intro_year=1966
Constraint[Prev][0]=none
EmptyImage[SE]=SH30.0.0
EmptyImage=SH30.0.1
EmptyImage[SW]=SH30.0.2
EmptyImage[W]=SH30.0.3
----------------

Of course with OTTD, there should be entries like TE=... and relybility=...

[MeusH]

Yes, this is similiar to what I proposed, mostly because it is user friendly.
And I'm sure there would be a way to set random liveries, refitting and wagon overwrite in other way than in NFO... like...

Code: Select all

cargoes {
default=passenger;
passenger=30;
mail=20;
goods=25;
valuables=25;
food=20;
}
wagonoverwrite {
//insert wagon's unique names here
"passenger_temperate" "passenger_cool";
passenger_arctic "passenger_cool";
passenger_tropic "passenger_cool";
goods  "goods_cool";
valuables "valuables_cool";
}

This would make engine refitable to other cargo types, also passenger wagons (there are two types of them in TTD) and some other would be changed to other-looking ones.

[DaleStan]

I know I should be silent. But here are my 5ct, more in detail the definition of the files used for Simutrans. Nearly everybody can do it, this there are no "Code" and "Artist" division there but everybody code their images him-/herself.

I haven't looked too closely at the DAT format, but when I last read the documentation I did not see (Simutrans wiki is currently borked):
- Variational Action 2 (in any of its forms)
- Random Action 2
- Callbacks
- Action 6 (write info from parameter into code)
- Actions 7/9 (conditionally skip)
- Action B (issue error messages)
- Action D (mathematical operations on parameters, set GRF controlled props)
- Action E (disable other files)
- Action F (custom town names)

I also do not recall seeing anything related to non-vehicles, but I'm sure that's just a matter of poor memory, not non-existent feature.

Writing a program that semiautomatical converts NFO/PCX into this format and doing the alignment correct was also easy.

I mostly trust you on the alignment; tedious, but easy. But what happens to George's Dolphin Intercity Bus?
But I find the code part harder to believe. May I see the 1/2/3 code (the graphics control code) for one or both of the USSet's Daylight or Sunset? (Specifically: The Daylight changes liveries depending on which vehicles it is pulling, and overrides its passenger and mail carriages. The Sunset overrides its pax and mail carriages in such a way as to remain streamlined regardless of the mix of single level and bi-level pax cars.)

I'd also like to see the PlaneSet's 747 or 747 EUD, one or both of the Osprey and Chinook, and any of Grigory1's planes. Even if Simutrans doesn't have have planes (It didn't last I played, and I'm afraid I no longer follow its development), the concepts should be abstractable into something that could work, if it were supported.
(Concepts there include: callbacks 15 and 19, cargo-dependent sprites, loading state, custom rotors, random sprites, and aircraft-state dependent sprites.)

And time spend on coding is better spend on drawing, isn't it?

No. Time spent coding is better spent drawing, while someone who can't draw does the coding.

And I'm sure there would be a way to set random liveries, refitting and wagon overwrite in other way than in NFO... like...

Code: Select all

cargoes {
<snip>
}

You seem to be missing cargo_no_one_has_conceived_of_yet.

Or should every single such file require updates every time anyone comes up with a new cargo?

[MeusH]

And I'm sure there would be a way to set random liveries, refitting and wagon overwrite in other way than in NFO... like...

Code: Select all

cargoes {
<snip>
}

You seem to be missing cargo_no_one_has_conceived_of_yet.

Or should every single such file require updates every time anyone comes up with a new cargo?

Yup, you're right here, I didn't have idea how to do that.
May I take the example of someone creating new passenger carriage?
This way, you're right, some trains may not have the wagon overwritting done.

However, what if there are "groups" of carriages, like "passenger", so all passenger carriages go there.
And if some engine does the wagon replacement, it would replace all wagons that are in the group...

Is it correct and effective way?