Opened 5 days ago
Last modified 23 minutes ago
#15505 pending defect (pending)
SCUMM HE MOONBASE: big endian problem (MORPHOS)
Reported by: | BeWorld2018 | Owned by: | AndywinXp |
---|---|---|---|
Priority: | high | Component: | Engine: SCUMM |
Version: | Keywords: | ||
Cc: | Game: | Moonbase Commander |
Description (last modified by )
I just test last scummvm (build 16-11-2024 master 2.10.0git)
Something wrong with gfx (check screenshoot)
All mode: OpenGL (Software or OpenGL) or SDL Surface
Game: Moonbase Commander (1.1/Windows/English)
MorphOS - PPC - BigEndian
Attachments (15)
Change History (21)
by , 5 days ago
Attachment: | moonbase.png added |
---|
comment:1 by , 5 days ago
Description: | modified (diff) |
---|
comment:2 by , 4 days ago
Owner: | set to |
---|---|
Priority: | normal → high |
Resolution: | → pending |
Status: | new → pending |
Thank you very much for taking the time to test games on MorphOS, and reporting the issues you see. This is very welcome and helpful!
I have a big-endian development system here, with a debugger and all that.
AndywinXp and I are working on this.
So far, we see that:
- Moonbase Commander indeed has the problems you report
- Freddi 1 is OK
- Freddi 5 has rendering issues too
- Blue's Art Time Activities has issues as well
The problem may be related to the recent rewrite of the GFX system for Humongous games.
I'll add some screenshots of what we saw. We're probably going to come back to this issue later this week.
by , 4 days ago
Attachment: | scummvm-arttime-00000.png added |
---|
by , 4 days ago
Attachment: | scummvm-arttime-00001.png added |
---|
by , 4 days ago
Attachment: | scummvm-arttime-00002.png added |
---|
by , 4 days ago
Attachment: | scummvm-freddicove-00000.png added |
---|
by , 4 days ago
Attachment: | scummvm-freddicove-00001.png added |
---|
by , 4 days ago
Attachment: | scummvm-freddicove-00002.png added |
---|
comment:3 by , 4 days ago
I've added some screenshots from own BE tests, at Andy's request.
For Freddi5, we saw that removing this part of Wiz::processWizImageDrawCmd() didn't change the result:
// Check if the images are in their native format and swap them if needed... if (_vm->_game.heversion > 99) { for (int i = 0; i < requiredImageCount; i++) { ensureNativeFormatImageForState(requiredImages[i], state); } }
In ensureNativeFormatImageForState(), we saw that compType == 1, so wiz16bpp is always false.
Investigation continues... :)
comment:4 by , 2 days ago
ok thanks, I try to test during the day
by , 21 hours ago
Attachment: | scummvm-baseball2001-00000.png added |
---|
Adding the baseball2001 screenshots that Andy wanted
by , 21 hours ago
Attachment: | scummvm-baseball2001-00001.png added |
---|
by , 21 hours ago
Attachment: | scummvm-baseball2001-00002.png added |
---|
by , 21 hours ago
Attachment: | scummvm-baseball2001-00003.png added |
---|
by , 29 minutes ago
Attachment: | scummvm-baseball2003.png added |
---|
by , 25 minutes ago
Attachment: | scummvm-baseball2003-2.png added |
---|
by , 25 minutes ago
Attachment: | scummvm-baseball2003-1.png added |
---|
by , 23 minutes ago
Attachment: | scummvm-basketball.png added |
---|
introduction video seem correct.