[olofsonprojects] Re: kobodeluxe in OpenEmbedded
- From: David Olofson <david@xxxxxxxxxxx>
- To: olofsonprojects@xxxxxxxxxxxxx
- Date: Sun, 10 Feb 2008 03:33:00 +0100
On Sunday 10 February 2008, Robert Schuster wrote:
[...]
> The real issue is that with a device having less (or no) keys, no
> joystick and most often only a touch screen game control has to be
> rethought a bit. :)
Yeah, that's what I figured. :-)
[...]
> >> My kobo binary displays no text
> >
> > Workaround for now: Try setting the "depth" option ("Display
> > Depth" in the menues, "depth" in the config file and -depth on the
> > command line) to some other value than 0 (Default).
> Have tried it but it does not work. This is how it looks btw:
> http://scap.linuxtogo.org/files/0b3b8a00e81831f3f058e837f9d9ed01.png
Ok... Guess this calls for some debugging then. Looked briefly at the
code, but I can't think of anything obvious to try.
Well, you can use '-logverbosity 5' and send me the output. Might be
some hint there, though I doubt it. (Not much debug output around
that code now, and if anything fails to load it should give up and
exit.)
Some switches that might be worth playing with:
-scalemode [1] Scaling Filter Mode
-[no]dither [On] Use Dithering
-dither_type [0] Dither Type
-[no]broken_rgba8 [Off] Broken RGBA (OpenGL)
-[no]alpha [On] Use Alpha Blending
Sorry, no values/limits in the builtin documentation yet - but you can
see the valid alternatives in the config menues. Have a look in
options.cpp.
[...]
> I will try kobo on the neo1973 (openmoko's free phone). Additional
> fun:
> It has only two keys and a touch screen. :)
Well... Maybe you could use the "Always Fire" option and implement
Asteroids style control. Or, binary control, but that leaves only
four directions accessible. :-)
Then again, in the specification, it looks like the only buttons are
the power button and the "Aux" button, and those aren't exactly
suitable for controls.
How about using the accelerometers? Grab the forces at "level start"
and "new life" as reference, and do the trig to calculate the
deviation. If the two accelerators are in different locations, it
might be possible to combine the signals in order to filter out
undesired input - if the OS/driver doesn't do that already.
> > Hopefully though, integer based processing and IFFT synthesis
> > (instead of the current brute force "spectrum" oscillator banks)
> > should speed things up enough that caching isn't required on
> > anything that's fast enough to render the game playable.
> That would be good for embedded-cpus without fpu. The N800/N810s
> have such a thing however. :)
Well, I know about the VFP, but that appears to be a SIMD extension or
similar. Is that actually usable without specific code?
As to the pre N800 Nokia tablets, Arnim contacted me specifically
about caching, as it would be required for a usable port. The sound
effects and instruments took 180 seconds to render on a 770. (ARM9 -
no floating point h/w at all, AFAIK.)
This was pre 0.5.1, so it's most probably a lot worse now. The
rendering time is close to two seconds even on my Q6600 @ 3 GHz.
(Only one core used, but still...)
Regards,
//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:
