[Scummvm-devel] R: Re: Fwd: PS2 backend - up & running (almost)

[sunmax at libero.it]

;-)

>> PSP?  *Looks at email subject and scratches his head*

So funny!

I 
have to reply to this one before going to bed,
I will upload couple of shots of 
the GUI and
the other answers tomorrow morning.

The PSP started as a semantic 
mutation in Max
(the good one) first mail:

 "As far as I can tell, the PSP 
uses the 555 mode"

The second "P" took the place of the "2" and generated
this 
part of the thread ;-)

On PS2 we are using Gs* not SDL - IIRC it was derived

from another open-source PS2 gfx lib project.

Ciao,
 -max


>----Messaggio 
originale----
>Da: joostp at 7fc1.org
>Data: 30/10/2008 0.33
>A: "Vicent Marti"
<tanoku at gmail.com>
>Cc: "ScummVM devel"<scummvm-devel at lists.sourceforge.net>

>Ogg: Re: [Scummvm-devel] Fwd:  PS2 backend - up & running (almost)
>

>PSP?  *Looks at email subject and scratches his head*
>
>Vicent Marti schreef:

>> Hey everyone,
>> 
>> fixed the crash with the overlay blitting and the 
chopped buttons.
>> Regarding the bitmode, that's easy enough to change. Check

>> VectorRendererSpec.cpp, line 157: VectorRenderer *createRenderer(int
>> 
mode);
>> It wouldn't quite work with a new function to the OSystem API, 
because
>> the bit format must be known at compile time. Maybe it could be set

>> with a define flag. This should be discussed.
>> 
>> Also, I can't reproduce 
the bug with the buttons not restoring to
>> their previous state, nor anything 
relating the cluttered look of the
>> GUI (i.e. except for the button text 
which has been fixed, when ran
>> with -g1x in my computer, the buttons are 
pretty much pixel-exact to
>> the old GUI, there is no superfluous spacing, the 
text scroll has 8
>> lines and so on...).
>> 
>> Can you post some pictures of 
the thing running on your PSP? I've only
>> been able to test the GUI by 
overriding the SDL screenInit() to
>> initialize the screen at the PSP's freaky 
resolution. It seemed to
>> work ok without any of those issues.
>> 
>> Cheers,

>> 
>> Vicent Martí
>> ----------------
>> http://www.smartlikearoboc.com
>> 

>> 
>> 
>> On Wed, Oct 29, 2008 at 6:26 PM, Max Horn <max at quendi.de> wrote:
>>> 
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
>>>
>>> 
-------------------------------------------------------------------------
>>> 
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge

>>> Build the coolest Linux based applications with Moblin SDK & win great 
prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in 
the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> 
_______________________________________________
>>> Scummvm-devel mailing list

>>> Scummvm-devel at lists.sourceforge.net
>>> https://lists.sourceforge.
net/lists/listinfo/scummvm-devel
>>>
>> 
>> 
-------------------------------------------------------------------------
>> 
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> 
Build the coolest Linux based applications with Moblin SDK & win great prizes

>> Grand prize is a trip for two to an Open Source event anywhere in the world

>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> 
_______________________________________________
>> Scummvm-devel mailing list

>> Scummvm-devel at lists.sourceforge.net
>> https://lists.sourceforge.
net/lists/listinfo/scummvm-devel
>> 
>

>-------------------------------------------------------------------------

>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge

>Build the coolest Linux based applications with Moblin SDK & win great prizes

>Grand prize is a trip for two to an Open Source event anywhere in the world

>http://moblin-contest.org/redirect.php?banner_id=100&url=/

>_______________________________________________
>Scummvm-devel mailing list

>Scummvm-devel at lists.sourceforge.net
>https://lists.sourceforge.
net/lists/listinfo/scummvm-devel
>