32bit Graphics: To Do, Roadmap, Feature requests

[Jupix]

To do

These are minor issues, or essential issues that we'd do well to address as priority #1.

Administratory

• Reorganise forum stickies (Done, by me)
• Fix autopack mirroring (Done, by me)
• Fix devpack compiler (Done, by me)
• Implement automatic sprite completion tracker, using the repository status field to track completion (Done, by me)
• Overhaul item completion trackers at the wiki (Do we still need them?)
• Complete project spec and start vote on implementing it (done, passed voting)
• Write tool for tracing a specific sprite into a repo release. (done, by me)
• Write guide for developing 32bpp NewGRFs

Technical

• Fix bugs in the EZ patch (no longer needed)
• Fix rendering bugs/glitches that pre-exist in OTTD but are made more prevalent/apparent/visible by the EZ patch (waiting for documentation, by me)
• Draft spec for 32bit NewGRF format (not needed any more)
• Implement aforementioned format to gain support for creating a standalone base set (done, by Michi_cc, Rubidium, frosch, peter1138, et al)

Graphical

• Complete an EZ temperate set to market the patch/project

Everyday tasks (the I'm New, What To Do? list)

• Model ingame items.
• Turn sprites into playable packages. ("Coding")
• Convert old packages at the repository into modern standard tars. (Ask me for admin privileges.)
• Write tutorials and guides for the wiki Graphics Development Documentation.
• Do codework to solve the problems documented in this post.
• Recruit people.

Project roadmap

The roadmap should serve as a ballpark indicator of where we're heading.



Feature requests a.k.a. the "wet dream diary"

These are graphical features that people would like to see in the game, or stuff that should/could/would be nice to be implemented in the game in the future.

These are directly related to the 32bit graphics rendering engine, extra zoom, or indirectly related, caused or made more important by the possible adoption of 32bit-EZ in trunk.

They would most likely be pet projects of a few programmers, not feature requests aimed at the actual developers.

• Implement a more visually pleasing ("realistic") way of reversing trains, instead of just "flipping" them
• Implement triangular sprites for fields to use on coastal / railway tile corners
• Add possibility more variation in sprites for tiles to reduce repetition in tiling (for example, coasts, hedges, fences)
• Match track gauge on diagonal track piece to other track bits, and remove sharp points on the corners with sprites built from elements.
• Related to above: implement smooth terrain (changes the tiling system)
• Break free of the half-tile vehicle length cage
• Implement more vehicle angles for slopes and curves
• Implement an infinitely scalable GUI (make playing easier/possible for people who can't see what they're doing with the current GUI)

[Wasila]

Very good! This is the kind of progress I was talking about!

Firstly, when you talk about an automated progress meter surely that would require base set graphics to be distinguished from current ones in the repo? Also would that make the wiki redundant?

* Implement a more visually pleasing ("realistic") way of reversing trains, instead of just "flipping" them

Secondly, how is this related?

[Leanden]

Without completely changing the way the engine works with trains, i can't see how reversing trains will ever be more aesthetically pleasing.

[Jupix]

Firstly, when you talk about an automated progress meter surely that would require base set graphics to be distinguished from current ones in the repo?

No, the database for that can and will be separate.

Also would that make the wiki redundant?

Depends on whether there's a need for an item-based tracker. Naturally it's possible that a properly implemented automated tracker will replace the manual wiki-style trackers.


I'll not comment on the feature requests as they are not mine. Apart from the vector GUI.

[Ben_Robbins_]

Wasila: It's related because this is a graphical project, with additional zoom levels. It is something considerable more exposed at Full zoom and if train length is delt with again more exposed. The things may be handled completely separately as patch's of there own, but in the end it's a list of 'things' that if done, will remove the most prominent visual glitch's currently seen.

If you remove this from the list, then remove everything that isn't just a bug in the 32bpp FZ patch, becuase the entire list can be posted in the OTTD suggestions forum as well as here in regard to the 32bpp FZ build...it is general; but graphically relevant.

[Kogut]

Without completely changing the way the engine works with trains, i can't see how reversing trains will ever be more aesthetically pleasing.

Maybe to add pseudo track (between two normal) on station tile to show movement of detached engine?

[Ben_Robbins_]

Sounds more complex than having the train just reverse; although in saying that, it is now possible to flip the engine, rather than the train so who knows. I guess the issue with reversing is that a carriage would need to operate like a lead engine and vice versa.

Note: the graphical glitch is 'the flipping train'. Trains being at the wrong end of a long train would be a 'reality' glitch, but graphically it would be fine.

[Wasila]

Depends on whether there's a need for an item-based tracker. Naturally it's possible that a properly implemented automated tracker will replace the manual wiki-style trackers.

Surely, if you input what each sprite is, you could have the automated sprite tracker automatically churn out an item-based list.

No, the database for that can and will be separate.

So after uploading a file to the repo you would then need to input it on to a database?

[Bus]

I personally think that smooth tracks, smooth terrain and some complicated train reversing are all against the spirit of TTD. I really love the (relative) simplicity of the current system and the way you can easily read the map / plan your railway etc. For example with smooth terrain you would find yourself wondering what is the exact height of this tile compered to this other tile, is this road going to be up or down the hill etc. Smooth tracks would make it harder to "read" the track layout when you see it. And changing the train reversing system seems just completely unnecessary.

[hyperion]

@Jupix:congratulations for your new title.
i agree the 32bpp forum needs reorganization.
i don't want to criticize all the amazing work you all make but i think it could be useful
of course it's a forum but but i think it's very disturbing for a newbee to find his way in all the threads and it seems very complicated to have a really full playable version of the game.
there are threads about an algorythm for better colmpany colors,about no zoom 32bpp version,about 32bpp extrazoom version,about 32bpp gfx version,about blend graphics,about 32bpp graphics,about classical tar files,about standard tar files for opengfx.
could it be possible to release a playable binary game version with all its corresponding 32bpp files?????

I personally think that smooth tracks, smooth terrain and some complicated train reversing are all against the spirit of TTD. I really love the (relative) simplicity of the current system and the way you can easily read the map / plan your railway etc. For example with smooth terrain you would find yourself wondering what is the exact height of this tile compered to this other tile, is this road going to be up or down the hill etc. Smooth tracks would make it harder to "read" the track layout when you see it. And changing the train reversing system seems just completely unnecessary.

@bus i agree with you too.
theses improvements seem very interesting but don't follow the spirit of ttd.
smooth tracks and more angles:in this case all the vehicle graphics will be totally out of date.

i thought that we all playing openttd and not open locomotion.
Otherwise good idea to try to give more order for this project.

[Ben_Robbins_]

Points such as smooth landscape, date back to the very first mentions of this project, where I think the ideas were a completely different game. The proposals here don't make a different game. The comparison to locomotion isn't really justified. Visual similarities aren't game play similarities. The concept of working to make anything remotely similar to locomotion is about as off-putting as I could imagine.

The criteria I have in mind ensures no game play changes. It is souly graphical.

Although I would put smooth landscape as minimally important, somewhere right at the bottom of the list of things to do, there has been a calling for it, and I can see consistency in it's appeal from the popularity of other things. Such features as this, and smooth tracks, wouldn't be forced on players...there could even be a flick-on/flick-off feature like trees showing. If people want to hold onto the original TT look so tightly, as to be appreciative of the original simplicity then this isn't the project for them...

My justification of only having graphical changes therefore doesn't rule this idea out, however on the related point of balancing time taken for advantage gained, such a feature would take a mammoth amount of time, in particular for the farm sprites. Therefore I wouldn't consider this an aim for getting to a 'completed' 32bpp FZ goal, but rather a future idea. I.e. Sprites should be made to 'current aims', and redone for ''future ideas'.

[maquinista]

Smooth tracks is a interesting feature, but this is OpenTTD. Smooth tracks and other features (3d landscape) could be a fork named "OpenLocomotion".

I prefer to "finish" OpenTTD first.

------
IMHO we need special 32 bpp extra sprites. I mean sprites like the road arrows, new signals or overhead wires. These new sprites could be used in the bridge slopes and entrances, and they could solve the problem of the grass between the road and the bridge. The docks needs two extra sprites more, because they shares the sprite used in the part over the water.

[Wasila]

I think ironing bugs and getting a proper base set should be far higher up on our list of priorities then generally Locomotion-style wishes that don't add much such as smooth landscape.

[Ben_Robbins_]

To put it bluntly the locomotion comparison is really a terrible point. I really hope that you guys can see a greater list of differences between these 2 games than 1 having smoother corners than the other... There are hundreds of games out there with smooth corners...would this proposal make OTTD just like them as well! For 1 locomotions curves are not build on 1 square, you use track pieces spanning many squares...so..fundamentally...completely different game play, building method, and look. The likeness is just 'presences of visual curves'...so on the basis of calling it open-locomotion...we may as well call it Open-FHM...cause it's exactly the same.

In essence, to the other points, I agree; of course we should aim to replace all sprites first. but...and it's I consider it a big 'but'. If we complete the graphics, spending weeks on replacing just separate groups of sprites such as 'the roads', then to get past the finish line, just to have to redo these is a demoralising concept. It's important to weigh up what decisions should be taken now, and graphics made accordingly, and what decisions to make at a later date.

I also agree, it's very low on the list. It's a luxury, rather than a bug fix. What we need to decide on is how long things will take to code/make sprites for, with or without the change, and therefore is it worth doing it sooner or later, or not at all.

I currently find it very hard to spend much time making rail sprites, no fun in producing such crude graphics.

[Jupix]

Surely, if you input what each sprite is, you could have the automated sprite tracker automatically churn out an item-based list.

Yeah, but who's gonna manually input names for thousands upon thousands of sprites?

So after uploading a file to the repo you would then need to input it on to a database?

"Input to a database", as in flag it as part of the base set, yes.

@Jupix:congratulations for your new title.
i agree the 32bpp forum needs reorganization.
i don't want to criticize all the amazing work you all make but i think it could be useful
of course it's a forum but but i think it's very disturbing for a newbee to find his way in all the threads and it seems very complicated to have a really full playable version of the game.
there are threads about an algorythm for better colmpany colors,about no zoom 32bpp version,about 32bpp extrazoom version,about 32bpp gfx version,about blend graphics,about 32bpp graphics,about classical tar files,about standard tar files for opengfx.
could it be possible to release a playable binary game version with all its corresponding 32bpp files?????

Thanks. Well, yes, we're heading into that direction, even if we aren't quite there yet. It's mostly a packaging issue and not difficult to do. In fact, the "32bpp packs", by one of our users, which you could download from one of the sticky topics here, is exactly what you're requesting...

I think ironing bugs and getting a proper base set should be far higher up on our list of priorities then generally Locomotion-style wishes that don't add much such as smooth landscape.

No wonder you think that, since that's exactly the way it is in the OP.

[Wasila]

Yeah, but who's gonna manually input names for thousands upon thousands of sprites?

I see what you mean - but they managed at least an in-game item by in-game item list in the wiki so far - we could just steal that.

No wonder you think that, since that's exactly the way it is in the OP.

Good! I was just trying to make the point that that is to be discussed on another day, when we have achieved everything else.

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?

[Leanden]

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

[Wasila]

There's 3000 of them, just to warn you! We're just waiting on Jupix to finish his automated tracker.

[Ben_Robbins_]

Is '3000' an estimation, taking into consideration 3 sprites, per original sprite (z0,1,2)?

If this is a suitable way of dealing with this issue, and the work won't be worthless within a month, then it may be worth 10 or more people each doing a few hundred. That does seem plausible.

[Wasila]

I believe 3000 is the figure excluding extra zoom levels - but I don't think you'd need three entries for each sprite (just three completed columns for each level), meaning it would only have to be typed out once. Any progress on this though awaits Jupix and exactly how his automated tracker will work and how close it is to completion.