f13.net

There's enough developers in this forum, could one of you make a port of DirectX for Linux plz?
You'd make zillions of dollars supporting developers porting their games to linux while you were at it.

If I win the lottery, that's what I'd blow my money on. That, and Scotch. Well, hell, I could go get some Scotch right now...

Sorry, I'm busy trying to port notepad to Linux.

What exactly are you trying to run?

Portal-avatar-whores.

Huh?

Oh, I dunno... Everything.
This is more of: I wanna stop using windows all together, than just trying to get 1 game to work. I don't think porting notepad will achieve my goal.

Edit: I guess I should add... I would like to see the porting of games to Linux as commonplace as it is to port them to console systems. Which isn't going to happen due to: DirectX

I think you should just run windows.

That would solve your problems.

But I like Linux better... except for the games.

Soooooo why does this thread exist?

I think what you are looking for is Cedega (http://www.cedega.com)

so some developer looking for something to do would say "Hey, that's a good idea" and do it? At least, that was the plan.


Ooo! Cool.

Actually right now regular old Wine works better than Cedega for running Steam.  Yesterday there was a step by step guide on how to install and run TF2 (and other assorted Steam goodness) on linux on digg, I'm sure you can find it if that's what you want to do.

If you've got a fast computer with one of the new dual cores you could run Windows as a VM in Linux, apparently the new CPUs have some sort of instruction set which makes VM work pretty much realtime.

No, never think that again.

I think you would need more lawyers than developers to accomplish that.


And take Ookii's advice - Linux is not my stomping ground.


I love Big Brother.

Linux is so much harder to install/operate than any console ever.  I don't understand your comment.

Also Linux sucks.

Everything sucks, it just sucks in different ways.

You got that right, brother.

So would shooting yourself in the head. Doesn't mean its a good idea.

I don't get the joke. Shooting oneself in the head wouldn't solve any problems. But installing windows would DEFINITELY fix the gaming problem.

Linux doesn't even have a decent setup for it's own native game/graphics oriented API's, let alone something owned by Microsoft. Hell, it barely has a fucking standard filesystem to even place those files in the same place for everyone. I like OSS and all, but the entire movement needs a massive kick in the nuts for not having very many standards with it's flagship OS.

Linux is good, however, for hosting games. And that's probably all that it will be.

XHangman was fun. 

I also love Big Brother.

"Plz port DirectX to Linux" is a meaningless statement.  DirectX is the API programmers use to ask Windows to ask hardware to do something.  A simplified way to say it is that if you ported DirectX to Linux then Linux would be Windows.  What actually needs to happen is that a standardized API is created that can then be used to talk to Windows, Mac, Linux and etc... via their own preferred API.

In those terms I think that it's pretty obvious that what you are asking for is about a billion dollars in development, assuming you can get everyone involved to play nice and help out.  Good luck with that, I'm sure Yegolev will be happy to get on it once he is finished porting notepad.exe to Linux.

NVIDIA made something like that (http://developer.nvidia.com/object/cg_toolkit.html) but I don't know if anyone's actually using it.

Sony uses it for the PS3.

You just described the GFX abstraction layer in Torque 2! /duckandrun

Seriously though--games are written in the GFX API, and render devices are loaded dynamically based on the underlying capabilities. DX8, DX9, DX10, OpenGL x.y, fixed function, software render, Xenon (XB360), etc., etc.

I'm sure it's wonderful but I'm also pretty sure I can tell you what one of the main complaints you get about it. 

"Abstraction layers limit the users ability to manipulate and optimize to the full complexity of the interface being abstracted."  Am I rite?

DirectX really only caught on because it exposed enough underlying complexity while still providing access to advanced memory management (among other things) to make the trade off of moving from DOS attractive.  Abstracting out the direct OS interface is a great theory but there has to be more than just cross platform to really get buy in.  In this case it's competition, the Id guys aren't going to use your abstraction layer because the Unreal guys aren't because they get X performance bonus from doing it the hard way and Id's product has to compete.

People have been trying to do hardware and OS neutral design for a long time now.  It almost never seems to work quite right though, you end up with Java apps which by being the 'Jack of all Trades' just ends up as the 'Master of None'.

So let me get this straight...  You're an avowed Linux lover, and yet you've never heard of Cedega.

The whole, "OMG M$ is tha borg!" shit is sooo last century.

You have the source code of the render devices as well, so if you want the optimization, you have the ability to do so--but not everyone interested in making games requires it, so the abstraction layer is available.

That means that to get higher levels of optimization and/or functionality you have to go back to coding to each individual rendering API, correct?  Sounds suspiciously like a cop out.   :-P

The thing I remember as being cool about Cg (in theory) is that it was designed specifically to accomodate fancy hardware features (programmable hardware shaders, that sort of thing) that other APIs lagged in supporting, rather than just aiming at the lowest common denominator of what was currently there.

I think you're taking what I said completely out of context, or I didn't give enough information. If you want to use DX9 capabilities and the hardware supports it, force load the DX9 render device. If you are building your code for the 360, you'll need to use the 360 specific render device, but the code you write yourself as part of making the game doesn't change--just the underlying implementation.

It's black or white : if you want cross platform/cross device, it's built in with no additional effort, but you won't have the highest quality of optimization for your particular project. You will of course have a highly optimized set of render devices, generally speaking, since device drivers are provided, but he mentioned wanting to ride the bleeding edge, so there's a built in assumption that a particular game might have mechanics that could utilize optimizations at the lowest levels.

If you want the highest optimization for your project, then you'll need to do the optimizations on any platforms you want it optimized for. How is that a cop out?

Finally, your "I can't use abstraction if I want to compete with others" argument was proven pretty wrong with the old school I must code in Assembly generation. Certainly I agree Java as a cross-platform solution isn't appropriate for making hard core games--but I never said it was, and it's not even in the same ballpark regarding what I'm talking about.

I did not say that.  I even pointed out a very successful example where it did work.  I said if there weren't enough benefits to outweigh the minuses then people would be slow to adopt because the competition is so tough.

Sorry for the bold but you decided to not read what I wrote.

Fair enough--especially with your follow-on reference to Java however, I responded to what seemed to be your point. If commercial developer YYY wants to gain a few frames by mucking about in direct render device code they have full flexibility to do so in any case--consider it abstraction for convenience if you will.

Because if the project in question will require you to drop out and code some parts in DirectX anyway, what's the point of using this API for it?  Why not just use DirectX to begin with?

What's really wanted is an API that provides all the benefits of DirectX AND builds on any platform.  This, of course, is nontrivial.   :-P

(http://www.concept420.com/marijuana-pictures/data/media/7/linux_stoned.jpg)

The one who should *really* chime in here is Quinton. Him and his unrealistically cute pokemon avatars have been around this particular block a time or two.

Which block?  I'm not a windows guy by any means -- much more embedded systems and suchlike.  I'm also not out there waving the "the future is linux on the desktop" flag, because that's kinda silly.

As pointed out above you need a lot more than just "DIRECTX" to make it trivial to easily port (or just run) win32 games on linux.  Projects like Wine aim to provide as much as they can of that environment, but it certainly is a *lot* of work and win32 is a moving target.

Unless your portability layer gives you everything you need such that you never want to deal with the underlying OS (or only just minimally), from a financial standpoint almost any company is going to target the platform that's 95% of the market primarily.  Even assuming you could pretty easily build on linux, you still have to QA that, deal with issues that crop up on it, etc.  You can easily dump a ton of cash/resources into something that will be a tiny tiny fraction of your sales.

Personally, I love the linux to death for development stuff and it pays the bills, but I keep a win32 box around for PC games.  Helluva lot easier than most other alternatives.

- Q

I love linux, use it at home and at work, but the request doesn't make much sense.

- It's a massive amount of work.

- DirectX is owned by Microsoft and hardly a standard. If you could re-engineer it, without running
into a patent, there's still nothing to stop MS changing it and breaking your version at will. They have
a distinct interest in windows games being windows only.

- Most linux users just don't care too much, for most of them it's a quick reboot into windows and
they can play games at full speed with no issues other than those windows brings. This is a large part
of the reason why the movement to bring games to linux failed.

- The other part is that you can barely get retail shops to stock PC games under the onslaught of
consoles. Expecting them to stock linux games is optimistic. Maybe this one will fade if online distribution
takes of, but that's not the case yet.

I was talking about your emulation work, as there are pretty large parallels between emulation and cross-platform APIs. :)

I did that once. It's pretty bad when an OS doesn't even come with a decent text editor.

I wouldn't say that so loudly.  vi users can be vicious if provoked.

I'm a pico guy myself. Not any more arcane than notepad really.

Used pico for a long time myself until I found Joe!

Bah, nano is better.

(And Cedega has issues with running most games. Also, the video driver situation on Linux is somewhat borked.)

The only way I see the game tide turning from DirectX to something else is for Linux (or OS X) to get some huge killer app that is only available on that platform. Something along the lines of a WoW or Half Life. In theory, that could happen if enough of the talent out there got togethor, but it's very wishful thinking.

On a side note, and this may have been before DirectX really took off, weren't quite a few of the major games/engines developed in Linux/Unix first and then ported to Win and Mac? I'm thinking some of the early id games in particular. Or is it just that the major portions of the underlying code were developed on *nix workstatinos in C/C++? I seem to recall reading that or seeing that somewhere many moons ago.

Just keep praying to the WINE gods. They'll get us there eventually.

Doom 1 and 2 were originally developed on NeXTStep ([edit] And Quake as well). It was Objective C, not C/C++. They didn't come on to Linux until much, much later though.

One reason why Apple even got Carmack back to supporting them again was because he loved the NeXT tools so much. Didn't really pan out though, I guess.

If you want a great read about this exact topic pick up a copy of Masters of Doom (http://en.wikipedia.org/wiki/Masters_of_Doom). John Carmack used a NeXT cube to build Wolf 3d.

A thing about John Carmack is his support for OpenGL (http://www.rmitz.org/carmack.on.opengl.html) which most of the games id makes are based upon, also why you see the cross platform support very quickly (Note: I mean in regards to engines after and including Tech 2 (http://en.wikipedia.org/wiki/Id_Tech_2)). But I really wonder how long it will continue due to the license revenue generated for id by Linux(etc) gaming.

What's really interesting how Microsoft can deliver an amazingly good API/toolkit for developers to build upon. The OpenGL alternative leaves you still lacking in how to handle game controller/audio/network stacks across different OS's. Maybe I'm pessimistic but the time for open standards has come and passed as it seems the market has accepted DirectX as a standard. Will Microsoft aid in porting it? No reason for them too but we have seen progress in the development of a cross platform .NET (http://www.mono-project.com).

My notepad.exe joke certainly took a bad turn.

I'd like to know how notepad is arcane, though.  Is it so arcane that I just can't find the real editor commands?

Ah, I meant pico wasn't arcane, like notepad isn't arcane.

Vi is arcane. Emacs is arcane.

Derr, OK.  I got it now.  I like Vim.  It is far more arcane than vi.

When I think of pico or nano, somehow "Baby's first text editor" comes to mind.

I used to use pine on a bsd/os shell account. That's where I started using pico as well.

That I even remember shell accounts or bsd/os, or even used email in the command line days should prove that I'm not really a baby.  :-P

But it's not that I can't use vi. I just don't want to. Llike thousands of other things in the unix world, it was originally intended as a joke.

I can't see how a baby could be expected to remember f = right, b = left, p = up, and n = down.

You can uses the arrow keys now!

What got me was 'G' (has to be upper case) takes you to the end of the document.

My quote was for pico keys.  Both vi and Vim use the more-useful-if-you-think-about-it h,j,k,l for movement.  Seems like f,n,p,b are for people who have to hunt for a key anyway.  Arrow keys are nice, but they are so far away.  I R LAZY.

G is not as bad as CTRL-L (not CTRL-l), in my opinion, but you won't use that nearly as often on modern terminals.  Vim has allowed gg to do what 1G does, which is awesome... until I have to use vi.

b and w are far more useful in vim IMO.  v, CTRL+v and I, d, y and p are all winners too.  I mapped split screen and move cursor to other split to F2 and F4 though so I don't remember what they actually are otherwise I would point out those commands as well.

Oh, I don't actually use h,j,k,l very much.  I'm all about b,e,B,E,0,$, and sometimes w if I remember it.  Just saying those basic movement keys make more sense to me.

The window-switch keys are CTRL-W-movement_key, and you remind me that I should remap that... I just don't do splitscreen very much even though it is completely awesome.

What is this, pico is so freaking easy I feel dirty using it.

You certainly don't have a lot of things to remember, so I agree there.  Have fun holding down f a lot.  I'm sure it's totally awesome but it's not something I want to do.  I also don't want to have a text-editor slapfight, so I'll just drop it.  Everybody use whatever they like.

(http://img255.imageshack.us/img255/6585/pcmacbsdsq9.jpg)

Someone do OS/2!

(http://www.virtualdollhouse.net/dollhouse%20pics/Gifts%20page%20photos/Marlene/Coffin%202.jpg)

The second guy is actually the other 3 in disguise.