Slashdot Mirror

I'd develop it in SDL + OpenGL.

What is XBMC? What is SDL? What is Wayland?

FFS TFS needs some TLC.

XBMC is a "software media player and entertainment hub for digital media".

SDL is Simple DirectMedia Layer and "is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer".

"Wayland is a computer display server protocol and a library for Linux implementing that protocol."

XBMC = XBox Media Center - http://xbmc.org/ SDL = Simple DirectMedia Layer - http://www.libsdl.org/ Wayland = http://wayland.freedesktop.org/

SDL stands for "Simple DirectMedia Layer" and "is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer."

I have had the feed of the SDL Mercurial changelog on watch for a good while, from back when I felt I could make a game with SDL within a reasonably short time.

Times changed, assorted Shit Happened (both within and without my PC), and my SDL tinkery and SVG tinkery became Blender tinkery (short YouTube video of mine) became "fuck this I'll just play some Torchlight and roughly build a witch there instead", but I still had the feed on watch and saw a relevant change. The summary had a different tone from the many other changes I've seen before, enough to make me think "Something big will come from this." Then I closed the feed tab and went back to whatever the hell I was doing, I forget.

I admire Sam Lantinga's work (and patience) with SDL, given the collective trouble the various OSes bring. Many of the recent changes were for iOS...that must've been fun.

I have had the feed of the SDL Mercurial changelog on watch for a good while, from back when I felt I could make a game with SDL within a reasonably short time.

Times changed, assorted Shit Happened (both within and without my PC), and my SDL tinkery and SVG tinkery became Blender tinkery (short YouTube video of mine) became "fuck this I'll just play some Torchlight and roughly build a witch there instead", but I still had the feed on watch and saw a relevant change. The summary had a different tone from the many other changes I've seen before, enough to make me think "Something big will come from this." Then I closed the feed tab and went back to whatever the hell I was doing, I forget.

I admire Sam Lantinga's work (and patience) with SDL, given the collective trouble the various OSes bring. Many of the recent changes were for iOS...that must've been fun.

This kind of thing already exists:
1. The Linux Standard Base (LSB) has the goal of creating a standard set of libraries that you can code against that will be available on almost any Linux box.
2. SDL, which works on a wide varieties of Linux, as well as Windows and MacOS.

DirectX has the advantage of other features built in. OpenGL is just graphics. DirectX also does audio and manages controller input.

Low, there are several Open source API's that offer these other features, and some that bundle them with OpenGL, but it isn't as standardized.

I use LWJGL personally.

Indeed, OpenGL and Direct3D are direct competitors, not OpenGL and DirectX. One Free, cross-platform alternative to DirectX used by many games for both 2D and OpenGL-based 3D graphics is SDL

most games use SDL for the 'other stuff'.

Something like SDL?

It runs on Windows. I don't know how much use it gets there, but it's used on Linux all the time.

SDL beats OpenGL. (and is quicker and easier to code than DirectX by a mile)

I wasn't aware that SDL was a graphics API that beat OpenGL! This is some pretty heavy stuff, I think I'll have to research SDL's 3D acceleration APIs: http://www.libsdl.org/opengl/index.php

Could you file some bug reports, or send some patches? It seems to be open source, so changing the implementation without altering the interface should benefit everyone. I think we'd all be thankful for your efforts.

http://bugzilla.libsdl.org/

It's possible that the Windows implementation people are not experts at optimization, and might appreciate your tips.

In the rare case where GPL apps become profitable, the source is closed by the copyright owners(SDL anyone?)

You could be talking about a different SDL than I am, but this SDL is under the LGPL. If you're referring to the fact that SDL is often linked to a proprietary video game (as the LGPL is designed to allow), I have yet to see a viable business model for Free video games that aren't MMO.

There's no reason open source code can't call DirectX. Look at SDL

SDL is easy and is supported by a wide variety of languages. Works on both Linux and Windows (per the original post). Seems like a good fit.
http://www.libsdl.org/

OpenAL, or SDL. SDL handles networking and graphics as well. It is the open equivalent of DirectX.

This post on the SDL mailing list thinks dynamic linking is now allowed opening the door for LGPL and even GPL in commercial projects on the devices. http://forums.libsdl.org/viewtopic.php?t=6549

Why will Firefox use Direct2D instead of SDL?

Parent obviously didn't read the summary. But that said, the code written in NeHe's tutorials are ported to like 20 or more platforms, and you might find that to be useful.

I learned OpenGL by buying a copy of the Red Book, and then used Allegro (a cross-platform gaming library) to set up a rendering surface. This could also be accomplished by using the SDL library, but I do not have any experience using it.

(Regarding Allegro, the 4.4 series is a completely different API from the 4.9 series in development, but both can create a window for rendering OpenGL. I would personally suggest using the 4.9 series.)

You want to look at SDL

Simple DirectMedia Layer is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer. It is used by MPEG playback software, emulators, and many popular games, including the award winning Linux port of "Civilization: Call To Power."

cut&paste sort of works everywhere. except where it doesn't.
for example, there's still no cross platform cut and paste support in sdl (http://www.libsdl.org/), which is a major pain in some cases.

If you want "close to the metal" POSIX API compatibility then there's Cygwin which is easier to use IMO and more actively developed but doesn't support the *full* POSIX spec or there is UWIN which supports most of the POSIX spec.

Combine this with OpenGL, OpenAL, the SDL and Cygwin/X, QT, a Java layer using the SWT from Eclipse, *shudder* GLUT *shudder* ;) or IMNSHO preferably wxWindows/wxWidgets and you've got yourself a full cross-platform programming toolkit that can do just about anything.

jdb2

From http://www.libsdl.org/ :

SDL supports Linux, Windows, Windows CE, BeOS, MacOS, Mac OS X, FreeBSD, NetBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX. The code contains support for AmigaOS, Dreamcast, Atari, AIX, OSF/Tru64, RISC OS, SymbianOS, and OS/2, but these are not officially supported.

You just might have overreacted slightly.

And what percent of people running around with MP3 devices HAVE a 'nice pair of cans' instead of cheap earbuds, and I have to say that I've NEVER seen a 'pocket sized amp'. If you do this, you're going to have to face it: You're an audiophile and relatively out of mainstream. You know, the people happy with the earbuds that came with their iPod and 64k MP3 streams?

In either case we're taking advantage of the notion that NOT ALL of the data is important; indeed much of it is relatively irrelevant to our perception.

No, not irrelevant. Remember that thing about patting your head and rubbing your tummy? That used to be a relevant example of a practical neurological limitation of the motor cortex (IIRC.) Pianists used to be one of the only groups of people who could do this easily. Today everybody types and uses a mouse and/or plays video games, and that's not challenging to anybody anymore.

Conversely there have now been studies (which I have been unable to find via Google for some time and I've been severely regretting lately) that show a waning capability of people to tell when and how an image has been stretched. This is due to the prolific presence of widescreen video displays that stretch pictures inappropriately and are robbing people en masse of that particular neurological faculty.

I do not want to see something similar happen to our musical perception.

the kernel application binary interfaces are a moving target.

That's why we have glibc, which abstracts that ABI from applications.

Kernel driver interface - the horse was already beaten to death many times ( see here ).

a consistent configuration system, to enable distribution;

Windows tried that with Registry - and it didn't worked. And it will never work since "one size never fits all" requirements of all applications.

native file versioning;

Was tried many times before and failed miserably. As long as majority of files are blobs, versioning on level of file system makes no sense. Versioning on level of applications is implemented already more or less everywhere it was needed and SVN/git is there for the rest of applications.

audio APIs;

See ALSA and its user-space libraries.

See SDL.

and the integration of X11 with apps.

As was shown by FreeDesktop initiative not really needed nor X folks want to be bothered by all the end user bells and whistles.

Finally, he argues that Linux needs a committee to insure that all GUIs work consistently and integrate better on the back-end with the kernel.

Committee?? Buahahhahahaha!!!1!!cos(0)!!!!!!!

All what he says was tried before (see (11)) and generally can be described as "failed".

I've got no funds, and I'm targetting Mac OS X and Windows initially, and maybe XBLA/WiiWare later. The first step is choosing a multiplatform framework (I'm using Playfirst's Playground SDK) or even a cross-platform library to develop your own framework (like SDL, OpenGL and OpenAL as appropriate).

Limiting yourself to one platform limits your potential customers. If you start with multiplatform at the beginning of development, it doesn't take much more time/effort (look how Blizzard works, they ship Mac and Windows binaries on the same disc).

There are other advantages to working multiplatform, too. Different compilers flag different errors and warnings, reducing your post-release support costs (for code bugs, at least). Different platform behaviours and expectations will point out UI and game play issues earlier. You've always got at least one current-ish backup of your code/assets on your "other" platform. ;-)

But, for the love of gaming, if you're not going to work multiplatform, don't make it impossible for third-party porting houses to do the work for you. And I'm not talking about your code here, I'm talking about wanting piles of cash up-front to "let" the third parties do the porting for you, or simply ignoring them.

It's more plausible than you may think. If any of the current video chat frameworks use SDL for their output, you can use SDL's AALib output driver. It will automagically mogrify your video into text, live!

Here's the FAQ entry on it: http://www.libsdl.org/faq.php?action=listentries&category=3#30

The non-Microsoft "stacks" suck. Bottom line.

Spoken like a true cluebie. Simple Directmedia Layer is actually a much better solution and runs on everything under the sun. Super simple to use (especially compared to DX), OpenGL works right alongside, and it supports "all those other things" you need for making games and not just doing 3D.

Correct me if I am wrong, or feel free to clairify:
If I use GPL code, I must provide the GPL code that I use.
If I code my own stuff using GPL, my code isn't automatically GPL too.
So if I make an game with security through obscurity, but use GPL code, I'm fine right? Or am I wrong, and all code I write using GPL code suddenly becomes GPL too?

I think it might help you to separate the meanings of "use" (meaning run the code) and "include" (meaning put the source code into your own work), and to change occurrences of "code" with "source code".

OK, so your questions then become:

If you meant this:
Q: "If I use GPL code, I must provide the GPL code that I use." ... then the answer is this:
A: No, use (as in run) GPL code however you want, with no obligations on you.

If you meant this:
Q: "If I include GPL source code in my work, I must provide the GPL code that I included."
A: Yes. The GPL source code is not yours, and you do not have permission to include it obscured in your work.

If you meant this:
Q: "If I code my own stuff by running GPL programs like emacs, vi and gcc, my code isn't automatically GPL too."
A: Correct. Your code is your code ... if you wrote it, then you do with it whatever you want.

If you meant this"
Q: "If I code my own stuff including GPL source code which wasn't mine, my code isn't automatically GPL too."
A: This is complex. If the code is mostly yours and there a little bits cut & paste from GPL source code of others, you are probably OK. If however the code is mostly the GPL work of others, and you have merely added or changed small parts of it ... then your modified work must also be released as GPL code.

Q: "So if I make an game with security through obscurity, but use GPL code, I'm fine right? Or am I wrong, and all code I write using GPL code suddenly becomes GPL too?"

Essentially the same question as before. If you are just running GPL code such as Linux kernel, vi editor and gcc compiler and you are writing your game as your own work ... then your game is your code, and you can do with it what you want.

If however, your game includes, say, stuff taken from the SDL library http://www.libsdl.org/ then you have to work out a deal with the SDL authors, or make your game GPL.

It is really all quite simple to follow ... your own source code that you write is yours. GPL source code that others write is not yours, and you have to abide by the terms of the people who wrote it if you want to copy that work of source code into your own work.

Even schoolkids get this principle ... you can't copy someone else's homework and expect to get your own marks for it ... that is cheating ... do your own work.

1. Download libsdl (Simple DirectMedia Layer, works on many OSes and platforms)

2. ???

3. Profit!

Yes I will compare them, for graphics.
And direct X is horrible to work with by comparison.

True insight if ever I've seen it. I can't speak for the quality of OpenGL, but my point is basically that Microsoft are the only vendor that's provided a single API set for gaming, making it an attractive option for game devs. Graphics, while a big part, is only a part of gaming.

You should definitely have a look at Anagramarama. It's a fun game for many different ages, and can certainly be played in groups. Also with/without adults. Also exists in other languages than English. The game is available to GNU/Linux, Windows and Mac and BeOS. Inface it should probably work on all platforms that support SDL.

Wow, Microsoft uses SDL in their products?

Does this mean we'll be seeing IIS on Linux or OSX soon?

How about some SDL threading?
Not doing all that other stuff? Maybe pthread can save your soul?

So help out a N00b. Is Open GL strictly for graphics, or does it cover other system calls like sound and user IO?

Graphics only.

Why oh why is there nothing out there that allows programmers to write some kind of ANSI coded games that will compile on mutiple operating systems without error or modification?

I take it you've never heard of SDL? Just use an OpenGL-enabled surface for graphics, and the standard SDL APIs for sound and input.

Future solution: either using virtualization or crafty API emulation, make Linux be able to transparently run Windows games and software.

Nope, that's a trap. OS/2 was essentially 100% Windows 3.1 compatible, and what happened? Developers thought, "Why bother writing an OS/2 native app when I can just write a Windows app and be compatible?" So OS/2 never got any apps to speak of.

Linux needs a better, cross-platform gaming API. Fortunately, it has one.

However, if you really have your heart set on compatibility, check out WINE. I'm running a few older Windows games (Alice, Freedom Force, Tomb Raider III) flawlessly with that. Many of 'em don't work, but I'm surprised how many are playable.

Not only DirectX includes DirectSound, Directinput, ...

That's why there's the Simple DirectMedia Layer.

plus, using DirectX give you an almost automatic ticked to the XBox platform

And you need OpenGL to work on the PS3. So the big commercial games are doing the multiple render paths anyway.

Until there's a more standardized desktop environment such that developers can target one one platform and know that they'll have broad Linux market reach, why would any company bother?

Um... there already is. OpenGL + SDL covers basically everything DirectX does (yes, DirectInput and all that). If you need environmental audio, you can use OpenAL, or roll your own as I gather Id did for Doom3 (and not just on Linux, on Windows as well - you need a patch for hardware audio). As a bonus, SDL apps run on Windows and OSX (along with several other platforms) as well.

Games don't care about the desktop, except for installing a menu item and/or an icon to run the game. And, well, there's a standard for that, too. Once they're running, they take over the screen anyway.

The issues with Linux gaming is entirely a chicken-egg market-share problem. There is just not any kind of technical barrier. Anyone doing a PS3 version is already doing an OpenGL version anyway, so a Linux port is actually quite easy at that point.

Several years ago I tried making a linux to windows cross compiler and failed.

Its not that I care about the particulars of GCCs politics. I just want there to be multiple sets of open source compiler politics. I'm glad that egcs was a temporary split. I started using linux around the point of it being reemerged. However, I want there to be another group of people trying another set of ideas, challenging a few sacred cows that GCC holds dear. I don't know what those sacred cows are, but I assume that those who worked on Open Watcom, PCC and GCC have different ideas on how a compiler should work and as a result we get a wider pool of ideas being implemented. This means some duplication of effort, but in the end competition is good.

I think I was missing the prebuilt libc part. If thats all that I was missing I'm going to be quite angry. The long howto that explains the origin of the term canadian cross compiler does not mention that one small detail. Perhaps I'll give it a try.

Several years ago I tried making a linux to windows cross compiler and failed.

I think I put a decent amount of effort into my attempts and I definitely knew how toproduce a standard linux hosted linux targeted instance of GCC that would produce working binaries. A few years later I installed watcom and while it did not support Linux, I could install already working binaries that allowed me to compile dos, windows, os/2 and netware binaries from my windows machine.

Now the reasons for this are largely political. GCC works just fine as a cross compiler, I'm sure today I could get it to work now that I have written a lot more code, compiled more tarballs, and generally know more than I did then. I was able to get a freebsd to windows cross compiler working just fine thanks to the ports collection. Watcom never got a ready for prime time linux compiler, but what they shipped to end users as "experimental" always was a windows hosted compiler targeting linux.

Now there is no technical reason that gcc or a third party can't make the cross compiling process simpler, but other than poor college students that like to experiment, anyone who needs a cross compiler either can do it themselves, can hire someone that can, or has to do a lot of hoop jumping.

DirectX is HEAVEN for game devs, because in theory it means we can write to a single standard for the windows platform, and have our games work on any card.

For your purposes, it sounds like OpenGL+SDL would be heaven, too; possibly even a better one. :-> You can write to a single standard and have your games work on any card, too - but on lots of platforms. Not just Windows, but also Mac and Linux, plus quite a few others. The book "Programming Linux Games" is only a little out of date (basically in the audio section) but is available for free download and covers the ground well. I've been using it for a project and it really is quite straightforward but complete.

Okay, you'd have to rewrite engine code, I grant that. But I'm pretty sure you'd only need to do it once forevermore. And if DX7 really is going away, you'll have to do it eventually anyway.

Did you ever hear of SDL?

Linux multimedia dev, meet Simple Direct-media Layer. It's been done, it's used, it works, and it's open. The trouble lies in the politics of getting developers to port their games and engines over to SDL from DirectX and other proprietary libraries.

I quoted a hell of a lot more of your post then you quoted of mine and I backed up my points.

Well, you reiterated your points, but that's not quite the same thing as backing them up. You can't really accuse 'Linux in general' of just sitting around waiting for the competition to fail. (First off, there isn't a 'Linux in general' anyway, but again, others made that point, too.) I pointed out four markets that Linux companies are actively competing in and doing quite well at. It's worth noting that none of those markets had any one company owning around 90% market share before Linux came along.

I further pointed out that it's only in the last couple of years that Linux companies have been seriously targeting the desktop, and I stated they've done well from a technical standpoint. But there really is a chicken-and-egg problem in the desktop arena, and just saying "Y'all need to try harder" isn't going to cut it.

Loki Games made some poor business decisions (though, actually, not all of them were poor) but one technical thing they did very right was SDL. That plus OpenGL plus OpenAL is really a very nice setup for making games, and it easily rivals DirectX (yes, DirectX is more than Direct3D, that's why I pointed out the other two libraries which cover the other stuff). Several top game engines (including a very biggie, Id's) support Linux. From a technical perspective, it's hard to be more welcoming. But there still aren't many commercial games for Linux, because there isn't a big market for Linux games, in part because... there aren't many commercial games for Linux. That's a real problem, and that's what I and others are referring to when talking about the trouble of invading a monopoly market. (Of course, the PC games market isn't showing all that healthy growth anyway... I'm not sure games will continue to be such a sticking point for Windows retention in the future.) Fortunately, it's not the only factor.

Linux companies like SUSE and Red Hat and Canonical are targeting corporate desktops first, because it's an easier market to break into. A smaller collection of necessary apps for the majority, and the features (lower price, lower hardware requirements, mature management features (like remote admin), and mature privilege separation, etc.) are a very good fit, enough to to drive some switching.

I rather think once people are exposed to Linux where they work they'll use it at home, too. (That's one of the ways Windows got to where it is now.) The underlying OS matters less and less these days anyway; 80% of the things average people do involve the web. The more cross-platform apps people use, the lower the 'potential barrier' is to switching. (Witness how fanatically MS is fighting Office interoperability...) There won't be a "year of desktop Linux" any more than there was a "year of server Linux". There wasn't a "year of Mozilla/Firefox", either; it just grew until... y'know, I can't remember the last time I ran into an IE-only site...

It'll happen eventually. Open standards are in the interest of the consumers, and eventually they spread. Consider how many networking models there were in the 80's, and then by the late 90's it was all TCP/IP, despite vendors attempts at lock-in. The same will happen with open-source software and general computing, it'll just take a while. (Note: I'm not predicting the demise of commercial software. In many areas, e.g. games, it makes a lot of sense. But I figure most companies will eventually go the Id model.)

Anyway, that's enough for now. Maybe you can respond to more than one point next time, or at least a single point in context.

This seems like a window of opportunity for a new OpenGL standard.

Or--even better--a window of opportunity for a new SDL version. SDL is comparable to DirectX as it offers control over sound, graphics, mouse/keyboard/joystick. OpenGL is just for graphics so comparing it with DirectX isn't really fair. :)

How many times does it need to be said... SDL and similar open-source cross-platform libraries cover the rest of Direct X that OpenGL does not already cover.

As somebody already said, there is a java client which uses the same NASA imagery as WW. Also very interesting imho is that the developer of gaia, the once open-sourced client for GE, switched his code to use the NASA data after being shut down by google. Gaia uses the sdl library and therefore should compile on any system sdl supports (from www.libsdl.org: "SDL supports Linux, Windows, Windows CE, BeOS, MacOS, Mac OS X, FreeBSD, NetBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX. The code contains support for AmigaOS, Dreamcast, Atari, AIX, OSF/Tru64, RISC OS, SymbianOS, and OS/2, but these are not officially supported.").

1) The big difference is that direct3D is made by MS. So it is only on windows. OpenGL however is on OSX, windows, and Linux. Any game that is made with direct3D is likely to only be supported on windows. The advantages change back and forth with every update but for the most part MS can push people to use directX so that they are forced to keep the games on windows. The smart game companies know this is a bad idea but the little ones can't afford to do anything about it.

2) People try to do that all the time. It's just not that easy and tends to not catch on. I don't know if this http://www.libsdl.org/ is the SDL that you are talking about but that is an attempt at doing just what you said. Java also started out with a similar goal in mind

Cross-platform libraries can help with this in many of the aspects you mentioned.
http://www.libsdl.org/ , for example. Supports BeOS too.

However, a problem with your idea, is that game developers often desire to optimize the performance of the game, and virtualization doesn't help things in that department. Would you enjoy as much if an abstraction layer between the game engine and your hardware made it run at 20fps?