[Lachesis]

Yep, it's already time for another one! Special thanks to Terryn, Spectere, who has gone through the trouble of making Mac OS X DMGs for us, and ajs, who although he has stepped aside from the main dev work has continued to provide plenty of advice and continues to build the release packages.

Release Info

Less than three weeks after the last one, MegaZeux 2.84b is here a few weeks
early to fix a key regression regarding the use of REL commands with the
COPY x y dx dy command. While several new features have been added, this
release was mostly about rooting out as many crash bugs from MegaZeux as
possible. An official public beta release of debytecode has been pushed off
once again due to time constraints.

Most notable as far as new features go, pressing 'E' while a game's title
screen is running will now take you directly to that world in the editor. A
blank new world may still be created with 'F8', and now with the 'N' key. The
function key corresponding to the new 'E' functionality is 'F9'.

A major new aspect of this version, which could be seen as a bugfix or as a
new feature, is MegaZeux's ability to validate the MZX, MZB, MZM, and SAV file
formats. Validation has been rigorously tested and refined, and a comprehensive
list of most world files that fail any check is available on the MZX Wiki. File
load crashes and force-quit "Out of memory" errors in these instances are nearly
a thing of the past.

One final major change regards the file manager dialogs (Load / Save Game, etc).
These dialogs have been internally overhauled to avoid permanent directory
changes unless a valid world or save file has been loaded. If any bugs are
experienced using these, they should be reported to the MZX Bug Tracker.

Complete Changelog

>>DOWNLOAD MEGAZEUX v2.84b<<

Windows x86
Windows x64
Ubuntu i386
Ubuntu AMD64
Mac OS X (thanks Spectere!)
Source Code
More ports at devzero...

>>Read the New Release FAQ!<<

>>Instructions to compile the MZX source<<

>>Online Help File (updated for 2.84b)<<

[Terryn]

We're not planning a new release for a while, I don't think. We mostly wanted to get this one out to fix the big spotted regression and to provide a much more stable platform for the upcoming DoZ.

OH AND LET'S FINALLY BKZX TONIGHT

[Lachesis]

Important config.txt changes (since the autoupdater didn't replace it for me!):

• You can now specify startup_path so MZX starts up somewhere specific! No spaces though
  
• You now can not specify part of a path with startup_file, because of the former new field.
  
• You can now specify multiple update_host fields. I suggest making updates.digitalmzx.com the primary and updates.mzx.devzero.co.uk the backup; update attempts are made in the order they're listed in the file. You can specify up to 16 before it starts ignoring extras but I really hope nobody will ever need that many
  
• You can now specify backup_name with a directory as part of the name and it will try to make the directory when the backup file is created.

[Spectere]

Lachesis, on 21 June 2012 - 08:05 PM, said:

NOTE: Once again, we're without a Mac OS X release.

http://dev.spectere....n-universal.dmg

Not anymore!

[burstroc]

Again, my heroes

[Lachesis]

Spectere, on 21 June 2012 - 09:41 PM, said:

http://dev.spectere....n-universal.dmg

Not anymore!

Uploaded to the archive and fixed my post. Thanks! :>

[Spectere]

No problem. I'm glad I can finally do something to help out around these parts.

[Spectere]

Here's that x86-64-only build that I talked about making: http://dev.spectere....rwin-x86_64.dmg

Do what you will with it. One thing to note: this was built with the latest Xcode on Lion, and as such uses the LLVM toolchain. It was compiled with -mmacosx-version-min=10.5, so it should work. Really, I dot see any reason why it wouldn't work, but Apple hasn't been too keen on backwards compatibility lately (or, for that matter, giving developers the choice to make backwards compatible applications beyond a couple of OS revisions). If anyone has a 64-bit capable Mac running Leopard or Snow Leopard, your feedback would be greatly appreciated.

This post has been edited by Spectere: 23 June 2012 - 04:18 AM

[Lachesis]

If at least one person can confirm it works for them in 64-bit *Leopard I'll put that one up as an alternate download to the OSX page. It's not that much smaller than the universal, though (ie modern MZX games frequently range anywhere from 10MB to 50MB in music, .8MB isn't going to make a ton of difference).

[Otto Germain]

Runs perfectly on my mac... I can't stop playing MZX now. Again.

Brilliant work. :]

[ThDPro]

Otto Germain, on 26 June 2012 - 11:26 PM, said:

Runs perfectly on my mac... I can't stop playing MZX now. Again.

Brilliant work. :]

You should DoZ then.

[Lachesis]

Glad that's working for you -- I uploaded the x86_64 package as an alternate download on the OSX page and left a short note in the description. Thanks again, everyone!

Unrelatedly, something is funny about SET "$string.length" "value" -- not that it ever worked properly before 2.84, but there's a different problem with it now and until I find the root cause I strongly recommend nobody uses it.

[Otto Germain]

ThDPro, on 27 June 2012 - 07:34 AM, said:

You should DoZ then.

Shhh, I'm trying to get the day off work so I can, you'll ruin the surprise.

[smilymzx]

I think we still need proper win32/64 building instructions, as building it is not working with the instructions availible, libpng is still not working for my platform even though I followed the instructions,

the last time build instructions worked for me was in v2.83, but something went beserk since v2.84, as libpng appears to be rejected in the attempt of building this version even!

This post has been edited by smilymzx: 29 June 2012 - 10:55 PM

[Terryn]

the libpng .a file in mingw32.zip doesn't mesh with MINGW/GCC 4.7.0 right now. Build your own libpng (and consequently, your own zlib).

[mzxgiant]

I know you're probably talking about mingw32, but if you're actually talking about the MSVC build, let me know -- I seem to be one of the only people who uses it

[smilymzx]

Which versions of libpng and zlib do we need for it to rebuild successfully?

[Terryn]

I'm fairly sure it doesn't matter much. Newest worked for me.

[smilymzx]

I will need new binaries if possible, please (Mingw only)

or can I compile with MSVC10 for use in Mingw, is it possible that way?

EDIT: Compiled ZLib in MinGW with success, LibPNG is fine: it looks like, it should already be the latest LibPNG

EDIT2: One error left, in Time.h, Undefined reference in _gmtime32 in function _gmtime

This post has been edited by smilymzx: 30 June 2012 - 04:03 PM

[Terryn]

When you compiled libpng, did you place the resulting .a file in your /(username)/bin/mingw32/lib/ folder and overwrite the older one? Sounds like you haven't.

EDIT: To restate, it's not the VERSION of libpng that's the problem here, it's that the provided libraries were compiled under MINGW/GCC 4.6.2. IT'S THE BUILD ENVIRONMENT OF THE PROVIDED LIBRARY, NOT THE VERSION OF LIBPNG, THAT'S LIKELY CAUSING PROBLEMS.

[ajs]

I refreshed the dependencies package against the broken compiler in the new mingw.

http://mzx.devzero.c...ocs/mingw32.zip

--ajs.

[smilymzx]

ajs, on 30 June 2012 - 01:26 PM, said:

I refreshed the dependencies package against the broken compiler in the new mingw.

Thanks for the new dependencies. Redone my full MinGW install using your instructions, But now I get a error for a missing png.h according to graphics.o!

Is there a typo by any chance?

EDIT: Two options:

1: Move all dependencies to the the regular INCLUDE, LIB and BIN directory, in the MINGW installation path, Like This:
C:/MinGW/Include, C:/MinGW/Lib, C:/MinGW/Bin.
(It Works with the current MINGW32.zip when I build MZX, for now)

or 2: Rename the H directories to point to a desired directory, For future MakeFiles: ${User}/Mingw/

This post has been edited by smilymzx: 01 July 2012 - 06:30 AM

[ajs]

You're supposed to add <place you extracted deps>/bin/mingw32/bin to your PATH variable, then it uses libpng-config --cflags to add the right -I flag. You must also extract the mingw32.zip into your $HOME folder, no other location will work correctly. I imagine you did this right the first time but for whatever reason changed things the next time you tried.

Merging all the files into your mingw installation is a recipe for disaster. It'll break upgrades of mingw. There's no way it's correct for us to refer to the mingw prefix explicitly in any makefiles.

Just follow the original instructions please. I did so myself last night and didn't encounter any issues.

--ajs.

This post has been edited by ajs: 01 July 2012 - 07:14 PM

[smilymzx]

ajs, on 01 July 2012 - 12:08 PM, said:

You're supposed to add <place you extracted deps>/bin/mingw32/bin to your PATH variable, then it uses libpng-config --cflags to add the right -I flag. You must also extract the mingw32.zip into your $HOME folder, no other location will work correctly. I imagine you did this right the first time but for whatever reason changed things the next time you tried.

Merging all the files into your mingw installation is a recipe for disaster. It'll break upgrades of mingw. There's no way it's correct for us to refer to the mingw prefix explicitly in any makefiles.

Just follow the original instructions please. I did so myself last night and didn't encounter any issues.

--ajs.

It works for now...

Thanks.

[Lachesis]

Just some quick mentions about 2.84b before the Day of Zeux:

REL [SELF, PLAYER, COUNTERS] (FIRST) / COPY BLOCK x y w h "$string" t doesn't work correctly.
SET "$string.length" n causes memory corruption in games made in 2.84(b).

Don't use these in the Day of Zeux. I severely doubt there's time to get 2.84c out before the DoZ, sorry. Fortunately, they're pretty edge-case-y -- the first is only used in one game I know of (Demon Earth, for the player's name) and the latter has pretty much never been used anyway.

[Old-Sckool]

Also save your game before attempting to exporting robots to file if your into that thing. Megazeux will crash if the pathname is too long. (63 chars)

This post has been edited by Old-Sckool: 03 July 2012 - 07:44 AM

[Lachesis]

Yeah, but who uses paths that long anyway?