SDL and/or FB access for a ported game

ledow · 07-10-2013, 10:10 AM

Hi,

I just picked up a Kobo Mini - ridiculously cheap and I thought it would be quite hackable. I'm not disappointed!

I was looking at porting a piece of software that I'm familiar with - Simon Tatham's Portable Puzzle Collection - to it. It seems a good match for the touchscreen, limited colours, slow screen updates, etc.

I've previously ported this to the GP2X which runs on an ARM chip, so I'm hoping to reuse most of my work but it's the display that I'm finding a pain.

Do we have any way to refresh / draw direct to it reliably across all Kobo models yet? I've looked into the files on my device and it seems to think it's a 16-bit display and framebuffer (when I dump the contents of fb0), but I'm assuming that's just a variation on published information which says the Kobo tends to give 4- or 8-bit framebuffers.

I don't mind interfacing direct with the framebuffer for now, and calling pickel for screen updates, but I'd like to move to a more integrated solution eventually. Do we have any information that way yet?

Also, I'm going to be re-using my SDL-based backend. Probably, initially, I'll just disable the SDL graphics functions and use it as a pixel-shifter on a dummy framebuffer, but I was wondering if there is any SDL library available for the device yet, or will I have to get compiling? I don't need video-access or acceleration, but I just use the SDL_gfx library a lot in my port of the puzzles collection along with various SDL_Surfaces as the backend storage for screen images. At worst, I'll just compile SDL in a "dummy" mode and use it to generate bitmaps that I'll throw at pickel's "showimage".

Apart from that, anything else I should know? I have ARM-compatible code, I assume tslib is available for touch screen interfacing (or, at worst, probing the Linux input devices directly), I don't need sound or fast graphics updates, I have plenty of storage, it seems, so I'm hoping it'll be quite a nice port.

Is there any information about getting a link to an executable into the menu of the Kobo so it can be run directly? I've seen it done with a "book" that ran an executable.

(Also, did anyone else spot that in the SD card there are other games for the menu? My UK WHSmith Kobo only shows Sudoku and Chess but there's Linux .so's in there for Boggle and all sorts).

PeterT · 07-10-2013, 01:17 PM

I think if you look through this sub-forum you will find lots of useful tips; what toolchain to use for cross compiling; the Kobo Launcher that can be used to launch you own tools; even look at the koreader project for ideas

KevinShort · 07-10-2013, 02:19 PM

Hi, ledow, welcome to the forums!

The Mini does indeed have a 16-bit framebuffer. The only Kobo models with a 4 or 8-bit framebuffer are the original Kobo and the Wifi. The Touch, Mini, Glo, and Aura are all 16-bit.

For updating the e-ink display after you've written to it, you can check out my code from here and also tonyv's code here.

SDL can write directly to the Kobo's framebuffer no problem. I've used pygame, a SDL wrapper for python, to draw to the screen. I also managed to get SDL gnuboy to run on my Glo, although with no keyboard there was no way to control it.

Hopefully this is a little helpful, if you have more questions feel free to ask away.

giorgio130 · 07-10-2013, 03:33 PM

As PeterT was saying have a look at https://github.com/koreader for a standalone solution; also SDL has been ported to kindles, and it should be straightforward to apply the fixes for a kobo port.

ledow · 07-10-2013, 04:15 PM

Thanks for the links.

I had the toolchain up and running already but had only done a printf("Hello World") at the time of writing the first comment. The toolchain is basically the same as I had for the GP2X, with a more generic ARM compiler, so I'm currently just churning through cross-compiling some C-based libraries to ARM (I have about 10 libraries and their dependencies to cross-compile in order to use my old GP2X code as-is).

Currently messing about with a virtual machine with an Ubuntu copy of Eclipse with MinGW (32 and 64), arm, and Linux compilers trying to get them all to the same point so I can start tweaking my code to fit the Kobo's quirks without having to worry about the development environment.

A quick SDL-based test was indeed successful, I just have to smarten it up and then hopefully the bulk of the work is done and it's just making it look pretty on the Kobo (it was originally coded for a landscape screen but it would better suit a portrait, it has keyboard "emulation" code to solve the same problem of the Kobo not having that kind of input, it has it's own launcher/interface menu that isn't part of the original games, etc. etc.).

If/when I get something clean and finished, I'll put my virtual machine image up somewhere to save others the effort of setting up all the cross-compilers and Eclipse to work for "one-touch" compiles for the platform.

07-10-2013, 10:10 AM	#1
ledow Junior Member Posts: 2 Karma: 10 Join Date: Jul 2013 Device: Kobo Mini	SDL and/or FB access for a ported game Hi, I just picked up a Kobo Mini - ridiculously cheap and I thought it would be quite hackable. I'm not disappointed! I was looking at porting a piece of software that I'm familiar with - Simon Tatham's Portable Puzzle Collection - to it. It seems a good match for the touchscreen, limited colours, slow screen updates, etc. I've previously ported this to the GP2X which runs on an ARM chip, so I'm hoping to reuse most of my work but it's the display that I'm finding a pain. Do we have any way to refresh / draw direct to it reliably across all Kobo models yet? I've looked into the files on my device and it seems to think it's a 16-bit display and framebuffer (when I dump the contents of fb0), but I'm assuming that's just a variation on published information which says the Kobo tends to give 4- or 8-bit framebuffers. I don't mind interfacing direct with the framebuffer for now, and calling pickel for screen updates, but I'd like to move to a more integrated solution eventually. Do we have any information that way yet? Also, I'm going to be re-using my SDL-based backend. Probably, initially, I'll just disable the SDL graphics functions and use it as a pixel-shifter on a dummy framebuffer, but I was wondering if there is any SDL library available for the device yet, or will I have to get compiling? I don't need video-access or acceleration, but I just use the SDL_gfx library a lot in my port of the puzzles collection along with various SDL_Surfaces as the backend storage for screen images. At worst, I'll just compile SDL in a "dummy" mode and use it to generate bitmaps that I'll throw at pickel's "showimage". Apart from that, anything else I should know? I have ARM-compatible code, I assume tslib is available for touch screen interfacing (or, at worst, probing the Linux input devices directly), I don't need sound or fast graphics updates, I have plenty of storage, it seems, so I'm hoping it'll be quite a nice port. Is there any information about getting a link to an executable into the menu of the Kobo so it can be run directly? I've seen it done with a "book" that ran an executable. (Also, did anyone else spot that in the SD card there are other games for the menu? My UK WHSmith Kobo only shows Sudoku and Chess but there's Linux .so's in there for Boggle and all sorts).

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Getting SDL to work on DirectFB	B_Lizzard	Kindle Developer's Corner	13	10-01-2012 12:42 PM
Can this app be ported to M92?	PF4Mobile	Onyx Boox	0	08-09-2012 09:50 AM
Having ported a hit game from iOS, one developer reveals the good, bad and the ugly	RockdaMan	Android Devices	9	06-21-2011 12:26 AM
Kobo Firmware Access and Early Access Program	PeterT	Kobo Reader	115	08-09-2010 08:06 PM

07-10-2013, 01:17 PM	#2
PeterT Grand Sorcerer Posts: 12,167 Karma: 73448616 Join Date: Nov 2007 Location: Toronto Device: Nexus 7, Clara, Touch, Tolino EPOS	I think if you look through this sub-forum you will find lots of useful tips; what toolchain to use for cross compiling; the Kobo Launcher that can be used to launch you own tools; even look at the koreader project for ideas

07-10-2013, 02:19 PM	#3
KevinShort Addict Posts: 348 Karma: 209937 Join Date: Jan 2012 Location: Virginia, US Device: Kobo Wifi, Kobo Glo	Hi, ledow, welcome to the forums! The Mini does indeed have a 16-bit framebuffer. The only Kobo models with a 4 or 8-bit framebuffer are the original Kobo and the Wifi. The Touch, Mini, Glo, and Aura are all 16-bit. For updating the e-ink display after you've written to it, you can check out my code from here and also tonyv's code here. SDL can write directly to the Kobo's framebuffer no problem. I've used pygame, a SDL wrapper for python, to draw to the screen. I also managed to get SDL gnuboy to run on my Glo, although with no keyboard there was no way to control it. Hopefully this is a little helpful, if you have more questions feel free to ask away.

07-10-2013, 03:33 PM	#4
giorgio130 Time Waster Posts: 422 Karma: 289160 Join Date: May 2011 Device: Kobo Glo and Aura HD	As PeterT was saying have a look at https://github.com/koreader for a standalone solution; also SDL has been ported to kindles, and it should be straightforward to apply the fixes for a kobo port.

07-10-2013, 04:15 PM	#5
ledow Junior Member Posts: 2 Karma: 10 Join Date: Jul 2013 Device: Kobo Mini	Thanks for the links. I had the toolchain up and running already but had only done a printf("Hello World") at the time of writing the first comment. The toolchain is basically the same as I had for the GP2X, with a more generic ARM compiler, so I'm currently just churning through cross-compiling some C-based libraries to ARM (I have about 10 libraries and their dependencies to cross-compile in order to use my old GP2X code as-is). Currently messing about with a virtual machine with an Ubuntu copy of Eclipse with MinGW (32 and 64), arm, and Linux compilers trying to get them all to the same point so I can start tweaking my code to fit the Kobo's quirks without having to worry about the development environment. A quick SDL-based test was indeed successful, I just have to smarten it up and then hopefully the bulk of the work is done and it's just making it look pretty on the Kobo (it was originally coded for a landscape screen but it would better suit a portrait, it has keyboard "emulation" code to solve the same problem of the Kobo not having that kind of input, it has it's own launcher/interface menu that isn't part of the original games, etc. etc.). If/when I get something clean and finished, I'll put my virtual machine image up somewhere to save others the effort of setting up all the cross-compilers and Eclipse to work for "one-touch" compiles for the platform.

Advert

Advert