[olofsonprojects] Re: kobodeluxe in OpenEmbedded
- From: David Olofson <david@xxxxxxxxxxx>
- To: olofsonprojects@xxxxxxxxxxxxx
- Date: Sun, 10 Feb 2008 01:44:54 +0100
On Sunday 10 February 2008, Robert Schuster wrote:
> Hi David,
> thanks for developing Kobo Deluxe! It is a awesome game.
>
> In your quest to bring kobodl on as many systems as possible I have
> something special for you: I just added a build recipe to
> OpenEmbedded.
[...]
Nice! :-)
> However I have seen that there was already an attempt to bring Kobo
> to Maemo. However no sourcecode has been released and I am sure that
> a bit of porting is neccessary.
I don't know about the details, but the game relies only on SDL and a
few POSIX calls that seem to be available pretty much everywhere.
glSDL is optional. Platforms without POSIX style user accounts might
need some #ifdefs (similar to what's done for Win32), but the code
should be there.
> My kobo binary displays no text
That's probably caused by a known issue with the graphics
loading/processing code, and it seems to happen on various other
platforms as well. Haven't had time to look into it yet, though.
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).
Normally, this sets the display depth on platforms that support it
(usually only possible in fullscreen mode, where applicable), and is
ignored otherwise - but it seems like I screwed something up in
0.5.1.
> and ingame a key binding is missing
> to shoot.
> @arnim: Can you send me your patches?
>
> @david: Are there plans to merge those modifications upstream?
Input is going to be fully configurable eventually, but platforms
without normal keyboards would still need special default mappings.
So, patches are welcome! The information will be useful in some form
no matter what.
If any other changes are needed, I'd definitely prefer to have them
merged in, as long as we're not talking about major changes that
cause maintenance issues. (I don't even have any hand held devices to
test on as of now.)
Well, there is the painfully slow sound rendering, which will also be
dealt with eventually - but at least it *works*, AFAIK.
The workaround for that is the "Cached Sounds" option, but that isn't
something that can (currently) be done by the build/install scripts.
As it is, you have to manually ensure you have write permissions
wherever the sound scripts are stored, start the game, activate
sounds + music and activate "Cached Sounds" to get them rendered to
disk.
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.
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:
