[olofsonprojects] Re: kobodeluxe in OpenEmbedded
- From: Robert Schuster <theBohemian@xxxxxxx>
- To: olofsonprojects@xxxxxxxxxxxxx
- Date: Sun, 10 Feb 2008 05:11:23 +0100
Hi,
its me again. :)
You may add fic gta01 (armv4t) to your ports list:
http://scap.linuxtogo.org
David Olofson schrieb:
> 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. :-)
I found the "mouse" option (without text this was difficulet to set in
menu) and switched it on. Now I can steer by moving a pointer across the
touchscreen. That is pretty neat. You can literally point at the
enemies. On the small neo screen my hand was in the way a lot.
For the Neo the menu controls need to be changed a bit: Button one could
be "move to the next item", button two "invoke". Furthermore it should
not react so quickly on mouse presses, every 'move' with the pen is a
click ...
I will try to get that working later.
>>>> My kobo binary displays no text
> 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
Haven't tried this yet but will do so later.
Still I have found out something that is weird: The Neo can operate in
two screen orientation ( 480x640 (default) and 640x480 (rotated) ).
In the first video mode text display is just fine. However in 640x480
(where kobo makes much better use of the display area) it is not. :$
> [...]
>> 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?
No the VFP is a modern FPU for the arm cores.
Btw: If you had not said these things about the sound engine I wouldn't
have noticed. Sound and music on the n800 are quite good. It begins to
studder when you leave fullscreen mode (some other app interferes) but
otherwise it is ok.
> 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...)
Ah now I get it. You mean the preparation/loading at the beginning.
Yeah, this takes a while on the Nokia but it is not that bad.
Completely different thing on the Neo (without fpu): It took around ten
minutes...
On a completely different topic: Have you ever thought about adding a
multiplayer option? Something like red player has his red bases and blue
player has his blue bases. Whoever destroys the other's base faster
wins. Red stuff can shoot blue stuff and vice versa. How flexible is the
game's engine in this regard?
Regards
Robert
Other related posts:
