Transport Tycoon Forums

Wasila wrote: EDIT: I was just checking the list and wanted to check - what does it mean by creating a temperate set to market the EZ patch? Don't we want the other climates eventually too?

Naturally, but a full temperate set would be a marketable product in itself, and would probably create some nice buzz around the project. If nothing else it would at least help finish the other climates.

Wasila wrote:I believe 3000 is the figure excluding extra zoom levels - but I don't think you'd need three entries for each sprite

Correct, it would be at a per-sprite-# basis. Zoom levels can be extrapolated automatically.

Another aspect to reduce the total amount of typing here is that multiple sprites under one title (like ground, fields, railway & roads, etc etc) could obviously be named using a XXXX-XXXX syntax. I haven't ever looked at the game's sprite tables so I don't know the total amount of sprites, but I'd estimate we are still in the thousands rather than hundreds.

Jupix; how much progress have you actually made on the auto tracker? How exactly will it work?

Wasila

Wasila wrote:Jupix; how much progress have you actually made on the auto tracker?

In terms of code? None.

How exactly will it work?

1. There's a web UI for flagging repo entries as part of the base set. It adds repo IDs to a DB.
2. Script reads the sprite names contained in the tars at those IDs.
3. Would be useful at this point if the DB contained a list of sprite #s and their descriptions from the 8 bit base set.
4. Out of the data described above, the script can output a nifty progress table.

Just as noone else commented here, and it does not fit into the other thread.

Jupix wrote: Step 2. Standard for 32bit NewGRFs exists and tools have been modified to support that standard. (Doable by 2011)

Standard for non-EZ sprites exists for 3 years. There is a lack of tools though. As mentioned already several times (also in the other thread), but another time in this thread: NML (http://dev.openttdcoop.org/projects/nml) is most promising in this area. It can already directly encode .grf without .nfo, it just needs a volunteer to make it encode .tar and adding 32bpp sprites at the same time. So if anyone here is interested in 32bpp and knows python, take your chance...

Step 3. Someone has started work on a patch to implement the aforementioned standard in the game client. Initial releases support loading graphics so that work can start on converting content into GRFs. (Done by 2012?)

This is already covered by steps 1. and 2.

Step 4. 32 bit base set has been compiled in the aforementioned format from the pngs that we currently churn out. (Work starts when step 3 is achieved, we probably have a lot of pngs by then)

Same as for 2. Already possible, lack of tools.

• Implement smooth railway tracks (changes the tiling system)
• Related to above: implement smooth terrain (changes the tiling system)
• Break free of the half-tile vehicle length cage

The way I understand these items (including the trains to move on the "smooth tracks") you might just start over a new project, maybe Transport Empire. Especially the last one (vehicle lengths) will likely never hit ottd. I know that there was a patch once, but it seems like most fans of it did not notice how much essential stuff it broke. (like trains driving through each other, removing track between two wagons of the same train, signals switching to green while there is a still a train passing though a short signal block,...)

• Switch to a (...) gui with scalable fonts et al

Fonts are scaleable since 0.5, since 1.0 also the GUI scales to make texts fit. (I do not comment the (...) part.)

To repeat myself again...again (again): Originally back many years ago the idea of this project was to have long curves doing 45 degrees maybe over a 3x3 tile. This would have drastically changed things. This is not what has been listed here as a future intention. I, and I believe all others, currently in the project have dropped the concept of these curves because it fundamentally changes game play.

However let us not look over the fact that zooming in changes how we see things. Other changes really need to be changed in order to reverse the effect that zooming in creates. One of these is the exposing of the sharp track connections between tiles as well as a different gauge for diangonal track bits to ensure linkage. Basically a bug in standard zoom may be so minor it's not a bug, where as in FZ it is a clear graphical glitch. A patch would make it as subtle as it is in standard zoom. It wouldn't change the game.

To put it into a simile for simplicity purposes: This is like taking a car and sticking an engine in that takes it twice the speed. The car will then rattle at high speed. Adding measures to stop it rattling are there to retain original qualities.

Note also, a curved track doesn't have to coincide or be related in anyway to any changes to trains having more angle of rotation. Boogies fly of the tracks at way to many points as is for corner alignment to have to retain any perfection.

Jupix: can you change the original post slightly so that people stop seeing 'curves' as locomotion curves please!

Leanden wrote:If you provided me access to the tool to input all the sprite names, i'd happily sit and do that.

sames

EDIT: Woo! 600th post!

frosch wrote:Standard for non-EZ sprites exists for 3 years.

"Non-EZ" being the critical word there. Our plans include EZ. Though I appreciate your input about NML.

Fonts are scaleable since 0.5, since 1.0 also the GUI scales to make texts fit. (I do not comment the (...) part.)

Yeah, my bad, I knew there was a font scaling feature, don't know if it works the way I intended, though. Which means infinitely adjustable. However, that particular point was more about the overall scalable GUI than the fonts.

Jupix: can you change the original post slightly so that people stop seeing 'curves' as locomotion curves please!

As it's really your thought that I would be putting into words (and seem to have failed at it once already), I'd appreciate it if you reworded it to your liking.

Match track gauge on diagonal track piece to other track bits, and remove sharp points on the corners with sprites built from elements.

That would be my ideal way of dealing with it, as said, so as to change the least to retain the most.

Quite frankly: "smooth curves" is a feature totally unrelated to 32bpp, extra zoom or anything here.

I guess I should keep my mouth shut though about mixing different feature (requests)

It's a separate 'feature', but it's not unrelated. It's an issue made apparent by FZ. It's cause is unrelated, but it is a graphical issue made more apparent by FZ, therefore it's FZ's problem.

FP updated.

FP Updated again.. and stickied.

I know I'm annoying, but ... Is it possible to update and and unify the Wiki tracker (http://wiki.openttd.org/32bpp_graphics_ ... ra_zoom%29)?

extrem123 wrote:I know I'm annoying, but ... Is it possible to update and and unify the Wiki tracker (http://wiki.openttd.org/32bpp_graphics_ ... ra_zoom%29)?

Yes. It's a wiki

fp updated

frosch wrote:Just as noone else commented here, and it does not fit into the other thread.

Jupix wrote: Step 2. Standard for 32bit NewGRFs exists and tools have been modified to support that standard. (Doable by 2011)

Standard for non-EZ sprites exists for 3 years. There is a lack of tools though. As mentioned already several times (also in the other thread), but another time in this thread: NML (http://dev.openttdcoop.org/projects/nml) is most promising in this area. It can already directly encode .grf without .nfo, it just needs a volunteer to make it encode .tar and adding 32bpp sprites at the same time. So if anyone here is interested in 32bpp and knows python, take your chance...

I've been teaching myself NML over the last couple days, so I can start coding and uploading some GRFs. Should I just do individual sprites/small groups of sprites or build bigger packs? Or am I just completely on the wrong track here?