Slashdot Mirror
No More Unreal Ports For Linux?
Ant was among the first to write with a link to this article on Blue's News claiming that Epic's new game engine is Direct 3D only, based on statements made at an E3 demo yesterday. Check that link to read the full article, but consider this excerpt: "A major side effect of this is that any
future ports of Unreal-engine titles that use the new technology will need to have a
completely rewritten rendering system, making Mac and Linux ports significantly
more difficult."
DoenerMord also wrote, saying "This
kind of puts some perspective on recent comments from Tim Sweeney (the man behind the Unreal engine) on Microsoft's
breakup ..."
Quoting from http://lists.openprojects.net/pipermail/glx-dev/19 99-December/002511.html:
I asked a microsoft rep about exactly that one time. He said they would
"protect" the API. Big difference from SGI's tacit aproval of mesa.
Sadly, what many people are ignoring is that not only the Linux ports are losing out, but the PC as a platform, too. To get the last 4 games that I bought run on my Win system, I had lots of trouble, lots of tweaking to do. For me that's fine, but for the average John Smith user it's a nightmare. I went to E3 last week and at the PS2 booth I overheard Jay Wilbur behind me (formerly id, but now I guess working for Epic), saying that though they sold UnrealTournament poorly on Win, they hope that on PS2 it will receive the attention it has lacked so far. I think this may be the last year of the PC as a gaming platform, as - let's face it - the second generation of console platforms are just very attractive for developers - potentially much higher sales and much better issues regarding technical support. QA is getting to be a major trouble these days. As much as many /.ers may believe that Linux ports are the key to success, I think that the platform losing out is the PC in general. If there are PC ports in the future it will be ports from existing 2nd gen consoles and if these ports are from XBox, it is clear that this may be problematic for Linux ports.
The spec is already open, otherwise people wouldn't be able to program games for it. The major problem is, that if you want to use direct3d, you'd need to implement a lot of windows core functionality in order to get it to work. It would probably end up being a lot more work then porting OpenGL, actualy. You'd need direct Draw, for sure. a lot of GDI code, and a lot of COM stuff, as well.
ReadThe ReflectionEngine, a cyberpunk style n
Sure different implementations in D3D have different capabilities. In D3D, however, they are all emulated to smooth things over. Take compled vertecies for example. In OpenGL, if the ICD doesn't support that extensions, then you're ass out. In D3D, it is emulated where not avaible. The thing is that the new vertex and pixel stuff in DX8 will be emulated where not available. Write to the API and you can be sure that high quality implementations like nvidia's and matrox's and ATI's will accelerate the shading correctly. If the feature is not available, then it will be correctly emulated by D3D. About you second point, I think there is a general concensus that extensions suck. Take those nVidia extensions. Sure every feature will be there, but you'll have to rewrite your code to support the Radeon, then you'll have to do it to support Matrox's new card. A game developer is not going to wait a year for the ARB to approve an extensions when a major new graphics arch comes out every 6 months. Also, about MS shafting vendors, you've got it wrong. The game developers and the hardware companies come up with a set of featueres they want. Then the game developers ask for a set of features they'd like to see in hardware. MS puts those feautures in D3D, emulating them if they are not available in hardware. They bait the hook if you will. In the next revision of graphics cards, the hardware vendors take the bait and add that feature to the graphics hardware. This transition is seamless. When the new cards come out, the feature goes from being emulated to accelerated. No shafting is involved. In fact, MS hates nvidia (too much support for OpenGL), but I don't see any features in D3D shafting nVidia. In fact, quite the opposite, stuff like cubic environment mapping shows of a lot of features in nVidia cards. As for your third comment, MS stopped copying OpenGL features long ago. Why? They ran out of features by versions 6. Most of the cool, nifty stuff in 7.0 is new, and 7.0 is quite stable and fast. I doubt 8.0 will be any different.
A deep unwavering belief is a sure sign you're missing something...
Eh, that's true, but..
The GNU port of Allegro is in a rather bad state right now. I downloaded it to play a nifty game called "Liquid War", and straight off discovered that I had to install the binary version because it would not compile from source. (it looked like a syntax error, as I recall, but I wasn't in a mood to hunt the bug down) Once installed, it worked -- except for several very annoying efficiency problems: among other things:
-> it appears to not block at all, even when the program is doing nothing but waiting for input with an unchanging display. I suspect it just spins to handle timing instead of sleeping (I haven't tried to verify this)
-> Drawing seems to be insanely inefficient. I don't know whether it's using shared memory (I suspect it isn't), but I've seen games of much less visual complexity work with much less CPU usage. Some button-pushing popped up what looked like a meter of time used, showing that almost all the time was going into drawing routines rather than game logic.
-> For some reason, Allegro insists on using its own special mouse cursor instead of X's.
The upshot of this is that displaying a static title screen takes 100% of my CPU time. Not so good.
Of course, this is really still a beta version of the port and I'm sure it'll get better..unless these problems (eg, assumptions of 100% CPU access) are present in the API as well. I haven't looked to see, perhaps you can tell me.
Daniel
Hurry up and jump on the individualist bandwagon!
No one I have ever known has done that. And they get pretty good performance to, at 100mhz :)
ReadThe ReflectionEngine, a cyberpunk style n
Actually, if these were standardized on hardware, then the API would never evolve. No cubic environment mapping for you!
A deep unwavering belief is a sure sign you're missing something...
Err, isn't that the standard that Microsoft is using to force people to upgrade from to Win2k with their refusal to release DX6 for NT4?
The problem is, no one follows the "standards" the same way. Take HTML for example ...
... those OEM vendors signed the contracts, no one forced them to do so ...
Bad example. HTML is not supposed to look the same everywhere. When are people going to figure that out? HTML is supposed to be a presentation-independent, logical markup language. You markup what you are trying to say; the user agent (browser) determines how to say it.
Netscape and IE. Wait, hold on, those two are guilty of extending the markup language on their own...
I'm not saying NSCP and MSFT aren't both guilty of the crime of discarding standards. Indeed, I've condemned Netscape for their behavior in the past. Mozilla, at least, is based on standards, although I think that was because NSCP saw that was their only hope.
I personally just want to use whatever works well, and I want it to be the same.
So, we shouldn't have a choice? A single, select few companies should control what is fast becoming the most important communications medium in human history? We should be at the mercy of MSFT, AOL, and the like?
And you call yourself a libertarian? Libertry is the root of that word, and it seems you're not all that familiar with the concept.
Um, MSFT very much forced them to do so. It was either that, or lose their right to to distribute Microsoft's OS, which was pretty much the only choice (see monopoly). The only choice the companies had was to sign the contracts or go out of business.
If that's your definition of "liberty", well, I'm glad I don't agree.
There is a great advantage to having a somewhat standardized Operating System.
There are advantages to having a somewhat standardized health care system, too. And to the regulation of firearm ownership and operation. Yet, if you are a libertarian, I'm sure you are strongly against such things. Why are OSes different?
One of my greatest frustrations with Linux is the amount of variance in the systems and the versions of the libraries they include.
Funny, that's my greatest frustration with MS-Windows. On Linux, all I have to do is grab a copy of the library I need, install it, and I'm all set. The better package-management tools even take care of this for you, automatically and transparently.
On Windows, that is often illegal, and when it isn't, you still cannot have more then one version of a library installed. DLL Hell. No, thank you!
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
> OpenGL seems to me to be an exceedingly well-thought-out, clean, and consistent API.
;-)
It is. Check out the blue book for more goodies on the orthogonality of OpenGL.
> What is wrong with GL?
Not a hell of a lot.
- The only real drawback of GL is that software rendering speeds, are, shall we saying "quite lacking". It was meant for 3d hardware.
- OpenGL drivers usually aren't as optimized as DirectX due to limited time and money.
- Some people will complain that the OpenGL doesn't support every new feature in a consistent way, but the OpenGL extension is a much better way to do things. ANY vendor can add their own extensions. After implementations settle down, it may become part of the standard. Look at how long it took M$ to get rid of the Execute Buffer garbage in Direct3D 2/3.
--
"If I protest an illegal tax, does that make me an illegal tax protester ?
> I have never understood why no one has developed a game OS.
... ;-)
It's called Winblows 9X. The darn thing isn't stable enough for anything else
the celeron-II is a decent value for BX-motherboard owners who will overclock to 100-112Mhz. the article you mentioned even admits it didn't overclock the celeron-II properly, although it's written very slyly, as if it purposely was meant to slander the new celeron-II. bad choice of reading, if you ask me. try www.hardocp.com or www.overclockers.com, etc. sheesh
The difference is that IE is "tied" into the operating system. You're not _required_ to have telnet, or Lynx, or an equivalent of Lynx.
It's sad, but true. OpenGL needs a lot of
extensions now, and these extensions must be
made mandatory for the next generation of
games.
Cards are now hitting the market with environmental bump mapping, cube mapping, texture coordination perturbation, etc, and unfortunately, the only way these are currently supported is through mutually incompatible OpenGL vendor extensions.
In typical MS fashion, DX1,2,3..5 sucked. By DX6-7 were good, and now DX8 overtakes OpenGL.
You can't blame game developers from moving away from OGL if they can't write to a consistent standard API that utilizes all of the hardware acceleration features available on a card.
This christmas we will see the ATI Radeon, 3dfx Rampage, and NV20. All of these chipsets are likely to support the DX8 shading language. OpenGL won't except through proprietary extensions like NVidia's register combiners extension. That means developing a game that uses advanced photorealistic lighting on OGL will be hard.
Herein lies the difference between open-source and commercial development. MS actually runs conventions, gathers developers and manufacturers together in the same room, has people present papers, and say: What do you want in the API? The game developers and hardware manufacturers interact, and MS adds the most request features to the API.
As far as I know, there is no open-source equivalent to MS Meltdown, E3, WinHEC, etc.
What Linux needs is a hardware/kernel convention so that there is some actually two-way communication between developers and manufacturers instead of just: "Gimme your goddamn specs so I can write a driver."
The only reason that UT windows made the sales is because there was no Linux boxed version available. Yeah, I had to buy the windoze version and d/l the binaries to play under Linux. And you know what, my framerates blew away everyone else running it under windoze. I guess they are ditching Glide for the very same reason nVidia is ditching Linux: money. Seems they enjoy sucking the micro$oft moneycock just like nVidia. Thanks a lot, Epic. Enjoy your time while you can.
"Klaatu, verada, necktie!" -Ash
id wrote Quake 3 entirely in OpenGL and entirely by themselves. Loki merely packaged it for them.
Interested in open source engine management for your Subaru?
You can't "just port Direct3D to linux", because D3D is carefully licensed and protected by Microsoft. The reason they switched to D3D-only is because OpenGL doesn't have the features Sweeney wanted, and he told Microsoft to add such features to D3D. OpenGL's ARB just can't implement new features and versions of OpenGL as quickly as Microsoft can add new features to D3D, due to organization structure and manpower.
I guess I can add Epic to my list of companies to no longer buy games from. Right up there with the fine folks at Blizzard who refuse to allow Linux ports of their games. Tim Sweeny just doesn't make any sense to me. Unreal was a decent game ruined by horrible netcode, and a tereribly buggy/unoptimized engine. The UT engine is just as much a bloated turd as the Unreal engine is, rarely topping 40 FPS on even the most powerful systems out there. Perhaps if Tim stepped back and tought about how it might have been easier to work with an OS that isn't so damned buggy and hard to code for, his own games might not have required the numerous patches that he had to write to fix all the horrible bugs.
I bought Unreal Tournament only because there was a linux port of it.
I will certainly not buy Unreal 2 unless there is a Linux port of it. And a server only port is not enough for me.
However, the "flamebait" moderation on your post show how immature and ignorant many Linux users are, please don't let such dogmatic opinions stop you from implementing FreeDirectX.
-T
What's really interesting is that EPIC seems to be desperate enough to bank on their relationship with Microsoft, and they do all that in a very foggy situation when Microsoft can be split up and God know what else can happen to them. EPIC is really taking a major bet here, and this probably is because they are not really doing too well in financial terms, hence comes cash infusion from Microsoft. Games development is an expensive business you know... and hey, EPIC guys deserve to drive Ferraries, too, right?
alexc
Join Majestic-12 Distributed Search Engine
Or what about a cross-platform security feature like Kerberos? No wait, I got to think more about this one.:-)
The problem here is again, a different stack here, a different browser here, a different protocol there, a different compression scheme here, a different xml engine there, a different ipsec here, and you get the point.
I could see microsoft being forced to allow its applications to run/be developed for OTHER platforms, but making win98/win2000 and future versions be broke up to replaceable components is DUMB. And that will cause problems.
P.S. You can diss glide, but it was 3dfx voodoo and glide that started the whole PC gaming era as we now it. Without them, we would all still have VLB 1 meg Cirrus Logics :)
I am slashdot, that is, i am one of the many people that read and believe in slashdot and its ideas about open source. I feel that if microsoft would release the source code for its products they COULD be improved drasticly. But about this whole DirectX thing
DirectX is a standard that is not perfect, but does its job quite well. only problem is that it is ONLY windows. If the DOJ breaks up microsoft then EPIC may not be able to pull back together enough to improve their games using OpenGL or something. They are jumping into a TRUST relationship with microsoft saying "you can do it, and we will make our shate for your shate only"
my solution,
the DOJ make microsoft release source code for the technologies that give it an advantage. DirectX for one. Microsoft gives the Linux comunity the source for DirectX, next day there is a custome installer for GNOME or KDE, BeOS can run every game windows can with perfect memory protection, and Macs can play more than solitair on their proprietary OS. Next step
DOJ looks at Intel and says Monopoly, you must turn over all of your proprietary technology and Open-source the plans, suddenly the AMD thunderbird is socket370 on a Alpha bus at 200MhzFSB and you can still clock it down to 66MhzFSB to run your old celeron366.
Overclockers are happy because they have BUS options up to 200-or 400mhz later on- and still use the chip they have today, and then they can upgrade down the road. They know that their socket370 chip will work in any new motherboard. Servers are running the same socket370-or socket A if your diehard AMD- so you can strap in your new AMD Athlon Xeon-which just happens to support first generation SIMD and advanced 3Dnow- and you can swap it out for the new 1.5Ghz Intel whillimet Xeon-which has a better SIMD but its 3Dnow aint quite as good.
Standards are good, and there is something to be said about open source, final thoughts:
open source every standard, not to be modified necesarily, but to MAKE it standard. Game developers would only have to make one rendering engine, it would run on Mac, linux, BeOS, BSD, windows, java, the new amiga, everything. they would just need some poor, boored hacker to port the executable over.
Join the OpenUT list at openut.sourceforge.net. I will guarentee it is an installation issue. 99.9% of the maps out there work just fine. In fact, I haven't found one that doesn't, but I know of a few circumstances that would prevent a map from running. jf
Like it or not, the X-Box will still be the fastest performing console available when it is released in Q4 2001.
Given how complex the PS2 graphics engine is, and how current games have only just scratched the surface of what it can do, I'm not convinced that the X-Box will even be faster than PS2, let alone PS3 which should be out by then. Never mind the graphics engine, the X-box would appear also to have a hard time competing on memory bandwidth vs PS2 with RDRAM. I'm no fan of RDRAM in general, but in situations where bandwidth is more important than latency - which includes graphics - it certainly beats SDRAM.
Anyway, my point wasn't how X-Box compares to other consoles, but how it compares to PCs and users general speed expectations. A 600MHz processor is hardly top-of-the-line today, let alone by Q4 2001. AMD's SLOWEST processor is about to be the Duron 600MHz, which has a full speed bus and will beat the PIII based Celeron II. Processor speeds from both AMD and Intel are expected at 1.5GHz in Q1 2001, and 2GHz by Q4.
VooDoo 5 6000 may be $600 now, but by Q4 2001 it'll doubtless be MUCH cheaper as well as replaced and outclassed by VooDoo 6 or whatever. nVideo will also obviously keep bringing out higher performance cards, while the X-Box's design is frozen. Given the relative size of the games console and PC markets, game developers will continue to target PC platforms for games (maybe X-Box/PC can be targeted together), and user's expecations wil be raised by PC performance levels.
If you've ever looked at the PS2 graphic engine architecture (Ars Technica have a good in depth review), you'll realize how complex it is, and what type of performance it can offer to games that truly take advantage. It's very hard to compare it to PC graphics cards. It's significant though that a number of arcade games manufacturers are switching to Sony's engine...
so it'll be an easy port to the Xbox once it's released. I'm sure Microsoft threw them several million dollars.
is not JUST a graphics API like OpenGL is. DirectX is a whole package of media libraries. Funny thing about this is I sent in an Ask Slashdot a couple months ago asking if people were using OpenGL more or D3D. Anyways, DX is very popular (in my estimation) because it is a unified set of media libraries that are all written together and in the same way. A bonus is that video and sound cards have hardware DX support. This is a boon to any game developer because it means the CPU can pump out a few extra transforms or some smarter characters and so forth. What I have yet to hear about is a completely open and cross platform media API. There probably are a few floating about, they need some attention. I really like being able to play the same game on multiple platforms, I really wish more games could be developed on multiple platforms. I would have thought a game like Unreal would have primarily cross platform development in mind, you're trying to get as many people fragging as possible. Oh well, I don't play Unreal anyways and HALO will be on Mac and PC so I'm happy.
I'm a loner Dottie, a Rebel.
hahah
Oh well, I suppose they do.
Of course, this is going to ruin the lives of people like us now. I think that we might possibly have to find some replacement, but what I wonder...
http://www.doublezero.uklinux.net/
Doublezero: like Slashdot, only less useful.
Does any of you know how a 3D engine works? only the backend renderer needs to call the 3d api to visualize stuff. the rest is just internal database management, gamecode, I/O etc. No d3d specific code. That the engine he's producing now is D3D only is not a weird thing: it's portable easier to the X-box, plus you can truely write an OO engine.
Porting the engine to other platforms takes time but not that much. If there will be a huge market for linux games (which there isn't, so why putting any money in a linux game) they will add an OpenGL renderer. They need to add a psx2 renderer anyway. Because OpenGL is now beeing ported to the psx2, OpenGL support is only a matter of time. (But sweeney doesn't like OpenGL, and face it: it's not a statement he made public himself, it's a note from the E3 from a reporter who probably heard this in the mensroom where sweeney and carmack both were taking a dump and calling eachother names)
Get a grip...
--
Never underestimate the relief of true separation of Religion and State.
MEEPT is back! All Hail MEEPT!
Please moderate the parent up. (only moderate my plea down after moderating the parent up, or ignoring my post and moderating nothing)
Why?
Because now that slashdot is censoring trolls and other fun-loving individuals, (try posting something with "First Post" in the subject line, too many capital letters, too much punctuation, etc., etc. and see what snide replies you get) a good way to combat this would be "intelligent trolling".
...and if you don't remember him, MEEPT is the king of intelligent trolling.
So please, let him post with a default score of 0 or 1 just so the funny ones have a chance of being moderated up more, and I can see his posts more often! (and look through his history, moderate the good posts up to +5!)
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
When Unreal 1 was huge, i remember constantly checking their page for a new patch, to fix the bugs in what was a game with great potential. This seems to be epic shooting themselves in the foot again, especially considering their main rivals are ever-expanding their linux compatibility. Let's hope they considering supporting more API's, or they risk excluding just what others are embracing.
3dfx and many other vendors have been working hard on DRI for a while now. Why not use it? I use the development dri to run Quake3a in linux, and it works just FINE. There's no reason to use Propriety Direct3d, DRI should do the exact same thing, and be cross-platform, right?
That would be a good idea, but it rests on the assumption that "Linux 3D developers could always stop hating M*crosoft for a few seconds.
Enough said...
"Dis aliter visum"
http://www.doublezero.uklinux.net/
Doublezero: like Slashdot, only less useful.
Wine Is Not an Emulator. It replaces windows libraries, it doesn't emulate.
Epic has already made a ton of money off of all three operating systems. And yet they would do something which would hinder that strategy? Particularly with an inferior 3D API?
I'm not worried about the Mac port; Westlake (who did the Unreal and UT ports to MacOS) has a lot of experience converting DirectX to interoperable API's (heck, most of The Sims is Windows-specific but they've already got it playable, albeit not yet at Alpha). But this could spell big trouble for the Linux port.
It's yet another of Microsoft's Broken Promises (tm). The Mac compatibility layer for DirectX was due years ago, according to Microsoft itself. And with a public API, a Linux layer would have been far easier to implement.
Now, let's look for a moment at layers:
DirectX
Pro - Easily controlled if you're in bed with MS, as Epic admits to being. Relatively easy to program.
Con - Windows-specific.
QuickDraw3D
Pro - Very easy to program. Available on many platforms via the Quesa project (already nearly complete). (and available on at MacOS and Windows in its original, closed implementation) Open-Source, again via Quesa. Implements a standard file format (3DMF, the basis for VRML97).
Con - No longer being actively developed by Apple.
OpenGL
Pro - The most powerful API out there. Already has the non-game marketshare by an overwhelming margin. Runs almost anywhere (hell, it even runs on PalmPilots!) Has Open-Source "alternatives."
Con - Few primitives, making it harder to program. Eats resources like you wouldn't believe; requires hardware acceleration for decent results. No true Open-Source "implementations," though that's more a technicality than anything else.
So which is the best? Each has its pros and cons. I'm more partial to the underappreciated QD3D (which, incidentally, Quesa implements on top of OpenGL). I will say that DirectX's platform specificity is a big problem unless you only plan to port the thing to the X-Box. But again, if you're in bed with MS, you can change the API practically at will. OpenGL really doesn't have that big a share of the gaming market (though overall it's overwhelmingly the most popular), but it's more powerful than any of the others. QD3D has ease of programming, but it never really caught on for some reason.
Their conclusion is probably because there's a huge overlap between Windows and Linux users (those who dual-boot to run Windows games), and it certainly doesn't make sense for them financially to support both platforms, since those dual-booting Linux users will buy their games anyways.
Besides, supporting DirectX only will get on Microsoft's good side, which leads to preferable treatment when the X-Box comes out. Remember, Microsoft will be the central authority for the X-box, as they have the right to issue an license for a game or not (unlike Windows). How does waiting two weeks for a X-box license sound, instead of waiting four months like the OpenGL-supporting id Software?
What this means is that you, as a gamer who wants to see games ported to Linux, should boycott game companies like Epic, who are departing platforms like the Mac and Linux for the greener pasture that is the X-Box. E-mail the developers at Epic that you refuse to dual-boot to Windows just to run their games, and that you will only choose games from developers that value the "right thing" over greed.
Go get your free Palm V (25 referrals needed only!)
No shit, as if I was'nt aware of the meaning of the acronym ... however, AFAIK, it actually *emulates* Direct3D by translating its API to OpenGL .. so there you go ...
It is obvious that Tim doesn't properly seperate between specifying
APIs and ABIs on one hand and a specific implementation on the other.
The TCP/IP stack example shows this: To end the DOS/early-Windows
chaos, people should have agreed (or forced to) APIs and ABIs, it
wouldn't be required to use one single implementation.
However, in several ways D3D as an API does what Game programmers want
where OpenGL does not. For example, it has better control over
texture loading, which is important for games that try to be more
beautiful and/or more outdoor - oriented than Quake. The step from
Glide to OpenGL/D3D initially widened the speed gap between Quake and
games like Unreal, Starsiege Tribes etc, mostly because texture
loading was suboptimal and couldn't be controlled/tuned as in Glide.
Microsoft quickly extends D3D in ways the game programmers want, while
the OpenGL consortium moves much slower and while moving it has to
weigth the concerns of "serious" (non-game) 3D applications as well.
There are some more far-sighted programmers like Carmack and Chris
Hecker who think (my interpretation) that using a single-vendor API
will cause more trouble in the long term than is worth the quick
improvements now, but few people enjoy the luxury of allowed to be
stubborn.
Sweeney has to position his product relative to Quake, he needs to do
some things better than Quake and (engine-wise) he lost ground while
moving from Unreal vs. Q2 to UT vs. Q3A. OpenGL needs a lot of
"right" tuning by the vendor and Quake is often used as the benchmark.
It is obvious that Sweeney *needs* the better control features of D3D
to get a product that is different from the new id engine while still
performing well.
I'd like to make clear that I'm absolutely on the OpenGL side here,
I'm just trying to point out that Sweeney isn't necessarily evil
(although his post about the MS splitup is rather stupid IMHO and I
can't agree with most of his programming language observations
either).
Martin
It's a perfect example of my point: Do we want to give the government the power to determine how software is designed, when they've created situations like this one above?
MSK
Epic Megagames have released some gems, although sadly it seems like those days are behind them now...
Epic have never seemed to find a groove with 3D games, though. There was a simply awful Wolfenstein 3D clone called Ken's Labyrinth (and wasn't this Ken the same Ken Silverman who developed Apogee's Build engine?), and since then they've been scrambling to catch up with Id.
But the problem is, if Janet Reno and Co. get their way, programmers won't have the power to make that decision anymore -- the government will.
Where on this Earth did you get that from? Have you been watching too many "X-Files" shows?
The government is not proposing, nor are they allowed to, dictate what programmers have the power to include in anything. If you honestly think that, I think you should log off, shutdown your workstation, and step outside. Notice the lack of flying saucers and KGB patrols. Once reality has returned, please re-join the discussion.
What the DoJ is proposing is that a single company -- one Microsoft Corporation, in Redmond, Washington -- be broken up into two or more seperate companies, as punishment for illegally using their monopoly power to stifle competition, and to help prevent it from happening again.
No more, no less. It will not affect what other companies can do. It will not affect what other programmers can do. It won't even affect what the new "Baby Bills" can do. It will simply split the companies and prevent then from working together.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
AFAIK, there is no intention to pull OpenUT or any of the source code. In fact Brendon posted to the OpenUT devel list that he was going to release the new UT 413 headers directly after E3 so we can start developing again.
Also note that Epic has done fairly little development for the Linux port, but rather released enough of the source code to allow the OpenUT group to get the engine running. Since the source release, the code has been ported to SDL for window handling, I/O, and OpenGL, and there is currently heavy development on the sound code, with, with the exception of 3d audio, is already on a par with the windows version.
But there are three things that that gives me much hope for the future with Unreal and Linux:
1) Daniel Volgel, one of the main programmers on OpenUT (probably would be considered the 'lead' programmer) started working for Loki about a week ago. He has a pretty good working relationship with Brandon Reinhart and I would imagine that there would be a dialog between Loki and Epic.
2) AFAIK, the playstation uses OpenGL as it's primary graphics API, and Linux as it's development platform. Heck, I KNOW that Brandon has been doing the UT port on a Linux box. How can you ONLY support D3D and still port to the playstation in a reasonable fashion.
3) It's a long way from here to a new Unreal Engine. Lots of times, and there is lots of time to change their mind.
Anyway, that's my 2 cents. I've enjoyed hacking on the OpenUT code, and will continue to. And EPIC has done the Linux community a great service in releasing parts of the UT engine source, which can be a great learning experience on how a game engine is written.
OpenUT is very playable on many systems, and this will only improve as the state of accelerated OpenGL (via DRI or GLX) on Linux improves.
jf
Bump-mapping, yeah -- indications of embossings and depressions in a surface, so environments look somewhat more like real objects instead of like painted plastic as in Doom and the Quakes -- but how do you mean, "proper"?
Surely this should have been one of OpenGL's strengths? Epic are saying that Microsoft are more open to developer's input than the OpenGL people.
Open standards aren't really much good if they're kept in a stranglehold by only a limited and closed number of people, are they?
--
Rare Window - free your photos
You should wait patiently. It took 5 minutes to render, but it rendered finally (I tried it on NT, sorry if it doesn't apply to linux version)
Szo
Red Leader Standing By!
Microsoft has demonstrated (Java) and continues to demonstrate (Kerberos) that the price for allowing them bring standards and interoperability to the PC market is strict Microsoft control over implementations of said standards.
You picked the wrong culprit if you're trying to identify who has excercised strict control over the 'standard' for Java.
Sun has run whining like a spoiled greedy child from three standards commitees thus far because they didn't want to give up ANY control of Java.
My point? Microsoft isn't behaving any differently than anybody else.
emulator is, namely, that which emulates (tries to act like, but is not) an origial product.
So the second system to implement an API is the emulator? All X11 servers but the first implementation (incl. XF86) are emulators, right? And all Java VMs other than the first are emulators, right? And the GNU system is a UNIX® system emulator, right? Microsoft IIS is an NCSA-httpd (now Apache Server) emulator?
Will I retire or break 10K?
I wish to high heaven the DOJ would take a reasonable course of action, like the one proposed in the above post. Breaking them up is just going to make it easier for MS to blame the DOJ, the states, Slashdot, Charlie the Bartender, and whoever else has accused them of being a monopoly. And, frankly, I don't know how many more insipient "they're trying to keep us from innovating!" commercials I can stand; I prefer my meals to stay on the inside.
So it surprises me that there is all that talk about dropping other platform support, especially after just committing to PS 2, as i doubt that it's going to have a port of Direct X.
Both Tim and Brandon's comments taken together look a little strange and may support rumors of dropping cross-platform support. But it's far from a clear cut statement that they will. BluesNews only reported that Brandon claimed it would be more difficult to port to Mac and Linux, not that it wouldn't be done. After all porting to PS 2 won't be any easier and it's definitely going forward.
Let's hope those platforms don't become victims of insignificant revenues, just after the Unreal engine is gaining respect in a market where only John Carmack stood out as a programmer more interested in better technology than revenues.
--ether
Not long ago, Sweeney had a post on the unreal tech page where he ranted and ranted about how great D3D and Microsoft tools are.
Another time, he had some none-too-favourable comments about OpenGL, claiming that Carmack was the only one who could 'afford' to take an ideological stand.
D3D is an ugly, non-standard uni-platform hairball. In every instance, D3D games look worse than OpenGL or even Glide games. And god help you if you're a programmer...just look at the case of Ultima IX. Origin originally wrote the engine for Glide and very quickly found out that D3D just could not DO what Glide did (at least, not without a LOT of pain). In the end the D3D performance was very much below Glide's performance.
So, if Sweeney wants to support D3D only, he's really going against the tide. The era of Windows '95/98 'only' is OVER. Ignore the seachange at your own risk.
One of the most common reasons to dual boot Linux is to run Windows to play games.
True. However, he's referring to hardcore gamers, who are more likely to be using dedicated gaming consoles (i.e. Sony Playstation, Nintendo, etc.) than either Windows or Linux.
There isn't a single game that runs better anywhere except on Windows. Get real! Windows runs games better. Period.
This is a load of absolute crap. Games written for Windows run better under Windows. Big surprise. Games written for Linux run better under Linux. The same is true of most games written for any particular platform: they will generally run best on their target platform.
As for what software and hardware combination runs games the best, neither Linux, nor Windows, nor Macintosh, nor any other generalized platform does it as well or as cheaply as dedicated gaming consoles. Not even your beloved Windows.
The Future of Human Evolution: Autonomy
Something I've always wondered.... Why has nobody made a DirectX-wrapper?
Write code that maps DirectX code to OpenGL (or something)
Tim also states that Microsoft has done a great thing by standardizing printer drivers, graphics drivers, etc.
Well, that's true, to a point, but what they've done is create *more* of a mess. Not only do several devices have their own set of instructions/routines, but quite often they're not documented.
Printing? Well, if PostScript had been standardized on the *hardware* side, as I wish it were, there would be no need for a software-side abstraction level. If OpenGL were standardized, as well as VESA, then the need for software-level abstraction would be nil.
The point? Microsoft may have come up with their own standards on the software side ("Standards are great; let's make our own!") but they've made a royal mess of the PC hardware world.
Stating on Slashdot that I like cheese since 1997.
The various X11 implementations are NOT emulators, since their purpose, their only purpose it to implement the X11 protocol itself. Berlin, AFAIK aims at EMULATING X11: because its main purpose is not to implement X11, it will implement X11 on top of another API. That's emulation. WINE, however, allows to run Windows programs on Linux. Linux is not meant to be a Windows implementation. See the difference? WINE is Not A [CPU/Machine Code/Virtual Machine] Emulator. It runs things natively, yes. That
these problems (eg, assumptions of 100% CPU access) are present in the API as well
Sorry, but you're right. Allegro was originally written for DOS. As such, it didn't get sleeping routines until 3.9.32, it displays the mouse cursor as a sprite in the game window, and it draws all graphics by blitting from an internal framebuffer to the X11 screen. But it also runs on framebuffer-console (fbcon), and many of the problems you experienced are gone. (If you care about cpu usage, why are you running an Allegro game on the server anyway?)
But it's still beta. Try Allegro 3.9.32 (from the Work in Progress page); it's quite stable now.
Will I retire or break 10K?
I am not sure if anyone has said this already,
(if has, shame on you moderators), but there is
an update on the page which says that whole thing
is misunderstading! Go read it yourself.
In other words, Mesa is to OpenGL as GNU is to UNIX.
Will I retire or break 10K?
It seems to me that Tim was simply pointing out his, and our, future dilemmmas: What will happen to the market place that I work in? Are my skills transferrable?
Well, I think there may be a way of preserving the benefits of the consistency (a word chosen to not imply any particular level of quality) of Windows while punishing MS for their actions:
They should be forced to surrender 9x, NT and Office to a rotating licence system. Every, say - four years, an auction is held for each of them and the 'best' offer gets to carry the product forward. MS should be broken up completely and auctioned off, the proceeds going to *international* charities covering the homeless, single mothers, victims of child abuse, famine and disease (yes, a large chunk of MS's worth came from outside the US - 'payback time' as the Americans put it).
The offers would have to include detailed manifestos that must be adhered to (preferably by law). The final twist? The winners could be decided by the registered users using an online voting system.
I am sure that a consortium of interested parties from the gaming and home user fraternity would like to take on 9x... and then this argument would be in vain.
Matt.
The problem here is again, a different stack tere, a different browser here, a different protocol there, a different compression scheme here, a different xml engine there, a different ipsec here, and you get the point.
And this is why standards are what should be followed. Not Microsoft's "Here is our proprietary solution that locks you into our platform" APIs, but standards. Like POSIX, like HTML, like CSS, like XML. If you followed the standard you will be okay.
It is when vendors like Microsoft decide to "enhance" the standard with extensions designed to lock out competition that things break down. Microsoft is an illegal monopoly, and something needs to be done to stop their abuse of that power, or the future of the information age will be owned by a single company.
Microsoft is an illegal monopoly, and something needs to be done to stop their abuse of that power, or the future of the information age will be owned by a single company.
I don't think breaking up MSFT is the best solution possible, but it may be the best solution possible under US law. I would rather be inconvenienced then enslaved.
What would my ideal solution be?
First, behavioral restrictions: Force Microsoft to publish complete specifications for all of their interfaces and file formats, and allow unlimited third-part re-implementation of them. If they cannot provide a spec, they cannot sell the product.
This would keep Microsoft from using their products to lock people into their products. People would be free to choose Windows, Exchange, IIS, IE, or what-have-you if that was the best product available. But if MS tries anything funny, people would be free to switch vendors.
Prohibit Microsoft from entering into exclusive licensing agreements with PC OEMs. This is something that is technically already done, but MS has found loop holes. Close them.
Next, some punitive and corrective measures. MSFT has broken the law and deserves to be punished; they also have locked out their competition in many markets and can continue that lock-out legally. So:
Prohibit bundling any other MS product with Windows for the next five years. No Windows Media Player. No MS-Works or MS-Office pre-loads. Force a choice on people, as MS has forced the lack of a choice on them for so many years.
Force MS to include freely available third-party browsers in the Windows OS package along with IE, and give users the choice of which they want to use. They've used their OS monopoly to build a browser monopoly; correct that.
But again, I don't know if any of this is possible or feasible, and I would rather be inconvenienced then enslaved.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
The problem for gamez writers is real. The fundamental problem with peecee gaming is that gamez, to get the performance gamerz want today, need to get very close to the hardware. Unfortunately, this is exactly the type of thing that good operating systems both prevent and facilitate: arbitrary random physical access to hardware devices is out of the question, but there exists one prescribed method of gaining the access you need, which offers protection from at least most mistakes. DirectAnything is hamstrung by two problems: 1) It fails to provide any real protection, and has been designed and implemented in the same slipshod way as the rest of windows, 2) It requires hardware support which is anything but universal.
So it's understandable that gamez manufacturers like targetting the consoles - it's a single known environment (as is pointed out in the article) which is generally rock solid internally and offers very direct hardware access, making high performance easy to get. Naturally, the lack of protection is problematic, but people have been writing hardware gamez since Pong - it's a science by now.
I would argue that, once completely implemented, the new DRI/DRM XFree implementation will be infinitely preferable to Microsoft targets for gamez developers. Why? Performance (with the right hardware), universal availability, and uniformity. In other words, you won't _need_ a FuxorGraphics model 455CA specifically; anything will work, though naturally if you want good performance you'll want something that can do hardware GL. GL is not itself without problems, but at least it's widely available. And with a fast enough CPU, software rendering is not out of the question (in fact, some SGI systems were set up specifically to do most of the rendering on the CPU. This is not altogether a bad thing; the 3D performance on those systems does not suck, to put it mildly).
Whether this ever happens, and whether it's ever adopted, remain to be seen. But even if all of his worst fears are realized, and DRI never gets completed in any sane fashion, it's not the end of the world. The worst doomsday scenario he comes up with is the death of the peecee. Would it be so bad to kiss the relic of the 70's, never designed but patched together by marketing types and marginal hackers from day one, unstable, unreliable, and nonuniform, a final goodbye? I'd like nothing better than the death of the peecee. Good riddance. Tragically, though, this fear is massively overblown: the peecee's existence relies on buyer ignorance and gullibility, of which there seem to be no shortage.
So, it seems while you tried to list 7 platforms, you really listed 3 that are so similar that you don't need DirectX to be portable.
Got HTML? Want LaTeX? Try html2latex
I will readilly admit I'm not into games as much as I'd love to be, but given the HUGE market segment this has generated, is anybody working towards a standardized Gaming Operating System?
I realise that driver support is a major stumbling block as are rendering "standards". It seems that the industry as a whole would benefit by a baseline OS that standardized API's could use and that would open an easier route for compatible drivers.
I know, Linux is this, but really now, I don't give a hoot about rebooting into a different OS optimized for gaming rather than suffering the overhead of any given OS.
"...calm blue ocean, calm blue ocean, calm blue zeroes, ones and zeroes, ones and zeroes...ahhhhh"
Wine Is Not an Emulator. It replaces windows libraries, it doesn't emulate.
Oh, please.
emulate: 3. Computer science: To imitate the function of (another system), as by modifications to hardware or software that allow the imitating system to accept the same data, execute the same programs, and achieve the same results as the imitated system.
Wine emulates the Windows binary interface. Funny names aside, Wine very much is an emulator.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Breaking up Microsoft into one OS vendor and one Applications company won't prevent Microsoft from adding stuff like TCP/IP or DirectX to it's OS! They're OS components, I don't think anyone would claim they're applications in the normal thoughts of the user (or the DOJ, surely).
I have two words for you: Trumpet Winsock
Networking used to be an addon application to Windows, but we're so used to being networked now we don't give it a second thought. As a comparison, networking is still technically an addon component in OS/2 (Warp 4 included) along with a lot of other software in the OS/2 package, presumably because of the government restrictions on IBM. Sure, it's great that you can easily replace your networking subsystem, but you're not going to, and the disjointed way it works because it's not part of the OS, blows IMO.
I'm sure if MS integrated a HTML/XML/WHATEVER-ML renderer into Windows properly, and got away with it without anyone noticing, 5 years later we'd all be wondering how we ever got along without it. Including such a renderer to most people = browser, MS have offered to hide the browser IIRC, keeping the renderer because it's rather useful (even for lowly help files). But certain people just cant accept that hypertext is useful for anything but a browser..
... But all the *good* Dreamcast games run right on top of Sega's bios. WinCE (or, as I like to call it, Windows Mini-ME) sucks on PDA's, it sucks on Dreamcast, it sucks everywhere.
If someone would pick up ECOS or EROS and write some OpenGL/Mesa driver code for it, that would simply rock.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
Kenn Cobb (also from Westlake) had this to say:
So, while it may not be a great situation, atleast Mac users won't be shut out entirely. Westlake knows what's up...
-doenermord
saw this on Blue's News:
"one of the reasons for this is the fact that they have direct input to Microsoft as to the development of the API"
I could see microsoft being forced to allow its applications to run/be developed for OTHER platforms, but making win98/win2000 and future versions be broke up to replaceable components is DUMB. And that will cause problems.
Problems. Even with MS's driver certification program there are still problems with video drivers (a component) and sound drivers (another component). What if MS bought 3dfx, nVidia, and Creative? Don't you think there would be fewer problems? I think there would be fewer. I think the quality of first release drivers would go up substantially. Do you think that scenerio would be a good thing?
What if Microsoft bought every company or division of a company that made anything at all for the PC market? That would bring them to a console-like level of control (or better) over the PC market. That level of control is proven to generate very high quality, high reliability stuff. Do you think this scenerio would be a good thing?
What if we turned the knob the other way? Dozens of Baby Bill Co.'s each write their own tiny fraction. Baby Bill Co. #34 writes the code for the IDirect3DLight interface, Baby Bill Co. #35 writes the code for IDirect3DExecuteBuffer, Baby Bill Co. #36 writes..., etc. Would that be a good thing?
My opinion is that the answers to the STRONG questions are no, no, and no.
Microsoft has demonstrated (Java) and continues to demonstrate (Kerberos) that the price for allowing them bring standards and interoperability to the PC market is strict Microsoft control over implementations of said standards. One of the primary sources of Microsoft's desire to innovate is the desire to "de-commoditize" standards (Halloween docs). So, I think it is fair to say that the more control MS gains, the less they will motivated to innovate. And so I think it is appropriate for the knob to be turned down a notch or two on Microsoft.
Dealing with variations in standard implementations and getting people to play nice together, insofar as standard implementations go, IS a problem, but Microsoft domination and lock-down of those standards is not the answer.
I was rather surprised when I realized that DeltaForce 2, which requires DirectX to run, ran under WINE. It slowly sunk in that Direct3D support had been implemented using mesa (OpenGL). But it's using unaccelerated OpenGL -- I have a Voodoo3 3000. I would very much love to be able to use my Voodoo3 to accelerate Direct3D games under Linux.
Try an strace. e.g.:
strace -f -o outputfile.txt whatever_the_binary_is_called
Then look at outputfile.txt
This will show you all the system calls (like requests to open files.) It is normal to see some errors opening files as anytime the binary is searching the path it will try to open files that are not there. This may give you a hint as to what is going on.
My hangup, BTW, was Hexen II. It was a great game with great artistry, but I made the "desktop jump" and nuked my Win95 partition in 1996 and although I can't say I never missed it, I can say that I've never had any regrets.
-Steve Bergman
Well, companies /have/ done this -- there are plenty of "Game OSes" which live inside the various console boxes ...
... the reason that people boot into Windows for games is support for direct video access which some games have atrophied themselves into requiring (snide, I know, you could say "intelligently take advantage of" too;) ) and support for cool input devices. Not to mention, low-level OS trickery aside, there simply aren't (nearly) as many games for Linux.
... =) That would be cool. I'd like one.
But the chief characteristic that they have is that they are closed. Not that the code has to be closed, but that they have to be very conservative in changes, to preserve compatibility. The game designers whose games would have to work in such a system need assurance that libraries won't change tomorrow, that the same video drivers will work on any card (or a predictable, finite set of drivers all of which could be included), and that all the device inputs they'll need are all accounted for, or that there is a generalized input mechanism to account for new ones. (Which all could be taken into account in your proposed game OS, don't get me wrong!)
Joysticks, flight panels, driving-game pedals / shifters
Maybe the Indrema will make a bigger splash than I picture it making
On the other hand, for the reasons I named (compatibility, assurance of conservative change), might FreeBSD be a better choice than gnulinux?
Sincerely,
timothy
p.s. OK, I admit it -- I'm not much of a gamer, certainly no developer, and I don't boot into Windows to play games. I have no moral ground to stand on. This is all speculation. But is it right?
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
I must say I find it difficult do disagree with him on this. In the early days of D3D there was heavy contention between OpenGL and D3D, I myself was very vocal on the side of OpenGL. OpenGL has barely moved forward in the intervening years whereas D3D has developed at an alarming rate. OpenGL support for the full range of features available on different graphics cards is limited at best whereas D3D has done a pretty good job of keeping up (although there are some nasty sides to the yearly release of the API).
Now I know I'm going to get flamed for saying anything pro a Microsoft api, and the first comment is going to be 'But Id software don't have a problem'. The largest benefit with openGL is that the specification defines exactly how every thing gets done, if the hardware can't do something it gets done in software, this unfortunately is also it's down falling. ID software don't have a problem, whenever they are about to release a big-name title all the card vendors run around making sure there drivers are optimally configured for the feature set ID is using. If you're a smaller developer, things work differently, the vendors are not as concerned with you and basically you have to limit yourself to using the features that the big-boys have already used. With D3D the situation is different, you are no longer shielded from the differences between cards but this can be used to your advantage, using once set of optimal features to achieve an affect on one card and another set on another (or a simpler effect).
The ironic situation here is that (Microsoft proprietary) D3D API is providing the smaller developer with a far more free development platform than the open OpenGL.
A PC (including Macs, workstations of various stripes, etc.) is a general purpose computing device; what would be the point in specializing one to run games? The gaming console is designed to that end and does it pretty well (except for the lousy resolution).
Have you EVER tried mixing thise "clone" pc's you talk about? Have you ever seen the inside of a COMPAQ? They're not a clone. You can't replace the motherboard on 99% of them because they're proprietary. DO YOUR HOMEWORK before you preach to me about CLONES and this and that.
a COMPUTER is not defined as a PC CLONE, where in the world is that misnomer coming from?
I don't think SUN calls there workstations PC's and IBM had nothing to do with there creation, the market demanded a workstation and sun provided. Sure the 'clone' market exploded, but it exploded around a common software packag called DOS and then Windows and Then whatever it is today. ITs because people chose DOS and chose windows and chose whatever they want to run.
Please, get your head out of your ass and look around. Standards are just one group or one persons concept of anything. Microsoft has Microsoft Standards and maybe YOU don't agree with it, but don't give me the shpeel on how having 2000 variants can be anything good for the industry.
Should we sue telephone companies because we can't run our own protocols or signals on the network? Should we sue cable companies because they choose what we get to watch? Should we sue cars because they put the stereo to high or two low? The world would be boring if evertthing was standardized.
Innovation is NOT conformity people
IF you claim that opengl is better, then please give some examples. All I know is that under Unreal tournment, directx is faster on my geforce 256.
Out of that whole message, this was the only thing I could even comprehend, so I'll address it. OpenGL is better for people who want a portable, robust API, that doesn't change every six months. It's not the only API out there, and it may not be the best for everyone.
And I repeat, there is nothing about an API that would make one faster or slower than another. An API is just a specification.
If a game is faster in D3D than in OpenGL on the same hardware, then this is almost always due to the fact that the game did not make better use of the OpenGL API, and has nothing to do with the illusion that one API is faster than another.
I used to live for "The Glorious Meept!!"'s posts but I haven't seen him since the user names went into action--I thought he had disappeared completely. Thanks for pointing this post out!
Smiley face not withstanding, Wolfenstein 3D was here before 3dfx. I'd say Wolfenstein 3D started the whole gaming era as we know it.
Once again, it was a creative programmer that made it all possible. Originality is the key here, not wiz-bang hardware. You probably wouldn't care about 3dfx if there weren't certain Wolfenstien derivatives (like Quake).
----------
Stupid sexy Flanders.
This post is full of inaccuracies. It is clear that this post is either a troll or the poster has never done significant development under either D3D or OpenGL.
Did anyone else find this claim of Tim's surreal? Microsoft *broke*
so many existing, widely adopted industry standards (like TCP!) when
they suddenly decided they needed to get in on the internet game.
The definition of "emulator" has a slippery slope: NES virtual machines emulate the NES binary interface. Java virtual machines emulate the Java binary interface. Linux emulates the UNIX® source interface (most of POSIX® and much of the Single UNIX Spec). XFree86 "emulates" the X11 source interface. GTK+ emulates the GTK+ source interface. So you're saying an emulator is any program that exposes APIs, that all libraries are emulators?
Will I retire or break 10K?
Last I checked Carmack was still keeping everything nice and cross-platform anyway, right? Quake 3: Arena with it's milestone parametric surfaces in a commercial product is the real technical innovator. With more to come in it's successor which will be available to the honestly commercially negligible Linux and Mac gaming communities, I'm really not understanding why people are getting so bent out of shape about this. MS did something right - in a corporation so broad and fear-inducingly all-encompassing do we dare paint everything as 'evil' regardless of actual merit? I would hope for more objectivity from the idealistic opensource/free speech community than that! Complain about shoddy work, and let good work from your competition inspire you to outpace them for everyone's benefit.
--Ryv
I have never understood why no one has developed a game OS. A game company could put a boot loader on a CD and the end user could put the cd in and boot from it and play the game. This could be done with GNU/Linux. If someone made a distro of Linux that was for games only. For years I have not understood why this has not happened yet. I though of this back in 91/92.
The above is not worth reading.
There's a portable wrapper around much of DirectX. It's called Allegro. It supports nearly everything popular that runs on x86 (DOS, Windows, GNU/Linux, BeOS) and other hardware (the X11 version supports linux-ppc, Slolaris, HockeyPUX, AIX and Pains, etc.) but does not support Mac OS because none of the developers has a Mac to code on. And there are lots of games written for Allegro, including all of mine.
Will I retire or break 10K?
It's called Windows CE, and it powers some Sega Dreamcast games (mostly PC ports) and will power most Xbox games.
Will I retire or break 10K?
"3dfx VooDoo 5 6000 just BLOWS AWAY nVidia GeForce 2 according to early sightings"
So? The X-box won't be using the GeForce 2. The X-Box will be using a custom NVidia chip based on NVidia's next generation architecture. The GeForce 2 is also available NOW, at a price of $349.95 USD. The Voodoo 5 6000 will sell for $600. The Voodoo 5 6000 is also not yet available. There is not even an estimate for a release date because 3DFX is having trouble getting it to work.
The processor will still be much faster than the CPU of any other console on the market. It will only have to run at low resolutions of television screens (Just because it is HDTV compatible doesn't mean it can run those kind of resolutions.).
Like it or not, the X-Box will still be the fastest performing console available when it is released in Q4 2001.
I bought Unreal for the Mac, and was thouroughly disappointed by the difficulty of ever playing a networked game.
The two releases (PC and Mac), where constantly out incompatible.
So personally, I don't care what they do with it :)
Winton
A number of people (including myself) started boycotting them when they released a linux server but no client for Unreal. Linux was a good enough OS to run their server, but not good enough to run their client. Why would I run a game server for a game I can't play? Why would I purcha$e a game just to serve it, and never play it? I felt a bit insulted by that whole deal. So, even when they made "amends" with a Linux port for UT, it was too late. Yes, it may be silly, but I can and will hold a grudge. Plus, it's not as if they are the only game in town. I still manage to spend too much time playing their competitors games. If they don't choose to look at the potential future of Linux, it's their own foot they're shooting....my money will just go to their compititon.
I find Tim's comments deeply ironic.
What did the world do before Microsoft invented the 3D acceleration API? Umm. We got along fairly well with OpenGL thank you. OpenGL would undoubtedly be in a better position today had Microsoft chosen to cooperate with all the other OS vendors to make OpenGL the single viable API.
What did the world do before Microsoft invented the TCP/IP stack? Dunno about the rest of you, but I was pretty happy with BSD sockets. The real question is why it took so damned long for Microsoft to put that functionality into their OS. Oh wait. I know why - they were busy maintaining their monopoly through slash-and-burn acquisitions, exclusive OEM licensing agreements, glossy marketing, and back-stabbing short-lived 'alliances' with other companies.
Paul.
For those of us who don't follow this sort of thing, wine already does a fair chunk of DirectX, including Direct3d. If you want to play Windows games, go help wine.
"Please don't sigh like that, maam"
Microsoft fixed that with Windows 95's built-in TCP/IP.
The government's proposal would basically shackle Microsoft and prevent them from adding new features of that sort to the OS
(on that networking was bad under DOS but works fine on Win95+)
Breaking up Microsoft into one OS vendor and one Applications company won't prevent Microsoft from adding stuff like TCP/IP or DirectX to it's OS! They're OS components, I don't think anyone would claim they're applications in the normal thoughts of the user (or the DOJ, surely).
Linux and Mac will have to push OpenGL over DirectX - I'd say that's quite reasonable. At least it's not as bad as Glide ...
it's in my head
Although this is an obvious troll, I'd still like to address these points, because a lot of people posting here seem to be clueless on some of these issues:
We are not talking about D3D 3.0 anymore. 7.0 is here, and its not your mother's pansy-ass D3D anymore. It's as fast as OpenGL, and blows it away in features and power.
This sounds more like market-speak than any kind of statement based in fact. Can you provide some examples of how an API can be fast and/or powerful?
OpenGL used to be safe in the knowledge, that as much support as D3D could get, it was still king in terms of features. Not anymore. These days there are a host of features that the D3D programmer has direct access to, but is not directly accessible from the OpenGL API.
Tell you what... For every "feature" you can find that cannot be implemented as an OpenGL extension, I'll list one that isn't in D3D... Go on, I'm waiting...
OpenGL is does not have the speed advantage anymore.
Well there goes all your credibility. Please explain again, how an API can be faster or slower than another one. An API is just an interface. Some vendors' implementations may differ in speed, but there is nothing about the API that specifies a speed difference.
The OpenGL API is not powerful enough. It does not give you enough low-level access.
You're programming down to the vertex on both API's. How much lower do you want to go, and still be able to run on all hardware?
OpenGL is not extenible. Sure there are OpenGL extensions, but they are silly compared to the ones in D3D.
They're silly... Another statement based in fact I see...
Yea thats right everyone.. Just a troll.. move along.. nothing to see here..
Flamebait? I think a moderator needs a lesson in reality. There would be an incredible amount of animosity towards a project to implement Direct3D under Linux. Never mind the fact that Microsoft has exactly as much right as SGI to promote a 3D API.
--
Sometimes it's best to just let stupid people be stupid.
It's clear both API's will be around for a while, so why not learn to live with them both?
Only the most hard-core pundits are going to make this out to be some kind of war between API's. They both have their advantages and disadvantages--and as programmers, we can choose which one suits our needs best.
Those who want a portable and robust API will choose OpenGL, and those who want to be able to run with the latest hardware and take advantage of Windows-only features, can choose D3D.
They both have their drawbacks too. It's unfortunate that OpenGL's review process takes so long to specify new features, just as it is unfortunate that D3D changes with each version at MS's whim. As a programmer you just have to decide which drawbacks you can live with.
The Justice dept must force M$ as part of their punishment to open up the Win32 APIs & DirectX3D APIs to a multi-million dollar trust funded by M$ so the Win32 APIs can be used to make (independently tested) post Beta ports of Wine for MacOSX, BeOS5, Linux & the other nixes. Also the DirectX3D APIs must also be ported to the above mentioned platforms (also funded by the M$ punitive punishment trust). M$ must also be force to make (independently tested) ports of all their future apps to MacOSX, BeOS & Linux, before they can make the Win32 ports of the same app avaliable. Also they should be boxed together on the same CDs (like the way ClarisWorks have both the Mac Port & the Win32 port on the same CD & Beos comes boxed with both the PPC port & the X86 port in it) - to minimise stockage/shipping/ordering/sales confusion. This may encourage M$ to make future versions of Windows POSIX complient, to aid portability - which should make it easier for other developers to cross port their apps too. Really splitting up M$ will acheive buggerall, & if the 'baby bills' were to actually compete against each other, all that would happen, would be that all the other alternatives would be coaught in the crossfire & end up collateral damage.
I'd really like to see what Tim's opinion would be if MS decided to release a 3d game engine with Windows as one of the people in the forum said. Let's see if he is as sympathetic to MS's cause when it is his company on the line.
Oh, and if DirectX is such a superior gaming platform then what about Unreal Tourney for Linux and Mac? Maybe I'm just a conspiracy theorist, but it seems as though maybe Bill has thrown a little money Tim's way to cause a complete 180 in the company's direction, no?
The real-time virtual reality visualisation, of the type used for simulation etc, is much different to games in what sense?
Both try to convey a air of realism to the user.
The only way that OpenGL standards in any way might not make them suitable for games is that an OpenGL compliant driver must produce a minimum level of quality ie. some speed hacks are not allowed if they impair the visual quality.
The many demo games that ship as part of Irix should show that SGI for one have always used OpenGL for games.
So, how is OpenGL falling behind the times? What does D3D provide which OpenGL doesn't.
...................
...................
...................
So the second system to implement an API is the emulator?
Are you being obtuse on purpose, or were you born that way? Read what I flippin' wrote.
All X11 servers but the first implementation (incl. XF86) are emulators, right?
X11 servers are generally implementing the X11 protocol standard, not trying to act like the original X server implementation. In fact, many of them -- including XFree -- use the same code.
And all Java VMs other than the first are emulators, right?
I suppose that depends on Java's status this week -- is it a standard, or a product owned by Sun?
And the GNU system is a UNIX® system emulator, right?
That was how it started, after all. RMS wanted a Unix system without the Unix license problems.
Microsoft IIS is an NCSA-httpd (now Apache Server) emulator?
Well, I can't speak for Microsoft. Are they trying to be NCSA HTTPD all over again, or are they trying to implement the HTTP standard? (Or, more likely in MSFT's case, embrace and extend the standard?)
If a project is trying to implement a standard, then I wouldn't call that an emulation. They are starting from scratch and creating something that meets an abstract specification.
But, if a project sets out with the goal of implementing something which acts just like another product, then they are building an emulator, by definition. Emuate means "act like".
Is that clear enough for you, or do I need diagrams?
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
????
I thought the T&L engine in GeForce is what SGI terms a geometry engine ie. a matrix cruncher to take the load away from the main CPU. What extensions does this put into OpenGL?
Of course MS is going to give game developers more input into their API. With the release of the xbox MS is going to court as many game developers as possible. But just wait a year or so down the road when these developers have abandoned all other platforms and are dependant on MS they will stick them with outrageous licensing fees or make them somehow pay through the nose to use d3d just like they've done so many times before.
It's kind of offtopic, but if somebody could answer this question for me I would be able to get totally rid of my win98 partition.
.unr files locaed under Maps/)
How come Unreal Tournament under linux can't find the maps for the game (you know, those
Everything has been installed properly (over a thousand times). The different patches don't do anything better and it pisses me off.
If you have had the same issue, and you fixed it, I would be extremelly pleased if you could tell me how you made it to work.
Thanks for advance.
dudle
Looking for a great online backup: Green Backup
They may not be intersted in developing for Linux and Mac directly, but does this mean they are not interested in providing support for OpenUT and and other pseudo OSS projects? I hope they don't decide to just grab the cash and run, since the thing that makes PC games stand out is that they are open to enhancemnets and add-ons unlike console games.
You don't think that Windows 98 pretty much meets the criteria? It always has the latest and greatest Microsoft gaming API and best driver support, and is backwards compatible with 20 years of DOS games.
On the other hand it's too unstable for even 8 hrs/day of regular work, has no security or other wasteful 'overhead' features, and so on. It's even explicity marketed as a low-end home OS versus Windows NT.
--
Business. Numbers. Money. People. Computer World.
I experience serious video problems with WINE
After three or four bottles things are really out of focus
134340: I am not a number. I am a free planet!
1) The PE (Personal Edition) is free!
2) It can be setup in a file in a Windoze partition. Double click the icon, you reboot into BeOS.
3) Speed. This is where it blows everything else away. Can any other OS claim a boot time of 10 seconds?
4) Ease of use. A dummy could use it.
5) Speed. So fast, there is no wait cursor.
6) its POSIX compliant
7) Have I mentioned its fast yet?
Well, enough of my ranting, at this point the websites do a much better job. check out http://free.be.com to download it / get more info / whatever.
Long Live Be!
Linux is only free if your time is of no value
Be in Your Senses
D3D's not very good on WINE yet (it's only around DX3 level), but OpenGL support is in current CVS now (look for it in the next release). If you have a XFree86 4.0 supported OpenGL card it plays Half-Life in OpenGL mode (quite fast on my TNT2 even). Gaming on Linux is gonna get even more interesting as we go I think :)
Mesa cannot legally call itself an implementation of OpenGL, because it has not taken SGI's hideously expensive testing process. Pretty much everyone agrees that it's "close enough" (even SGI) so this is more a semantic point than anything else. But stupid as it is, that's enough to scare away some businesses.
All of that sounds really nice, but it still misses the fact that for raw processing power, the X-box will still be the fastest console out there. Sure the PS2 might have a zillion extra little things that developers with lots of time and money can exploit, but only if they see fit to do so. The RDRAM is nice, but only if it gets used.
The big advantage to the X-box is a static architecture that presents easy ports, and is familiar to many game developers already, versus the PS2 which is a new world for the brave (apologies to A. Huxley for that one). A designer already good with X86 programming can do all kinds of wonderful stuff if he only has to work on one system. The big reason games today are still often far less pretty than we would like is that they cannot be optimized for any specific machine, whereas with the X-box developers can tweak to their hearts' content without having to worry about a tweak that works well on an N-Vidia chip killing performance on a chip from S3.
Don't assume I am just a rabid NVidia/X-Box fan. I don't really give a damn who wins the console/3D wars aslong as the games are good. I am just point out the obvious facts, that the X-Box is going to be able to do more than any other console out at the same time, which it rightfully should be given that it is to be released almost 2 years after the PS2 (remember, PS2 debuted much earlier in Japan than it will in the US).
Let me preface this with saying that standard APIs are definatley the most desirable solution, and that I have very little experience in developing OpenGL software. However, there is a problem with how slowly standards tend to evolve. When you have a mature standard such as POSIX or TCP/IP it's much easier to develop to the standard and still put in all the features and performance that your market desires.
Gaming hardware and software is evolving at an amazing rate right now, and deciding standards by committee isn't usually a quick process. You also have the problems of people on the standards committee having conflicting goals. 3dfx may have some feature that no one else has, and want support for it integrated into OpenGL as quickly as possible. Other compainies are going to have other priorities, and feel that 3dfx's feature is just slowing down the implementation of the features they think are improtant.
There are also companies that are unwilling to put their technology into an open standard such as OpenGL. Those same companies may be willing to lisence their technology to Microsoft to put it in DirectX.
Standards like OpenGL are also very succeptable to feature bloat. You get the I'll vote for your feature if you vote for my feature syndrome going, and you end up with a standard which includes so many features that no one can really implement them in drivers.
Microsoft's method of unilaterally creating DirectX can allow them to more quickly add features which take advantage of new technologies. Because it's a closed standard, they can also start working with hardware vendors to add new features under NDA. This allows Microsoft to get a head start on implementing new features, and allows the hardware vendor to wait to announce new features and not tip their hands to their competitors.
If you goal is protability, then standards are the way to go. If your goal is to get the newest features out to your customers, and you're willing to accept that your customer base will be smaller, then a propriatary API may be a reasonable choice.
They still seem like a Linux friendly company ( Epic, NOT GT Games). Hopefully Loki could work with Epic to port games like they already did with the D3D only Heavy Gear II (excellent port to opengl) and like they did with Quake3 for id. I have purchased two copies of UT and like it very much. If Epic is listening, then please don't cut off the Linux community. We do play and pay for your games.
Kindness is the language which the deaf can hear and the blind can see. - Mark Twain
I find it amazing that people continue to give SUN grief, especially over Java.
...
Java is platform independant. The standard does not contain what you want? Write it yourself! It should work on other Java platforms.
Examples of what Sun has done in the past:
1. Significantly improved UNIX, feeding the improvements back into SVR4.
2. Developed RPC and NFS, then gave them away as open standards.
3. Developed the SPARC processor, then openly licensed the architecture. SPARC is now independant of Sun.
4. Drove the workstation market closer and closer to PCs in terms of price. Still not there yet, due to the sheer volume of the PC market (economies of scale, and all that.)
5. OpenFirmware. Plug in that card. No drivers yet for the OS? No problem, just use the built in openfirmware drivers. No processor dependancies. Cool.
Now, let's look at what microsoft have contributed to the computer industry:
1. Erm, EMS, to allow DOS users to use more than 640k RAM! Wow, fancy that on a 1Meg+ machine.
2. Microsoft mouse protocol, which, erm, allows for only two button mice.
3. Microsoft Office, with it's open, documented file formats. No wait
4. (Scratch head,) Yeah, the internet. Didn't Win95 bring this previously out of reach inter-network of computers within reach of the common user?
5. Windows Terminal Server. Now several users can use a single machine at once. Fancy that.
And? Heavy Gear II was ported to Linux from a Direct3D-only game to OpenGL. Sure it took some work, but Loki did it and it looks awesome. I'd highly recommend it to anyone looking for some new gaming action.
For all those that want to rag on Glide, keep in mind which of the 3 APIs are fastest, free, and work best under Linux. Okay, so you can play Quake 3 under Linux with your Nvidia. I can play everything and faster at that with my Voodoo X. Suck it.
Interested in open source engine management for your Subaru?
Although this is an obvious troll, I'd still like to address these points, because a lot of people posting here seem to be clueless on some of these issues:
>>
Nope, not trolling.
This sounds more like market-speak than any kind of statement based in fact. Can you provide some examples of how an API can be fast and/or powerful?
>> I was just trying to be poetic. Geez, nerds. APIs can be faster or slower than others based on how effectivly it allows access to hardware and how effectivly it manages resources. Take early versions of Direct3D. They were the reason that D3D got a bad name. An engine implemented in D3D and equally optimized as one implemented in OpenGL would lose very significantly in the D3D case. Back around D3D 3 or 5, a glide or OpenGL game would run upwards of 40% faster than the same engine using a D3D renderer. In current implementations, however, the pipeline has been streamlined, the whole thing has been nearly rewritten, and provides much better access to hardware.
Tell you what... For every "feature" you can find that cannot be implemented as an OpenGL extension, I'll list one that isn't in D3D... Go on, I'm waiting...
>>>>>>>>>>
Did you not read my entire post before answering? I say that extensions suck. They are not evenly implemented and the developer has to be constantly aware of which ones he is using. I can easily (relativly) write an engine that uses every features in D3D. Now no matter what graphics card I'm using, my app will run, with D3D smoothing over hardware differences. In OpenGL, I have to use extensions, and for a lot of the cutting edge features (like the ones that nvidia is exposing as OpenGL extensions) are not ARB or EXT extensions, and in that case I have to write seperate code for each card I want to support. Eg. If I use the skinning support in DirectX 8.0, my game will automatically take advantage of both the GeForce 2 and the Radeon. In OpenGL, I would have to use both the NV skinning extension and the ATI skinning extension. Do you think the ARB is going to be able to keep up with a market where major hardware changes happen in 6 months? Hell no.
OpenGL is does not have the speed advantage anymore.
Well there goes all your credibility. Please explain again, how an API can be faster or slower than another one. An API is just an interface. Some vendors' implementations may differ in speed, but there is nothing about the API that specifies a speed difference.
>>>>>>>>>
API's can be fast or slow. Have you ever implemented an API before? Take hypothetical API X and Y. To change the color in X, I have to create a color object, register it with the server, then activate the color change. In Y, I send three color components to activate the color change. Which do you think will be faster?
You're programming down to the vertex on both API's. How much lower do you want to go, and still be able to run on all hardware?
>>>>>>>>
That's not my point. The vertex level is entirly irrelevant to what I'm talking about. In OpenGL, you have an abstract access to color, depth, etc buffers, vertex buffers, and hardware resources. In D3D, you have direct access to these. You can create hardware buffers, vertex buffers, etc. Hell, you even have direct access to what textures are uploaded to the card! None of this glPrioritizeTextures crap. Case in point, in D3D, you can render directly to a secondary hardware buffer, let's see OpenGL do that!
They're silly... Another statement based in fact I see...
>>>
Did you bother to read the last half of the post??!!! I go through point by point on why GL extensions are silly! They aren't implemented fast enough to keep pace with the evolution of consumer hardware, and they aren't implemented evenly/they aren't emulated when not implemented.
A deep unwavering belief is a sure sign you're missing something...
Wine seems to emulate Direct3D quite OK -- AFAIK, Unreal (not Tournament) for Windows runs on it in Direct3D mode. I guess it should be quite possible to link future Unreal games to WineLib.
Almost everybody knows that hardcore gamers use Windows. Do you think hardcore gamers fiddle around with an experimental Operating System? No, they play games.
Maybe you'd better come outta that cloud.
The basis of the government's case (at least part of it) is that, in their opinion, a web browser cannot be part of an OS.
That's just plain wrong.
The basis of the government's case is that, according to US law, a monopoly cannot use their monopoly power to further their own products. It doesn't matter what Microsoft is trying to bundle with Windows; what matters is the fact that they are a monopoly. If you are a monopoly, you have to tread carefully, or your monopoly will be taken away -- forcefully. That's the law, and for good reason.
Why is that so hard for people to understand?
I'm glossing over the legal issues, partly because they're complicated and partly because I don't know them all, but please accept my rough interpretation of the case.
I am sorry, but I cannot accept an interpretation that is fundamentally flawed.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Berlin, AFAIK aims at EMULATING X11: because its main purpose is not to implement X11, it will implement X11 on top of another API. That's emulation.
Personally, I wouldn't call that an emulation, per se. I would call it a X server implemented for the Berlin platform (similar to the XFree port for OS/2). But that is starting to split hairs; if you want to call Berlin's X support "emulation", I won't argue with you.
WINE, however, allows to run Windows programs on Linux. Linux is not meant to be a Windows implementation.
True, but I never claimed that Wine made Linux a Windows emulator; I claimed Wine itself is a Windows emulator.
WINE is Not A [CPU/Machine Code/Virtual Machine] Emulator.
But it is an OS emulator.
BTW, "Wine" originally stood for "Windows Emulator". The change to the recursive acronym came later. I suspect the reasons were:
Emulating -- acting like -- Windows could be interpreted to mean crashing a lot, and they wanted to avoid that.
A lot of people seem to think that "Windows Emulator" also means "i386 Emulator", which Wine most explicitly is not.
Recursive acronyms are fun.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Yep, you heard it here first. OpenGL is losing the 3D API war to Direct3D. Heresy, you say, but hear me out.
A) We are not talking about D3D 3.0 anymore. 7.0 is here, and its not your mother's pansy-ass D3D anymore. It's as fast as OpenGL, and blows it away in features and power.
B) OpenGL used to be safe in the knowledge, that as much support as D3D could get, it was still king in terms of features. Not anymore. These days there are a host of features that the D3D programmer has direct access to, but is not directly accessible from the OpenGL API.
C) OpenGL is does not have the speed advantage anymore. D3D has evolved to the point where it is just as fast as OpenGL, if not faster (depending ont he OpenGL ICD being used.)
There are many reasons why OpenGL is falling behind, but I'll highlight the main ones.
1) The OpenGL API is not powerful enough. It does not give you enough low-level access. When I first learned OpenGL, I was shocked to see that I had no control of hardware resources. I was used to DirectX and allocating and deallocating hardware buffers left and right. Nope, OpenGL didn't let me have any fun with that stuff. Even more shocking was that it had no concept of a vertex buffer. Sure, it would let you use the glVertexPtr command to select an array, but graphcis cards cannot optimize that properly because the data can change between calls to glVertexPtr. D3D offerers a host of low level features dealing with buffers and the like to allow you to wring as much performance as possible out of the hardware.
2) OpenGL is not extenible. Sure there are OpenGL extensions, but they are silly compared to the ones in D3D. There are many problems with extensions... First, they take forever to pass as an ARB or EXT extensions. Second, even then they are not implemented on all ICDs. Take a look at the MS software renderer. No compiled vertex arrays or multitexturing for you. Third, they are not emulated when they are not implemented. You have to have seperate code paths for each combination of extensions you may require. In D3D, I can turn on a new feature confident in the fact that if the feature is not supported in hardware, it will be emulated. Eventually, all hardware will accelerate the feature and my app will automatically take advantage of it. No such thing for GL apps. The extension problem is going to reach a watershed as the new graphics accelerators come out with all these hardware features. Take the new accelerators that accelerate skinning or keyframing. MS will just make a keyframer COM object, and you can use the functions in that. If hardware accelerated keyframing is not available, then it will be emulated by D3D. In OpenGL, get ready for glKeyFramerATI and glKeyFramerNV and glKeyFramerS3, ad nauseum, or not glKeyFramer at all! Then you have more extensions for stuff liek texture compression. In D3D just, set call some functions in the texture object.
Despite all this, I still use OpenGL. Why? Because though I prefer the COM-based approach of D3D, and I like the low level control, and I like advanced rendering features, I hate windows, and I like BeOS. All that BeOS (and Linux, and QNX, etc) supports is OpenGL. I think that OpenGL needs a major overhaul in version 2. OpenML is coming out to compete with the rest of DirectX, but can OpenGL be updated to compete with Direct3D? The shoe is on the other foot now.
A deep unwavering belief is a sure sign you're missing something...
I've been picking up a little bit of OpenGL, and it seems to me to be an exceedingly well-thought-out, clean, and consistent API. Certainly better than the small amount of Win16/32, and the rather larger amount of DOS, programming I did. Admittedly, I haven't done any DirectX programming; maybe Microsoft has designed an uncharacteristically decent interface, but anyway:
What is wrong with GL?
Daniel
Hurry up and jump on the individualist bandwagon!
Ok, I agree with that...lots of different people can lead to compatiblity problems. This doesn't mean that they can't be overcome, but problems can and do occur. But then...
Jigga-What?!? Ok, this is were he losses me. First, isn't MS in trouble for exactly that...forcing software makers to do things that MS wanted them to do? What about choosing standards based on technical merit...you know, robustness, interoperability, that sort of thing...instead of standards based on their ability to tie developers to a single platform?
What ever happened to Open Standards? You know, like the ones used to build the Internet and make email work? Again, I'm no expert, but they seem to work pretty well. Don't look now, but your soaking in them! I realize some of the Open Standards may not have developed as quickly or as well as some of the MS 'standards', but how much of that was due to MS marketing muscle?
I'm not trying to bash MS or Tim Sweeney, but I don't know that dominating a market can be compared to 'setting standards'. If there's something I'm overlooking, someone please fill me in.
I'm sorry, but I don't understand why no more games by Epic for Linux is a bad thing? Maybe I missed something, but I'm sure the games sucked arse to begin with...
----------------------------
--Loco3KGT
--elguapo.penguinpowered.com
----------------------------
Blessed be he who reads this post, Cursed be he who tells my boss.
Ok, I've programming in OpenGL for awhile and DirectX 7/8. OpenGL is great and all, as long as you're running on nVidia hardware. All other drivers just suck. To take advantage of stuff like hardware T&L you have to use OpenGL extensions. Even with the nVidia OpenGL driver this is kinda rough. You have to manage a chunk of AGP memory that can be accessed directory by the hardware with vertex data and what not to be streamed in without processor intervention. In DirectX and it's buffers all this is handled under the hood. I'm targetting XBox specs with my project (~150 M sustained, lit, transformed poly/sec) which can only be done with serious hardware T&L. Then you use something not nVidia. Great DirectX support, mediocre to suck-ass OpenGL support. Go with DirectX you get Dreamcast, PCs, and XBox. Go with OpenGL you get nVidia on a couple OSes... The linux market is no where as large as those consoles. I'm writing code to be as portable as possible with plug-in rendering engines, but it's a lot of work and maintence. The target is all platforms, PC, console or appliance with an internet connection and 3D capabilities, but it's a tremendous amount of effort to support everything and the smallest market share gets lowest priority (Linux).
Ryan Earl
Student of Computer Science
University of Texas
This move really surprises me, but maybe it shouldn't.
The way I see it, one of Epic's ways of bringing in cash is through liscensing out the Unreal engine. Not too surprising, since it is fairly extensible. But I'm not sure that going DirectX-only is a good way to attract potential liscensees, as it at least appears to cut down on the versatility of the engine.
So you're saying an emulator is any program that exposes APIs, that all libraries are emulators?
No, I'm not, and that should be obvious. Check my previous post, and you'll see the formal definition of what I'm saying an emulator is, namely, that which emulates (tries to act like, but is not) an origial product.
Don't be obtuse.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Yes but the use of DRI is transparent to an application programmer. DRI is an OpenGL driver interface, not an application interface. You call the same OpenGL libraries with the same API whether you are using XFree 3.3.X without DRI, or XFree 4.0 with DRI. The difference is that in one case they go through the X library pipeline, and in another case they go directly to the hardware.
This is why, as someone else mentioned, you can run the same Quake 3 binary on a system with XFree 3.3 or XFree 4.0, you just get the DRI speedups in the latter case. The Windows OpenGL implementations already go directly to the hardware. Depending on your point of view, Windows either already uses an X DRI equivalent, or it just doesn't need one. The same OpenGL API calls still work in Windows, it's the other OS API calls that have to be converted.
Of course the only way you can get Windows to do realtime networked 3-D rendering by the application that's running on the massively-parallel supercomputer is by designing your own 3D network protocol or by buying an X $erver with GLX extensions.
Laissez lire, et laissez danser; ces deux amusements ne feront jamais de mal au monde. - Voltaire
Might want to check your keyboard. Seems every place you type an S, a Z comes out instead. Or are you just a 13 year old fuckface?
I agree. DRI is just appearing, and OpenGL on DRI should privide excellent performance.
3dfx VooDoo 5 6000 just BLOWS AWAY nVidia GeForce 2 according to early sightings, while Celeron II benchmarks shows that Intels decision to deliberately keep the 66MHz bus to slow it down was very effective!
So much for X-Box performance! A 600MHz PIII derived processor (i.e. Celeron II) and nVidia are already looking outdated before the box is even introduced!
VooDoo 5 6000 vs GeForce 2
Celeron II benchmarks
Now that two of the biggest Quake1 developer groups have joined. Maybe we can tell Epic to go die with microsoft, and play gpl'ed games instead.
And I remember the days when Windows didn't have one at all!
.oO0Oo.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter