32bit Graphics Extra Zoom Patch

[BeeJAy]

Can you please reupload them in a format that we can use those builds? I think I'm not the only one who experienced these kinds of problems, but I don't know for sure of course. If it's something my fault, please tell what shall I do to uncompressed them. ps: I'm using Windows 7 64-bit, if it helps.Thank you

i checked this and you right Winrar cannot handle this but 7z should (make sure you have the latest version, i used 7.10)
i would supplied it with self extractor but the forum doesn't allow exe files, anyway i repacked it with winrar (its take a bit more space now)

Thank you, it works now,

But I have another question for you as far as I noticed for the past 2 patched builds, including 18891, why at the game menu doesn't say the version number followed by the M word or something like that as with the build 17832? Now it says "OpenTTDnorev000"

Thanks again for the repack version

I believe it's related to the SVN client the person that builds the game uses, for me it occurred before I knew that if you run TortoiseSVN on x64 windows you must for example install both the x86 and x64 version of TortoiseSVN otherwise the revision number won't be sent to the compiler.

[petert]

Thank you, it works now,

But I have another question for you as far as I noticed for the past 2 patched builds, including 18891, why at the game menu doesn't say the version number followed by the M word or something like that as with the build 17832? Now it says "OpenTTDnorev000"

Thanks again for the repack version

That shouldn't happen with my builds. I also don't know what causes it, some kind of corrupt svn data causes it.

[neob]

i doubt that, svn checkout clean, patch aplied clean, compile clean etc...

the only 2 problem there is the one in the bundle we talked about, which is suppose to be.
and this one: error PRJ0019: A tool returned an error code from "Determining version number" returned from determineversion.vbs

i figured this is some to do with me i having WIN7 64bit, anyway its has no implication on the binary except the rev num (which i dont really care about during game play)

[petert]

With MSYS/MinGW, you can change the revision number with "./configure --revision=r#####M". Not sure if you can do the same thing with MSVC and the pre-processor definitions (try REVISION=r#####M).

[GeekToo]

... anyway its has no implication on the binary except the rev num (which i dont really care about during game play)...

I will be relevant when multiple norev versions appear, and people start asking questions about a certain problem. Not being able to say what revision they use will make it harder to diagnose. Certainly when the readme.txt indicates it's a 1.0.0 beta version.

Nontheless, thanks a lot for posting the binaries.

[neob]

^ good point, i'll try petert suggestion over the weekend also is there a way to find the exact reason for the script failure?

[GeekToo]

You may want to check your src/rev.cpp. I don't know why configure did not recognize your checkout as an svn checkout, but here's what's in mine:

Code: Select all

* norev000 is for non-releases that are made on systems without
 * subversion or sources that are not a checkout of subversion.
 */
const char _openttd_revision[] = "r18907M";

[Sensation Lover]

hi guys,

sorry, but where can i find the win 32 binaries? the instructions on this link ( http://wiki.openttd.org/32bpp_Extra_Zoom_Levels ) at the downloading section, clicking the win32 binaries link brought me here (the page before). but i can't find any.

thanks a lot,
S.L.

[Ben_Robbins_]

They are on the page before this.
(OpenTTD 32Bpp.r18891.x86.rar)

[maquinista]

I have found a bug with the new railway fences position. I think that It would be easy to fix, changing a bit the bounding box of the bridge entrance.

How I can change the saturation? I tried this but I don't see changes.

[Sensation Lover]

me again.

first of all thanks Ben (didn't knew that win 32 binaries is the x86 archive ).
i fallowed the instructions here (http://wiki.openttd.org/32bpp_Extra_Zoom_Levels), and i get the error attached. can you help me please?

thanks and best regards,
S.L.

[maquinista]

me again.

first of all thanks Ben (didn't knew that win 32 binaries is the x86 archive ).
i fallowed the instructions here (http://wiki.openttd.org/32bpp_Extra_Zoom_Levels), and i get the error attached. can you help me please?

thanks and best regards,
S.L.

Did You made these changes?
http://wiki.openttd.org/32bpp_Extra_Zoo ... l_Settings

[Ben_Robbins_]

Reading a crash report is a bit out my depth, but it says out of memory along the top.

Have you got the game running but then found it crash's a short while in? If this is the issue, follow this set of instructions

edit: beaten to it!

Maquinista: Are you hitting Ctrl-R to make everything update? You may need to hit the varying keys repeatable for a noticeable effect also. That bug does only seem to happen with the fence realignment, seems to be fine in v12. Strange since the shift is so minor.

[Sensation Lover]

Oh my God!!!!!!!!!!!!!!
It's the first time i play with 32bpp... guys you are Gods of art and codding... OMG OMG it's so marvelous!!!!!!!


once again thanx Ben. I thout i should skip that step

[maquinista]

I have found a new bug: the land is drawn over the fence and It doesn't have shadow. I think that It could be solved moving the bounding box of the fence sprite one point up.

[maquinista]

There is a new feature on r18959. It allows to draw more than one sprite on the ground. I have modified a old GRF with some new station tiles. It is a very simple GRF, made only with original sprites.

This file doesn't work well at the moment because this feature is not implemented in the latest release, but It will allow to build some new station graphics easily, because other stationsets are too complex to replace.

Also, the next release will have railtypes. Railtypes is a new GRF feature that allows more types of rail tracks.

[Ben_Robbins_]

Not clear on exactly what you mean. Would you set up new situations for those sprites to appear, or can we simply make current single sprites out of multiple sprites, and can these be on any layer ground sprite/building sprite? If so, the issues caused by grass exceeding the tile edge can be dealt with?

[maquinista]

Not clear on exactly what you mean. Would you set up new situations for those sprites to appear, or can we simply make current single sprites out of multiple sprites, and can these be on any layer ground sprite/building sprite? If so, the issues caused by grass exceeding the tile edge can be dealt with?

The new feature on r18959 would allow to make a new station GRF for passengers (like the default station) with two ground sprites. This will allow to draw the platform behind the grass of the front sprite, not over the grass.

[Ben_Robbins_]

Will the station (which exceeds the ground tiles perimeters) then have tiles appear on top of it, if those tiles are embanked? If not, then this has a lot of potential, and could help with many problems.

[maquinista]

Will the station (which exceeds the ground tiles perimeters) then have tiles appear on top of it, if those tiles are embanked? If not, then this has a lot of potential, and could help with many problems.

My idea is create a GRF file with the default with a default railway sprite and a ground piece. These two sprites will be behind the grass. The other two platforms will be placed as "building" sprites. Also, the platforms have erased their bottom area.

The problem of embanked tiles are that they are fully redrawn, and the grass will be under the platform. I think that with some changes in the blitter these problems could be solved, but It needs lots of code.