Domain: libsdl.org
Stories and comments across the archive that link to libsdl.org.
Comments · 355
-
What is so restrictive about LGPL?
-
Re:What about..GLUT is very ugly to work with. It is not Object-Oriented. I use it somewhat like I use MFC. Great to get things up and running quick. But I wouldn't use it for production level code.
The input handling is annoying at best. It is similar to handling the WM_KEYDOWN and associated messages. Who want's to do that. That is an inflexible solution. That is why DirectInput was invented. To give a OO, abstracted view of the input devices connected to your machine.
Just to add to that. I really hope SDL really takes off. Without trying to be rendundant, developers really need a cross-platform library that matches DirectX. I can't wait until the first major game is released using SDL or something similar. That's the better solution to getting games for Linux rather than WineX or whatever other emulator you want. And contrary to what they claim, Wine is an emulator.
You have to admit that Windoze is king in the PC gaming market. So let's develop a library that allows developers to make games on Windoze...and then get Linux, Mac, etc ports for free.
-
Re:What about..
Simple Directmedia Layer. It, and associated add-on SDL_* libraries, provide simple, easy to understand and use, pure C APIs to the basics a game developer would want. It handles input/output, and acts as a gate to OpenGL for 3D.
(from SDLsite:)
Simple DirectMedia Layer is a cross-platform multimedia library designed to provide fast access to the graphics framebuffer and audio device. It is used by MPEG playback software, emulators, and many popular games, including the award winning Linux port of "Civilization: Call To Power." Simple DirectMedia Layer supports Linux, Win32, BeOS, MacOS, Solaris, IRIX, and FreeBSD.
SDL is written in C, but works with C++ natively, and has bindings to several other languages, including Ada, Eiffel, ML, Perl, PHP, Python, and Ruby.
Pretty much all commercial games on linux use SDL, as well as most new little games on linux, and a fair proportion of them on windows and MacOS
See here for more details. -
Re:What about..
Something like SDL you mean?
-
libSDL
You may know about libSDL on Linux, which has been used in many Linux games. Loki has also succesfully ported across several Windows games to it. Don't be fooled by the name "Simple DirectMedia Library": Simple doesn't imply 'restricted', and 'DirectMedia' doesn't mean that only abstracts multimedia capabilities.
libSDL is a cross-platform library which supports not only video and audio, but also threads and timers. There are also plenty of support libraries for it -- including a cross-platform networking library that works on Linux, Windows, MacOS and BeOS. There's plenty of example programs for you to work with, it's open-source, and perhaps most importantly, it is mature and tested. The only downfall of it is that you'll have to track down the documentation for it, but there are plenty of SDL gurus around if you know where to look (the SDL mailing list is a great start). The SDL homepage itself also has links to other similar ambitious libraries, such as clanlib, if you don't like it. I definitely recommend that you check it out.
-
libSDL
You may know about libSDL on Linux, which has been used in many Linux games. Loki has also succesfully ported across several Windows games to it. Don't be fooled by the name "Simple DirectMedia Library": Simple doesn't imply 'restricted', and 'DirectMedia' doesn't mean that only abstracts multimedia capabilities.
libSDL is a cross-platform library which supports not only video and audio, but also threads and timers. There are also plenty of support libraries for it -- including a cross-platform networking library that works on Linux, Windows, MacOS and BeOS. There's plenty of example programs for you to work with, it's open-source, and perhaps most importantly, it is mature and tested. The only downfall of it is that you'll have to track down the documentation for it, but there are plenty of SDL gurus around if you know where to look (the SDL mailing list is a great start). The SDL homepage itself also has links to other similar ambitious libraries, such as clanlib, if you don't like it. I definitely recommend that you check it out.
-
Re:Platform indenpendent API?
It's called SDL, it works on many platforms already including Linux, Windows, PlayStation 2, and more. It should be easy to port to others as well. It's LGPL'd I believe, and documented well.
-
Wine is important, but..
In my opinion, there is no future for linux gaming if wine is the only way to go..
The problem is: at the moment, the best gaming API
is Microsoft DirectX, like it or not, and
the likelyhood of DirectX becoming a cross-platform API is zilch.
So obviously, Wine is needed at the moment, partly as a windows-simulator,
but also as an implementation of DirectX on linux.
In the long run, however, It's unhealthy to be dependent on an API dictated by microsoft.
We need a new, open, alternative.
Perhaps SDL 2.0 or OpenGL 2.0 is the answer needed?
Linux needs a killer DirectX-killer-API, much in the same way DirectX was the
MSDOS-killer that moved games development to windows.
However, if wine is the future of linux gaming,
we are (indirectly) giving that future to Microsoft.
-
Notes on company name, portability/games, and X
the company name is 'convergence integrated media GmbH' or simply 'convergence', NOT 'Digital Convergence', so they're NOT the company who did the infamous (license-wise)
:Cue:Cat (this company is called 'Digital:Convergence', btw), but the company who also does the (pretty cool) LinuxTV-drivers for DVB-cards from Siemens/Hauppauge.
the portability issue is softened by direct support of DirectFB as backend by ClanLib, GTK 2.0+ and even SDL (from not-yet-released version 1.2.3 on, get it from CVS), so basically writing code for one of these will give you portability beyond Linux. GGI supports it as well, but not the way it was intended (they're just re-using the binary drivers with their own API).
while replacing X might be something you COULD do with DirectFB (if you'd really want to), code-size and speed seem to be of more concern to the developers, which is quite understandable if you've got settop-boxes in mind. The approach of X is at totally different one, i.e. network-transparent, hardware-independent, portable graphics. DirectFB can simply (additionally and optionally) support the needs of a typical X application/client, so the article was maybe a little bit too anti-X .. -
Re:Back in my day........
Maelstrom is now a GPL released game built on the SDL library. it runs on linux, windows, mac, and be. the original company, ambrosia software made some cool little games.
i played the heck out of maelstrom on the mac when i was in school. good
little sound effects. 'yahoo! all right!'
-sam -
Re:Beginning of a GOOD viscious circle...Whoa! How in the world is standardizing on the Windows API good for Linux multimedia? (Oh, and there's a perfectly good Linux standard already -- SDL, which was used for all of Loki's work.)
WINE's install is fairly straightforward, but it distributes many, many shared libraries into its target directory. You might want to rethink how heavy its dependencies are -- one screwup, and the whole install is pretty much toasted, and you have all these extra libraries to guess about when trying to cleanup. (And that's skipping the performance, which is usually a little flaky and noticably slower than when run under straight Windows -- or, if you have a normal (non-DirectX) app, under Win4Lin or VMWare.)
Oh, and just for the record, it's "vicious"
:-) -
Re:OT: Quick easy graphicsOn Linux:
- SDL + C lets you do graphical stuff. It's not as simple as you want, but after a few days of immersion it's straightforward.
- Postscript (via ghostscript). Type 'gs' and a window will pop up. At the prompt, type:
1 0 0 setrgbcolor /Times-Roman findfont 30 scalefont setfont 100 100 moveto (Hello) show to put some text on the screen. Type 200 200 moveto 200 300 lineto 300 300 lineto 300 200 lineto 200 200 lineto stroke to draw a box. Adobe has a postscript tutorial on their site. If you stick your commands in a file, it's a postscript program. You can print it on a postscript printer, or run it through ghostscript to create an image, or distill it into a PDF.
Or try this:/red 0 def /green 0 def /x 0 def 0 1 10 { x 400 moveto red green 0.5 setrgbcolor 0 100 rlineto stroke /x 15 x add def /red red 0.1 add def /green green 0.1 sub def } for for a set of colored stripes.
- SDL + C lets you do graphical stuff. It's not as simple as you want, but after a few days of immersion it's straightforward.
-
SDL
Well done, you've just described SDL.
-
Transgaming Says: SDL == WINEX
These people are so bloody backwards as to think that near perfect direct x api emulation will gain us native applications. Why this is, I do not know. After having spoken with their coders at LWCE, I doubt they understand what a native binary is, let alone how they can compare api emulation to native binaries. The worst part is when they tell me that SDL is so similar, when it's not. SDL isn't emulating any behaviour, it is an API. It may be similar in some respects to DirectX, but it is not letting you use non-native binaries in Linux. People who want to support microsoft emulation have tried before, succeded in emulation, and then promptly failed as nobody wrote native applications for their operating system (OS/2 anybody?). If you want Linux gaming through companies like Loki (who produce native games) to fail, buy whatever these jokers are going to sell you.
If you want Linux to succede as a desktop so we can be finally free of the shackles we support when we buy into propietary API's like DirectX, and become the gaming platform of choice, buy native games from online stores like tuxgames. Do not spend one dime on what isn't native and you won't be funding the market speak of sales figures against a Linux desktop. -
SDL: An Alternative
-
SDL: An Alternative
-
Re:Sega DC operating systems3) Linux - it runs all right.
It would be interesting to port SDL to Dreamcast, though probably useless at this point.
-
Re:You'll need to do the thinking..
You've been doing some nice trolling.
I'll counter your psuedopoints.
There is no money to be made in Linux market.
First, just because there isn't a large Linux game market right now doesn't mean there will not be in the distant future. Since this compiler is only at version 2.0, now is the PERFECT time to get into Linux. That way, this compiler can grow with the Linux gaming market.
There is no "Linux users acceptance" here, if developers get to have it for free, that is it, you just killed your entire market here.
There are all kinds of free liscensing schemes which could apply to the free version. "Free for non-commercial use, etc. etc." Budding game developers might want to try the free version. Professional developers would almost certainly be willing to fork out the cost for the commercial version. After all, those are small expenses compared to the cost of developing a video game now days.
I don't think they want to get in, for the simple reason that there is almost no money to be made in Linux market selling compilers.
Sure they want to get in. They want to get in if the future of Linux gaming is bright. Sure, that's questionable. But then most business ventures are questionable. Some just make more clear business sense than other. If the Linux game market really sees a boom in the next five years then having their feet in the game-centric compiler door before the boom hits will have been an excellent decision. It's a risk, but I'd be willing to say it's a worthwhile risk. It's like gambling on fair odds with a high payout.
I think the real question here isn't so much if THEY want to invest the time in a Linux version, but rather, if the Linux community really wants to see Linux move in that direction.
It's partially my opinion that Linux users actually don't WANT Linux to become so mainstream that a large portion of the software for it is commercial, and only binary distributions exist. That sort of market is generally what happens to a mainstream OS, and it goes somewhat against the grain of Linux.
I personally think a game-centric compiler for Linux is a great idea. It's certainly no worse of an idea than SDL, and SDL is definately coming along nicely. The future of Linux gaming looks a whole lot better today than I would have thought it would a few years back. There's still along way to go, though. -
DirectX does only three things
The author of the post, and the person who posted the story, clearly wanted to make a comparison between OpenGL and ALL of DirectX, which as as mentioned before, is ludicrous because of all the stuff OpenGL is lacking.
DirectX does only three things: graphics, sound, and input. OpenGL handles graphics, GLUT handles input, and OpenAL can do sound. Other multimedia programming libraries include Allegro, SDL, and ClanLib, all of which can coexist peacefully with OpenGL graphics.
-
You mean SDL?
This has probably already been said, but the SDL library is probably our best bet. It has been in development for the past two years or so, and has progressed immensely into a stable and feature-rich development platform. It is a complete cross-platform solution for high-performance game graphics, sound, and input on an insane amount of platforms, including the requisite Windows, Mac (both Classic and OS X) and *nix. Ports are also available or in the works for QNX, BeOS, Amiga, and a number of other OSes, I'm sure. I have used it for some of my projects, and I must say it is far superior to any other API I have ever tried, including DirectX (which it encapsulates nicely
:-). Sam Latinga, the founder and main coordinator of SDL, is not only a great programmer and API engineer, but a nice guy as well. -
Re:Good idea...Hmmm... I forgot about OpenAL. But have they actually done any thing yet? Are they even working anymore or is this just another defunct project?
How about SDL? I know its a bit simplistic, but it is rather cool and runs on an assload of platforms.
-
SDL can be used
One of the cross-platform multimedia libraries that has already been ported to the PS2 is SDL. f you have the PS2 Linux Dev kit (hard to get) then you can just download PS2 SDL from here.
I have no idea how well the support is... or the speed... but it works well enough that there is a port of Maelstrom for it. I have heard that you may also be able to use the SDL OpenGL wrappers to make 3D PS2 apps.
If you are using the PS2 Linux dev kit, you can use the GCC (I think) as well as autoconf|automake.
-
SDL can be used
One of the cross-platform multimedia libraries that has already been ported to the PS2 is SDL. f you have the PS2 Linux Dev kit (hard to get) then you can just download PS2 SDL from here.
I have no idea how well the support is... or the speed... but it works well enough that there is a port of Maelstrom for it. I have heard that you may also be able to use the SDL OpenGL wrappers to make 3D PS2 apps.
If you are using the PS2 Linux dev kit, you can use the GCC (I think) as well as autoconf|automake.
-
For 2D use OpenGL. For input use Allegro.
As well as that, are there any decent cross-platform 2D & Input layers that could fit in with OpenGl, OpenML & OpenAL?
For input, you could use SDL's or Allegro's input layer. For 2D, just use the special case of OpenGL graphics where z = 0 (note that this is also how DirectX 8 does DirectDraw, as a special case of Direct3D 8).
It would be interesting to see how those three fit together, as it really could give OSS a set of API's to combat DirectX with effectivly
AllegroGL (OpenGL graphics + Allegro input + Allegro sound) works nicely.
-
hardware
I think you can't have 3D audio library without advanced sound device drivers. And AFAIR emu10k1 driver supports effects like delay/flanger/gain, but do not support 3D sound. Main problem is - nobody need advanced sound drivers.
Most of people just need to listen mp3 (it's similiar to word processors - most people need only .doc import/export). The only way to fix that is to create more 3D games for Linux.
So download SDL then get some info from OpenGL site and gamedev then start coding! :-) -
OpenGL and SDLFYI, Sam has ported Jeff Molofee's OpenGL Tutorials to use SDL and made them available at http://www.libsdl.org/opengl/intro.html. I have personally tried them out on both Windoze and Linux.
As a graphics programming enthusiast, I really couldn't have asked for more. Kudos to Sam!
-
Professional game developer says: There is!
I've been a professional game developer for over ten years. I've programmed DOS, Windows, N64, Dreamcast, and Playstation 2. I've used DirectX for many years. Through all of this, my complaint about game programming has always been: the tools are horrible! And DirectX (although it's a million times better in its recent incarnations) is no exception to this. Writing games is fun _despite_ the tools, not because of them.
Recently I had the oportunity to use SDL. It took me less than five minutes to have a program running which displayed a 24-bit BMP, full screen, on my Linux box. About fifteen minutes later, I had put together a small Tetris clone. I was stunned. SDL rocks the hell out of anything I have used on any other platform - and that includes five years of developing on Windows, and using the $20,000 Sony PS2 dev kit.
Best of all, SDL is portable to all other UNIXes, Windows, BeOS, MacOS 9, and Mac OS X. I can't vouch for how well it works on those other platforms, but if it's as easy as I suspect, then any game developer should be in heaven using it.
So perhaps by saying "there is no DirectX equivilent" you mean to say that "there is no graphics/input/sound/3D toolkit for Linux which sucks balls"? -
Why OpenGL (was Re:Interesting decisions they made
Secondly, the idea of running EVERYTHING through OpenGL is particularly bothering. Most video hardware has some very specific optimisations for 2D work and by going through a specific 3D interface you are tossing all those performance advantages out the window. Sure, ok they want to create the ability to play with Windows in 3D - my question would have to be "Why".
Actually, there is one reason why you would want to have something like this: You could have hardware accelerated windowed graphics.
Traditionally you can expect to get some form of hardware acceleration or another in a graphic applications if you run them in full-screen mode (the details are complicated, and I wont bore anyone... but it essentially has to do with your applications *sometimes* being able to write directly to the screen buffer on your videocard in full-screen mode). This is pretty consistant across most OSes (Win32, Linux, etc.).
However, when you run them in windowed mode, all of a sudden your application has to deal with swapping information into and out of video memory (it no longer has exclusive rights). (This has been discussed quite fervently lately on the SDL dev mailing list).
In other words, you can have an application (not 3D, just 2D graphics mind you) go from great FPS in fullscreen mode to horrible FPS in windowed mode.
The advantage to having EVERYTHING running through OpenGL is you can then have hardware acceleration inside individual windows.
Okay, so that's an answer to the question "Why?".... but that isn't a very good reason in and of itself....
Beyond some multimedia applications and games, this really wouldn't give many benefits to the average application.... -
SDLI'm lucky enough to program with SDL for a living, and it really rules - no doubt about it.
It's really easy to get involved with, and you can find a link to its homepage here
Good work Sam - you've really pulled one out of the hat here !
-
You NEED to check out SDL
Hello, for everyone saying "The problem with OpenGL is that it doesn't include a cross platform abstraction for sound and input", you NEED to go check out The Simple DirectMedia Layer. SDL integrates with OpenGL and provides cross-platform (essentially it wraps DirectX on Win32 and Xlib/XDGA on *nix) access to mouse, joystick, sound, etc.
-
SDL !
If you want an open and portable equivalent of Direct X (not only Direct 3D), go for SDL.
SDL supports 2D graphics, but also 3D (through OpenGL wrappers), CD-Rom operations, sound, network, load/save of bitmap formats, joystick, etc. And it can renders on windows, X11, svgalib, GGI, AA, BeOS, etc.
SDL is very easy to program, and everything is designed in a very consistent way. -
Re:CoverageYou can get GCC for windows (and it works well). THere is no law against developing free software for windows. Poeple just *aren't doing it*
It's even easier than that. You don't even need windows to build an app for it. Just cross-compile for it. The SDL homepage provides an excellent setup script, and after that it's just cross-configure.sh && cross-make.sh.
I'm building my windows binaries for GLtron for over a year now, without having to mess with VC++
- Andreas
-
Game project donations...hosted by TuxGames.comIf you want to support game-related projects -- including graphics engines -- drop by TuxGames.com and make a donation.
Donations to the cross-platform Simple Direct Media Layer project are also being accepted at the libSDL.org site. (SDL, BTW, recieved a $1,000 grant from the Linux Fund, so you might want to look there too.)
Keep in mind that while most of these projects are developed for Linux, ports to Windows and sometimes Mac OS are usually included. So, even if you don't run Linux -- or any *nix -- you can still benifit.
Projects that you can support include...
New Breed Software creates software for both the Agenda handheld (Atari 800 emulator, Agendaroids, Aliens,
...) and X (Circus Linux, X-Bomber, ...).www.linux-games.com (note the "-") also has a couple Agenda programs as well as Penguin Command, Castle-combat, Timewarp...
glTron? Nuf' said.
Chromium BSU is another action-diversion.
FreeCiv, PipeNightDreams...well, go see the entire list yourself.
-
Game project donations...hosted by TuxGames.comIf you want to support game-related projects -- including graphics engines -- drop by TuxGames.com and make a donation.
Donations to the cross-platform Simple Direct Media Layer project are also being accepted at the libSDL.org site. (SDL, BTW, recieved a $1,000 grant from the Linux Fund, so you might want to look there too.)
Keep in mind that while most of these projects are developed for Linux, ports to Windows and sometimes Mac OS are usually included. So, even if you don't run Linux -- or any *nix -- you can still benifit.
Projects that you can support include...
New Breed Software creates software for both the Agenda handheld (Atari 800 emulator, Agendaroids, Aliens,
...) and X (Circus Linux, X-Bomber, ...).www.linux-games.com (note the "-") also has a couple Agenda programs as well as Penguin Command, Castle-combat, Timewarp...
glTron? Nuf' said.
Chromium BSU is another action-diversion.
FreeCiv, PipeNightDreams...well, go see the entire list yourself.
-
Re:time to change my future
Personally, I'm wondering what (if anything) is going to become of Loki's development tools like Simple DirectMedia Layer and smpeg. These projects were originated by Lokipeople (especially Sam Lantinga), and I consider these development tools much more important than a port of [Insert name of 3-D graphical wank-fest here].
-
Re:Won't office working kill Linux?
I'd say that SDL was the open source answer to DirectX... done right (as a small, simple layer that can be added and extended as necessary). Just another nice thing that Loki did for the world.
-
Re:Linux Evolution
It really is getting to that point. Having installed recent versions of Linux, I can say its true. Every time I install a new version of Linux, I'm astounded by how far its come and how different it is to the version I installed six months before it - I feel like I have to learn a whole lot all over again. Every time I install a new version of Windows, OTOH, I'm astounded by how little has changed in the couple of years that have passed since the last release. From what I've heard about XP, it sounds like MS may be starting to respond to that by actually improving things... that would be pretty neat, the OS industry has stood stagnant for far too long.
I started using Linux in 1995, and installed it on my own PC first in 1996. At that stage, I had to recompile the kernel just to get my Sound Blaster to work! There were some OK windows managers, but "desktop environments" (e.g. Gnome and KDE) did not exist. There was no linuxconf, i.e. no centralised configuration system - everything had to be configured by editing its own text files somewhere in
/etc. There were no graphical installs. I remember a year or two after that having to download kernel patches and recompile to get FAT32 support, and I remember having to recompile the kernel to get IP forwarding to work for IP masquerading. Internet dial-up involved editing numerous script/chat files and figuring out pppd parameters. There were no decent game API's like SDL, no decent widget toolkits like Qt/gtk. I find it mindblowing just how rapidly the average Linux distro has evolved in six years. Compare that to Microsoft and you suddenly realise just how stagnant the commercial OS industry has been - in 1995, there was Windows 95. Now there is WindowsME, which has hardly changed. A nicer browser has been integrated into the OS, and has finally become more or less stable. Some more hardware devices are supported, and a few minor eye-candy changes have been added. A few bugs have been fixed, but many obvious bugs that where there in the first release of Win95 are still there. That about sums it up. Microsoft would have us believe that that is six years of development? Of course, there is also Windows 2000, which, while not bad, doesn't represent all that much development either from NT4.My general feeling for the past year or so was that Linux would catch up to being equivalent (and superior) to Windows sometime toward the second half of 2002. It still seems to be on track to do so. I haven't seen XP, but as I said, it sounds from what I've heard that MS might be realising that they may need to start improving their software again. Thats a good thing. There is no question of course that Linux has been behind in most things (with the exception of networking, I've always preferred the Unix networking model), but its definitely about to catch up.
-
Re:actually...
> Actually, I ported it, while working for Loki.
> I have since added support for TV output.
Before this gets modded down as a troll, I'd like to point out that according to the comments in the source code, the PS2 code in SDL is written by Sam Lantinga (slouken@devolution.com), which is who the poster of the parent says he is. This is just to avoid rampant confusion like in the Tux Racer discussion yesterday, with people ignoring Patry's attempt to bring sanity into the discussion. B-)
For further info on new features (such as the TV output feature (currently only in CVS)), see the ChangeLog. -
Re:It's settling...
Actually, it is rapidly becoming "Just use SDL" - from the FAQ:
Q: Does SDL support 3D acceleration?
A: Yes, as of version 1.1.0, SDL has full support for the OpenGL API.
Given that it also has support for joysticks, sound, video playback, CD playback, and a host of other things - there isn't much reason to use anything else. Plus, there are a ton of libraries and such that use SDL as the underlying base, allowing you that much more freedom and flexibility...
Worldcom - Generation Duh! -
Re:allegroI've used Allegro (for corporate projects, even). I have nothing against Shawn Hargreaves. I think he's great, and I'm glad he wrote the library, because for years it was the best free game programming library out there.
But now I have to say that Loki's SDL is better. -
Sounds like the SDL website would be more helpful.That's at http://www.libsdl.org. If you're writing games for Linux, it should always be your first stop.
If you want to learn OpenGL, your next stop should be NeHe's tutorials on Gamedev.Net.
GameDev itself is helpful...
As is Flipcode...
If you're interested in writing a good game, you should learn from those that came before you. Check them out using emulators from Zophar's Domain...
Also, no game developer worth his salt can ignore the virtual treasure trove of information archived at GamaSutra...
And finally, you'll want some cool free video game tunes to listen to while you code. The two best sites for video game remixes are Bart Klepka's remixes and Remix at Overclocked.org:
http://bart.overclocked.org/
http://remix.overclocked.org/Go to it. I hope to play your games soon.
-
Re:I've been waiting...On a slightly different tack, you might be interested in PyGame, a portable game programming framework for Python which wraps SDL. Of course, there are bindings for other languages as well (just look at the SDL Homepage), but PyGame is very well implemented. Here is a example of what a very simple demonstration app looks like in PyGame. One of the best applications/games using PyGame so far is Solarwolf, a remake of an old Atari 2600 game (hmm... looks like the site is down at the moment, though).
One of the best ways to pick up game usage tips is to look at source code. One guy who's coded loads of SDL games (in C) can be found here. In particular - check out Circus Linux - it's a lot of fun
:). -
Shake your google, kidStart here... SDL site
Here's the SDL doc project.
Here's an article comparing X-based programming to SDL-based programming.
You can use OpenGL techniques in SDL, so here's some OpenGL stuff for you...
This NeHe page comes complete with a version of the infamous Gears ported to SDL.
Finally, if you really want to start getting the best out of it, you'd better get on hardware acceleration. Either switch to one of the latest commercial distributions (RH 7.1 and Mandrake 8.0 do 3d out of the box), or use the source, luke.
-
Shake your google, kidStart here... SDL site
Here's the SDL doc project.
Here's an article comparing X-based programming to SDL-based programming.
You can use OpenGL techniques in SDL, so here's some OpenGL stuff for you...
This NeHe page comes complete with a version of the infamous Gears ported to SDL.
Finally, if you really want to start getting the best out of it, you'd better get on hardware acceleration. Either switch to one of the latest commercial distributions (RH 7.1 and Mandrake 8.0 do 3d out of the box), or use the source, luke.
-
Shake your google, kidStart here... SDL site
Here's the SDL doc project.
Here's an article comparing X-based programming to SDL-based programming.
You can use OpenGL techniques in SDL, so here's some OpenGL stuff for you...
This NeHe page comes complete with a version of the infamous Gears ported to SDL.
Finally, if you really want to start getting the best out of it, you'd better get on hardware acceleration. Either switch to one of the latest commercial distributions (RH 7.1 and Mandrake 8.0 do 3d out of the box), or use the source, luke.
-
Re:what about them?
have you considered SDL? I've used it for some development, and I've found that it is both powerful and flexible enough to support development on both Win32 and Linux environments.
It's equally interesting to note that it supports OpenGL - I happened across the old NeHe tutorials that I learned on at the OpenGL webpage, re-written to include information on SDL. Good stuff.
The technology is there; the trick is to convince developers that learning the new API is worth it, and that by doing so they will make their code more portable - and that this is a good thing. -
Windows portAll the other trendy open-source killer apps have a windows port, including the GIMP, Mozilla, GNUPLOT, GhostView, Emacs, etc. etc. etc.
With libraries like SDL being built cross-platform, and now even seeing a Windows port of the GTK+ library, why not? How better to take customers from Intuit and Microsoft than to attack them on their own native platform?
I'm a Quicken user right now, but I would jump to a free (as in beer, speech, whatever) alternative for Windows if I had the chance (cause installing Linux is not my preferred course of action right now)
-ubermuffin
-
Re:You forget cost/profit analysis
That's why there is SDL. It uses DirectX on Windows and DRI on X (as well as many other graphics layers / OS's).
I think the problem with Windows developers in general is that they don't think of coding crossplatform in the first place. It's easy to understand why: they are taught DirectX and MFC, and Windows has a huge percent of the desktop market. Also, some games are coded so horribly (compare the duct-tape-that-is-EverQuest to any Blizzard product) that porting certain games look like they would be a nightmare.
On the other hand, I think Linux developers are more trained to code portably. With all the unix flavors out there, source portability is already a must. It also seems that these developers care about porting to Windows. Many apps for X are available on Windows (like a lot of the Gtk stuff), but not the other way around.
So Linux developers actually care about portability, but Windows developers do not. Maybe we can convince them to change their ways?
Surely the Windows developers out there don't thoroughly enjoy Windows-only programming, do they? I've used DirectX, and it was ludicrous. It isn't direct at all (Come on, DirectMusic? DirectPlay? Direct is just a buzzword..) and the classes are a mess. I haven't heard much good about MFC either, but I've heard only good about Qt (and I've used both).
Qt works on Windows. There's no reason to use MFC. Yes it does cost money, but aren't we talking about real game companies here? SDL works on Windows. There's no reason to use DirectX "directly" (whatever that means). You know how long it would take to port Windows apps/games to Linux that were all written in Qt and SDL? All of a recompile. -
Maybe now's the time to askPerhaps now is the time to ask if anyone has had the same problem as myself. I'm not sure if it's related to the kernel, to X, or to software that runs under X, but there has been a serious problem with my system for around four months.
So I fire up X, and use it for a while. Within a short amount of time, the screen blanker starts to come on only in X within one second. This usually happens after heavy disk usage, perhaps after a run of mkisofs to create a CD image that I am about to burn. So I say what the hell, and fire up a terminal window and type 'xset off' to kill the blanker.
I decide to fire up a timer based video game. Quake 3 will suffice for an example. I enter a map, and the sky is moving very quickly. I fire a rocket and the explosion blinks at the end of the hallway immediately.
I have written code in the past with SDL's cross platform timer, and however they implement it in Linux is also broken, because code that I have written is no longer timed correctly.
The timing for my machine is broken. The only way I can fix this is to reboot. My system clock is running at a normal speed, and this doesn't happen in Windows 2000. This is a bug in the GNU/Linux system.
I'm going to try the new kernel version, but after reading the changelog, I don't have much hope for 2.4.5.
Has anyone else experienced this? It's VERY troubling.
X -version returns 4.0.2, though I have tested 4.0 and 4.0.1.
uname -r returns 2.4.4, though I have tried every kernel since 2.4.0.
/lib/libc.so.6 returns version 2.1.2 compiled by egcs.
I have a Quadro 2, however I have also tested a TNT2 Ultra.
hdparm is set to DMA on on my IDE drive.
I have an AMD/750 with a VIA chipset.
I'm using the NVidia binary-only drivers, though the problem persists with the stock NVidia drivers that come with XFree (tried 4.0 and 4.0.2)
My distro is Slackware 7.0.
-
Re:Isn't another approach possible???
> Anyone know if it is even possible to write a language which can do this???
Actually, such a beast already exists. For example ANSI/ISO standard C compiles nicely on Windows, Linux, BeOS, MacOS and whatever, and the only real problem is finding a graphics and sound API that works on all the operating systems you want to use. SDL together with OpenGL provides practically all of the features needed for modern games (it doesn't appear to support 3D sound and suchlike).
If you write a game using standard C (or C++ for that matter) using only the SDL and OpenGL APIs, it should recompile without changes on tons of operating systems, including Win9x, NT, BeOS and most Unix-like systems.
As most games are written in C or C++, making the transition should be hard, especially if the programmer is familiar with OpenGL.