Hi, sorry but based on the replies I think perhaps I was misunderstood. I
want to port SDL onto a new embedded OS. I just wonder if there are any
guides anywhere as to how to go about this? I am sure I will need to wrap or
rewrite some low-level functions, but I have no idea where to start.
Thanks
Dirk Coetsee
This one’s come up before, and the response generally is something like this: The public header files contain a list of functions that SDL supports. Use native platform APIs to implement them so they work. How you do it is up to you. It’s hard to give implementation details for a new platform, since every platform is different, but try to do a good job. Good luck!>________________________________
From: Dirk Coetsee <dirk.coetsee at gmail.com>
Subject: [SDL] SDL on new OSHi, sorry but based on the replies I think perhaps I was misunderstood. I want to port SDL onto a new
embedded OS. I just wonder if there are any guides anywhere as to how to go about this? I am sure I
will need to wrap or rewrite some low-level functions, but I have no idea where to start.Thanks
Dirk Coetsee
---- Dirk Coetsee <dirk.coetsee at gmail.com> wrote:
=============
Hi, sorry but based on the replies I think perhaps I was misunderstood. I
want to port SDL onto a new embedded OS. I just wonder if there are any
guides anywhere as to how to go about this? I am sure I will need to wrap or
rewrite some low-level functions, but I have no idea where to start.
Thanks
Dirk Coetsee
Hi, sorry but based on the replies I think perhaps I was misunderstood. I
want to port SDL onto a new embedded OS. I just wonder if there are any
guides anywhere as to how to go about this? I am sure I will need to wrap or
rewrite some low-level functions, but I have no idea where to start.
Take a look at README.Porting in the SDL source archive.
See ya,
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
There are no guides as to how to port SDL. Here are a few tips.
Start with 1.3, that is where the real work is being done now days.
Try to borrow as much of the low level code as you can for your new OS.
If you find your self tempted to change any of the system independent parts
of SDL you are probably wrong and most likely very wrong. Go back and
rethink the problem and then ask Sam about it.
You are going to have to dig in and learn the structure of SDL. You’ll need
to learn the file structure first. Notice where you find files named for
operating systems and windowing systems, those a directories where you are
going to spend a lot of time. You’ll add directories for YourOS in all those
places.
You’ll need to learn the fine structure of the code. The overall structure
of the code is a simple two layer system. The top layer is machine
independent. The bottom layer is OS and hardware specific.
In between the two layers is the context. The context is a big structure
that contains pointers to all the system dependent parts of SDL. If you look
around you’ll find it. Put in stubs for all the system dependent parts and
get it all to compile, then start filling in the stubs.
Expect to spend some serious time getting the build system to work, your new
additions need to fit with the SDL build system. SDL has a million #ifdefs
and you need to get all the right things defined. Much easier to do it if
you use the existing build system.
SDL is built just like every other portable system I’ve ever seen, so if you
don’t understand the two layer structure of portable systems then SDL is a
good place to learn it.
But, seriously, you’re going to have to spend a lot of time reading source
code to figure it all out. SDL is well documented, but documentation is over
rated. Documentation lies, code does not lie.
Use the Source Luke.
Bob Pendleton
2009/3/21 Dirk Coetsee <dirk.coetsee at gmail.com>> Hi, sorry but based on the replies I think perhaps I was misunderstood. I
want to port SDL onto a new embedded OS. I just wonder if there are any
guides anywhere as to how to go about this? I am sure I will need to wrap or
rewrite some low-level functions, but I have no idea where to start.Thanks
Dirk Coetsee
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
±----------------------------------------------------------
Start with 1.3, that is where the real work is being done now days.
If you’re on a tight deadline and you don’t need 1.3 features like
multi-window support, you might want to use 1.2, honestly. It depends on
whether you want to merge your changes back into the main branch and if
this is something that needs to be upgraded over time (1.2 is stable,
but dead).
Here are some other tips…
If your system is some variation on Linux, you might find the code
already works (there is fbcon support for video, etc, already, and it
runnable on lots of embedded systems already). You almost certainly can
steal the POSIX stuff if you have an OS on your device at all.
In 1.2 or 1.3, mostly you’re going to find that you have to go look at
the audio, video, etc directories. All the platform stuff gets its own
directory under there, and there’s a well-defined interface that the
high level uses to talk to the low-level platform stuff. Cut-and-paste
from the platform that is closest to yours, or use the “dummy” targets
as a skeleton to build on.
For things you don’t care about (perhaps you have video but no audio on
the device?), just use the dummy target…it’ll make SDL think the
subsystem is there, and it just won’t do anything. This makes getting
existing SDL apps up and running easier, as well as lets you fill in one
subsystem at a time. SDL can also be built with specific subsystems
removed (#ifdef’d out entirely). For example: your embedded product
probably doesn’t care about CD audio.
If you’re using a Unix environment to build, you should add your stuff
to configure.in … if you have a custom build environment, the
README.Porting text file will tell you what to compile.
Feel free to ask the list if there are any specific subsystem questions.
Several readers have written SDL ports to various platforms and can
explain the finer points of obscure things if you get stuck.
Good luck,
–ryan.