What would be required to port SDL to a new platform? Besides the obvious
(video drivers, audio drivers, etc.) are there any “field notes” anyone
has in porting SDL. I’m interested in the low-level facets, and what Sam
considers hardware necessary to support a new platform. Are there any
assumptions on underlying video/audio hardware, threads, keyboard and
mouse events, etc? Or can a port be “minimal” (no keyboard,
joystick/mouse input only, no window manager, limited threads, etc.).
Any ideas?
Marcus
are you thinking console development here?
playstation, ps2 or dreamcast?
is there already such an effort going on?
At 3/8/00 4:52:00 PM, you wrote:>What would be required to port SDL to a new platform? Besides the obvious
(video drivers, audio drivers, etc.) are there any “field notes” anyone
has in porting SDL. I’m interested in the low-level facets, and what Sam
considers hardware necessary to support a new platform. Are there any
assumptions on underlying video/audio hardware, threads, keyboard and
mouse events, etc? Or can a port be “minimal” (no keyboard,
joystick/mouse input only, no window manager, limited threads, etc.).
Any ideas?
Marcus
What would be required to port SDL to a new platform? Besides the obvious
(video drivers, audio drivers, etc.) are there any “field notes” anyone
has in porting SDL. I’m interested in the low-level facets, and what Sam
considers hardware necessary to support a new platform. Are there any
assumptions on underlying video/audio hardware, threads, keyboard and
mouse events, etc? Or can a port be “minimal” (no keyboard,
joystick/mouse input only, no window manager, limited threads, etc.).
There really isn’t any limit to how minimal a port can be.
Obviously, more is better, but the MacOS port didn’t have anything
but 16 and 32bpp graphics and keyboard and mouse input for a long
time. I only considered it stable once the mouse routines and sound
had been added, but ports have started with less. 
SDL has been designed fairly modularized so it can run with a minimum
of hardware, if necessary. For example, the Linux driver how has AAlib
support - ascii video output, occasional mouse support, and some of the
more common keys.
It’s all up to you.
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
Yeah, I’m about to sourceforge some GPL (probably) cross development tools
(gcc 2.95.2, binutils, newlib) for PSX (grey and Net Yaroze) and PSX
PocketStation. There are limited libraries for SDL-type stuff to do on
the PSX (video and audio and events), and the good ones are Sony’s code,
and I don’t want to encourage users to link Sony’s code (for obvious
reasons). Besides ever since I downloaded Circus Linux, I’ve wanted to
see it on my favorite console :)!
As far as another project doing this? I dunno, there was a brief thread a
couple months back but that’s all I’ve seen.
I just want to make sure I get stuff started the right way to avoid
headaches later.
I have NO info on any low-level stuff on PSX2 or DreamCast, but I
haven’t bothered to look - my specialty is PSX.
MarcusOn Wed, 8 Mar 2000, Dave McClurg wrote:
are you thinking console development here?
playstation, ps2 or dreamcast?
is there already such an effort going on?
At 3/8/00 4:52:00 PM, you wrote:
What would be required to port SDL to a new platform? Besides the obvious
(video drivers, audio drivers, etc.) are there any “field notes” anyone
has in porting SDL. I’m interested in the low-level facets, and what Sam
considers hardware necessary to support a new platform. Are there any
assumptions on underlying video/audio hardware, threads, keyboard and
mouse events, etc? Or can a port be “minimal” (no keyboard,
joystick/mouse input only, no window manager, limited threads, etc.).
Any ideas?
Marcus
Cool, I know I can do joystick, mouse, audio, and video for the PSX, but
threads are going to be tougher (due to sparse documentation). While I
start porting, I’m also going to document my experiences into a general
"porting guide". The main thing I’m worried about is maintaining some
compatibility with existing apps, but I’ll get the guts done first.
I’m not really a game coder yet, but I think porting SDL to PSX will allow
me to break in and learn SDL and PSX development at the same time. If
anyone else has ideas on this, let me know.
Thanks,
MarcusOn Wed, 8 Mar 2000, Sam Lantinga wrote:
There really isn’t any limit to how minimal a port can be.
Obviously, more is better, but the MacOS port didn’t have anything
but 16 and 32bpp graphics and keyboard and mouse input for a long
time. I only considered it stable once the mouse routines and sound
had been added, but ports have started with less.
SDL has been designed fairly modularized so it can run with a minimum
of hardware, if necessary. For example, the Linux driver how has AAlib
support - ascii video output, occasional mouse support, and some of the
more common keys.
It’s all up to you.
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
Besides ever since I downloaded Circus Linux, I’ve wanted to
see it on my favorite console :)!
HAHAHAHAH! Cool!!! Burn me a PSX CD once you get it ported. 
-bill!
Cool, I know I can do joystick, mouse, audio, and video for the PSX, but
threads are going to be tougher (due to sparse documentation). While I
start porting, I’m also going to document my experiences into a general
"porting guide". The main thing I’m worried about is maintaining some
compatibility with existing apps, but I’ll get the guts done first.
I’m not really a game coder yet, but I think porting SDL to PSX will allow
me to break in and learn SDL and PSX development at the same time. If
anyone else has ideas on this, let me know.
VERY cool. Let me know if you have any questions.
The threading is the least important of the API’s, as long as the audio
can be done via callback some other way.
See ya!
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
I’m about to start a port of SDL to a new platform. Google didn’t
have any advice for me. Anyone here have some hints, tips, or words of
wisdom before I start?
Thanks,
Pat Roberts
Lowermars.com
I would just tell you to be as familiar as possible with the platform
before you start, and hope for your success.
see you.Em Sun, 25 Jul 2004 15:57:55 -0700, Patrick Roberts escreveu:
I’m about to start a port of SDL to a new platform. Google didn’t
have any advice for me. Anyone here have some hints, tips, or words of
wisdom before I start?
Thanks,
Pat Roberts
Lowermars.com
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
Using Opera’s revolutionary e-mail client: http://www.opera.com/m2/
Patrick Roberts wrote:
I’m about to start a port of SDL to a new platform. Google didn’t
have any advice for me. Anyone here have some hints, tips, or words
of wisdom before I start?
AFAIK, there is no such documentation. I googled for it to no avail too.
That said, it’s not that hard to move forward and do it directly.
First, gather as much information as you can about your underlying
platform, like what it can/cannot accelerate and how to do it. With SDL,
you’ll be mostly interested in the video capabilities (can it do blits,
if so do these support alpha, colokeying…) , the input system (how to
read the keyboard, mouse…), and the audio system (what mixing
rates/sound formats are supported…).
Then look at the dummy backends for each one : src/video/dummy,
src/audio/disk (which is almost dummy except it writes to disk),
src/main/dummy… and duplicate the ones you need.
I mostly worked with video backends so here’s specifically what I think
is the easiest way to get a new video backend up :
- write the boostrap structure and functions (Available, CreateDevice)
- write the basic functions : VideoInit, ListMode, and SetVideoMode. Let
the acceleration bits (blit_hw, blit_hw_CC…) at 0 for now
- write the AllocHWSurface function (if your platform doesn’t have hw
acceleration, that’s just a return -1)
- write the surface locking/unlocking functions (if your platform needs
these, it’s important to have them working correctly early, that’ll save
headaches later on). If you don’t have hw accel, these will be pretty
empty too.
- write the UpdateRects and FlipHWSurface functions
- you’ll probably need some placeholder functions to make the thing
compile now, add these
At this point, you have a more or less working video driver, but it’s
not accelerated. Get everything to work ok before moving to part 2
Now if your platform has hardware acceleration features that match the
SDL interface, here’s the fun part :
- write the HWFillRect function
- switch on the acceleration bits, preferably one by one
- write/modify the CheckHWBlit function that reports whether or not
hardware accel for a blit is available
- write/modify the HWAccelBlit function that does the accelerated blit
Note most backends don’t have hw acceleration or don’t make use of it,
and thus stop at the end of part 1.
Ok, I think that’s all. I’m not sure if that’s the best way but that’s
how I do it.
Good luck !
Stephane
Wow- Thanks! This is fantastic. Hopefully this message gets archived
somewhere, or maybe we can combine our experiences and make a porting faq.
This is my first time porting code for a public project. Should I use
the latest release source, or checkout a copy of the latest CVS? I
didn’t see any contributing code guidelines on the libsdl page, so am I
right to assume I need to send the finished port to someone to have it
considered for integration into the official dist?
Thanks again
Pat
Stephane Marchesin wrote:> Patrick Roberts wrote:
I’m about to start a port of SDL to a new platform. Google didn’t
have any advice for me. Anyone here have some hints, tips, or words
of wisdom before I start?
AFAIK, there is no such documentation. I googled for it to no avail too.
That said, it’s not that hard to move forward and do it directly.
First, gather as much information as you can about your underlying
platform, like what it can/cannot accelerate and how to do it. With SDL,
you’ll be mostly interested in the video capabilities (can it do blits,
if so do these support alpha, colokeying…) , the input system (how to
read the keyboard, mouse…), and the audio system (what mixing
rates/sound formats are supported…).
Then look at the dummy backends for each one : src/video/dummy,
src/audio/disk (which is almost dummy except it writes to disk),
src/main/dummy… and duplicate the ones you need.
I mostly worked with video backends so here’s specifically what I think
is the easiest way to get a new video backend up :
- write the boostrap structure and functions (Available, CreateDevice)
- write the basic functions : VideoInit, ListMode, and SetVideoMode. Let
the acceleration bits (blit_hw, blit_hw_CC…) at 0 for now
- write the AllocHWSurface function (if your platform doesn’t have hw
acceleration, that’s just a return -1)
- write the surface locking/unlocking functions (if your platform needs
these, it’s important to have them working correctly early, that’ll save
headaches later on). If you don’t have hw accel, these will be pretty
empty too.
- write the UpdateRects and FlipHWSurface functions
- you’ll probably need some placeholder functions to make the thing
compile now, add these
At this point, you have a more or less working video driver, but it’s
not accelerated. Get everything to work ok before moving to part 2
Now if your platform has hardware acceleration features that match the
SDL interface, here’s the fun part :
- write the HWFillRect function
- switch on the acceleration bits, preferably one by one
- write/modify the CheckHWBlit function that reports whether or not
hardware accel for a blit is available
- write/modify the HWAccelBlit function that does the accelerated blit
Note most backends don’t have hw acceleration or don’t make use of it,
and thus stop at the end of part 1.
Ok, I think that’s all. I’m not sure if that’s the best way but that’s
how I do it.
Good luck !
Stephane
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Wow- Thanks! This is fantastic. Hopefully this message gets archived
somewhere, or maybe we can combine our experiences and make a porting faq.
Well, people were talking about wikifying the SDL docs. That would probably be a good occasion to write a small “how to port SDL to new platforms”.
This is my first time porting code for a public project. Should I use
the latest release source, or checkout a copy of the latest CVS? I
didn’t see any contributing code guidelines on the libsdl page, so am I
right to assume I need to send the finished port to someone to have it
considered for integration into the official dist?
Yes, usually people base their code on latest CVS and wen they’re done send patches to this list against latest CVS. Also, there is a 20kb limit on the posts to this, so you might want to post a link if your patch is too big.
Stephane
putting this in the wiki is a good idea.
Stephane Marchesin wrote:>>Wow- Thanks! This is fantastic. Hopefully this message gets archived
somewhere, or maybe we can combine our experiences and make a porting faq.
Well, people were talking about wikifying the SDL docs. That would probably be a good occasion to write a small “how to port SDL to new platforms”.
This is my first time porting code for a public project. Should I use
the latest release source, or checkout a copy of the latest CVS? I
didn’t see any contributing code guidelines on the libsdl page, so am I
right to assume I need to send the finished port to someone to have it
considered for integration into the official dist?
Yes, usually people base their code on latest CVS and wen they’re done send patches to this list against latest CVS. Also, there is a 20kb limit on the posts to this, so you might want to post a link if your patch is too big.
Stephane
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Stephane Marchesin <stephane.marchesin at wanadoo.fr> wrote:
Yes, usually people base their code on latest CVS and wen they’re done
send patches to this list against latest CVS. Also, there is a 20kb
limit on the posts to this, so you might want to post a link if your
patch is too big.
also consider breaking up the patches into smaller, meaningful pieces.
review gets a lot easier and patches are more likly accepted.
clemens