32bit Graphics Extra Zoom Patch

[GeekToo]

Parallel to some new developments I will present in this thread sooner or later, and complying parts of the code to the standards, I've been working on some issues in the zoomed out level, that were reported in this thread:

-8bpp sprites not resizing right when zooming out
-black pixels on the sloped ground sprites

If someone still sees something wrong in the screenshot( a deliberate mix of 32bpp and 8bpp sprites), please post a reply, now that I'm working on it.
--
PS Ben: I tried to reproduce the problem with the crashed trains, but I couldn't (which does not necessarily mean there is not a problem) . It's just hard to fix a problem I can't reproduce.
I tried for about an hour on zoomed in and normal level, stopping one of the trains, building the missing track and let the trains crash (which btw pointed me to the fact that the crashed vehicles palette definitely needs some work still). When the crashed trains were removed from the game, everything continued normally. So maybe you have to increase the sprite cache size. If someone else can reproduce this, please report so, preferably with debug logging.

[Ben_Robbins_]

hmm I'm very puzzled, I just tried doing the same test again and I can't get it too crash.

I originally tested it 4-5 times, and it consistently happened at the same point. I then checked it with 'crashtest.sav' and it worked. I then uploaded it, and downloaded it from here and checked once more and it worked. I can still make it happen in V6 though...but...I deliberately checked before posting that it was v8, and I was testing some new sprites also which I can see now on checking are not in the sprite folder for pre v8 versions, so I wouldn't have been playing pre v8, unless I am just going mad, which is very possible. So I am very puzzled, and I shall check for it again on the arrival of newer builds. Sorry for taking an hour of your time, and thanks for taken so long to check it out!

I can't see any incorrect scaling on that image though so good work!

[Roujin]

Ok, examined your screenshot and there are three spots that came to my attention..

a) (red) the factory seems to have a hole between some sprites, you can see the ground through it
b) (yellow) something is misaligned at this piece of track
c) (blue) what are these white spots at the border of the farmland?

[Korenn]

some of those white spots should be fences, but some of them appear to be bugs

[GeekToo]

Sorry for taking an hour of your time.

Don't be, I do have some experience in software deveoping, and did learn the following the hard way:
-The most disastrous and reproducable crashes are usually the easiest to solve.
-When 1 user has a problem I cannot reproduce, that's usually an indication that there indeed is a problem. The fact that I cannot reproduce, can be caused by different hardware, memory problems etc, etc. Esp. memory problems can cause very random crashes, and are sometimes hard to find. I don't know whether this is the problem here, if I did know, the bug would already be gone..

Because the non-reproducable, intermittent bugs tend to stay in the software as last bugs, I learned to invest some time into them immediately when they arrive. So I'll put it on the bug list anyway, and if it does not happen again for some time, like a month, I'll classify it as an incident.

@Korenn and Roujin: Thanks for finding that, guys. I did find a small bug in the resizing algorithm that caused the white fences to leave a white spot app. half a tile to the right, and did not align the industries right in some cases. I've already solved it, so it should be fixed in the next update. This is exactly one of the reasons why it's nice to develop open source software: fast feedback, and thus fast quality improvement. I mean, this patch is not even a month old, and I feel it's already improved big time thanks to the feedback.

[GeekToo]

Sorry for the double post, but here's a new revision.

Changelog V9
==============
-8bpp sprites were not scaling right when zooming out
-8bpp sprites were not interpolated right when zooming out
-corrected black pixels on the sloped ground sprites when zooming out
-first effort to comply the code to the standards
-added interpolation when zooming in on the 8bpp sprites, just to make a slightly better image from the original sprites when zooming in. Not perfect in any way, but it will get obsolete when more 32bpp sprites are available.
-company colour was applied in full saturation where the sprite had rgb 0,0,0, i.e. when the original was completely black.
-Compatibility with trunk tars ( for zoom 2 and above ). This caused the graphical problems of Bazil14. So now you can use the 32bpp tars for trunk for the more zoomed out levels.

[DeletedUser5]

Great! This time first
How about kind of additional sprite for crashed vehicles. For example your bus isn't in full company colour. As I guess a lot of vehicles won't be made in full CC so it would be great implementation.

[Nickman]

Again, here are the windows binaries .

Have fun with them!

[SupSuper]

I've spotted a bug on v9. When zoomed in, the 8bpp sprites show black gridlines between the tiles.

[GeekToo]

@ Soeb: crashed vehicles in the original game are created by changing the palette. If we want to use different sprites for crashed vehicles, we would have to add extra sprites, and I don't know how to do that. The original game just uses a different palette to show crashed vehicles. Maybe it is possible by means of newgrfs (I could ask DaleStan whether it is possible to add extra sprites for crashed vehicles). I like the idea of new sprites for crashed vehicles, and I don't like the format of newgrf, but if that is the only way to do it, so be it.

@NickMan: Thanks(again) for adding the windows binaries!

@SupSuper: The gridlines are caused because I implemented a simple interpolator that does not take into account the transparency. So for transparent areas it interpolates with rgb 0,0,0. So this is not a bug (when you define a bug as erroneous behaviour), but a property of the iinterpolator. I can improve that, but as I said before, this is only temporary, just to create a nicer picture for the zoomed in 8bpp sprites. When more 32bpp sprites are available, this issue will become obsolete. And to enforce that I don't want to become the 8bpp sprite to look too good or else 32bpp will never be created , so this is not very high on my prio list.

[Eddie]

And to enforce that I don't want to become the 8bpp sprite to look too good or else 32bpp will never be created , so this is not very high on my prio list.

Good idea, make 8bpp unbearable so that everyone has to finish the 32bpp project.

[DeletedUser5]

@ Soeb: crashed vehicles in the original game are created by changing the palette. If we want to use different sprites for crashed vehicles, we would have to add extra sprites, and I don't know how to do that. The original game just uses a different palette to show crashed vehicles. Maybe it is possible by means of newgrfs (I could ask DaleStan whether it is possible to add extra sprites for crashed vehicles). I like the idea of new sprites for crashed vehicles, and I don't like the format of newgrf, but if that is the only way to do it, so be it.

I know. I though there is a way to do it. Like mask is ****_z*m.png so I think there is a way to do it somehow to use ( only when it exist, if not just change palette ) additional sprite for crashed vehicles.

[peter1138]

The original game just uses a different palette to show crashed vehicles. Maybe it is possible by means of newgrfs (I could ask DaleStan whether it is possible to add extra sprites for crashed vehicles).

Bit 7 of property 0xB2 is set when a vehicle is crashed.

And to enforce that I don't want to become the 8bpp sprite to look too good or else 32bpp will never be created , so this is not very high on my prio list.

But less chance of the developers accepting it. A basic zoom with no interpolation is preferable to these artefacts.

[GeekToo]

Bit 7 of property 0xB2 is set when a vehicle is crashed.

Ok, thanks, I do not know newgrfs very well, but I will have a look at the patch wiki, and try to understand this. Of course, anyone that already does, feel free to post a newgrf.

But less chance of the developers accepting it. A basic zoom with no interpolation is preferable to these artefacts.

Mmm, you just managed to get it a lot higher on the prio list. So I've got 3 options:
-leave it as it is now (not the preferred option by at least one of the developers)
-improve the interpolation
-revert to the previous version as far as it concerns the zoomed in 8bpp sprites

Since the issue will be obsolete when more 32bpp sprites are available, I think it is going to be option 3, but I'm willing to listen to the users. So if you all think it should be option 2, I'll go for that, so provide some feedback please.

[SupSuper]

I think option 3 is fine, better focus on bigger priorities, and no matter how much you try to enhance it, a 8bpp sprite is always a 8bpp sprite.

[GeekToo]

No matter how much you try to enhance it, a 8bpp sprite is always a 8bpp sprite.

Wise words

After some distraction in graphics I did some coding: I ran a gprof profile, and did manage to optimize the blitter with 15% (and there's room for more). Not a very spectacular feature for the average user, but performance is always important in games.

Which leads me to the following question: which improvements/features are considered most urgent?

[maquinista]

I have made (with GIMP) the sprites 1035 and 1036 with the sprites 1013, 1014,1015 and 1016. Is only the z0 tiles.

I will try it with the sprites 1023 - 1030, but it could be more dificult.

Edit:
Sprites from 1023 to 1026 has been made.

[DeletedUser5]

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.

[athanasios]

And shadows are wrong.

[maquinista]

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.

Thanks. I will download it.