Opened 18 years ago
Closed 17 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 |
| Version: | Keywords: | ||
| Cc: | Game: | Freddi Fish 1 |
Description
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)
language=en
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)
Change History (25)
comment:1 by , 18 years ago
| Owner: | set to |
|---|
comment:2 by , 18 years ago
comment:3 by , 18 years ago
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
Thanks
comment:4 by , 18 years ago
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 by , 18 years ago
| 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 by , 18 years ago
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 by , 18 years ago
| Priority: | normal → blocker |
|---|
comment:8 by , 18 years ago
| Summary: | HE Trying to start game 'Freddi Fish 1: The Case of the Miss → HE70-73: Fails to load mouse data (Endian issue?) |
|---|
comment:9 by , 18 years ago
| Summary: | HE70-73: Fails to load mouse data (Endian issue?) → HE71-73: Fails to load mouse data (Endian issue?) |
|---|
comment:10 by , 18 years ago
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 by , 18 years ago
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 by , 18 years ago
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 versions."
comment:13 by , 18 years ago
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 tried.
comment:14 by , 17 years ago
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 ensureResourceLoaded(Script,1) loadResource(Script,1) openRoom(1) _res->createResource(Script,1,3060) 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 by , 17 years ago
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 by , 17 years ago
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 by , 17 years ago
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 by , 17 years ago
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 by , 17 years ago
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.
by , 17 years ago
| Attachment: | res-endian.patch added |
|---|
comment:20 by , 17 years ago
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
comment:21 by , 17 years ago
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 by , 17 years ago
| Owner: | changed from to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:23 by , 17 years ago
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.
Please try copying freddi.he3 from the original CD again, just in case the file is corrupt.