Direct X is only officially for windows. That's why it's a pain in the ass to get any games for Linux, because Windows is in bed with the game designers getting them to make in Direct X, and this is a **** to emulate.
Printable View
Direct X is only officially for windows. That's why it's a pain in the ass to get any games for Linux, because Windows is in bed with the game designers getting them to make in Direct X, and this is a **** to emulate.
Well, I guess I knew that... not sure why I even asked. Just making sure I guess. That does suck. That's probably why they're planning on a new graphics system. They seem to have just come to realization (.NET) that there's a whole other market out there for their software via alternative operating systems. Either that, or like I said earlier, they've been scared into it by companies like Sun and SGI (or perhaps the govt') who support multiple platforms. Which is the way it should be.
[ ;) ]Quote:
The main problem with Opengl is that there is not really any liberys that take care of everything else a game uses as nice as DX does.
*cough* *Allegro* *cough* True cross-platform. Recompile without changing a single line of code. Stays up-to-date with whatever the newest technology is without an API change (though a semi-needed independent API change may be comming up in a year or so, but nothing major). AllegGL works like a charm.
[\ ;) ]
Maybe I'm looking in the wrong place, but the best game I could find (some weirdness called Mookie) written with the Allegro API had all the appeal of Atari as far as graphics are concerned. And it was supposedly written for windows under DirectX. 16-bit hobbyists? eh...
However, OpenGL has really caught my attention. Check this out:
Ambient Pshychosis at
http://www.gamedev.net/opengl/files.html
> Direct X is only officially for windows.
And why shouldn't it be? The engine for my GM car's not gonna fit in a Ford.
Doesn't matter, though, because:
> Of coarse for an amiture game programer, as well as someone who wants people with graphic cards that are not the newest, both off them offer more then enough fetures.
Exactly. Everyone complains about the capabilities of one or the other, when the vast majority of us (maybe even all of us) aren't doing things that are really going to challenge either API.
I'll drive the porchse you drive the pinto :p
>
How portable is my question. I'm still trying to understand all this confusing mess of portability. I guess i'm not alone because it seems to be a big issue with everyone.
So, let's say I wrote and and compiled GL code in VC 6, how difficult would it be to convert it for other operating systems?
<
OpenGL code is 100% portable all you must change is the OS specific program code such as the windowing system input and the like, unless your using glut that is.
As far as i know pretty much what you have to do is recompile it for the specified platform.
>Is directX portable at all? If so, which would be easier to convert?
no, and OpenGL.
SDL, the open source and portable DirectX "alternative". It supports sound, has better window management than glut (can force a full screen), and has better input handling (support for joysticks, etc).
http://www.libsdl.org
Speaking of which, I recently found a small bug in the source code to one of the example programs in an SDL library, sent the author of the library (who works at Blizzard... the Blizzard), and he responded with this in email I recieved yesterday.
Quote:
Subj:
Re: Trivial bug in chat.c in SDL_net library
Date:
Wed, 13 Feb 2002 1:24:16 PM Eastern Standard Time
From:
Sam Lantinga <[email protected]>
To:
[email protected]
Thanks! I've added your fix to CVS...
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Excellent, SS! Add that to your CV as "Troubleshooting for Blizzard"
Heh, well, its not actually affliated with Blizzard, its his own project, but he works at Blizzard as well.
Without the managed environment you would not be able to have language interoperability in a pure OOP environment. No manifest tied to the IL .exe that enables other programs to share classes and methods. You would not have the benefit of .NET my services and you will be back in the days of having deployment snags such as having to register components manually. I can see how you might not need it for console applications and linux, otherwise managed code is the way to go.
go SDL!
easy to use....incredibly portable...lots of nice features...very fast...works incredibly well with OpenGL.
I'm unfamiliar with the game you cited, but Allegro is such a beautiful thing because it doesn't compete with anything. It doesn't even try to do graphics etc. Everything you see is a DirectX and OpenGL mixture (or others on other platforms). Allegro is a wrapper. It is designed to make things like graphics, sound, input, compressed data files, and 3D standard for the programmer. When new technology comes about, it is plugged into Allegro, and you don't have to learn yet another interface.Quote:
[Allegro has] all the appeal of Atari as far as graphics are concerned.
Ports of Allegro are not only spreading across platforms, but even across languages. Version 4.0 just recently was released, and it represents the first really polished version of the lib. It is "giftware", so it is impossible to say who uses it, but I'm sure some amateur programmers advertising their use of it will come out with something to impress you in the not too distant future.
In the mean time, check out the API, and decide if you like it better than knowing the eight different library APIs it encompasses. You can always mix and match Allegro with any of them if you desire. Or just learn them, it can be quite beneficial. However, when I want to develop something quickly - especially something cross platform, I'm going to be using Allegro.
The future of Allegro looks very bright, including gaming console and PDA ports. The idea is really similar to .NET, but you can use the language compiler you want and it compiles to machine code (which some of .NET will do as well).
Sorry for the lateness of this response, hadn't read the thread for a while. ;)
P.S. If there is a real weakness to Allegro, it is that the API is a tad dated in look. It relies on variables like mouse_x, which just isn't acceptable really. The next version of Allegro is going to address just that, and change the naming around a bit so that it can't get easily confused with other code. A simple current fix is to write your program in an OO fashion, but there aren't too many things to avoid really, so it is still pretty easy to come up with unique, small names.