Opened 13 years ago

Closed 12 years ago

#2679 closed defect (fixed)

HE71-73: Fails to load mouse data (Endian issue?)

Reported by: (none) Owned by: fingolfin
Priority: blocker Component: Engine: SCUMM
Keywords: Cc:
Game: Freddi Fish 1


0.9 svn June 3rd
(yeah, i know, it's old - can't build myself, SDK troubles)

(0:1:0x37): freddi.he3: premature end

on starting the game (either old adding or newly added)


Windows version

gcc version 4.0.2 (AmigaOS build 20051012)

Worked with at least 0.8 full (i know it worked with
pre0.8, because i did the testing for it!)

Ticket imported from: #1506591. Ticket imported from: bugs/2679.

Attachments (2)

res-endian.patch (18.1 KB) - added by fingolfin 12 years ago.
zoodemo-cursors.png (25.4 KB) - added by sev- 12 years ago.
Mac colored and Win32 cursors from zoodemo

Download all attachments as: .zip

Change History (25)

comment:1 Changed 13 years ago by Kirben

Owner: set to sev-

comment:2 Changed 13 years ago by Kirben

Please try copying freddi.he3 from the original CD again,
just in case the file is corrupt.

comment:3 Changed 13 years ago by (none)

Recopying didn't do anything, hmmm

Could you take a look if these are right, please?

MD5Sum: 6daf76c1fe724ce6bf2e4c5175f39352 Freddi.he3
Freddi.he3 36864 bytes

if not, my CD FileSystem does something funny while copying


comment:4 Changed 13 years ago by sev-

I suspect that Win32 resources reading code may be not
endian-safe. I know that Mac resources code is not
endian-safe for sure. Will take a look into it.

comment:5 Changed 13 years ago by sev-

Summary: HE Trying to start game 'Freddi Fish 1: The Case of the Missing Kelp Seeds'HE Trying to start game 'Freddi Fish 1: The Case of the Miss

comment:6 Changed 13 years ago by Kirben

Also reported to occur in puttzoo, when used on the
AmigaOS, see closed bug #1508416.

Sounds like we definately have endian issues, when loading
mouse data from Windows resources, which are stored in the
*.he3 file.

comment:7 Changed 13 years ago by Kirben

Priority: normalblocker

comment:8 Changed 13 years ago by Kirben

Summary: HE Trying to start game 'Freddi Fish 1: The Case of the MissHE70-73: Fails to load mouse data (Endian issue?)

comment:9 Changed 13 years ago by Kirben

Summary: HE70-73: Fails to load mouse data (Endian issue?)HE71-73: Fails to load mouse data (Endian issue?)

comment:10 Changed 13 years ago by SF/daniel9

What is the status of this bug?

I ran into a few Dutch versions of Humongous games that seem
affected by this bug. It would be very nice if someone is
working on it...

ScummVM is lovely for the kids, my son is addicted to the
Pajama Sam games...

comment:11 Changed 13 years ago by eriktorbjorn

It looks to me as if there already is code to convert the
various parts of the resource to appropriate endianness. The
problem might be the functions before it determines what
kind of data it's trying to read. The read_library()
function would be one example.

But I don't have the hardware to test this, so there's
little I can do.

comment:12 Changed 13 years ago by SF/daniel9

I have done some tests, maybe someone will know what went wrong:

As a test I used my Mac copy of Freddi Fish 1. This is the Dutch version, as
that is the only one I have.
I use a Mac so I use Mac build of ScummVM:
Version 0.10.0SVN of 3 october 2006:exactly the error message of this bug.
Version 0.9 & 0.8.0a also generate exactly this error message.
But Version 0.71 just works fine.

So my question is: What did change in the code between 0.71 and 0.8.0a?
I am not a programmer so I think: "Why don't we put back the part of the
program from 0.71 that seems responsible for this problem in the newer

comment:13 Changed 13 years ago by SF/daniel9

Oh, I am sorry, I was too fast. With version 0.71 the game is working, but I don't
see my mouse cursor. That makes the game very hard to play. But what I meant
is, the game does not crash while starting up, like it does in all newer version I

comment:14 Changed 13 years ago by (none)

I thought i throw in a little debug log...

Opening hashed: Games:ScummVM/Games/FreddiFish1/Freddi.he2
Opening hashed: Games:ScummVM/Games/FreddiFish1/Freddi.he4
Total music tracks 29
getResourceAddress(Script,1) == 0x200d45ac
runScript(Global-1) from 0-0
(0:1:0x0): getResourceAddress(Script,1) == 0x200d45ac
(0:1:0x9): Script 1, offset 0x9: [6B] o6_cursorCommand()
(0:1:0xB): Script 1, offset 0xb: [6B] o6_cursorCommand()
(0:1:0xD): Script 1, offset 0xd: [FA] o70_setSystemMessage()
(0:1:0x1B): Script 1, offset 0x1b: [FA] o70_setSystemMessage()
(0:1:0x20): o70_setSystemMessage: (241) 1.0
(0:1:0x21): Script 1, offset 0x21: [1] o6_pushWord()
(0:1:0x23): push 10
(0:1:0x24): Script 1, offset 0x24: [43] o6_writeWordVar()
(0:1:0x26): pop 10
(0:1:0x26): writeVar(55, 10)
(0:1:0x27): Script 1, offset 0x27: [1] o6_pushWord()
(0:1:0x29): push 0
(0:1:0x2A): Script 1, offset 0x2a: [43] o6_writeWordVar()
(0:1:0x2C): pop 0
(0:1:0x2C): writeVar(154, 0)
(0:1:0x2D): Script 1, offset 0x2d: [1] o6_pushWord()
(0:1:0x2F): push 141
(0:1:0x30): Script 1, offset 0x30: [43] o6_writeWordVar()
(0:1:0x32): pop 141
(0:1:0x32): writeVar(157, 141)
(0:1:0x33): Script 1, offset 0x33: [3] o6_pushWordVar()
(0:1:0x35): readvar(157)
(0:1:0x35): push 141
(0:1:0x36): Script 1, offset 0x36: [6B] o6_cursorCommand()
(0:1:0x37): pop 141
(0:1:0x37): Opening hashed: Games:ScummVM/Games/FreddiFish1/Freddi.he3
(0:1:0x37): check_offset: size=2 vs 9000 offset=0 size=2
(0:1:0x37): check_offset: size=80000002 vs 9000 offset=80000000 size=2
(0:1:0x37): freddi.he3: premature end!

Does the last "check_offset" look suspicious?
Not that i'd have the slightest idea whats going on, but
maybe the comparisation is going beyond Freddi.he3's
borders and though triggers the exit/debugger?

I know, i'm again completely wrong :-)

comment:15 Changed 13 years ago by sev-

Yes, I am fully aware that my cursor loading code is not endian-safe. I just need to take time to debug it on BE device. HE3 file is usual Windows executable which consists only of resource section with cursors.

comment:16 Changed 12 years ago by SF/hillsoftware

I can give some feedback on this.

Even though we didn't seem to have this problem with older versions like 0.7.1 we were still getting premature end messages. They were just warnings on 0.7.1 but later versions actually error out.

I have two OS X machines. One PPC (G5) and one Intel based Mac. The Intel Mac works fine and doesn't have errors with any of the few HE games with problems on PPC systems (fbear, FF1, Putt Zoo, etc). All tests were done with the latest subversion universal build on the site. Same data files for the games too.

I noticed the problem starts at the read_library routine. The first check to see if the magic header is IMAGE_DOS_SIGNATURE fails because the SIGNATURE on disk is byte swapped from what is in the header file. The signature on the disk is 0x4d5a, but the header file resource_he.h has it has 0x5a4d (which will work as expected on Intel machines).

I would think it is safe to say that all the information stored in the DOS image header is going to be byte swapped on big endian machines.

I commented out all the checks so it would pass through this code without generating a premature end error, and the games did load. In some cases the mouse cursors were weird looking, but the games did load.

I am assuming that only a few HE games (maybe the ones I mentioned above) have cursor data in an executable.

Do latter games store them in other files?

comment:17 Changed 12 years ago by Kirben

The effected HE games are:
Fatty Bear's Birthday Surprise
Putt Putt Goes to the Moon
Putt Putt Joins the Parade
Freddi Fish 1
Let's Explore the Airport with Buzzy
Let's Explore the Farm with Buzzy
Let's Explore the Jungle with Buzzy
Putt Putt Saves the Zoo

In meantime, can use the DOS or Macintosh versions of data files. Almost all HE games included multiple versions of data files (Usually Macintosh and Windows).

All HE80+ games store their cursor resources in the main data files, instead of using platform specific resource files, so aren't effect by this issue.

comment:18 Changed 12 years ago by SF/hillsoftware

Hmm. I thought Fatty bear was a DOS only game at least the version I have.

I checked on my disks (fatty, zoo,moon,parade, ff1) and none have Mac versions.

I got these for my first daughter when they all first came out, so maybe they didn't bundle everything back then.

comment:19 Changed 12 years ago by Kirben

There are Windows (ISO) and Macintosh (HFS) sections on the CDs of almost all the Humongous Entertainment games I own. With the only exceptions been:
Humongous Classic Collection - Let's Explore with Buzzy
Pajama Sam 3 (Marked as Macintosh/Windows, but missing HFS section).

We have had reports of single releases of earlier games including the Windows and Macintosh versions too.

Changed 12 years ago by fingolfin

Attachment: res-endian.patch added

comment:20 Changed 12 years ago by fingolfin

With the attached patch, I can run various Windows HE demos just fine under Mac OS X / PowerPC (i.e. a big endian system). However, some caveats:
* I didn't clean it up yet (deliberately), so lots of debug printf's are still in it
* The cursors are only black and white. Is this a bug, or is it this way on Intel systems, too?
* It would be good to verify that the changes don't break little endian systems.

If the cursors are colored on intel machines (i.e. if there is still something missing in the patch), then it would be good if somebody could show me the debug output of e.g. airdemo, so that I can compare with what I get here.
File Added: res-endian.patch

Changed 12 years ago by sev-

Attachment: zoodemo-cursors.png added

Mac colored and Win32 cursors from zoodemo

comment:21 Changed 12 years ago by sev-

Mac and Win32 games use different cursors.

I'm attaching the reference image.

It appeared that Mac b/w cursors are broken (they're all black) in current SVN. I'll take a look at it later. They are used in backends which do not support cursor palette.
File Added: zoodemo-cursors.png

comment:22 Changed 12 years ago by fingolfin

Owner: changed from sev- to fingolfin
Resolution: fixed
Status: newclosed

comment:23 Changed 12 years ago by fingolfin

I just commited a cleaned up version of my patch. So the original issue reported here should be fixed (at least it works fine over here).

According to Eugene, the NE code is not used, so I am going to remove it.

No idea about the mac cursors being broken -- once somebody sends me a Mac HE demo, I'll be happy to have a look at that bug, though.

Note: See TracTickets for help on using tickets.