Slashdot Mirror

Wow, you're a bright one aren't you? Take a look at Mac hardware... it's practically IDENTICAL to PC hardware, including that of graphics processors. The problem isn't hardware, it's software companies not willing to port games on mac. And from what I've seen since I bought my MacBook, any games that are on here run so damn well that it's not funny.

Does SDL (Simple DirectMedia Layer) count?

In most areas. What's lacking is a DirectX equivalent to woo over the game developers.

Something like SDL? SDL is today a mature and stable library, already used by a lot of games, both commercial (notably the Unreal series) and OSS.

In my experience, games suported both on Windows and Linux run awfully smoother on Linux, for some reason. Load times are also reduced by half.

Use Simple DirectMedia Layer or Qt.

If I understand the question, I think you want to try GLUT. If you are feeling adventurous, try OpenGL enabled SDL. http://www.libsdl.org/

I think he's talking about Microsofts COM and DCOM, and probably OPENGL and DirectX or something..

.. but then there's Gnomes Bononbo for a COM layer and the directx alternative SDL, so I think hes just sounding off.

Agree and good comparison! Making games for Linux now is like what making games for DOS was years ago.

Obviously you have not tried developing games for Linux. If you had (and actually given it a good go), you would have come across the wonderful world of SDL, OpenGL, OpenAL, etc.

Because OpenGL is just graphics, DX handles everything. Yes, I know about SDL. Did you know that by default SDL uses DirectX drivers though for graphics on Windows? Hmm..

We can't blame Average Joe. If they (and their ISPs!) didn't hear about Jabber, it is somehow Jabber's fault.

I really wonder if all ISPs know about Jabber.

I wonder why Jabber community doesn't work with Tipic corp. (http://www.tipic.com ) to implement video/audio chat to jabber? Because they are closed source? Well, their server and client are closed source but they are using open standards.

Look what it says:

Tipic Voip/audio implementation is based on the following Open Source projects:

- http://iaxclient.sf.net/ Basic VOIP stack. Tipic added video, wideband audio and support for echo cancellation.
- http://www.speex.org/ Default audio Codec. Tipic sponsored the echo cancellation improvements.
- http://www.theora.org/ Default Video Codec.
- http://www.libsdl.org/ Video visualizzation in TipicIM.

So, they managed to make a open standards based video chat. Problem is, the geek community sees videochat as "lame". Well, average people LOVE it.

I wonder how many people congratulated them for implementing such a thing on Jabber?

I bet that Average Joe would use Jabber if it performs much better on video chat. That is the "geek vs average user" thing hurting open standards as usual.

Who used Mozilla while it was a total geek thing? How many average, non techie people use Firefox because it performs better and promises more security than IE?

Remember people blamed average Joe not using Mozilla giant instead of IE. Who's fault was that than?

Look to another example. Gizmo project is completely open source, not coded by guys who coded Kazaa and completely open standards based. It has many non techie, non geek users. Do you think they are impressed by GPL, RMS and open standards? No, Gizmo sounds better than Skype, that is all :)

Do you *NEED* .NET? Can you learn something else? Something cross platform, maybe? Surely there's something out there that will do the job?

Don't tell us that it comes with source code so it should be spyware free.

Okay, it's not built as a result of profit motive, and so it should be spyware free.

Do you think that ANY ordinary ppl can handle source code, what is "source code" ?

Well, depends how you define "ordinary", however... OSS zealots also happen to be anti-spyware zealots. Any malicious code would be pointed out in no time flat, even if Linus, Cox, et al. decided "hey, lets put some ads in here". You know *someone*'d post something on Slashdot about it.

DirectX 9 that I need to sqeeze top performance from my apps, where is such a direct hardware support on Linux ?

SDL, next question.

Probably going to be modded down as a troll, but...

Alternatives does exist. Besides Direct3D and DirectInput, which realisticly speaking are the ONLY pieces of DirectX that actually work well (the rest being just too much bother to be worth it), DirectX sucks ass. And yes, IAAGD (I Am A Game Developer).

Right now, you'll get the great graphics, but game devs have to do ALOT more work for input, audio and networking.

I think you're thinking of a different SDL than http://www.libsdl.org/index.php

There are other thirdparty libraries that offer this kind of support:

http://www.libsdl.org/libraries.php

There is even an SDL based opengl render target.

Tommy.

Why, that's because OpenGL is for graphics, as is Direct3D on Windows. If you want to compare something to DirectX, try SDL, which happens to be in the same category.

I'd start with the following:

• The man pages and info documentation included with any Linux system.
• The Gnome and KDE developer sites. If you're developing commercial software, develop for Gnome and your app will work fine on KDE.
• For specific applications like graphics and audio, you may need to use other libraries (i.e. libsdl and wxWidgets)
• If you have any questions, there is 24/7 live human technical support for application developers on IRC. Don't undervalue this - being able to ask a real human and get an immediate answer is huge. (try asking in irc.freenode.net #linux or #debian for what channel to ask specific questions if you can't figure it out)

Technical reason.

Developers just not targetting it is not it. It isn't like multimedia libraries don't exist for many platforms including Linux.

It's FUD spreading people like you who give OSS projects bad press. Go stand in the corner and think of what you did.

Tom

Fortunately, there's MinGW, various IDE's, and a bunch of
Open source
libraries available online.

/Library/Frameworks
~/Library/Framworks

The nice thing about frameworks is that they can include multiple versions of the same library and generally include the necessary C headers, so that developers have everything they need to write an application. They can also support localisable language files too.

BTW SDL can be found at http://www.libsdl.org/

I know I'll get modded troll for this, but I hate gamers that insist upon there being a Linux version.

I dislike messages where even the writer admits that his message is propably not considered to contribute much to the discussion on hand but posts it anyway. I feel nothing but scorn for people who use such utterances as a method of trying to get moderators to think the poster as an independent thinker - an impression that is usually further reinforced by references to "Slashdot hive-mind", "Slashbots" and other such phenomenons assumed to exist on Slashdot - and therefore cool and therefore worth modding up.

If you can't get modded up without playing head games with moderators, you don't reserve to be modded up.

Yes, Linux is great and all, and we all want to see it become the next desktop platform, but is it too much to ask for you to either dual boot Windows or have a separate box for your Wintendo?

Yes, it is too much to ask that I should devote several gigabytes of hard disk space to Windows and go through the hassle of rebooting every time I want to play. It is outright unreasonable to except me to get two powerfull computers to play.

I'd rather see the game developer focus more on making a quality game than have a lesser game that is cross-platform.

Use SDL and the resources needed for cross-platform support are lessened considerably.

Besides, design and programming (at least in larger projects) are two separate phases, so the game quality is pretty much already decide when cross-platform issues come up.

Finally, I'd rather see a game that works on my computer than one that doesn't.

Ryan "Icculus" Gordon

I hear he recently lost much of his nerve, was kicked out of his parents' house in New Jersey because they thought his "Linux porting venture" was just another bad move. He dropped out of High School, doesn't have any education outside of reading Bill Ball novice Linux "technical" manuals. He got his first Linux porting job at Loki Entertainment Inc, situated at Tustin in California. Worked next to Sam Lantinga the maintainer and founder of Simple Directmedia Layer. After Loki went under bankruptcy protection, Ryan fell apart. He was living in his office for awhile, and that is when he incurred much butt sex. Sam Lantinga went on to better things, and now works at Blizzard Entertainment Inc for only God-knows-what in World of Warcraft. Ryan returned to his parents' backyard, porting some U.S. Army propoganda software as well as Unreal Tournament 2003, Unreal Tournament 2004, and FriedChickletts MUD. He's pretty much unimpressive, and generally unavailable for porting jobs. I suppose that's why Linux Game Publishing was not willing to hire him to port Candy Crunchers. I also hear Ryan has taken a liking to homosexual lifestyle, (NOTE: goatse balls, men, and Lenin poster) which explains why his choice of books is rather questionable in the "gender-confusion" sort of way.

I think you're wasting your time asking for burned-out hashish-eaters, like Ryan. You should contact the Alpha Troll in Linuxgames.com forums for all your porting needs.

To confirm you're not a script,
please type the word in this image: ridIcculus

Porting games to it should be easy, it seems to come with SDL support right out of the box -

    http://www.libsdl.org/index.php

I'll get one for sure! :)

Yes Dell could slap a free version of Linux on it and save maybe $30-50. If Dell actually cut a deal to License Red Hat or SUSE I'm willing to bet it would end up costing the same or more than Windows.

Why would Dell license Red Hat or SUSE when they can put Fedora Core (or Debian or Gentoo or whatever) into as many machines as they like for free ?

Trying to make a financial arguement here is silly, switching to a different OS isn't going to save anyone money, it will just go into different pockets.

Of course switching to a cheaper OS is going to save the buyer money. Your argument is the silly one.

There are about 100 distros to choose from every one somewhat different. Total nightmare for application developers, end users, and to support

Which is why Dell would only pick one (1) distro and put that to every machine they deliver.

There are two major desktops and GUI frameworks, and a whole bunch more little ones, again a total nightmare for application developers and to support. Applications written to one still dont integrate with the other. Users hate that. They want everything to behave consistently like OSX. Developer hate that because the want to write and test to one API and have it run everywhere.

This is a good point; however, Dell could simply decide to use Gnome by default and include KDE unsupported. I'm assuming that you speak about customer support and not support libraries and such ?

Most people can't fix the stuff that doesn't just work, especially audio, networking, display and printing. Networking is different on every distro. Audio and printing are some better but there are 10 different approaches to each and again for application development audio support is a complete disaster. At this point queue all the people that will say, just use audio API X and you will have no problem, except you will get 10 people saying this and every one of them will substitute a different API for X.

Another good reason for Dell to pick just one distro.

Until Linux stops fragmenting, and focuses on applications and a friendly platform for application development its simply never going to unseat Windows on the desktop and has a great potential to get beat by OSX.

This fragmentation is a natural consequence of the open nature of the system. You can adapt it to different tasks, so people do just that. Different distros have different goals, so they differ in implementation as well.

That said, all programs I've cared to try have worked just fine in both RH9 (used as desktop) and Debian Stable (used as headless server for home network), so I think you are calling wolf for nothing.

Hell I'd take BeOS on the desktop in a lot of ways. BeOS multimedia support, especially audio completly embarrases Linux. After 10 years you would think the Linux world would have got a clue and ported/cloned it because it works, versus Linux multimedia which is a fragmented catastrophe.

What do you mean ? SDL seems to work just fine.

There are still companies using BeOS for multimedia for example n demanding theatrical productions because it is so well done.

Well, perhaps you should explain what's so great in BeOS multimedia capabilities. Maybe some kernel developer happens to be reading Slashdot, sees your post and says "I gotta do that!".

Why not try,

I guess more importantly to ask is, will SDL be available so I can release my games on it ;)

Start Here. Go there, read and do what it says.

And FYI, I'm resisting the urge to make snide remarks about the naivety of your comments. You state that you're ernestly going to try "making some games" (if you manage ONE coherent game I'll be impressed), and that you enthusiastically want to make 3D games (but appear to be scared of C++).

In the words of Yoda: Try not. Do. Or in this case, "after asking on Slashdot, try some of the suggestions".

Learn from games you play. You've obviously played a computer game before. Take one that's similar to the game you think you want to make. Write down all the things that you do in that game and what you think the game has to do to support that action.

(ie: you click "new game", the board re-initializes and sets up the game state. You try and move a piece, the game checks to see if it's a valid move. You win the game, the game somehow detected that condition. You've got a high score, the game knows this and stores it somewhere).

Write this down for a game that you know, then try to change it into the game that you want to make. Then expand each section with detail and keep adding more and more game features while keeping everything coherent. You'll soon figure out how complex (or simple) your game will probably be.

Great program design begins on paper. A great implementation can come later when you've got the broad strokes figured out. (Unless it's an organic design (which is often unavoidable in live projects where you can't afford to break something) - in which case, welcome to hell).

One of the first things that is beaten into 1st year computer science college students is that you should not cling to any one language. You should grow to the point where you can easily pick up any language thrown at you (the specific advanced knowledge later coming with experience).

FYI, there are decent free C++ tools and libraries available for Windows, you don't have to use whatever Microsoft tries to push on you.

With your Java background you might want to try messing around with Proce55ing (a very good prototyping tool) to solidify some of your ideas.

And of course, break the rules when it suits you.

I agree that just doing it is best.

I started looking at the SDL Wiki example page, and after looking over the code and browsing the game programming wiki I just started coding.

My first game, and first use of SDL is mousetrap - the graphics suck, but at least one person liked it.

SDL really was a pleasure to work with, and suprisingly easy to get started with.

Now I'm working on a more graphical platform game.

I've written a small game that some folks find addictive:
http://www.nongnu.org/tong

It's from an old idea I had and was looking for an excuse to teach myself SDL, which some buddies and I had chosen for a much more ambitious game we're still working on.

We chose SDL primarily because it is cross-platform. I use and develop under GNU/Linux myself, but I want all my windows-running buddies to be able to play my games. OSX and even DreamCast porting is trivial, as SDL happily runs on those platforms and many more.
http://www.libsdl.org/
SDL is very well documented and very slick to use, even to a newcomer (so long as you do have some programming experience). I'm a C and C++ guy, and SDL works with those natively, but if you wish to stick with Java or any other such language there are appropriate bindings. I highly recommend the libraries SDL_image and SDL_mixer as well, for boosting image and sound loading support. (I love being able to have my game just load up .png and .ogg files directly... it just feels all warm and fuzzy :^)

I subscribe to master Miyamoto's game design theories, which basically amount to making your game into its own little playground, running on its own rules and rewarding the player for being clever. Keep the controls simple; a person should be able to pick up and play. Now, my game Tong is pretty rough at first, so I maybe don't follow this thinking very well in practice, but the philosophy is an implementation of the old "Keep It Simple, Stupid" that you've heard so often and I think it's very sensible. Especially for budding game developers.

Even with a well-documented API and a clear idea of what you want your game to be, it's going to take a while. Get a demo of "stuff happening on-screen" with mock-up graphics to get a feel for how you're going to render things, then trash the whole thing and start building up all the pieces you need. If your strengths are with object-oriented design, figure out all your game entities in terms of objects that all inherit things like how to draw themselves. If you're more of a procedural programmer, and even if not, figure out your main game loop, what needs to happen every cycle and what can be called out in special cases.

Take your time, let it be a pet project. The last thing you'd want is to extinguish your interest by making it a serious commitment. Starting small and building up is an obvious and good approach.

Best wishes! Long live the independant game developer!

What is your target? Do you want to write a game for a Windows PC? If so, then maybe you should look into C# and Direct3D. If you want a cross-platform game that you can compile on Windows, Linux, BSD, and Mac OS X, then look into SDL and OpenGL.

You might want to start here if you're going the cross-platform route:
http://www.libsdl.org
http://andrew.textux.com/tutorials/tut1/tutorial1. html
http://www.kekkai.org/roger/sdl/

I have never been a fan of learning how to do something by reading about it. The only way to learn good game programming, IMO, is to actually try doing it. That's how I started with the game in my sig and its been working so far. While not a book, may I recommend you take a look at the Simple DirectMedia Layer (SDL) library? It's free, cross-platform, and is really easy to learn to use. It's written in C, but there are extensions to it in other languages. Good luck!

Network code is the one major thing SDL is missing that DirectX has...but once again, when you're working on a shoestring budget, how are you supposed to afford that?

Two points:

(1) SDL has a network library.

(2) The DirectX SDK is a free download.

Even Microsoft's command-line C/C++ compiler is a free download. Snag that, the platform SDK and DirectX SDK and you're set. The only thing you don't have is the IDE.

I use Visual C++ and DirectX at work for making multimedia applications - but there is an alternative. At home (because I'm cheap and also because I run Windows, OS X and FreeBSD) - I use the MingW32 which lets me use GCC, OpenGL and SDL and to make cross-platform code that compiles on any of my machines. I also use IBM's free Eclipse IDE with the C++ plugin and the Scons build system - because those also work everywhere.

And for that you use SDL

Why do you think we don't have that?

SDL - http://www.libsdl.org/index.php
OpenAL - http://www.openal.org/
OpenGL - http://www.opengl.org/

These are - specially SDL - very matured things and lot of games are coded in them.

If the original game was done right, and designed with crossplatform in mind, it shouldn't be too hard a task. But, it seems most developers these days like using the "easy" way out instead of doing it right....

• The instructor knew absolutely nothing about game design and programming, or even games in general before deciding to be the instructor of the course. So, he doesn't have quite the same grasp on the concept that most college students interested in game design and programming do.
• If you'll notice I've been saying game design AND programming. Personally, I feel the two are different aspects of making a game. I couldn't design a fun game to save my life (and I've tried) but I enjoy and feel I'm fairly proficient programming games. I thought the course would cover both aspects but so far it's been only game design using an application called Game Maker. I'll admit, the application is nice and very well put together, but it tries to completely remove the coding portion of creating a game.
• The programming portion of the course is going to be implementing the game engine in C++ found in the book Sam's Teach Yourself Game Programming in 24 Hours which seems kinda lame. He does want us to extend the game engine, but it's still just cut and pasting.
• Finally, the whole damn course is Windows-centric. I'm not a Windows hater, but I really don't enjoy using it if I don't have to. I proposed to the professor before the course was even an option that he look into something cross platform like SDL, which will run on pretty much any operational operating system available now. It also simplifies many things like setting up a window, handling input(keyboard, mouse, joystick), and even network code.

In this scenario, the WINE authors can use the large existing base of libraries to do the real work.

Please, list any emulators where that pattern does not apply. Just to think of one famous example, MAME translates calls in arcade ROMS and sends them to Linux libraries (such as SDL). By your baselessly arbitrary distinction, "emulators" can only be programs which don't link in any other libraries. (I could probably recompile WINE to include all the Linux libs internally- would that transform it into an "emulator" for you?)

Actually, wxWidgets would be a better choice. It is stable, and it is open source and free on all platforms.
Combine this with SDL (Simple DirectMedia Layer) and Boost.org, and you get a great cross-platform development toolset. SDL is "a 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."
Boost provides cross platforms threading and other nice things. If you keep your GUI seperate from from the main guts of your processing, you can do cross platform programming rather well.

You're correct, it's quite possible to write very portable code. For example, I compile our games (follow link at sig) for Linux, Mac and Windows from a single codebase.

The trick is to use portable libraries (in our case, SDL, ZLIB, and a few others), as few OS-specific APIs as possible, and in the occasions when you must use OS-specific code, encapsulate it in a library for which you have multiple implementations.

You end up coding against a (usually) thin layer which is completely OS-agnostic.

About Direct3D and OpenGL, one solution is to have an abstract renderer class which then calls OpenGL or Direct3D. Good examples are the excellent Ogre3D and part of the code in the Doomsday Engine.

1. I heard somewhere that the biggest problem with SDL is that it's designed to be simple, so a lot of more-advanced functionality simply isn't present. Is there any truth to that?

As of this morning, there are 118 SDL expansion libraries beyond the base libSDL; Extra SDL libraries

Things are improving, however. For graphics/sound/control, use SDL.

For desktop integration, go with the Freedesktop.org menu spec.

And for package management, there's RPM, standardized by all LSB-compliant distributions.

You mean like SDL? Open-source, object-oriented and very cross-platform, provides facilities for 2d and OpenGL graphics, sound, input, and timers. Unfortunately nothing in the networking department.

I think many of the popular emulators use it... don't know about "big" games though.

Here's the network stuff.

and there isn't a unified API for network, sound and inputs like DirectX (OpenGL is only for graphics).

Here ya go. All you lack is Network, which is easy to implement anyway.

Without a doubt, Simple Directmedia Layer (SDL) is the best platform for writing cross platform games. It provides a very clean abstraction layer to the high performance APIs (DirectX, etc.) available on each platform. Many people who code only for Windows use it since the API is a lot nicer than the COM based DirectX API. A number of commercial games have been ported to Linux using SDL.

For serious game programming, you need to learn C or C++. I would guess that 99% of all commercial games for the PC are written in mostly C or C++. This doesn't mean you need to write all of your code in a low level language. Even the original Quake used an interpreted language (QuakeC) for the game logic. But almost no language other than C or C++ will provide the speed or memory usage necessary for most commercial games.

If you'd rather concentrate on writing your game rather than learning C, try Python with Pygame. Pygame is a Python binding to SDL. It is fairly fast since all the low level graphics stuff is done using SDL. Certain things will be slower in Python (collision detection, physics, etc.) but most code isn't speed critical anyway. Some things will be harder in Python since it's easier to manipulate bytes and bits in C.

Also check out PyOpenGL if you want to learn OpenGL. It can be used in conjunction with Pygame. I used this when I was learning OpenGL and it's quite nice. The API is almost exactly like the C based API, but it is easier to use. At least one of the popular OpenGL tutorials has been ported to PyOpenGL.

Languages aside, SDL (Simple Directmedia Layer) is a great library for graphics/sound/network programming. Simple, easy to learn, cross platform. For a class project, it should do the trick.

I'd suggest C++ for programming languages, but that's probably just because it's what I've used for years.

--trb

Perhaps someone can suggest some other libraries/frameworks for input/sound/networking.

Well, you can try OpenAL for sound, and OpenTNL or RakNet for networking. You can use SDL for platform independent main(), window management (well, one window), and input (keyboard, mouse, joysticks).

Taking a look at the SDL website news shows that version 1.2.8 of the main library was released on December 15th (under a month ago at the time of writing). There also appears to be active development on supporting libraries (such as SDL_mixer, SDL_ttf and SDL_image).

Sure Loki were a major supporter but development didn't stop after Loki disappeared...

One problem is that OpenGL (pre 2.0, haven't looked at that yet) is horrible to work with if you actually want to get stuff done.

Then dammit, use a real game API instead of just a graphics language. Might I suggest SDL?

(p.s. Sorry if I'm beating a dead SDL horse in this discussion...but seriously, this is the answer, and it just seems like no one is paying attention.)

Back in Loki's day, the Linux market was a heck of a lot smaller. The economics have changed now. Linux is a much bigger phenomenon. Apple now has OS X, which is BSD.

It's time to try again. This time it will work.