[Scummvm-devel] PS2 backend - up & running (almost)

Max Horn max at quendi.de
Wed Oct 29 18:26:23 CET 2008


Hi Max!

Since the issues you bring up affect other people (esp. people working  
on the GUI code, and other porters), I am CCing this mail to scummvm- 
devl


Am 29.10.2008 um 05:24 schrieb sunmax at libero.it:

> Hey hey Max,
>
> ok here come all the good (and less good) news!
>
> Hacking hashmap (defaultVal out) got it to compile and run,
> but now there are couple of gotchas:

To give others a bit background info here: On PS2, the current HashMap  
code causes an ICE (internal compiler error) in GCC. This can be  
worked around by removing the explicit _defaultVal constructor:

../../../common/hashmap.h: In constructor `Common::HashMap<Key, Val,  
HashFunc,
   EqualFunc>::HashMap() [with Key = Common::String, Val = void
   (Graphics::VectorRenderer::*)(const Common::Rect&, const
   Graphics::DrawStep&), HashFunc = Common::IgnoreCase_Hash, EqualFunc =
   Common::IgnoreCase_EqualTo]':
../../../gui/ThemeParser.cpp:43:   instantiated from here
../../../common/hashmap.h:266: Internal compiler error in  
build_modify_expr, at
   cp/typeck.c:5516
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
make: *** [gui/ThemeParser.o] Error 1


>   - the first call to copyRectToOverlay on PS2 has params
>     x & y == 65535 (instead of 0), so we get an access violation
>     and a crash. I hacked a workaround to get it starting, but sure
>     it's weird (see under).

That sounds like a bug. It happens on desktops, too, although the  
value I see here is -1 / -1, not 65535. The SDL backend clips the rect  
passed to this method, so it is not noticeable there. Here is a  
backtrace:

#0  OSystem_SDL::copyRectToOverlay (this=0x1828200, buf=0x1757eafe,  
pitch=640, x=-1, y=-1, w=642, h=482) at backends/platform/sdl/ 
graphics.cpp:1185
#1  0x006e4aa4 in Graphics::VectorRendererSpec<unsigned short,  
ColorMasks<565> >::copyFrame (this=0x118f9b0, sys=0x1828200,  
r=@0x11a80b8) at graphics/VectorRendererSpec.cpp:242
#2  0x006bbce6 in GUI::ThemeEngine::renderDirtyScreen (this=0x1861200)  
at gui/ThemeEngine.cpp:967
#3  0x006bbfaf in GUI::ThemeEngine::updateScreen (this=0x1861200) at  
gui/ThemeEngine.cpp:954
#4  0x006a9fa5 in GUI::NewGui::redraw (this=0x1866600) at gui/ 
newgui.cpp:173
#5  0x006aad09 in GUI::NewGui::runLoop (this=0x1866600) at gui/ 
newgui.cpp:207
#6  0x00697665 in GUI::Dialog::runModal (this=0xbfffdd18) at gui/ 
dialog.cpp:73

Tanoku, any ideas? :)


>
>
>   - ok, up & running now. It cannot detect the modern theme (yeah
>     I copied the new one) so falls back to the classic hardcoded one.
>     (I like the python trick to generate it).

Have you tried setting the themepath, and then selecting the theme via  
the "Theme" button on "Misc" tab in the "Options" dialog?


> Now, these look kinda
>     weird:
>
>     - some of the labels in the buttons are chopped
>       (e.g. "dit Game..")

I can confirm this on Mac OS X, by running
   ./scummvm -g1x
So it is a bug/regression in the GUI code, I'd say. We may have to  
make the buttons a bit larger, or use a smaller font or so.

>     - is it supposed to be blue & green or I fucked up something?
>       (likely)

As far as I can tell, the PSP uses the 555 mode; the new GUI code is  
currently hardwired to use 565 mode (eeek), which probably explains  
the wrong colors. While Tanoku probably can make it 565 ready easily,  
what we really should do (soon, at least) is to get rid of the evil  
gBitFormat hack, and add some kind of "PixelFormat" struct, and an API  
to OSystem which allows querying backends for the pixelformat used in  
the overlay...

Tanoku, LordHoto, any comments?

>
>      - it feels more cluttered than the one still in 0.12.0: the

Note: I think you are referring to the GUI as shown in 1x mode -- I  
think Tanoku mostly focused on tweaking what is shown in 2x mode, when  
using 640x400 or bigger. But for the PSP and other devices with small  
mode, we definitely should tweak the 1x mode, too.

>
>       spacing between buttons seems too big, and when you have to
>       select a game you can only see 4 lines of text at a time, so
>       it's a scrolling frenzy to get to the game folder you want.

Sounds annoying :/

>
>       The mouse over changes the state of the buttons, but when
>       I move the mouse out it does not restore it (it may be on PS2
>       only, I still need to understand the new GUI changes impact).

Hm, I can not reproduce this under OSX. Can you reproduce this on your  
desktop computer?

>       Is that because the new GUI is still work-in-progress?
>       When it's done, I assume the classic theme should look
>       identical to the old one, right?

Mostly. We don't strive to be pixel identical, though -- if we see a  
way to improve things, we want to do that. Specific feedback is in so  
far highly welcome.

>
>
>    - in the about dialog ctr the line that adds the engine name
>
>        str += (**iter).getName();
>
>      crashes the PS2 on the third iteration.

Weird. Can you narrow the crash down? Does it crash trying to deref  
iter? or in getName? Or appending to str? Also, if you just comment  
out the line, does it then work?

> Are all the engines
>      supported? Should I leave some out? I am asking cause when
>      I try to add a game (DVD,USB,HD all work to browse folders
>      in my private branch) and click on choose it crashes...
>
>      ...so I wonder it this is because :
>
>      a) I have some non-fully-0.13.0svn-compatible engines in
>
>         -> please confirm which ones (if any) should stay out

No, this is not due to any engines being bugged.

>      b) I hacked the hashMap (and defaultVal is firing back)
>
>         -> please let me know when you have time, so we can
>            do a crash-session on this and work-around 3.2.2
>            compiler limitations.

Could be, I'd have to take a closer look at the code.

>
>
>      c) there is some memory corruption, likely caused by
>         overflow in the PS2 backend overlay code, cause
>         the GUI colors do look weird

The weird colors are not related. But of course if the compiler has  
one bug, it could have others, causing it to miscompile code etc....  
Hard to say from the distance really.

>
>
>         -> I will have a look to the new GUI code in the
>            next days, so I should figure it out.
>
> If you feel I am missing something in my analysis please
> let me know, I am always happy to run some extra tests ;-)


Can't think of anything, but maybe others have some ideas, we'll see/ 
hear/read!

Cheers,
Max




More information about the Scummvm-devel mailing list