[olofsonprojects] Re: kobodeluxe in OpenEmbedded
- From: David Olofson <david@xxxxxxxxxxx>
- To: olofsonprojects@xxxxxxxxxxxxx
- Date: Sun, 10 Feb 2008 06:49:00 +0100
On Sunday 10 February 2008, Robert Schuster wrote:
> Hi,
> its me again. :)
>
> You may add fic gta01 (armv4t) to your ports list:
> http://scap.linuxtogo.org
No one's safe from the Kobo addiction now! ;-)
> 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.
DOH! Maybe I should have pointed that out. :-D (Pun not intended!) It just
seemed too obvious, but...
> On the small neo screen my hand was in the way a lot.
...I figured that would be a problem. :-)
> For the Neo the menu controls need to be changed a bit: Button one
> could be "move to the next item", button two "invoke".
No problem, I think... Menu navigation is circular. (I *think* that goes for
all value entry "widgets" as well, but I could be forgetting something.
Looooong way around in some cases though...)
Either way, I'm having some ideas about some more modern GUI solution, similar
to that in the Steam games from Valve; dialog windows with buttons and stuff.
That should make touch screens usable out of the box, I think.
> Furthermore it should not react so quickly on mouse presses,
> every 'move' with the pen is a click ...
Hmm... Seems like that would need some device specific filtering.
And, in fact, the menu system reacting on mouse clicks is actually a bug
anyway; the meny system doesn't support mouse navigation! :-)
> I will try to get that working later.
Well... I think you'd have to ignore mouse motion and translate clicks into the
appropriate focus changes + activations. Should be a simple hack, but if it
isn't, I wouldn't waste too much time on it, as it might be thrown out soon
anyway.
[...]
> 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. :$
Unless the rotation is implemented in hardware, I'd think it's SDL that does
the rotation. If so, that would mean SDL uses an internal shadow surface, and
that may well mean that you get a different pixel format or something.
Or perhaps there is something wrong with alpha blending in that SDL version...?
(That would likely be disabled when a shadow surface is used, as many APIs only
accelerate blits to the screen.)
Does it attempt to use hardware acceleration for the blits?
[...]
> >> 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.
Yeah, I read up a little on it... Looks like pretty nice stuff.
> 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.
Ok. Might have to up the buffering/latency a bit then... Or maybe lower the
mixing quality, if the CPU load is the problem.
What's the output sample rate? (If it's significantly lower than 44.1 kHz, it
might cause the adaptive oversampling to kick in and increase CPU load, as many
of the sounds are rendered at 16 kHz or higher.)
BTW, would you know if the audio driver supports memory mapped I/O, ie shared
DMA buffer? (That would allow substantial buffering for solid playback,
alongside with "asynchronous" mixing for near zero latency. Stock SDL doesn't
support that, but most backends already use memory mapped I/O, so it shouldn't
be too hard to get at those buffers if desired.)
[...]
> > 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.
Ok. Well, there is the caching, but some healthy optimizations would probably
eliminate the need for that.
> Completely different thing on the Neo (without fpu): It took around
> ten minutes...
Yeah... *hehe*
> On a completely different topic: Have you ever thought about adding
> a multiplayer option?
Yeah, I think there are some notes about it in the TODO file.
> 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?
Well, it's all hardwired C++, but it's simple and well structured. Should be
pretty trivial to get multiple player ships on the map and stuff like that.
The hard part (in any real time multiplayer game) is dealing with latencies and
synchronization of game states. Unless you can rely on a constant network
latency of less than 10 ms or so, you absolutely need the clients to run
asynchronously, and to deal with any significant latencies, you need prediction.
Then again, as far as human players are concerned, you can't do much more than
assume that the input state doesn't change between updates. The rest (AI ships)
can run locally on the standard game logic, I suppose... That way, enemies will
do their stuff as usual, the chain reactions when bases explode will work
smoothly etc.
One would need to add support for "forced corrections" of the game state for
when the clients (or client/server) disagree when resyncing. Problem is passing
the whole state around is just way too much data (hint: ENEMY_MAX is 2048 ;-),
and passing deltas is kind of hard when everything's changing on both sides.
Easiest way might actually be to implement a "world snapshot" feature, so that
the world state can be rolled back to the time of the last sync and then
replayed with the correct input data from both players as it becomes available.
That way, only player input data should have to be transmitted, and that's just
four bits per 30 ms, raw. :-)
Oh, and there are five different base themes now, so... Five players, free for
all? Or why not two or more teams, with virtually unlimited numbers of players?
:-D
That said, I'm not planning on having "official" multiplayer support in 1.0.0.
The idea is to bring Kobo Deluxe up to "commercial quality" ASAP, and that's
quite some work even for the basic "refurbished XKobo" feature set.
Truth to be told, I'm sort of using Kobo Deluxe as a pilot project for future
shareware projects, but that doesn't really change anything at this point.
Still have to work on other things for food etc.
//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 --'
Other related posts:
