[olofsonprojects] Re: kobodeluxe patch to allow menu control with touchscreen
- From: David Olofson <david@xxxxxxxxxxx>
- To: olofsonprojects@xxxxxxxxxxxxx
- Date: Mon, 11 Feb 2008 08:30:49 +0100
On Monday 11 February 2008, Robert Schuster wrote:
> Hi David,
> thanks you liked my last patch. Here comes the first one which makes
> kobo deluxe usuable on more platforms! (especially those without
> keys :) )
[...]
Nice work! :-)
I'll have to look closer at this later, but some comments below for
now...
(Right now I'm busy fighting GCC 4.2.2, which is apparently trying to
optimize the EEL VM beyond the speed of light or something... Of
course, all that does is corrupt VM registers when the VM tries to do
inplace operations, which results in a mess not even Valgrind can
make much sense of. *heh* Even so, I've narrowed it down two
functions now, so I should have it sorted pretty soon.)
> Furthermore it would be nice if the game could somehow show the
> pointer borders. I haven't looked into the graphics routines but the
> following might be a possibility which you (with more knowledge
> about the game) can implement quickly I think: When switching
> between the menus some kind of distortion effect you could be
> painted along the border lines.
> The idea is that the learns how big it is by seeing it sometimes.
Well, anything is possible, of course. The tricky bit is that the
screen is using a "smart refresh" engine, so only areas that actually
change are updated. That means, the game view is updated every frame,
but the score displays, map window etc update only as needed.
(And yeah, this is one PITA with pageflipping displays. Triple
buffering can't even be detected in any obvious way, so there's a
manual option for that now. I'll throw in some write/flip/readback
hack to check what's *really* going on after initializing video, so
this option can be set automatically. This will speed up the smart
updates substantially on displays that "flip" by means of back->front
blits, as they can be handled like single buffered displays.)
Anyway, as long as the engine does what it should, it's actually quite
simple in theory. The engine provides low level windowing
functionality, where you subclass window_t and provide a refresh()
method to do the rendering. A window (or the whole screen, or a
specific area of the screen) can be invalidated to have it updated,
and the engine will automatically call the refresh() methods of all
affected windows as needed to update all display pages and whatnot.
So, I guess one could basically just implement a transparent overlay
window class that somehow has underlying windows refresh before it
refreshes itself. Then it's just a matter of throwing some nice
special FX rendering code in the refresh() method and placing these
windows over the "touch zones" as desired.
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'
---------------------------------------------------------------------------
The Olofson Projects mailing list.
Home: http://olofson.net
Archive: //www.freelists.org/archives/olofsonprojects
Unsubscribe: email olofsonprojects-request@xxxxxxxxxxxxx subj:"unsubscribe"
---------------------------------------------------------------------------
Other related posts:
