zBase (32bpp base set by Zephyris)

[Digitalfox]

Hi all!

I have made some pretty good progress. It would be really handy if people could help me spot missing sprites (i.e. ones that still appear as 8bpp). You can download the latest builds here.

Hi Zephyris

I'm running OpenTTDr24568 + Zbuild r171.

And there are a a couple of houses still in 8bpp, but I don't know if you are aware but r171 is from 30 September and the last work you done in Zbase is not yet there (I'm not complaining Rubidium, you're doing an awesome job )

Should I report the 8bpp sprites I find anyway?


Keep the great work guys, it looks beautiful and gorgeous on my new 24" 1080p Screen


Just a request, I'm aware of ogfx-biggui, but it's not in 32bpp and right now the Menu's (since they don't have the zoom feature the map has) look rather small, quite honestly they look almost like a pixel on the screen (Yes I'm over exaggerating) but can something be done to them, so they are bigger in 32bpp?

[Zephyris]

Should I report the 8bpp sprites I find anyway?

I guess wait till the next nightly comes out...

[Digitalfox]

Should I report the 8bpp sprites I find anyway?

I guess wait till the next nightly comes out...

And:

Just a request, I'm aware of ogfx-biggui, but it's not in 32bpp and right now the Menu's (since they don't have the zoom feature the map has) look rather small, quite honestly they look almost like a pixel on the screen (Yes I'm over exaggerating) but can something be done to them, so they are bigger in 32bpp?

[Zephyris]

Just a request, I'm aware of ogfx-biggui, but it's not in 32bpp and right now the Menu's (since they don't have the zoom feature the map has) look rather small, quite honestly they look almost like a pixel on the screen (Yes I'm over exaggerating) but can something be done to them, so they are bigger in 32bpp?

This isn't something I had thought about. I made the big GUI grf because I wanted to use it 100% of the time (and I do) so I hadn't noticed how tiny the original GUI looks...

I am totally in favour of including new, high resolution, 32bpp GUI sprites in zBase though I might not be able to find the time to make them myself. If they are going to be made then I strongly suggest they be made in inkscape as SVGs (i.e. as open source-compatible vector images) for future portability.

On a related note the big GUI is still not 100% bug free. Obvious problems are the close window buttons and the +/- buttons in the advanced settings window. On a related note I believe (though I haven't tested recently) larger bitmap fonts are not supported correctly. If anyone feels like tracking down and correcting these last few bugs I think it would be very worthwhile!

*edit* I should make it clear that the bugs with the current big GUI grf will pop up with any larger GUI elements, no matter how they are coded (i.e. no matter whether they are base set or newgrf).

[planetmaker]

On a related note the big GUI is still not 100% bug free. Obvious problems are the close window buttons and the +/- buttons in the advanced settings window. On a related note I believe (though I haven't tested recently) larger bitmap fonts are not supported correctly. If anyone feels like tracking down and correcting these last few bugs I think it would be very worthwhile!

*edit* I should make it clear that the bugs with the current big GUI grf will pop up with any larger GUI elements, no matter how they are coded (i.e. no matter whether they are base set or newgrf).

Yes indeed, that's still an issue within OpenTTD's code where scaling doesn't work properly

On the other hand, I do not believe that the sprite fonts should have adjustable height. If you need different size there, choose a font as supplied by the system (which could be made much more comfortable by a font selection UI).

the Menu's (...) can something be done to them, so they are bigger in 32bpp?

Not this way. That would be highly folly and hugely detrimental.

The only way to adjust that is a setting somewhere which allows selecting UI in different sizes, thus integrating ogfx+biggui somewhat into openttd itself.

[Digitalfox]

On a related note the big GUI is still not 100% bug free. Obvious problems are the close window buttons and the +/- buttons in the advanced settings window. On a related note I believe (though I haven't tested recently) larger bitmap fonts are not supported correctly. If anyone feels like tracking down and correcting these last few bugs I think it would be very worthwhile!

*edit* I should make it clear that the bugs with the current big GUI grf will pop up with any larger GUI elements, no matter how they are coded (i.e. no matter whether they are base set or newgrf).

Yes indeed, that's still an issue within OpenTTD's code where scaling doesn't work properly

On the other hand, I do not believe that the sprite fonts should have adjustable height. If you need different size there, choose a font as supplied by the system (which could be made much more comfortable by a font selection UI).

the Menu's (...) can something be done to them, so they are bigger in 32bpp?

Not this way. That would be highly folly and hugely detrimental.

The only way to adjust that is a setting somewhere which allows selecting UI in different sizes, thus integrating ogfx+biggui somewhat into openttd itself.

Hi planetmaker and thank you for joining this discussion

To be honest after I posted that question I started thinking over that proposal.

A Menu option to give "normal" size Menu's and "Large" size Menu's. It would mean ogfx+biggui to some degree would be part of OpenTTD.

But immediately I found a show stopper. The original sprites enlargement, case as far as I'm aware, I never seen them enlarged and don't know how good they would be. And not giving users of the original sprites large menu's would be against the work you guys have put to have everything that works on opengfx also available in the original sprites.

[Michi_cc]

The only way to adjust that is a setting somewhere which allows selecting UI in different sizes, thus integrating ogfx+biggui somewhat into openttd itself.

Q'n'd idea: Put a GUI zoom selector somewhere into the game options and use that to select the sprites just like the normal sprites are (i.e. either supplied via container v2 or scaled by the game).

[planetmaker]

The only way to adjust that is a setting somewhere which allows selecting UI in different sizes, thus integrating ogfx+biggui somewhat into openttd itself.

Q'n'd idea: Put a GUI zoom selector somewhere into the game options and use that to select the sprites just like the normal sprites are (i.e. either supplied via container v2 or scaled by the game).

That certainly would be an option as well. When I wrote my reply, I thought about a new action5, but this sounds nicer.

[Zephyris]

Q'n'd idea: Put a GUI zoom selector somewhere into the game options and use that to select the sprites just like the normal sprites are (i.e. either supplied via container v2 or scaled by the game).

I don't think this is that "dirty" an idea, It would certainly functionally work well, and would look no worse than the extra zoom levels in the isometric viewport.

[Zephyris]

Having said I might not have time to do the gui I though I would have a go at it anyway... There will be some gui elements in the repo soon.

[sweetdude]

Should I report the 8bpp sprites I find anyway?

I guess wait till the next nightly comes out...

Is there a release schedule implemented recently or something? A while back there where multiple releases a day, has it changed to 1 a week or so?

[Rubidium]

Is there a release schedule implemented recently or something?

Not really, but injury and illness makes it hard to keep up. Furthermore pushing a new version now will fail to compile because some sprites are missing/broken. Some of these sprites even used to be correcter a few days ago and for others they should be automatically generated, so they might just have been forgotten to be committed.

[Zephyris]

Is there a release schedule implemented recently or something?

Some of these sprites even used to be correcter a few days ago and for others they should be automatically generated, so they might just have been forgotten to be committed.

I have been doing some big updates to generation of the mask sprites, and some sprites got broken on the way :s It should be fixed now.

Not really, but injury and illness makes it hard to keep up.

Sorry to hear that I hope you are feeling better soon.

[Digitalfox]

... but injury and illness ...

Get Well and Best Wishes for Your Recovery Rubidium

[Rubidium]

... but injury and illness ...

Get Well and Best Wishes for Your Recovery Rubidium

The injury was Zephyris' finger and the illness just a common cold that I seem to have survived.

So, with further ado... a new 'release' of zbase. The ado being the compile farm actually compiling it, which takes at least an hour, or even waiting for the time when the nightly runs.

[Tafidis]

Hello,

I 've been pre-occupied with work and have missed this until now ...

WOW!!!

to Zephyris and all coders involved: Thank you very much!

What an amazing initiative, you guys are really making a lot of people happy! (well, me at least)

Just my 2c:

I have the feeling (although I don't understand all the details, after reading all the posts twice) that Lexa2 has a point w.r.t. mapping CC and other colors that change dynamically.

@Lexa2:

The "cubic spline interpolation" looks best, perhaps it would be useful to get some performance comparison in more ***real*** conditions (as I understood you just forced all sprites to be redrawn or something)
Of course having a setting to allow trade-off between performance-aesthetics would be great. I, for one, like to play with manageable numbers of trains (up to a couple of hundreds) on small-medium maps, so I would like an
option like that.

Again, a million thanks!!!

[Alberth]

Hi,

devzone seems down, and in case you're wondering what to do next, here are some issues

wrong_tile_pattern.png (446.25 KiB) Viewed 4399 times

The pattern at the grey tile is wrong, the others seem fine (Edit: Also the same green tile, see further to the right)

toy-shop and sweet-shop (-factory): There is just 1 middle sprite instead of 2 in zbase

toffee quarry, the opengfx base set has one more sprite than zbase

bubble generator has just 5 sprites, instead of the 10 that you have (right, middle, and left, a tube, and the moving block).

bubble_gen_result.png (204.8 KiB) Viewed 4399 times

is what I made of it. Bubbles are still 8bpp.
While you are at it, maybe you can improve the right pipe at the NE too, now it looks obviously unconnected.

Not all bad news though, your candyfloss forest looks delicious!

candyfloss_result.png (1.05 MiB) Viewed 1603 times

(also with swapped tile colouring, but I assume this is intentional)

Edit2: And your plastic fountain animation is very good too! It brings back good memories of the original baseset to me.

[Zephyris]

Thanks for the info, I though there would be quite a few things to fix. I do wish the sprite organisation for the default OpenTTD instries was more logical!

[Dimme]

Amazing how you've managed to create this nice set so quickly!

One of the steelmill tiles looks unfinished:

steelmill.PNG (680.26 KiB) Viewed 4221 times

[Zephyris]

Unfortunately I start a new job tomorrow which means the time I can spend on zBase will drop sharply

Fortunately it is quite close to finished! I would really appreciate it if people can help me out with:

1. Spotting bugs. In particular sprite misalignments. There are certainly a few of these, especially on complex structures like bridges. These can be reported here: https://old.dev.openttdcoop.org/projects/zbasebuild . Reports would be even more appreciated if you can use the sprite aligner tool (see https://wiki.openttd.org/NewGRF_Debugging) to work out the correct offsets and include those in the bug report.
2. Spotting graphical bugs. This might be things like company colours not working correctly or graphics that just look strange. These can be reported here: https://dev.openttdcoop.org/projects/zbase . Screen shots are very useful for this type of report.
3. Spotting missing graphics. It would be great if people could list missing graphics as bugs here: https://dev.openttdcoop.org/projects/zbase . This makes it easier for me to work out the last few sprites that need drawing.
4. Drawing the GUI. I would like to include double-width GUI elements drawn in Inkscape. I have started these for the main toolbar, but there are a lot more sprites to be made. The style is simple (1px black borders and subtle gradients) and any help drawing these would be appreciated.
5. Screenshots & savegames. Nice screenshots of zBase in action would be appreciated. Similarly savegames in vanilla OpenTTD (i.e. no newGRFs) with built up towns and infrastructure are very useful for spotting bugs.

With all bug reports remember to check if someone has already reported it!

I hope you all like the graphics, and hopefully it will give OpenTTD a new graphical lease of life.