32bit Graphics Extra Zoom Patch

[Szvengar]

OpenTTD fullzoom r19546: Win32

Improve cc algorithm: almost fix the company scheme colour.

[akaction]

OpenTTD fullzoom r19546: Win32

Improve cc algorithm: almost fix the company scheme colour.

r19546: has problem with backlighting when you remove road at the zoom level. At non-zoom level is it almost OK.
The same bug with backlighting bus stop coverage

[WaRoX]

What about win64 version? The last one was 32Bpp.r19180.Win64.rar several pages ago.

[Lord Aro]

a win-32 binary will work fine on win-64

[xmirakulix]

Is there a way to pull a 32bpp-ez diff against trunk from the repository on http://mz.openttdcoop.org/hg/32bpp-ez/ ?

[Szvengar]

r19546: has problem with backlighting when you remove road at the zoom level. At non-zoom level is it almost OK.
The same bug with backlighting bus stop coverage

Corrected, re-download from the previous post.

[Creat]

Is there a way to pull a 32bpp-ez diff against trunk from the repository on http://mz.openttdcoop.org/hg/32bpp-ez/ ?

Yes I would also like that very much... It would be ideal if these could maybe be created automatically on commits?
In any case, a current diff would be much appreciated

[WaRoX]

I downloaded latest version of 32bpp and skins yestarday, and I've noticed some bugs (I use OpenGFX):
1. As you see on the attached picture, many buildings (including stadium) are not finished. It is very annoying.
2. On the right side of the picture you see the red bus. All buses are blue, but when they take that position (up direction) they become red. I think that that company colors are missed on this skin.
3. Full map screenshot (Ctrl+G) crashes the game.
4. I like to follow my vehicles using Ctrl + clicking on the focus icon. But it works only in standart zoom. I think that additional zoom levels should support this feature too.

[maquinista]

1. As you see on the attached picture, many buildings (including stadium) are not finished. It is very annoying.

This is because They was not finished.

2. On the right side of the picture you see the red bus. All buses are blue, but when they take that position (up direction) they become red. I think that that company colors are missed on this skin.

It could be a problem of the mask file.

[Creat]

4. I like to follow my vehicles using Ctrl + clicking on the focus icon. But it works only in standart zoom. I think that additional zoom levels should support this feature too.

Actually GeekToo has mentioned on the previous page of this thread that he has implemented just that. So it should appear in one of the next versions I would guess...

[Szvengar]

OpenTTD fullzoom r19600: Win32

[Lord Aro]

OpenTTD fullzoom r19600: Win32

not another one...
just prefer to see a new version of the patch

[Szvengar]

OpenTTD fullzoom r19600: Win32

not another one...
just prefer to see a new version of the patch

I just try to be up to date against trunk .

[Szvengar]

2. On the right side of the picture you see the red bus. All buses are blue, but when they take that position (up direction) they become red. I think that that company colors are missed on this skin.

I don't have this problem, use the last pack I made (http://www.tt-forums.net/viewtopic.php?p=865380#p865380).

4. I like to follow my vehicles using Ctrl + clicking on the focus icon. But it works only in standart zoom. I think that additional zoom levels should support this feature too.

Works fine for me, at least with r19600. Becarful, it de-activate itself when you change zoom.

[xmirakulix]

I just try to be up to date against trunk .

I do too, but I am applying several other patches to my build, so I'd love to be able to pull a diff against upstream.

For those who need a patch, I am attaching a 32bpp-ez patch against upstream r19600 which is the revision 32bpp-ez is at currently.
It builds and runs fine under Mac OS X 10.6.3.

[Creat]

For those who need a patch, I am attaching a 32bpp-ez patch against upstream r19600 which is the revision 32bpp-ez is at currently.

Thank you very much, this is much appreciated! I also have to apply more than one patch, so this saves me from having multiple repositories locally just to generate the patches

[xmirakulix]

I also have to apply more than one patch, so this saves me from having multiple repositories locally just to generate the patches

Which is exactly what I'm doing now
I am attaching a patch against -r19615

[GeekToo]

To make life a bit easier for you, I've created a patch queue with all patches published on the forums up til now.

http://mz.openttdcoop.org/hg/32bpp-ez-patches

[Jupix]

Any news on the nightly build?

[GeekToo]

I did have a discussion about it on the #openttdcoop.devzone irc channel recently.

According the Rubidium, the process is pretty simple:
1 have a repo that can be checked out with the patch applied
2 have a place where the binaries can be stored
3 notify one of the openttd developers, to verify a safe compile can be made on the openttd compile farm (i.e. chance the patch compiles is pretty high, no security risks like coding a trojan into the patch present etc. , again according to Rubidium the chance that this patch would pass this test is pretty high, being around here for longer time, and downloaded and used by larger groups of users) and then request a run on the openttd compile farm.

2 can be arranged on the openttdcoop server, can be set up pretty easy when I request Ammler or Planetmaker.
3 would require 1, but then I foresee no problem there

That leaves step 1. I created a repo that was completely functional, but started it using an svn checkout. Although that works, it has the nasty side-effect that later hg updates, will always have to be merged for every file that got changed in trunk. Apart from that, it will show incorrect author names for files, which is not a funtional problem, but also not as clean as we would want it. Unfortunately, hg offers no means to repair that (at least not with the user rights I have on the openttdcoop server. So I decided to change the course a bit: I created a new repo, with the complete patch history in the patch queue. This has the advantage that every patch user/developer always can have the latest patch version and apply it to trunk with the correct revision, regardless of the cvs being used.

But for the compile farm, we also need a complete repo, and there we also had a discussion, a.o. with Ammler how to best arrange that: it seems kind of overkill for every patch on the openttdcoop server to have a complete repo, a combined repo that alternately applies one of the patches, and requests a compile run does seem more efficient, considering the fact that most patches only change a small amount of the trunk code base. But that discussion is not completely ended, it also would require some scripting. Another complicating factor is that I've been kind of limited in my spare time lately.

So, concluding, there is progress, but not as fast as we all would like.