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

Max Horn max at quendi.de
Thu Oct 30 17:52:31 CET 2008


Am 30.10.2008 um 00:20 schrieb Vicent Marti:

> 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);

Great, quick work!

> 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.

Actually, on the long run, it would be desirable to not have to  
specify a fixed bitformat during compile time. Already now, on OS X,  
we actually need to support both 555 and 565 mode in a single binary  
(currently, colors are wrong in fullscreen mode on OSX due to this;  
start ScummVM in fullscreen mode, use the modern theme, open a dialog:  
the background is 'dimmed' incorrectly).

While we probably can support multiple color modes right now by  
compiling in multiple specializations of the templates, and switching  
between them via some runtime checks, this bloats the binary. Not a  
major deal for desktop ports, but if we have any small device that  
requires this, we'd have a problem... also, does your code work  
correctly in 4444 mode, in 888 or 8888 mode, and in "wrong endian  
555/565" mode (i.e. 555/565 mode where the bytes are swapped --  
leading to the bits of one color not being "adjacent") ?

We really are facing a trade off here: Maximal speed and code size vs.  
maximal genericity. To me, it is not yet clear which one should be the  
winner. Like, is the GUI code fast enough? If yes, would it still be  
fast enough when using PixelFormats like SDL does, instead of  
specializing during compile time on a specific bitformat? If no, what  
about it is too slow? How can we speed it up? Does code specialization  
help at all? Bigger code size also means worse cache usage, which can  
also degrade performance. etc., etc., a complex subject :)


> 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...).

It actually has 10 lines for me -- though it should easily be possible  
to fit in 11, maybe even 12 lines, by slightly increasing the height  
of the list control, and moving the two buttons rows closer together.

Anyway, here's some feedback on the GUI in 1x mode. Note that I am in  
no way implying that the current layout is Tanoku's "fault", I merely  
am using this opportunity to write this down, hoping that somebody  
will take care of those :). For the RTL dialogs, that somebody might  
be Chris, too.

Launcher options dialog:
* Audio tab: the "Subtitle speed:" and "Text and Speech:" should IMO  
be aligned along the ":" with the other two labels.
* Audio tab: The "Text and Speech" button should be wider, right now  
it display "ech and Subtit" for me, instead of "Speech and  
Subtitles" ;). Maybe turn that into "Speech & Subtitles", too, to save  
two chars
* Volume tab: Align the three labels along their colon? (probably  
means setting them to be right aligned)
* Misc tab: The rendered popup is not wide enough to display the full  
renderer name. But we could grow it a bit, by moving the label more to  
the left, that might be sufficient.

Launcher game edit dialog:
* On the audio tab, if the Override checkbox is *not* active, all  
items are supposed to be grayed out. The popup button, however, is not.
* Volume tab: See options dialog

GMM (global main menu), triggered right now via F6 in SCUMM and other  
games:
* The "RTL" button is not wide enough to show its complete text ->  
could make it a lot wider, or shorten text?
* the options dialog in there has a Speech & Subtitles which is not  
wide enough (like in the launcher)
* also in the GMM options dialog, I would consider right-aligning the  
widget labels.



> 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.

As Max already clarified, we are talking about the PS2 (sorry for  
causing this confusion). The PSP does use 4444 mode, though, hence I  
wonder how the new GUI "looks" on it, too -- Joost? :)


Cheers,
Max




More information about the Scummvm-devel mailing list