Macintosh conversion/editing

[Norbert]

Below are two preview screenshots.
About 7-8 weeks to go until release.

[Norbert]

David, any chance you know which byte(s) allow me to specify the starting level; the New Game (⌘N) level?

[realXCV]

Personally, I would say it's the word at offset 0x11F4 in resource CODE 2.

[Norbert]

Personally, I would say it's the word at offset 0x11F4 in resource CODE 2.

I don't know what "resource CODE 2" means.
When I look at 0x11F4 in the executable, I see word 00 02.
Changing that to, for instance, 00 03 has no noticeable impact...
Maybe you could give me a collection of bytes instead of an offset?

[realXCV]

CODE 2 means the resource of type CODE with the id 2. And offset 0x11F4 is starting from the beginning of that resource.

The surrounding bytes are: 4E BA 02 C2 3B 7C 00 01 BA 64 42 2D A1 24. What you need to modify are the 00 01 bytes.

[Norbert]

The surrounding bytes are: 4E BA 02 C2 3B 7C 00 01 BA 64 42 2D A1 24. What you need to modify are the 00 01 bytes.

All right, that works. Thanks.
For me that word is at offset 0x3EDE in the MacBinary 2 BIN file export of the executable.
I guess it's the same offset for everyone?
(Assuming there aren't multiple versions of PoP for Macintosh.)

There are a bunch of other offsets that would be nice to have:
- Disabling the potions level.
- Starting hit points and minutes.
- The win level and room.

And if this port has a way to enable triggering of any tile, that would be useful.

[realXCV]

You should never use absolute offsets when dealing with resources. They could be moved around for many reasons.

How would you want to trigger your triggering?

[realXCV]

To skip potion: CODE 2 offset 0x1F70 change that 66 to 60
64 B2 6D BA 62 54 8F 66 0A 3B 7C 00 0F BA 64 4E

Timer: CODE 3 offset 0x10F0
B9 3E 60 1A 3B 7C 00 3C BA 8C 3B 7C 02 CF

Lives: CODE 3 offset 0x10FC
CF BA 80 3B 7C 00 03 BA 46 42 6D 96 36

Win room: CODE 3 offset 0x100
BA 22 60 0E 0C 2D 00 05 B9 73 66 06 3B 7C

Win level: that is part of a switch statement.

[Norbert]

To skip potion: CODE 2 offset 0x1F70 change that 66 to 60
64 B2 6D BA 62 54 8F 66 0A 3B 7C 00 0F BA 64 4E

Timer: CODE 3 offset 0x10F0
B9 3E 60 1A 3B 7C 00 3C BA 8C 3B 7C 02 CF

Lives: CODE 3 offset 0x10FC
CF BA 80 3B 7C 00 03 BA 46 42 6D 96 36

Win room: CODE 3 offset 0x100
BA 22 60 0E 0C 2D 00 05 B9 73 66 06 3B 7C

Thanks!

You should never use absolute offsets when dealing with resources.

If I understand you correctly, there's a resource table at a certain offset that I should use to check where each CODE block starts?

[realXCV]

Something like that. First, you need to calculate the offset to the resource fork from the macbinary header. (See the commented part in the uMacFile.pas file in the pop2 viewer I made a few years ago for that).

After that, here's some documentation:
http://mirror.informatimago.com/next/de ... ox-99.html

[Norbert]

I see. While I may be able to figure out how to make it all dynamic, it would take too much effort - time, energy - for me to understand the Pascal file and linked documentation. This is already a multi-month project as-is, and I need to balance this with many other activities. I think using absolute offsets won't cause any (immediate) problems. Unless I misunderstand how HFVExplorer works, it - and similar programs - will always serve up the same MacBinary (2) when exporting/copying the executable. It's true that, in theory, a user could move around resources, but I think that in practice it's unlikely anyone will do so. In fact, only a handful of people may actually use the editor. And a person who would move resources, would also be skilled enough to compile a custom version of the editor to work with different offsets. Also, the software will be GPL3+ licensed, so I or someone else may one day improve the way resources are accessed. Actually, I can't think of a reason to move the location of a resource. In theory, say, modified images might, for example, take up more space than they did originally, which could push other resources away, but in practice we lack tools to heavily alter the Macintosh port. Static offsets should be fine, for now.

[realXCV]

You're lucky, I did a few tests and while making changes to the resource fork is easier than you think, the most likely changes that could happen shouldn't affect the location of the LEVL or CODE resources in the macbinary file.

But you don't need compilation skills to make changes that would be significant enough. You need ResEdit (or any other resource editor).

[Norbert]

You're lucky, [...]

That's good to read.

The program should be finished and tested in about a month.
The release date will probably be September 23rd.

I've been able to copy lots of apoplexy code, but also rewrote plenty for various reasons.
The apoplexy editor has a messy, overly long ShowImage() function, and doesn't show tiles of the room above.
Changing these and other things (e.g. adding bloody chompers on the tiles screen) for the new editor had a substantial impact.
The new editor will be the second of mine to include the separately openable Map window.

[Norbert]

The release date will probably be September 23rd.

I'll have it ready sooner than that.
A week from now, probably. [Edit: Or tomorrow...]

Also, the Macintosh and DOS/Apple II levels are almost identical, but there's a very small - uninteresting; don't expect something cool - difference. The difference is in the potions level. Similar is that all the versions have guards in some of the unused rooms. (No resources are loaded for these guards by default.) The difference is that the rooms these guards are in are one less in the Macintosh version. For example, the DOS/Apple II version has a guard in the top left of room 10. This guard is in the top left of room 9 of the Macintosh version.

[Norbert]

The release date will probably be September 23rd.

I'll have it ready sooner than that.
A week from now, probably. [Edit: Or tomorrow...]

Released.