[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