[Scummvm-devel] Fwd: PS2 backend - up & running (almost)
Vicent Marti
tanoku at gmail.com
Thu Oct 30 00:20:04 CET 2008
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
>
More information about the Scummvm-devel
mailing list