Re:Off Topic: Linux Game Programming
on
Quake 1 GPL'ed
·
· Score: 2
If you've been programming for 10 years, just buy Steven's Advanced Programming in the Unix Environment to learn how to do basic OS stuff in unix, and get Computer Graphics, Principles and Practice, by Foley, van dam, et al. to learn how to do the graphics. Finally, the OpenGL redbook will round you out as far as graphics APIs go. For sound, go find the Open Sound System tutorial on the web.
That and some elbow grease (experimenting is the only way to learn) will have you writing games as quickly as is possible.
Your congresscritter hears about the patent office all the time, from the big companies giving them lots of money. Big companies suing each other like this is fairly rare, and they are willing to pay this price so they can continue to intimidate smaller companies from trying to compete with them.
Of course, there are good patents out there, for truely novel and inventive ideas, but they are more than drowned out in the sea of trivial and obvious patents on the legally unpatentable.
A combination of the patent office's willingness to patent anything, and the expense of fighting illegal patents, means that patents are an excellent method of preventing competition.
Even if every slashdotter wrote their congressperson, it would be lost in the noise of checks being written by large companies. Unfortunately, in the american political system, money speaks MUCH more loudly than constituants.
Win16 used handles pretty much exclusively to work around the extreme suckiness of the x86 real mode.
real mode isn't all bad though, with 256x256 textures, you can easily select the texture into ds, put the x coord into al, and the y into ah, and access [ds:ax] to get the pixel. Of course, this limited you to a single digit number of textures, but it was pretty fast to do affine texture mapping on 286s
All the apps I usually run are easily compiled for pretty much any common CPU. I would much rather have a CPU that ran one ISA lightning fast, rather than one that could run many ISAs but slower.
Perhaps if you have apps for other architectures that you want to run often the tradeoff would be different, but I am not willing to trade off a slowdown of the common case to speed up a very rare case.
1) You completely misunderstood what I said. There are tons of tradeoffs in CPU design, and lots of ISAs is fine with me. The point was, if I have the source, I can recompile for whatever I happen to use. A transmeta style CPU will of course never run a given ISA as fast as a CPU tweaked out to run one that specific one.
2) How many mainframe apps would be useful to run on your desktop PC?
All of the programs I use regularly are open source. And as more and more open source apps come out, more people will be able to say that.
FreeMWare is publicly developed. Transmeta could at this point be preparing to skip the country, after having transfered all its VC to a country with favorable banking laws (not likely, but possible).
Who needs a dynamic ISA when we have open source? The silicon wasted on the added complexity in transmeta's CPU could have been better spent making its core ISA faster. Perhaps now people see why having the source code is useful even to you non-programmers out there.
Yes, if they can pull off a retargetablle CPU, it'll be a neat trick, but hopefully Open Source will take over, and we will be forever free of instruction set tyranny.
no, not at all. Transmeta doesn't have a product released, and probably won't for the immediate future (next few months). And we still don't know more than the sketchiest outlines of what their CPU does. And we're not even 100% sure of that.
Yes, but we write whatever we're interested in. So there is no point complaining about whatever new things we could be doing if we weren't reinventing commercial products.
Someone (Kevin) thought that a virtualized x86 would be a cool project, so they started working. If you'd like to email kevin@bochs.com and tell him that you think he should be doing something new instead, feel free, however, don't be surprised if you get flamed.
Evidently not. If you want to go beyond running OSes for the same hardware as you own, you must go to emulation techniques like BOCHS.
"This idea" refering to virtualization cannot be extended beyond running an OS for X on a X machine. If you want to run an OS for X on a Y machine, you need to emulate the CPU.
The patent stuff shouldn't be a problem. MERGE (for SCO) has been virtualizing x86 PCs for years before VMWare existed. One of two things happen: 1) we have prior art in MERGE. 2) VMWare patented a novel way of virtualization that MERGE does not use, in which case we use the unpatented MERGE method.
I can't understand why people seem to have such a problem paying for software that they will (most likely) use to run a commercial OS. How many people out there are using VMWare to run NetBSD in a window on thier linux box?
I'm not raggin on FreeMWare, because its extra cool (by virtue of the paper on PC hardware virtualization alone!) but I see the reasons to work on it as idealistism and features/extensibility, not price.
The place I really see potential for FreeMWare is a software ICE type system. A rich debugging environment attached to a virtual machine would make kernel hacking much easier and safer.
VMWare and FreeMWare both virtualize PC hardware. Code executes natively on the host CPU. Playstations, and your intelligent toaster probably do not use the same CPU as your host machine. And non x86 host machines will be unable to run the x86 versions of NT, Linux, or BeOS.
CPU emulation exists and can do all of the above, however, you don't get something for nothing. CPU emulation (see BOCHS, executor, etc) is incredibly slow in the naive case, and even with complex techniques such as dynamic recompilation, signifigantly slower than native code.
BSD style union mounts let you mount the CDROM as / and mount a harddrive "over" it, so that the files on the CDROM show up, but anything you write gets put on the harddrive. This could be workable, although CDROMs are not the fastest things in the world.
FreeBSD's SMP support is roughly similar to Linux 2.0.x's. Not too good unless you have two compute bound tasks. Once you start hitting the kernel, the BIG_ASS_LOCK is grabbed, and everything serializes.
Looks like crap? Its pretty obvious that you've made up your mind already about linux gaming, but you really should have tried it first. the G400 gl driver looks just as good as the windows one, and is faster. Its quite simple really. As for the multihead, unfortunatly, you'll have to wait for XF4 for that one, or run one of the 3.9 snapshots.
They plan to license the engine to other game compnaies. They simply will not open source it, because then their potential liscensees would simply download the source, develop their own game, and then release their own open sourced game with copyrighted graphics/story/etc. And Epic loses out on that revenue.
Tell that to the g[24]00 owners. Interesting to note that the linux GL driver that is faster than its windows counterpart is the one that's been Opensource the longest, and has the most documentation. And John Carmack helping out.
If matrox would release the programming info for the WARP engine, instead of just a binary file full of microcode, I'm sure things would get even faster.
Don't discount the G400 MAX as a gaming card for linux. Its no Geforce, but its quite respectable.
BeOS has much better APIs than linus for things like audio plugins, although Linux has gone from nothing to nearly catching up in under a year. I give Linux another 6 months max before it is way more compelling for audio applications than BeOS.
Video is a different matter entirely, due to patent issues, closed formats and NDAs, and I think this is really where Be will find their niche. Looks like we finally have a replacement for the amiga.
Oh come on. no one is demanding anything on a silver platter. Why would I pay for something, when I can get something I prefer for free?
The better API of BeOS doesn't quite make up for the fact that I can't get at the code. I'm not criticizing Be for being closed, its their code, and their choice, but its simply not worth the money when I can get something better thats free (in both senses of the word).
I can get Redhat for free from an ftp server. I can't (legally) do the same with BeOS.
Plus, my quick echo DSP code runs with lower latency under Linux with mingo's patch than under the "media os" BeOS. And if I want to be hardcore, I can use David Olofson's RT/Linux soundcard driver harness and have latency limited only by the PCI burst size.
if your game isn't heavily threaded, just compile it for glibc2.0. This will get you 95% or more of the market, since glibc2.1 can run glibc2.0 apps transparently. That last 5% of (OLD) slackware users can install the glibc package, using pkgadd. Trust me, anyone running an old version of slackware can handle that.
The linux is fragmented argument is only really valid for heavily multithreaded applications like mozilla.
>(It's actually a very good way to open source video games and still make some money.)
Epic's hope is that if UT is successful (and it looks like it will be) they can then licsense the engine out to other companies. If companies GPLed their engine and just sold the graphics and story, the other companies would just take the code and develop their own GPLed game, with their own graphics and story. Not so good for Epic.
>but other game companies cannot legally use the code without making arrangements with the UT poeple.
Unless the other game companies GPL their code. Which is only a matter of time for a game with a custom engine that isn't likely to be licensed. It would be a bad idea for id to GPL q3. For a game like myst or warcraft GPLing the code could very well work, since mose of the value is the art and story attached to it. These would still fall under copyright.
You do know that Linux loads executable pages from disk as they are used, so most of the code for the parts of the program you're not using isn't using up memory. Its called demand paging, and every decent OS designed in the modern era has it.
Slashdot Mirror
If you've been programming for 10 years, just buy Steven's Advanced Programming in the Unix Environment to learn how to do basic OS stuff in unix, and get Computer Graphics, Principles and Practice, by Foley, van dam, et al. to learn how to do the graphics. Finally, the OpenGL redbook will round you out as far as graphics APIs go. For sound, go find the Open Sound System tutorial on the web.
That and some elbow grease (experimenting is the only way to learn) will have you writing games as quickly as is possible.
Your congresscritter hears about the patent office all the time, from the big companies giving them lots of money. Big companies suing each other like this is fairly rare, and they are willing to pay this price so they can continue to intimidate smaller companies from trying to compete with them.
Of course, there are good patents out there, for truely novel and inventive ideas, but they are more than drowned out in the sea of trivial and obvious patents on the legally unpatentable.
A combination of the patent office's willingness to patent anything, and the expense of fighting illegal patents, means that patents are an excellent method of preventing competition.
Even if every slashdotter wrote their congressperson, it would be lost in the noise of checks being written by large companies. Unfortunately, in the american political system, money speaks MUCH more loudly than constituants.
Win16 used handles pretty much exclusively to work around the extreme suckiness of the x86 real mode.
real mode isn't all bad though, with 256x256 textures, you can easily select the texture into ds, put the x coord into al, and the y into ah, and access [ds:ax] to get the pixel. Of course, this limited you to a single digit number of textures, but it was pretty fast to do affine texture mapping on 286s
All the apps I usually run are easily compiled for pretty much any common CPU. I would much rather have a CPU that ran one ISA lightning fast, rather than one that could run many ISAs but slower.
Perhaps if you have apps for other architectures that you want to run often the tradeoff would be different, but I am not willing to trade off a slowdown of the common case to speed up a very rare case.
PIIs and PIIIs can do microcode updates. Microcode does not an instruction set make.
1) You completely misunderstood what I said. There are tons of tradeoffs in CPU design, and lots of ISAs is fine with me. The point was, if I have the source, I can recompile for whatever I happen to use. A transmeta style CPU will of course never run a given ISA as fast as a CPU tweaked out to run one that specific one.
2) How many mainframe apps would be useful to run on your desktop PC?
All of the programs I use regularly are open source. And as more and more open source apps come out, more people will be able to say that.
FreeMWare is publicly developed. Transmeta could at this point be preparing to skip the country, after having transfered all its VC to a country with favorable banking laws (not likely, but possible).
Who needs a dynamic ISA when we have open source? The silicon wasted on the added complexity in transmeta's CPU could have been better spent making its core ISA faster. Perhaps now people see why having the source code is useful even to you non-programmers out there.
Yes, if they can pull off a retargetablle CPU, it'll be a neat trick, but hopefully Open Source will take over, and we will be forever free of instruction set tyranny.
no, not at all. Transmeta doesn't have a product released, and probably won't for the immediate future (next few months). And we still don't know more than the sketchiest outlines of what their CPU does. And we're not even 100% sure of that.
Yes, but we write whatever we're interested in. So there is no point complaining about whatever new things we could be doing if we weren't reinventing commercial products.
Someone (Kevin) thought that a virtualized x86 would be a cool project, so they started working. If you'd like to email kevin@bochs.com and tell him that you think he should be doing something new instead, feel free, however, don't be surprised if you get flamed.
Evidently not. If you want to go beyond running OSes for the same hardware as you own, you must go to emulation techniques like BOCHS.
"This idea" refering to virtualization cannot be extended beyond running an OS for X on a X machine. If you want to run an OS for X on a Y machine, you need to emulate the CPU.
The patent stuff shouldn't be a problem. MERGE (for SCO) has been virtualizing x86 PCs for years before VMWare existed. One of two things happen: 1) we have prior art in MERGE. 2) VMWare patented a novel way of virtualization that MERGE does not use, in which case we use the unpatented MERGE method.
No worries.
I can't understand why people seem to have such a problem paying for software that they will (most likely) use to run a commercial OS. How many people out there are using VMWare to run NetBSD in a window on thier linux box?
I'm not raggin on FreeMWare, because its extra cool (by virtue of the paper on PC hardware virtualization alone!) but I see the reasons to work on it as idealistism and features/extensibility, not price.
The place I really see potential for FreeMWare is a software ICE type system. A rich debugging environment attached to a virtual machine would make kernel hacking much easier and safer.
VMWare and FreeMWare both virtualize PC hardware. Code executes natively on the host CPU. Playstations, and your intelligent toaster probably do not use the same CPU as your host machine. And non x86 host machines will be unable to run the x86 versions of NT, Linux, or BeOS.
CPU emulation exists and can do all of the above, however, you don't get something for nothing. CPU emulation (see BOCHS, executor, etc) is incredibly slow in the naive case, and even with complex techniques such as dynamic recompilation, signifigantly slower than native code.
When slashdot descends,
Experimental box is
A smoking crater.
BSD style union mounts let you mount the CDROM as / and mount a harddrive "over" it, so that the files on the CDROM show up, but anything you write gets put on the harddrive. This could be workable, although CDROMs are not the fastest things in the world.
FreeBSD's SMP support is roughly similar to Linux 2.0.x's. Not too good unless you have two compute bound tasks. Once you start hitting the kernel, the BIG_ASS_LOCK is grabbed, and everything serializes.
Looks like crap? Its pretty obvious that you've made up your mind already about linux gaming, but you really should have tried it first. the G400 gl driver looks just as good as the windows one, and is faster. Its quite simple really. As for the multihead, unfortunatly, you'll have to wait for XF4 for that one, or run one of the 3.9 snapshots.
They plan to license the engine to other game compnaies. They simply will not open source it, because then their potential liscensees would simply download the source, develop their own game, and then release their own open sourced game with copyrighted graphics/story/etc. And Epic loses out on that revenue.
>Besides, 3-D is faster under Windows.
Tell that to the g[24]00 owners. Interesting to note that the linux GL driver that is faster than its windows counterpart is the one that's been Opensource the longest, and has the most documentation. And John Carmack helping out.
If matrox would release the programming info for the WARP engine, instead of just a binary file full of microcode, I'm sure things would get even faster.
Don't discount the G400 MAX as a gaming card for linux. Its no Geforce, but its quite respectable.
BeOS has much better APIs than linus for things like audio plugins, although Linux has gone from nothing to nearly catching up in under a year. I give Linux another 6 months max before it is way more compelling for audio applications than BeOS.
Video is a different matter entirely, due to patent issues, closed formats and NDAs, and I think this is really where Be will find their niche. Looks like we finally have a replacement for the amiga.
Oh come on. no one is demanding anything on a silver platter. Why would I pay for something, when I can get something I prefer for free?
The better API of BeOS doesn't quite make up for the fact that I can't get at the code. I'm not criticizing Be for being closed, its their code, and their choice, but its simply not worth the money when I can get something better thats free (in both senses of the word).
I can get Redhat for free from an ftp server. I can't (legally) do the same with BeOS.
Plus, my quick echo DSP code runs with lower latency under Linux with mingo's patch than under the "media os" BeOS. And if I want to be hardcore, I can use David Olofson's RT/Linux soundcard driver harness and have latency limited only by the PCI burst size.
if your game isn't heavily threaded, just compile it for glibc2.0. This will get you 95% or more of the market, since glibc2.1 can run glibc2.0 apps transparently. That last 5% of (OLD) slackware users can install the glibc package, using pkgadd. Trust me, anyone running an old version of slackware can handle that.
The linux is fragmented argument is only really valid for heavily multithreaded applications like mozilla.
>(It's actually a very good way to open source video games and still make some money.)
Epic's hope is that if UT is successful (and it looks like it will be) they can then licsense the engine out to other companies. If companies GPLed their engine and just sold the graphics and story, the other companies would just take the code and develop their own GPLed game, with their own graphics and story. Not so good for Epic.
>but other game companies cannot legally use the code without making arrangements with the UT poeple.
Unless the other game companies GPL their code. Which is only a matter of time for a game with a custom engine that isn't likely to be licensed. It would be a bad idea for id to GPL q3. For a game like myst or warcraft GPLing the code could very well work, since mose of the value is the art and story attached to it. These would still fall under copyright.
You do know that Linux loads executable pages from disk as they are used, so most of the code for the parts of the program you're not using isn't using up memory. Its called demand paging, and every decent OS designed in the modern era has it.