zBase (32bpp base set by Zephyris)

[Rubidium]

Not quite, the increased zoom level is also available for 8bpp sprites. The point of 32bpp sprites is purely colour depth.

And transparency/alpha channel too, no?

Exactly. 8bpp has, effectively, a 1 bit alpha channel. It either is alpha or it isn't. The remaining almost 8 bits are used for colours.

[54x]

Actually not so much, the point of 32bpp sprites is that you get increased resolution and colour depth, particularly at increased zoom levels.

Not quite, the increased zoom level is also available for 8bpp sprites. The point of 32bpp sprites is purely colour depth.

Right, technically speaking you can have the increased resolution without the increased colour depth, but in practical terms people do both at once in almost all cases.

[TadeuszD]

The problem is that the extra smoothness may hurt the playability, [...] Since most people prefer to play most of the game on the normal zoom level, it's a bit frustrating if a model you spend 20 hours only look like a blur.

For this reason, I believe that the pixel-art is still a better solution for creating nice sprites for ZOOMx1 or ZOOMx2 (also in 32bpp) than a simple automatic scaling down images from the Blender...
The bigger vehicles is not a solution, because it breaks proportion between vehicles, buildings and other objects like tunels...

[V453000 :)]

The problem is that the extra smoothness may hurt the playability, [...] Since most people prefer to play most of the game on the normal zoom level, it's a bit frustrating if a model you spend 20 hours only look like a blur.

For this reason, I believe that the pixel-art is still a better solution for creating nice sprites for ZOOMx1 or ZOOMx2 (also in 32bpp) than a simple automatic scaling down images from the Blender...
The bigger vehicles is not a solution, because it breaks proportion between vehicles, buildings and other objects like tunels...

Could not agree more

[Bad_Brett]

For this reason, I believe that the pixel-art is still a better solution for creating nice sprites for ZOOMx1 or ZOOMx2 (also in 32bpp) than a simple automatic scaling down images from the Blender...

Yeah, you have fun with that. Manually drawing thousands of animation frames in different sizes. It would have taken Zephyris 10 years to finish the set if he had done that.

I think a more realistic option would be to try different scaling algorithms.

[54x]

Are there plans to fill in the 1.3.0 interface sprites at some point?

Obviously this is non-urgent as it's not approaching a final release yet but it would be nice to have it all ready to go as soon as the new version drops.

[Zephyris]

There are far more than just those few gui sprites missing, most of the gui still needs drawing.... Any help would be appreciated!

[Dave]

Ah Richard. Not a 32bpp fan - until now. Excellent work.

[Zephyris]

Ah Richard. Not a 32bpp fan - until now. Excellent work.

Thank you! I really appreciate it

[Droperidolum]

Hi! I'm a old fan of TTD and newbie fan of zBase grf and FIRS. Guys, the work you've done is awesome!
But I have a question. Is this possible to make zBase 32-bit vehicles be reffitable for FIRS`s cargo? Currently I'm using 32-bit train engines and OpenGFX+ for refittable carriages, but it is uncomfortable to have 2 sets simultaneously (they are both in a vehicles list). Thanks! (and sorry, I posted In both threads )

[Mahoo76]

Hi Zephyris, this looks great. Found a misalignment for you

Tenthill Transport, 20th Sep 1936.png (225.83 KiB) Viewed 5720 times

[V453000 :)]

Hi! I'm a old fan of TTD and newbie fan of zBase grf and FIRS. Guys, the work you've done is awesome!
But I have a question. Is this possible to make zBase 32-bit vehicles be reffitable for FIRS`s cargo? Currently I'm using 32-bit train engines and OpenGFX+ for refittable carriages, but it is uncomfortable to have 2 sets simultaneously (they are both in a vehicles list). Thanks! (and sorry, I posted In both threads )

As long as it is a base set (OpenGFX/zbase), it cannot change the stats/capabilities of original vehicles - newGRFs do that. If it becomes (similarly to OpenGFX+ - the point of OpenGFX+ is exactly adding new features to the game instead of just changing sprites) a newGRF, like zbase+, there it can re-define those vehicles with same graphics but different stats/behaviour/capabilities/whatever. Base graphics change only visual appearance

[Gremnon]

Shouldn't the 'Old wagons New Cargos' GRF work just fine for that? I mean, it should pick up the zBase graphics for the original vehicles, but also make other cargos available as is wanted?

[kamnet]

Shouldn't the 'Old wagons New Cargos' GRF work just fine for that? I mean, it should pick up the zBase graphics for the original vehicles, but also make other cargos available as is wanted?

I can't remember if it only modifies the values, or if it also includes the original TTD sprites.

[V453000 :)]

I am pretty sure it contains (modified) original sprites, but rather check it yourself

[peter1138]

I am pretty sure it contains (modified) original sprites, but rather check it yourself

It doesn't. I took the time to check.

[Creat]

I mainly came by to say a big "THANK YOU" to Zephyris. This is some truly awesome work and - as far as I'm concerned - gave the game new life. I was really worried the 32bpp thing had run it's course. So seriously: Thank you!

I do hope the texts on http://www.openttd.org get amended to mention the existence of this (relatively) new base set. It would be a shame if new players didn't get to see it just because they never knew about it. Only OpenGFX is mentioned as an alternative to the original TTD files on the download page(s).

Lastly I want to chime in a little on the matter of the toolbar button sizes. I personally never had a problem with the original/small ones, but I understand those that do. It would probably suffice to go for a middle ground of the two, as the double sized ones are quite larger than necessary I feel. In any case, the large ones don't take up that much space that I'd consider it a problem. The only actual problem I have is with the pause & fast forward buttons: I can barely tell (visually) if the game is actually paused or not. When pressing it, the difference becomes clear(er), but it's still only a slight difference in shade of gray used. Could that maybe be a little more obvious? Possibly by adding a 3D-like border when it's pressed, simulating some depth (or any other way)?

[V453000 :)]

While zbase is a nice step in a rather undiscovered direction, firstly I think mentioning any base set on openttd.org is not the idea, it does not mention all newGRFs anyone has ever made either. Plus I believe BaNaNaS mentions zbase just like other things. http://bananas.openttd.org/en/base/ Regardless, if it is mentioned anywhere officially, OpenGFX was just the first one and is the default one so I find that quite understandable.

Secondly I think zbase is very unfinished; while not lacking any sprites, 99% of them need major improvements. From making things look less smooth and taking more time thinking about making more details (details visible with 1x zoom) in that sense, through strange rendering options which cause some sprites to have barely any contrast, opposed to sprites which are majorly overbrightened - example grain wagons in various rotations. Furthermore very strange blurs/glows around signals which look rather creepy in the otherwise rather dark and clean environment.

In addition to that, I think 32bpp obviously does have a lot more options in terms of colours, I doubt we can deny that. However with that comes another "downside". If you use the palette, it basically guarantees that your outcome always stays within some bounds of not just similarity to the other openttd stuff, but it also makes a very good choice of colours, provided that you use them well. I think a bit less artificial colours could be chosen as well for zbase, but perhaps that is just the rendering options again.

I am saying it all the time and I will say it again, rendering sprites is probably very hard to make look good at zoom 1x. With that I am asking myself if the rendering option is worth it if 1x - the most important view - looks bad. Maybe yes, maybe not, that is up to Zephyris to decide and eventually try to improve the current output; which I belive he also stated he is going to.

More pixels, more colours and more everything is cute to say, but it does not automatically mean it looks better. I can see where the general syndrome of automatic expectations from extra zoom things comes from, but I think it is mostly caused by a few factors. First of all, there is always the value of "look a new feature" which presents the sprites always in 4x zoom - every single thread with that is focusing on 4x zoomed sprites. Most of the time you spend in game however is in 1x and thus this view is most important. Obviously, the game lets you to zoom in for a bonus sight, but x2 is possibly the maximum useful zoom for construction itself, x4 is just for looking.
What I mean by this is, extra zoom artists should probably seriously consider what the aim is, because otherwise I would not call it "extra zoom", but "only zoom" - which is but a stupid calling of the feature, but you see what I mean.

Zephyris definitely without a question deserves huge respect for not just trying the area of 32bpp/ez, but also persisting and leading his project to a playable version. It would however be exponentially nice to work with this result some further and not just continue on the gained experience, but also to improve the outcome itself. No version 1 is perfect, of anything.

[Rob2269]

I have only just come across zBase, but I can't go back now. Outstanding work. Thank you.

[Zephyris]

Thanks for the kind words guys

Re: V453000 's comments
You have spotted a lot of important limitations with zBase, it really is a graphics set that is version 1, or first public beta, or something like that... The problem with introducing a feature like 32bpp extra zoom levels is that it requires a complete base set of graphics to get any interest from people developing and using graphics, but it takes a huge amount of effort to make that complete graphics set: it's a chicken and egg problem. Thats why I made zBase, it is "just" a "quick" production of all the graphics, but represents 134 hours of time modelling in Blender. That obviously doesn't include all the time managing sprites etc. which is a huge overhead. The graphics aren't perfect, but, to put it bluntly, I seem to be the only person making graphics for OpenTTD who has the ability to look past the imperfections in a few sprites and look at the big picture of 10,000 sprites. It was exactly the same situation with OpenGFX. I hatched the chicken... or laid the egg... or something like that anyway...

This is where anyone can help though. To contribute improvements to the graphics is now easy:
1. Using mercurial make a local copy of the zBase repository from the devzone: http://dev.openttdcoop.org/projects/zbase
2. Pick a .blend file of some sprites you want to improve and model the extra detail.
3. Press Ctrl+F12 and wait for the sprites to render.
4. Push the changes back to the repo.
You don't need to use any coding. Loads of standard textures are available. The basic building/truck/etc. shape is made and can be modified easily. Complex templates, like for terrain, foundations, rivers, etc., are already made.

On a side note you can read in simpler language about how I made zBase here:
http://calculatedimages.blogspot.co.uk/ ... phics.html
http://calculatedimages.blogspot.co.uk/ ... to-3d.html
http://calculatedimages.blogspot.co.uk/ ... ation.html
http://calculatedimages.blogspot.co.uk/ ... oduct.html