32bit Graphics Extra Zoom Patch

[Slye_Fox]

i modeled the freight wagons.

[LordAzamath]

Not all the people are like long trains. And usual ones is a classic. So it should be version of patch to usual trains.
Right now long trains with standard graphic are looking ugly. Sorry.

Same here.
Why is it not possible to make the length of the sprite variable, just like current 8bpp sprites?

Well it IS possible. Just code a train grf with other lenght and get tge 32bpp graphic to replace sprites there.

32bpp is purely sprite replacement. No coding can be done with it, it just replaces sprites from grfs. To get another lenght, you'd have to code it. And btw IIRC you can't get longer train wagons even with 8bpp anyway, but I could be wrong

[Zephyris]

If the "shorten vehicle by this many eighths" train action 0 property could be extended to allow elongation of the train...

[ArmEagle]

I only played with this for a short moment (and haven't been playing before that for a long time).
Got to say that this really looks neat! Especially the details in the train/wagon models are astonishing!

Just for playing with it, I added the normal 32bpp power station tar to the data folder for this zoom version. But then when you zoom in, it will fall back to the basic models. I don't mind graphics to get a bit grainy from zooming in (especially since like only like 5% of all graphics are converted now). Wouldn't it be better to fall back to normal 32bpp graphics if there are no z0-2 versions?

Also, it looks like the zoom-executables include new selector graphics. But these don't support the 'blueish coloring' when using drag&drop and highlighting (in the normal client, without 32bpp selector tars the highlight area uses blueish lines. The same happens when I use the normal 32bpp selectors in the normal client. So I guess it's not a specific issue for this zoomed version of the game, but I thought I'd mention it.

[Teemes]

i modeled the freight wagons.

Whoops, sorry, thought those were by Ben. I stand corrected. Great job on those, too!

[GeekToo]

Your mistake is understandable: SlyFox made the meshes, and Ben did the texturing and codecing for at least several of them.

Still busy with syncing to lastest trunk revision. A bit harder than I thought, cause Smatz did some modifications in trunk, that make the merging, well, let's say .. challenging..

[ArmEagle]

Continuing on finding 'issues'. It seems that preference is given to newgrf sprites over any available 32bpp graphics. I'd like to see it the other way around.

[GeekToo]

Just for playing with it, I added the normal 32bpp power station tar to the data folder for this zoom version. But then when you zoom in, it will fall back to the basic models. I don't mind graphics to get a bit grainy from zooming in (especially since like only like 5% of all graphics are converted now). Wouldn't it be better to fall back to normal 32bpp graphics if there are no z0-2 versions?

This point is still under discussion. I started with the way it is now, and don't upscale z2 32bpp graphics to z0 because it just looks ugly.
But there are more people than you that expressed that upscaling 32bpp z2 to z0 would look better than 8bpp (and among them were even OpenTTD devs) so I'm slowly considering to implement this.

Also, it looks like the zoom-executables include new selector graphics. But these don't support the 'blueish coloring' when using drag&drop and highlighting (in the normal client, without 32bpp selector tars the highlight area uses blueish lines. The same happens when I use the normal 32bpp selectors in the normal client. So I guess it's not a specific issue for this zoomed version of the game, but I thought I'd mention it.

Good point, didn't check this, but that could be just a matter of adding more pngs to replace to originals. If it is a matter of pallette adjusting, I guess I will have to take a look at the code

Continuing on finding 'issues'. It seems that preference is given to newgrf sprites over any available 32bpp graphics. I'd like to see it the other way around.

Thanks for the feedback, but I don't quite agree with you on this one.
Let me explain that a bit.

32bpp pngs are meant to replace original graphics, or newgrf graphics.
A newgrf can specify it wants to replace an original graphic, or other properties of the original game. A 32bpp png can only replace a graphic, not properties.

So if an original graphics is replaced with a 32 bpp png, and the newgrf specifies it want to replace the original graphics, the original graphics should be replaced, even if it is a 32bpp png.

But, 32bpp pngs can also replace newgrf graphics, so if you want a newgrf to replace an original graphic, and have 32bpp graphics, just create a directory bin/data/sprites/xxx where xxx is the newgrf name and put pngs in that directory that replace the newgrf graphics with 32bpp ones. The sprite number must be as specified by the newgrf.

So summarized:
-to replace only graphics, don't use the newgrf, and replace with pngs in the bin/data/sprites/trg1r (and other) directory.
-if other properties need to be replaced, use the newgrf, and replace the graphics of the newgrf by putting pngs in the bin/data/sprites/newgrf directory

[ArmEagle]

Ah, seems that I don't know half of it. But as long as 32bpp can override 8bpp newgrf sprites the way you said it, I guess that's just fine then!
Edit:Ah, that works indeed. I got annoyed by the ugly catenary, so I did some pixel painting (I'm SO not good with 3D tools), but I'm not done yet. (Using and overriding the Dutch Cat newgrf, since somehow there doesn't seem to be sprites for catenary in the base grfs. Shame that they somehow added one fence part, though perhaps that's necessary for something.).

I'm still so hyped seeing these great sprites! Though it's probably years out till even only the basics are completely covered.
Edit: This totally spoiled me from the basic graphics though. I mind it less if all trains (duplicated the one train to some other train's sprite IDs just for myself), bridges, trees (for myself I did some simple duplication on the trees, changing colors a bit) some, etc all look the same, than that I have to look at the basic sprites .

I wish The Gimp could work with the attributes. I can't figure out what PNG 'method' this is using. It isn't plain comments, and doesn't seem to be plain attributes either (ImageMagick's set attributes doesn't seem to do the same either).

[GeekToo]

Finally I managed to sync it with latest trunk revision (at least the version 9 of the patch). If you detect something that does not work (esp when it did work before) please report in this thread.

[Teemes]

Hey GeekToo!
I found a strange behaviour in v10 of the patch (applied to r12754). I figured that maybe I could get a variable vehicle length by using a newgrf and aplying an action0 property21 (shorter vehicle length). With a value of 04, this should lead to a vehicle that is half the length of the original one. This works as intended for the unpatched version of OTTD (exhibit A. The modified passenger carriages are only half as long as normal. Never mind them overlapping each other, that because I just changed the properties, not the actual graphics[1]...). So for the 12.5m vehicles in v10 this should give me a sprite length of 6.25m, right? No such luck. While the distance between the vehicles is definitely shorter in the depot (though still nowhere half of the original dimensions, exhibit B) on the actual track the distance is the same as for the unmodified vehicles (exhibit C). An interesting thing occurs when the train is at the end of the line and turns around: the distance between the last and the last-but-one carriage is significantly smaller now for some reason (exhibit D). At this stage, the game is very likely to terminate with an assertion failure sooner or later, especially if the track layout is more complicated than pictured...

In theory, can I use action0 property21 in the way described above. i.e. is the behaviour I observed only the result of a bug that can be fixed or does the way you implemented the longer vehicles exlude the use of this newgrf trick? Would be nice to have vehicles as short as 4.68m or as long as 12.5m (that would be the range of property21). Also, Ben Robbin's/Slye Fox's graphics could be reused by writing a "simple" newgrf and overriding the 8bpp sprites.

[1] ok, I added a red "A" (for some reason) to distinguish the modified and the unmodified graphics...

Edit: a new V9. Yay!

[mucha0815]

can someone upload a compiled version? thanks

[reylas]

can someone upload a compiled version? thanks

And with NoAI? That would be cool. GeekToo, you have to be running both

Thanks,
MarkS

[mucha0815]

Finally I managed to sync it with latest trunk revision (at least the version 9 of the patch). If you detect something that does not work (esp when it did work before) please report in this thread.

hmm, i cant find revision 13693
with the newest trunk i got problems with gfx.cpp

[connan]

You can downgrade through SVN. I personally prefere tortoise SVN client.

[GeekToo]

Teemes,

Thanks for trying that. You're right, it should be possible to shorten the trains by means of newgrf, but I never tested it because
coding newgrfs is not one of my favourite activities, so that probably is a bug in the V10 version

Unfortunately, newgrfs only offer a possibility to shorten the trains, not lengthen them or give an absolute length.

That does complicate things quite a bit, i.e. with the changed defaults of V10, it would mean that every train would have to be
newgrfed, just to make it look right again. I have not really decided how to handle that, so any good ideas are welcome

And with NoAI? That would be cool. GeekToo, you have to be running both

Yes, I am indeed. Because NoAI is synced with trunk frequently, and does not modify much ( if any ) of the files I changed, in theory it
should be possible to apply the patch to the NoAI branch, though I've never tried it, to keep my project dirs a bit organised.

with the newest trunk i got problems with gfx.cpp

gfx.cpp is changed in trunk recently, so downgrade, or to save you the hassle, use this update

[ArmEagle]

I'm still running r12030M here, with several 32bpp(-zoom) sprites added. And I just got this error for the second time:
"Out of sprite memory"

And then an assertion failed:

"ottdsrc/trunk/src/openttd.cpp"
"Line: 112"

"Expression: 0"


Both times this happened after the game was running for up to half an hour. And it happened after I zoomed in completely, then panning the view with the RMB.

[connan]

Have you changed the sprite cache size to 64? (openttd.cfg)

[ArmEagle]

Have you changed the sprite cache size to 64? (openttd.cfg)

Yes, I had to check, but it's at 64.
Edit:I've been playing for some time again, and it hasn't crashed since (reboot between these sessions).

[ArmEagle]

Ben is working on it and those two sprites that you posted were already done ( forgot to add that in my post ). And those are based on old version.

That's posted quite a while ago. Is there any chance all (normal) track sprites are done for _z0 now and that it just isn't updated on the wiki yet? I'd love to play with the set completed.