[11.16 makeobj]

[MCollett]

11.16 appears to start and run OK using a pakset compiled with an older version of makeobj, but if I use the same pakset compiled with the new 11.16 makeobj instead, startup fails with the fatal error (from wegbauer_t::alle_wege_geladen()) "No road found at all!"
Presumably the fault is somewhere in the new makeobj.

Best wishes,
Matthew

[jamespetts]

Hmm, that's odd: I can't reproduce that with the sources of Pak128.Britain-Ex. Can you compile it with the latest Standard version of Makeobj?

[MCollett]

Can you compile it with the latest Standard version of Makeobj?

No, I can't, since I can compile neither the current version of standard (112.3) nor the associated makeobj: the makefiles for both refer to subsidiary makefiles that are not in the source distribution (OSX/osx.mk for simutrans itself, and uncommon.mk for makeobj).

Using the latest version of the Pak128.Britain-Ex source from github shows the symptoms I described: compiled with makeobj from 11.11 it runs fine in 11.16, compiled with makeobj from 11.16 it fails to load in 11.16.

Would it help to exchange compiled versions of the pakset?  That might establish whether the fault is indeed in makeobj or is instead in the loading into the game.

Best wishes,
Matthew

[jamespetts]

Ahh, yes, you could try that, although the symptoms that you describe are very odd given that I cannot reproduce them.

[MCollett]

yes, you could try that

The compiled pakset is is too big for the Simutrans file sharing site, so I'll PM you a link to it on my Box account.  If it loads for you, my problem is presumably in 11.16 itself; if not, in the associated makeobj.  Either way, it would be good to check the reverse.

Matthew

[jamespetts]

I have it, and it gives me the same error as it gives you. It is also far too small - the current compiled pakset should be circa 225 megabytes. I suspect that this relates to updating rdpng.cc to the most recent version from Standard: it may be that you need to update some linked precompiled headers or similar, although I am not sure how that would work on MacOS X. You could, as an interim measure, restore the older version of rdpng.cc from Github.

[MCollett]

I have it, and it gives me the same error as it gives you. It is also far too small - the current compiled pakset should be circa 225 megabytes.

Duh.  I should have checked the size as soon as there was an error indicating that the set was incomplete.  That would have made it obvious that the fault was indeed with makeobj.

I suspect that this relates to updating rdpng.cc to the most recent version from Standard

I think you are right about the location of the problem (assuming you mean dr_rdpng.cc).  Rerunning the broken makeobj generates lots of warnings of the form

Warning: while loading PNG:   ignoring alpha channel for ./folder/./images/filename.png

I didn't pick up on them previously, having become so used to ignoring the lists of

libpng warning: Invalid pHYs after IDAT

that makeobj has always generated.

I'll poke around in dr_rdpng.cc.

Matthew

[jamespetts]

The "ignoring alpha channel" is a warning that is now generated for me, too, with the new dr_rdpng.cc, so this is not an indication of an error per se, but is an indication of the use of a new version of the file, which appears to corelate with your error.

[MCollett]

OK, going back to the old version of dr_rdpng.cc seems to fix the problem. 

Most of the changes between the two versions relate to keeping a copy of the filename for error reporting purposes, which should not affect the processing of the image.

There are two changes that might affect the actual image processing: the replacement of png_start_read_image(png_ptr) by png_read_update_info( png_ptr,  info_ptr), and the halving of the memory allocated per row.  But: both of these changes are after the check for an alpha channel, so cannot explain why the new version is consistently warning about ignored alphas while the old one is not.

Best wishes,
Matthew

[jamespetts]

Hmm - very curious. Perhaps the Standard developers might be able to help? This change also applies in Standard. I am afraid that the graphics code is rather a mystery to me.

[prissi]

The problem is that libpng is on of the most poorly documented libraries ever. We just took a code which was outcommented somewhere else as wrong and put something in which we hoped is correct (actually Dwachs did). It may be that on the MAC this is no longer working then. Since nobody own a MAC, we cannot test it there.