Transport Tycoon Forums

This shouldn't be mistaken with previous 32 bit graphic replacement attempts, it's a completely new development.

Sometimes a clean start is more efficient. It is very sad to be ignoring some fantastic graphics though (I particularly like ben_robbins_'s coast sprites http://jupix.info/openttd/gfxdev-repo/i ... ile&id=248 ). One day I hope my graphics are that good

What buildings and other stuff is included in the zbuild?

A few things I have drawn aren't coded yet, mostly due to mistakes on my part in the precise requirements of the sprites; e.g. not splitting the foreground and background on the bay-style bus and truck stations, not splitting the HQ buildings from the ground tiles. Alberth and Rubidium are doing an amazing job keeping up with my drawing (although a couple of alignments do need tweaking!).

Progress drawing so far is:
Terrain tiles (grass, mud, rocks, etc.).
Water and coasts (need some work!!!).
Foundations (including extra foundations).
Road (town and city).
Road depots and bus/truck stops.
Rail, monorail and maglev.
Rail, monorail and maglev stations and depots.
Tunnels.
Level crossings.
Bridges.
Temperate and arctic trees.
Farm tiles (crops).
Farm fences.
Landscape items (transmitter and lighthouse).
Many industries (coal mine, power station, oil wells, oil rigs, oil refinery, forest, sawmill, paper mill, iron ore mine, copper ore mine, gold mine, diamond mine, water tower).
Some temperate town buildings (~6 different buildings).

All in all fairly good progress, a long way to go though.

Road stations have not been done, as there are some graphics problems with it that need to be fixed first: https://dev.openttdcoop.org/issues/4090

But Zephyris.... where's the noise???

Great effort! And I like it how zooming out doesn't hurt my eyes anymore (ironically a by-product of creating zoomed-in sprites .

Current state for interested-people-but-not-enough-to-download-150MB (see attachment... these also grow a lot in size with 32bpp!)

FooBar wrote:

sweetdude wrote:getting this package back on the road again.

Back? It's never been off the road since it started two weeks ago
This shouldn't be mistaken with previous 32 bit graphic replacement attempts, it's a completely new development.

My humble apologies about this

But for the average Joe, this is just the newer 32 bit graphic replacement pack or 2.0 version if you want.

My humble apologies about this

No problem, I will take it as a compliment!

Zephyris wrote:Sometimes a clean start is more efficient.

Honestly at this point it's what it has been needing since recent events.

I'm ecstatic to see you working on this since it basically means there's a very real possibility of a full set releasing "soon-ish". It's what I always wanted for OTTD anyway.

All that makes me sad is my years of work not meaning much any more.

Jupix wrote:All that makes me sad is my years of work not meaning much any more.

One giant step for mankind ....

and all that

Jupix wrote: All that makes me sad is my years of work not meaning much any more.

Couldn't this be used to also support your 32bpp project?

Jupix wrote:All that makes me sad is my years of work not meaning much any more.

Why?

zBase is very nice, but the previous work could be a nice different set.

The problem is that every X years, some work is "wasted", for different reasons. If You want, We can discuss about that in the "high grass project" thread. It would be a good idea to have two projects finished. I can help, but we need to define the project, because I don't want more regressions (for example, Ggtextures allow to release rendered sprites under GPL, but that is not "enough GPL").

Also, if this set is GPL, We can share some sprites or models.

maquinista wrote:Also, if this set is GPL

It is.

I agree with you that the 32 bit replacement project isn't a waste. Basically it "just" needs someone to sort out the license issue: figure out what is GPL'ed and has sources and try to contact authors where that isn't the case. And then nothing stands in the way of creating a proper release. Maybe static NewGRFs that can be loaded on top of a fully completed base set is the best choice at the moment, which can later be transformed into a full base set. But that's something for one of the other topics.

Back on topic, I've just started a new game with zBase, and I'm impressed with the amount of work done in relatively short time.

maquinista wrote:(for example, Ggtextures allow to release rendered sprites under GPL, but that is not "enough GPL").

Nothing dictates that a base set for OpenTTD must be GPL, so it is always possible to take the old 32bpp sprites to make another base set. The GPL only comes into play if you want to use some parts of OpenGFX or zBase for it.

Of course, even for a non-GPL project, you'd need appropriate license/permissions for the sprite.

-- Michael Lutz

Sorry for a bit offtopic question, but how does the license compatibility issue is expected to be handled for a thing like "TTD baseset", which is de-facto a collection of the separate works done by various authors. What if, for example, some sprites (and related source files) are licensed under GNU/GPLv2, while some other are licensed under incompatible GNU/GPLv3? Could such sprites end up being distributed inside one "baseset"? Or should be this "baseset" splitted out in a number of parts with each part containing sprites that are distributed under mutually compatible licenses? Its not a question of a great importance for me, really, I'm just curious about it.

The base set GRFs are not splittable, so all sprites in one GRF must have a compatible license.

Rubidium wrote:in one GRF

For the GPL specifically I'd even think the complete baseset (with all its 6 GRFs) forms a single work and is GPL as a whole. GPLv3 and GPLv2 (without a 'later versions' clause) can't be mixed in that form.

-- Michael Lutz

Rubidium wrote:The base set GRFs are not splittable, so all sprites in one GRF must have a compatible license.

Yeah, forgot about the fact that basesets should be made as a "almost" single GRF. But from your answer it could be concluded that the most relaxed for of requiremet is for all sprites inside one GRF to have compatible licenses. I'd expected something like that but it is still good to know for sure .

Meanwhile I have another worry to share . Today I've been toying a bit with zBase debugging some issues in 32bpp-anim-aa blitter and had run into pretty annoying fact. I know that it's WIP and all but it looks like tile masks (or some other method that is being used to produce correct border shape for tile sprites) are not what they should to be to allow for (a) seamless intermixing with land tiles from "legacy" 8bpp tilesets and (b) seamless "join" of the land tiles inside zBase itself.

If you take a look into two attached screenshots you could notice that (a) there are visible seams between older 8bpp sprites and new 32bpp ones and (b) there are even visible seams between 32bpp sprites themselves. These screenshots had been captured using original 32bpp-anim blitter + a special "patched for gfx development" version of OTTD which fills every screen area it is going to redraw with a pre-defined color (yellow in this case). Filling is done in the ViewportDoDraw() routine right before calling ViewportAddLandscape(). In ordinary OTTD version these seams wouldn't be that visible because they'd be filled with "garbage" that had been left there after previous viewport drawings but could be very annoying as at some circumstances (especially at 32x zoom level) they would show up themselves like a "random garbage visible" which they really are.

It should be noted that this is not a "simple alignment issue", and it could not be fixed by changing sprite alignment for land tiles. Problem is in the land tiles themselves. There's another pic attached to this post illustrating the cause of the problem. Solution would be (a) to fix tile borders so all the pixels there are opaque and (b) in case intermixing with older 8bpp sets that haven't got 128x62 and 256x124 (yes, 62 and 124 are not an error - that's the exact dimensions of the original 64x31 sprites auto-scaled by the engine to the higher zoom levels) sprites supplied is desired then all tile shapes should be made matching shapes of the original tiles enlarged 2x and 4x times with the nearest neighbour algo.

LeXa2 wrote:seamless "join" of the land tiles inside zBase itself.

It's no problem or error but intentional by design: Tiles are supposed to have and show a border.

EDIT: In the interaction with 8bpp it indeed shows undefined pixels which is somewhat a problem. But that's difficult to solve - but it's less apparent with existing blitters.

planetmaker wrote:

LeXa2 wrote:seamless "join" of the land tiles inside zBase itself.

It's no problem or error but intentional by design: Tiles are supposed to have and show a border.

Sorry but you're wrong. If flat tiles that being placed by engine in 256x128 grid would not opaquely cover the entire area they're expected to cover - you'll be in trouble. Problem of "showing the border" is a thing of another matter - it's just "pixel near border coloured differently from inbound part of the sprite" and nothing more, and not "pixels near border having alpha values other than 255".

Consider standard situation of the viewport being scrolled to a some amount. Part of the screen pixels would be simply copied by blitter's ScrollBuffer() method, and rest would be drawn using ViewportDoDraw(). Engine does not flush the contents of the backbuffer (DIB in case of Windows, some other "bitmap" in case of Allegro or SDL) before drawing the sprites. It's not a problem if every target pixel would be replaced, but in case our "basement" has semi-transparent "seams" between tiles - we would end up with alpha-blending applied at that places mixing new output with the older contents of the backbuffer. If you happen to scroll a water area into a place where previously green "grass" tile had been displayed - you'd get a green showing up between the tiles. And so on.

You could easily test it yourself: download 256_0002.png for temperate climate, create a new canvas in GIMP big enough for 4 256x128 tiles to be visible, activate 64x64 grid so it'd be easy to arrange tiles in the same way the engine does, import 256_0002.png as a layer, duplicate it four times and arrange them using "snap to grid" as a handy helper. You'd end up with something like shown in the attached picture. I had cropped most interesting part and enlarged it to 300% so semi-transparent seams could be easily spotted. If that is really how it is supposed to be "by design" - then the design most probably needs fixing .

This is basically a can of worms that has been discussed to length in this topic: http://www.tt-forums.net/viewtopic.php?f=36&t=59251
I don't remember the outcome, but it may be worth reading before you end up suggestion all kinds of things that were suggested before.

FooBar wrote:This is basically a can of worms that has been discussed to length in this topic: http://www.tt-forums.net/viewtopic.php?f=36&t=59251 ...

Thanks for pointing on that, pretty interesting to read. Nevertheless, I don't want to turn this thread into a place for a heated discussion like had been held there, thus I'm not going to post my thoughts about "compatibility vs. existing 8bpp sprites" problem. Still, problem with semi-transparent seams between full zoom tiles is there and it has nothing to do with "compatibility", it's just tiles being made _slightly_ wrong (borders should be "sharp", no semi-transparent places should be left in process of ground tiles layout).

BTW, I've got a patch I made while been testing blitter that could be handy in debugging sprite-alignment issues. What it does is basically hi-jacking "Draw Bounding Box" feature and replacing it with a "draw landscape wireframe". How does it looks like and why could it be handy in fixing sprites alignment issues vs. zBase could be easily seen on the attached screenshot. I could post this patch here or in the development forum if somebody is interested in using it.