[Scummvm-devel] Fwd: [Scummvm-cvs-logs] SF.net SVN: scummvm: scummvm/trunk/backends/platform
aquadran at xtr.net.pl
Tue Nov 10 14:52:14 CET 2009
On 2009-11-09, at 23:15, Max Horn wrote:
> Am 09.11.2009 um 22:35 schrieb Max Horn:
>> Anfang der weitergeleiteten E-Mail:
>>> Von: Pawel Kolodziejski <aquadran at xtr.net.pl>
>>> Datum: 9. November 2009 17:21:14 MEZ
>>> An: Max Horn <max at quendi.de>
>>> Betreff: Re: [Scummvm-cvs-logs] SF.net SVN: scummvm: scummvm/
>>> On 2009-11-09, at 15:58, Max Horn wrote:
>>>> Am 09.11.2009 um 15:29 schrieb aquadran at users.sourceforge.net:
>>>>> Revision: 45775
>>>>> Author: aquadran
>>>>> Date: 2009-11-09 14:29:53 +0000 (Mon, 09 Nov 2009)
>>>>> Log Message:
>>>>> added samsung tv backend
>>>>> Added Paths:
>>>> This backend seems to duplicate most of the SDL backend -- very
>>>> ugly. Any particular reason it couldn't subclass the SDL backend,
>>>> instead of duplicating all that code?
>>> It's in progress, so subclass not yet, and there are small changes
>>> which does not allow much of methods as subclass. Also I don't want
>>> put hacks into main sdl code.
> Well, this new backend is still 95% identical to the SDL backend. I
> find this rather aggravating :/. As we make changes to the SDL
> backend, they will start to deviate further, though. I am scared by
> the prospect of having this SDL backend clone in there and starting to
> bitrot, just like ther old sdl-opengl backend. The SDL backend already
> contains tons of #ifdefs etc., so on the one hand it is not nice to
> had more, but on the other hand, it's not really making things
> But looking at your changes specifically, it seems to me that it would
> still be far preferable and indeed quite doable to realize this as a
> subclassed backend, by turning only a few key methods into virtual
> ones, resp. factoring out some code that you have to implement
> differently for your backend into new virtual methods. This will lead
> to much better code on the long run.
> Such a refactoring would be a nice small step towards refactoring the
> SDL backend to make life better for backends derived from it, such as
> the WinCE & Symbian backends.
> Disregarding the issues I have with the actual code, there is one
> other thing: I really really *really* dislike learning about a new
> backend being added via the commit message. This is just as bad as if
> it happens for an engine. This is really not good practice. In the
> future, I expect everybody who adds major new components like backends
> or engines to announce these *beforehand* on -devel, and wait for
> approval. Getting approval from either me or Eugene alone is not
> enough, this must go over -devel. Anyway, it's too late for that now;
> but please at the very least, write an email to -devel now which
> explains your new backend, what it is good for, and what your plans
> are to address the concerns I voiced above.
There are 3 things which are came into my mind right now.
- First take advantage of hardware 2D blitting.
To allow use it, destination surface must be HWSURFACE.
Source could be SW or HW.
It's unknown to me what are limitations. What pixel format it will work,
is it only 32 bit format? Is is capable pixel format conversion ?
How fast it is ?
So I need more test to figure out that things.
- Remote controller does not able double keypress.
Each keypress has some timeout delay until it send key up event.
So it's very difficult to do double click used in gui browser.
I wonder if it's possible emulate keypress by mapping to some
- Currently there is issues with positioning mouse cursor in game
Tested it with Tentacle. Mouse seems draw properly but game get wrong
coordinates. I'm a bit surprised, I did change thing only to SDL_Wrap
but maybe issue is here.
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
More information about the Scummvm-devel