32bit Graphics Extra Zoom Patch

[Lord Aro]

what i did was download the source from the ottd website and the patch from openttdcoop website then complie them using mingw
also, i note that i didnt have liblzo2 but i dont think that should matter too much should it?

[GeekToo]

clean checkout from ottd should do it: svn co svn://svn.openttd.org/trunk testdir
svn up to correct rev

First try a clean trunk compile: http://wiki.openttd.org/Compiling_on_MinGW
If that works apply the patch.
I haven't compiled on mingw since my virusscanner decided that msys is an extremely dangerous program that should not be started (even paid money for the thing ), and normally I compile on Linux, so I cannot really help you with that.

Btw, its fixed now on the repo.

[Bus]

Hm ok so now I have one more question. I don't really know anything about extra zoom or 32bpp so I'm probably missing some very basic information. When I run the game, some of the graphics show up and others don't. For example, only the basic electric signals use new graphics, all other signals use old ones. I'm running r19615 with patch from the previous page of this thread, opengfx 0.2.4 and BaseSet.tar downloaded from some place I don't remember anymore . I can clearly see the png files with signals in the 32bpp_extra directory but the game uses the old low-res graphics from opengfx.

EDIT: Oh right and the question is: how do I fix this?

[GeekToo]

The signals are not yet added to the 32bpp-extra newgrf, or better, the signals are in the newgrf, but the 32bpp sprites that accompanies that are not.

If there is a tar with a 32bpp-extra directory that you loaded from Jupix repo, you need to load the 32bpp-extra newgrf from: http://dev.openttdcoop.org/projects/32bpp-extra, and activate the 32bpp newgrf ingame.

[Bus]

Thanks! I didn't know about the grf. OK now the signals do show up but... they use wrong images (i.e. an image of a different signal and/or in a different direction). Could this be some sort of version collision?

[maquinista]

Thanks! I didn't know about the grf. OK now the signals do show up but... they use wrong images (i.e. an image of a different signal and/or in a different direction). Could this be some sort of version collision?

It's a problem of the number of the sprites.

[Bus]

So does that mean that my BaseSet.tar is somehow invalid? Is there some official place to get the latest graphics packs from?

EDIT: OK so I just discovered the repository . I've downloaded the Wotan signals pack and the results are the same. I assume this means that the pack in the repository is faulty. Is there any way to fix it?

EDIT2: I figured out how to rename the files to get the correct signals. No more help needed .

[maquinista]

So does that mean that my BaseSet.tar is somehow invalid? Is there some official place to get the latest graphics packs from?

EDIT: OK so I just discovered the repository . I've downloaded the Wotan signals pack and the results are the same. I assume this means that the pack in the repository is faulty. Is there any way to fix it?

EDIT2: I figured out how to rename the files to get the correct signals. No more help needed .

Not, the problem if the same of all users.

The number of the spries have wrong order. It could be fixed if someone puts the correct numbers of sprites in the TAR file. Maybe this takes a lot of time.

[Ben_Robbins_]

In relation to implement improvements. I've sometimes not stated things becuase it is a little easy to say 'I want' but I do have a list I've put together as I've seen bugs, so I'm going to just bring a few into debate. There are 3 types of bugs really.

* There are game play issues unique to the new FZ builds, such as, now solved(?) selecting town information issue.
* There are bugs that exist both in FZ and trunk but are particularly exposed by zooming in on them (or exposed by 'solutions' to fixes such as the embankment issue).
* Thirdly there are ideals. Dreams almost of where this is going. For instant in the original proposals the tracks had long curves up smooth flowing hills. I think this is a bit extreme, and I think it actually it would be a different game becuase of the huge fundamental differences. However there are some 'dreams' that I think I would support holding onto, which do not effect game play.

The main issue that most bothers me currently as Geektoo said about, is the embankment sprites drawing order...I've spoken to egladil on this for about 2 days straight..interesting, but I can see the challenge in solving it. Another issue under this '2nd group' is shadows exceeding the bounding box area. The elements outside the allocated area seems not to be called on to re-render until the screen moves and re-renders the lot.

A couple of others to bring into discussion: No coast sprites beneath bridge ends (similar issue to no pavements in city centres beneath bridge ends), and trees/hedgerows and embankments draw orders often having issues. The solution to this I suppose would in part be dealt with by previously stated embankment issue. I think the issue with trees/hedges has a different solution, which could have additional benefits. A slightly different issue again with hedges is there complete disappearance when a road runs along the top-left/right of the field. Hedge shadows are also useless as there on the base layer pass, meaning there hidden. Solvable by hedges having 2 sprites on pass 1 and 2?...(I'll stop there!)

Trees could be split into 2 parts. Trunk and Tree. Trunks would appear on the 1st pass, with the base sprites, much like the canal/river banks. This would mean they don't sit on top of hedges. Also..it would mean we could have trees in the hedgerows which I think is a key part of the landscape. Also it would mean that when trees are made invisible, the stumps would still show, still keeping them 'in play' but not blocking the view. To add to the varying hedgerow types (currently only replaced by the 1 set of sprites), could be used for variation in the hedgerows, rather than having separate sets of hedges. This would mean more could be going on in the hedgerow, without repeated tiles ruining it...

So...there's a few issues to discuss on all different levels of importance....I have plenty more!

So to conclude, I think it's important to have a clear list of changes which we can aim for within a time frame that means we should make graphics for that spec, and changes that we shouldn't make graphics for yet. It's important obviously not to do things twice, considering the size of the project, but it's also important not to hang on for almost ever group of sprites while waiting for changes with an unknown priority/appearance date/probability of appearance etc.

[maquinista]

The hedges shouldn't be drawn as ground sprites. They should have their own bounding box, like the railway fences.

The main issue that most bothers me currently as Geektoo said about, is the embankment sprites drawing order...I've spoken to egladil on this for about 2 days straight..interesting, but I can see the challenge in solving it. Another issue under this '2nd group' is shadows exceeding the bounding box area. The elements outside the allocated area seems not to be called on to re-render until the screen moves and re-renders the lot.

The embankment sprites could be solved in two ways, depending on the area were they are drawn and the surrounding sprites.
The current implementation draws the foundations always over the ground sprites, and this is unnecessary in some cases.

If the embankment is not covering other tiles, It could be drawn as a ground sprite with their ground sprite, and later covered with not ground sprites:

Old screenshot with a good order of appearance of sprites. I think that It could be wrong, because they should be rendered from left to right.

5, 7 and 9 are railway sprites (covered by station tiles).
6, 10 and 11 are embankment sprites.

foundations1.jpg (83.14 KiB) Viewed 3769 times

If the embankment is covering other sprites, It could be solved with a clipping mask (railway sprites near coast tiles uses a clipping mask). The clipping mask depends on the surrounding tiles. The clipping mask allows to draw only when the front sprite will cover the base of the rear objects (vehicles, buildings, shadows...).

Example when the front sprite should cover other elements. Light blue are the shadows.

foundations2.jpg (91.2 KiB) Viewed 3769 times

[Ben_Robbins_]

I'm not sure, but I asume everything with a bounding box is on the 2nd pass, and it's the 3rd pass itself. The railway fencing seems to be on this pass as well. This means that if you move the hedge there then it would have the same issues as the foundation sprite, sitting ontop of bits beneath it like the grass. That is why I suggested maybe the hedge would work like a building with a ground sprite and 2nd pass sprite. Otherwise, as with your suggestion, you would just be replacing a glitch with a new glitch.

The foundation/embanked tiles, rather than, as currently having them on the 2nd pass, have both on the first as ground tiles. I'm not really sure currently why they are an exception...they seem to be the only occurrence where no ground tile is actually present. I spent ages the other night looking in game for situations where having the foundation appear on the base layer would be an issue, and really looking for reasoning as to why it is why it is, but failed...any ideas? Maybe to do with the way there grouped? or is it for some benifit that is no longer apparent in relation to new OTTD features?

2 options in terms of coding then, either try shifting the elements to the first pass, or...a full blown rewrite of how the sprites are assembled!. (The later would be included in addressing the 'very' long train issue.) A potential 3rd way is just having 2 sprites for all ground tiles as people have suggested in the past. Like the hedgerow suggestion. Either way, it's not my call, but in terms of graphical glitch's, that's my reasoning.

[GeekToo]

I took a look a the embankment sprite drawing order today (I've done that before, but now I had my focus on foundation drawing).

Basically, it is a 2 pass system:
-first, the ground sprites are drawn (excluding the sprites on foundation sprites).
-then, all sprites on top of the ground sprites are sorted, from back to front, and put on screen.

The ground sprites for foundation tiles are in the second pass. This has a good reason: if they would be in the first pass, vehicles (drawn in the second pass), would show through the foundation ground sprites in front of them. In other words, looking at the picture Maquinista posted above (foundations2), the area Maquinista showed in light-blue, would be drawn over the foundation sprite.

I'm still not sure about the best way to solve this. In theory, the problem is very well solvable by sorting every sprite, including the ground sprites, from back to front. But sorting is a CPU-heavy algorithm, so this may have performance issues, and I'm pretty sure this is the reason the ground sprites are drawn in a separate pass.

A solution might be to draw everything on a per tile basis: start with the back tiles, find everything that is on that particular tile, including the vehicles, trees hedges, etc. Sort those sprites in the correct order (which should be pretty fast, since it would be a very limited number of sprites), draw them and continue with the next tile.

Problem here is that I don't know whether every sortable sprite (the pass 2 ones) are available on a per tile basis. E.g. I don't know whether the information on which tile a vehicle is, is easily available, or would require a lot of searches through the vehicle list, which is also CPU-intensive. It also would require a lot of coding, I think, so it's hard to do a quick hack to find out.

[NekoMaster]

I can't seem to open the source archive for nightly r36. It appers to be broken as my archiver reports an error while trying to open it. Im on Kubuntu btw, so i have the same archiver that Ubuntu has

[GeekToo]

Hi Neko master, I think you confuse the patch with the 32bpp-extra newgrf:
http://dev.openttdcoop.org/projects/32bpp-extra

Post issues in this thread:
http://www.tt-forums.net/viewtopic.php?f=36&t=47288

The patch does not have nightlies yet. Anyway, I tried unzipping the zip file, and also the source tar.gz, and both work for me, so I'm not quite sure what your problems seems to be.

[Ben_Robbins_]

Geektoo: Thanks a lot for taking a look at the code, very interesting/informative post. Good to see a reason why the foundations are on this pass.

I've attached a diagram for easier referencing. The problem seems to exist on the top 7 (A-F, P); C might be avoidable. On O, G, M, L, J and I do sit on-top of distant tiles, but building sprites would be embanked behind, and trains shouldn't be able to expose this. Are there other considerations for those 6 tiles? 3 tiles I think would be fine (N, K and H).

For your idea on drawing on a per tile basis, do you mean that the 2 pass's are made into 1? If so, would a glitch be the tree shadows (only an issue in FZ), as the shadows rely on the tree's being on a higher level than the ground tiles in order to appear on tiles beneath (on screen). Tree shadows just being a current example of what could apply to many things.

Would the proposal made for the hedge's work here? Where the foundation tiles are split into 2 bits, a ground sprite, and 2nd pass sprite? Need to consider the amount of sprites that would need splitting. In the example, the railway sprites wouldn't need a unique replacement tile, it could share them with roads I think...becuase of the tile edge similarities, and if fully opaque wall makes up the back pixels, 2 sprites, wouldn't change the appearance (doubling 100% opaque having no effect). So we would need 6-7 grass edge sprites, the same for pavement, few for roads ending at the 'cliff edge'. Some building sprites may need to mask parts of the ground tile there on. Not an issue really for FZ, but for trunk it might require a few sprite changes. train/bus Stations, airports etc can also be embanked although like buildings have a sprite on each pass.

<edit> The 2nd image attached shows the 'problem' bits of the tile. Parts of the rail/roads tiles that are unique to those sprites fall into this zone.
<edit2> Making images show!

[Kogut]

Images are invisible.

[maquinista]

We don't need new sprites. We could use the current implementation used in some tiles.

Some sprites are drawn in screen with a mask. There are some examples in the game (1 and 4). Tiles like 3 doesn't need to be redrawn, because They don't cover other tiles.

[zottelloco]

Hey, i have problems witch the 32bpp_extra newgrf. I put the 32bpp_extra.grf and the sprite-folder into the data-folder and activate the grf ingame, but nothing happened. what am I doing wrong?

[GeekToo]

Which version are you playing with?
Which blitter did you start it with?
Which 32bpp_extra.grf did you use?
What did you expect that doesn't happen?

[zottelloco]

Which version are you playing with?

Ottd r20016 (should a newgrf not be independent from the game version ?)

Which blitter did you start it with?

I made an entry into the ottd.cfg:
[misc]
blitter = "32bpp-optimized"
sprite_cache_size = 64

That's the only blitter I know.

Which 32bpp_extra.grf did you use?

32bpp_extra-nightly-r36

What did you expect that doesn't happen?

I expected that there are two additional zoom level, when I turn down the mouse wheel But it does not happen, I can only scroll down to the standard zoom level