Now this… must be a pipe dream.
Has anyone out there ever attempted to create a version of SDL that would produce code able to run on a console system?
Super Nintendo, Nintendo, Genesis, Playstation, etc.
Its gotta be a pipe dream I know… but it sure would be neato.
Robert Schultz - @Robert_Schultz
Robert Schultz schrieb am 02 Feb 2001:
Has anyone out there ever attempted to create a version of SDL that would produce code able to run on a console system?
Super Nintendo, Nintendo, Genesis, Playstation, etc.
Actually, the dreamcast would be the most promising platform for
such a project (since it’s got a working serial port, optional ethernet
adapter, and most importandly, already runs BSD & linux).
Tricky. I can’t speak to anything but the Playstation, but it would be an
interesting problem. The Playstation is only a 3D renderer – so all the
SDL video access stuff is meaningless…UNLESS you wrote an OpenGL wrapper
for the Playstation API, and then you would have to deal with all the
specialized and incompatible drawing calls on the Playstation.
It would probably impose a real performance hit, as well.
Both the PS and PS2 are very specialized hardware systems. To maximize
their performance, you really have to dig in and take advantage of their
strengths and weaknesses. (For example, the PS has a 4kb execution
buffer. So all the submodules of a program are should fit into 4k.) It
doesn’t lend itself well to cross platform programming.
That isn’t to say it wouldn’t be very useful to have and API that would
allow you to quickly move games among the various machines. Video Game
companies spend a huge penny on porting.
lee>Now this… must be a pipe dream.
Has anyone out there ever attempted to create a version of SDL that would
produce code able to run on a console system?
Super Nintendo, Nintendo, Genesis, Playstation, etc.Its gotta be a pipe dream I know… but it sure would be neato.
Robert Schultz - <mailto:bert at ncinter.net>bert at ncinter.net
Tricky. I can’t speak to anything but the Playstation, but it would be an
interesting problem. The Playstation is only a 3D renderer – so all the
SDL video access stuff is meaningless…UNLESS you wrote an OpenGL wrapper
for the Playstation API, and then you would have to deal with all the
specialized and incompatible drawing calls on the Playstation.
Not only this. We’ll also have the same flap we had back when someone
proposed porting Crystal Space to the Playstation. I suppose no one has
forgotten that SDL’s licensing is LGPL, and that sort of prevents Sam or
any of the developers actively involved in developing SDL from signing the
NDA which Sony requires of all would-be Playstation and PS2 developers. I
hope this is not true of other gaming consoles.
Oh and by the way, what happened to the Dreamcast is unfortunate. Sega
has decided to pull it from production, so I guess that’s out.On Fri, 2 Feb 2001, Lee Thomason wrote:
–
Rafael R. Sevilla <@Rafael_R_Sevilla> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
“Rafael R. Sevilla” wrote:
Tricky. I can’t speak to anything but the Playstation, but it would be an
interesting problem. The Playstation is only a 3D renderer – so all the
SDL video access stuff is meaningless…UNLESS you wrote an OpenGL wrapper
for the Playstation API, and then you would have to deal with all the
specialized and incompatible drawing calls on the Playstation.Not only this. We’ll also have the same flap we had back when someone
proposed porting Crystal Space to the Playstation. I suppose no one has
forgotten that SDL’s licensing is LGPL, and that sort of prevents Sam or
any of the developers actively involved in developing SDL from signing the
NDA which Sony requires of all would-be Playstation and PS2 developers. I
hope this is not true of other gaming consoles.
The PSX has 1MB RAM. Do you really want to run GL (or SDL) on that :?
PS2 is a lot more powerful obviously, but it’s not made for GL either.
Oh and by the way, what happened to the Dreamcast is unfortunate. Sega
has decided to pull it from production, so I guess that’s out.
Millions of units are already out, a large number of games are still in
production, and it’s likely that Sega will license the technology. The
DC is far from dead. (Except for my DC, of course, which just got fried
by a damaged controller – time for an RMA…)
-John> On Fri, 2 Feb 2001, Lee Thomason wrote:
–
Underfull \account (badness 10000) has occurred while \spend is active
John R. Hall - Student, Georgia Tech - Contractor, Loki Software
The PSX has 1MB RAM. Do you really want to run GL (or SDL) on that :?
The C64 only had 64 KByte of RAM and yet I spend enough time playing games
on it. I don’t know how much memory a GameBoy has but definitely less than 1
MByte. One MByte can be a lot of memory for 2D games.
To keep it on- topic. Did anyone ever have a look how much memory SDL
consumes for internal caches/ buffers/ lookup tables and stuff like that?
Programmer, Epic Games Inc.
Why would you want to go the way through OpenGL? “All” you had to do were to
write a 2D wrapper for the PSX’ 3D functionality. This should be really
straightforward.
Programmer, Epic Games Inc.On Fri, 2 Feb 2001, Lee Thomason wrote:
Tricky. I can’t speak to anything but the Playstation, but it
would be an interesting problem. The Playstation is only a 3D
renderer – so all the SDL video access stuff is meaningless…
UNLESS you wrote an OpenGL wrapper for the Playstation API,
and then you would have to deal with all the specialized and
incompatible drawing calls on the Playstation.
Daniel Vogel wrote:
The PSX has 1MB RAM. Do you really want to run GL (or SDL) on that :?
The C64 only had 64 KByte of RAM and yet I spend enough time playing games
on it. I don’t know how much memory a GameBoy has but definitely less than 1
MByte. One MByte can be a lot of memory for 2D games.
Agreed, but there’s hardly room for a hardware abstraction layer, even a
well-behaved one like SDL.
libSDL.so is 972k on my system (granted, it’s decked out with options
and not stripped).
-John–
Underfull \account (badness 10000) has occurred while \spend is active
John R. Hall - Student, Georgia Tech - Contractor, Loki Software
Agreed, but there’s hardly room for a hardware abstraction layer, even a
well-behaved one like SDL. libSDL.so is 972k on my system (granted, it’s
decked out with options and not stripped).
UT on Linux including all libraries it ships with (that includes SDL, OpenAL
and libmikmod) is ~ 3 MByte and that’s a lot of code in there 
Also keep
in mind what you can do with little memory or little size -
http://www.theproduct.de is an awesome demo that is only 64k in size. I am
getting off topic here but I can’t see why you wouldn’t be able to get SDL
up and running on a machine with 1 MByte of memory. If you can get gcc (and
SDL) running on a Visor there is very little what you can’t do 
Of course
you’ll statically link against SDL so the linker can get rid of any
unnecessary code and of course you always want to strip your binary. Oh,
also don’t forget that libSDL links statically against some libraries.
My point is that SDL is a thin enough abstraction layer to be able to work
very well on embedded systems and consoles. Don’t
forget the small systems - that’s where the money seems to be in the Linux
world if you believe all the hype
Programmer, Epic Games Inc.
Not only this. We’ll also have the same flap we had back when someone
proposed porting Crystal Space to the Playstation. I suppose no one has
forgotten that SDL’s licensing is LGPL, and that sort of prevents Sam or
any of the developers actively involved in developing SDL from signing the
NDA which Sony requires of all would-be Playstation and PS2 developers. I
hope this is not true of other gaming consoles.
I have pasted, following my signature, the standard response from MS
concerning Xbox development, which clearly states that developers must sign
license and ND agreements…
Olivier A. Dagenais - Software Architect and Developer
Thank you for your interest in the Xbox development.
The Xbox is the most powerful game console yet built, and it is a
non-trivial platform for which to develop. If you are not conversant in
modern programming techniques and tools, if you don’t know C++, DirectX, and
have a solid grasp of modern processor and graphics technologies, you
probably want to reconsider trying to develop a game until you have these
fundamentals down. On the other hand, if you know DirectX and nVidia, have
made games on other consoles, and/or PC’s and have a great idea, you should
definitely talk to us.
The Xbox is a game console. As such, we are not likely to approve
development or publication of non-game titles at this early stage. The ideas
we want to see are hard-core games for hard-core gamers in the 16 to 26 year
old market. If you want to make the next great children’s educational title,
then Xbox is not for you at this time.
There are three ways to get on board Xbox development. The primary method
for becoming an Xbox developer is to be working with a publisher on an
approved Xbox title. Developers working on approved titles have access to
full technical support and development kits. In addition, they have the
benefit of having someone else paying the bills! The other two methods are
designed for “unsigned” developers who are working without a publisher. The
programs are not open to minors.
There are two programs for unsigned developers:
The Independent Developer Program makes Xbox technical information
available to developers who are willing to sign a non-disclosure and license
agreement. This is the program that most unsigned developers will take part
in. The materials - known as the Xbox Prototyping Kit, or XPK - will be
provided free of charge and include basic technical specifications,
information on best practices for Xbox development, instructions on how to
put together a PC-based system which can act as a low-end Xbox dev system,
and a prototype development guide which covers the important issues involved
in making Xbox games. While there will be no technical support offered,
there will be newsgroups accessible to participants in the program.
Note that the Xbox Prototyping Kit does not contain any development tools
and does not enable you to develop code in and of itself. You will also need
to purchase Microsoft C++ 6.0 (Professional version recommended), and the
DirectX 8 SDK. The DirectX 8 SDK is available on-line at
http://msdn.microsoft.com/directx/ and Visual C++ can be purchased at any
major software vendor.
To apply to the program, send an email with the subject “XPK Application” to
xbox at xbox.com and include your name, company name (if any), mailing address,
email address, phone and fax numbers.
The XPK will be available in January, 2001.
The Xbox Incubator Program will allow serious developers with the
resources to self-fund a prototype development effort to obtain development
kits and technical support as if they were publishers. This program is
limited to a relatively small number of developers and is intended to offer
support to the best teams with the best ideas. To that end, the key
requirement for acceptance is a game concept that blows us away and the
wherewithal to turn it into a real prototype.
There is an initial application that must be completed and returned to me.
If your application passes review, you will be sent a non-disclosure
agreement to complete and once that is in place, you will be invited to
submit a full proposal using our form and any collateral material you may
wish to attach. A review committee will vote on the proposals. If the
concept is approved, you will be allowed to obtain development kits at the
same price as a publisher and will also be granted access to developer
support services.
The incubator program has a 6-month time limit. Within 6 months, you need to
have found a publisher for your concept, return for re-authorization, or
return the development kits.
Applications for the Incubator Program are available now. If you wish to
apply to the program, send email either to me ( scober at xbox.com
<mailto:scober at xbox.com>) or if you are in Europe or Australia/NewZealand to
Adrian Curry ( adcur <mailto:adcurry at xbox.com>ry at xbox.com) with your
request. Please include complete contact information for our records.
Sincerely,
Scott Berfield
Account Manager Developer Programs
I don’t know how SDL would behave when compiled for such a target in it’s
current form, but do keep in mind that run-time decisions and support for
multiple display targets results in a great deal of code. A game console is
usually less complex in this respect than any single SDL target, and add to
that that you can eliminate even more code by sticking to a single video
mode, rather than supporting all available modes in the production binary.
64 kB is probably in the very low end for anything but direct-to-hardware asm
code (perhaps one could use a modern C cross compiler for C64 development,
but I haven’t tried it…), but a compile time abstraction layer (ie no run
time detection and multiple targets) might well be viable for 16+ bit
machines.
The real problem (the way SDL looks now) is probably that one would have to
add support for things like hardware parallax scrolling (SNES) and hardware
sprites (most 8 and 16 bit platforms) to get usable performance on consoles
designed before the 3D era. For example, the SNES has a ridiculously slow
CPU, and wouldn’t cope with any kind of blitting without help from something
like that Argonaut designed RISC found in some cartridges.
That might sound doable, but looking at the interfaces used for sprites and
tiled backgrounds on PCs, Macs etc, it would be more complicated than 2D
blitting emulation using OpenGL. Common limitations with the specialized
hardware used in 8 and 16 bit machines and 8+ bit consoles are different
pixel formats for sprites and different parallax layers, “weird” limitations
of sprite sizes and limited number of sprite channels, allowing only vertical
reuse. (Ok, I did horizontal reuse of sprite channels on the Amiga, but the
copper code for that was all too similar to vertical color bars on the C64;
not suitable for serious animation.
As to 3D; how would a stripped down OpenGL API work on the 3D accelerated
consoles? From what I’ve seen of hardware docs for those, real OpenGL would
have to run some 80% software emulation to do things “right”, but being more
tolerant could result in something usable. More portable than not portable at
all, that is - one could develop an engine on a PC or Mac, and then adjust
lighting and blending as required on a real console.
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Monday 05 February 2001 06:47, John R. Hall wrote:
Daniel Vogel wrote:
The PSX has 1MB RAM. Do you really want to run GL (or SDL) on that :?
The C64 only had 64 KByte of RAM and yet I spend enough time playing
games on it. I don’t know how much memory a GameBoy has but definitely
less than 1 MByte. One MByte can be a lot of memory for 2D games.Agreed, but there’s hardly room for a hardware abstraction layer, even a
well-behaved one like SDL.
libSDL.so is 972k on my system (granted, it’s decked out with options
and not stripped).