Pandemonium, and its successor, Pandemonium 2, did it right. The gameplay was still 2D actually, but the graphics (and the 'curved' structure of the levels) gave it an awesome 3D perspective (it really looked great on my Voodoo 1).
The clockwork level (which you get to play twice, and the first part, where the clockwork isn't in motion yet, is already difficult enough) still gives me nightmares.
You can buy your own fire bandages and resist/mana/mongoose/whatever-your-class-needs potions in the AH. They're cheap, and farming the money takes not much time.
Yes, I should have either writen 20:00 or 11:30 p.m. Which is likely responsible for your mathematical slip. from 8:00 to 11:30 is 3.5 hours, not 5.5 hours.
Many people complain that WoW either sucks up your whole time, or you don't get anywhere. That's not true, you can easily play the game two evenings / week and still see the whole end game content.
The solution? Find a group that's *organized* (i.e. has a webpage and a forum). Their raids have fixed schedules. You show up at 7:50 p.m., buff up, raid starts at 8:00 and at +/- 23:30 you can go to sleep. Since the big raid instances only reset once a week, you don't have to do more than two evenings (and if your group is getting really good, you can even clear MC in 4 hours), which you would have wasted with reading slashdot or watching TV anyways.
And if you believe that, I've got a bridge to sell to you.
It's not about what the card/driver *claims* it can do. It's about what it *can* do, and hopefully in a reliable and performant fashion. Mistakes happen, and buggy hardware and software gets released. But it doesn't necessarily get patched/fixed. That means it's the application programmers responsibility to work around the issues.
> A Direct3D programmer doesn't have to know whether they're using an Intel, ATi or nVidia chip, for example, in order for their code to work.
HAHAHA! Best joke I've heard in a while. You obviously haven't been programming with D3D a lot.
It's absolutely vital that you check Vendor ID, Device ID, and Driver version in order to work around the countless bugs, quirks, and performance holes in all the well known broken systems out there (unless you absolutely want to slap a BIG 'only supported on Card X with (at least) Driver Y' STICKER on your packaging).
While constructors and destructors are mostly syntactic sugar (just use CreateFoo() and DeleteFoo() functions), C++ has one thing C has not:
Exceptions
If they're used correctly (read Bruce Eckel's "Thinking in C++"), they provide an exceptionally (pun intended) powerful method for handling errors. C's setjmp/longjmp is vastly inferior.
> I liked the fact that it took me about 6 months to hit 60, because WoW was exceedingly boring for a lvl 60 toon.
It may come as a surprise to you, but for some people *it is fun* to see 20 or 40 people working together, play their classes well, and kill the uber bosses in Molten Core or Zul'Gurub (it's not just W00t-EPIXXX! - of course, we dont mind those either).
I can't believe this got modded to +5. Direct3D retained mode was generally frowned upon and completely ignored even in the days of DirectX 3. At least since version 6, Direct3D is a perfectly usable API and the TextureStageState setup as introduced in DirectX 7 just beats the crap out of OpenGLs glTexEnv mess.
1) Doom3 uses OpenGL 2) The problem with wrapping OpenGL is *not* performance. It's *extensibility*. With Microsoft controlling OpenGL on Vista, it'll be forever stuck at OpenGL 1.4, and vendors won't be able to provide any new extensions. That'll will effectively give Microsoft control over the way hardware is developed. If the IHVs can't add a new feature of their cards to the API (e.g. through GL_ATI_someextension), there's no point in adding it. It'll go unused until Microsoft decides to update Direct3D.
The uncanny valley effect is about *robotics* and NOT computer graphics. It's the things that walk & talk and pretend to be human that give some people shivers, NOT things they see on a screen.
Heh, I'm not sure he'll already play video games at age 6, his mom might object strongly (although, racing games seem rather harmless). But maybe I can convince her by arguing that he won't have to 'compensate for his lack of gaming' when he's 12-14 years old.
I second that. Even for a single char, there's not enough choice (e.g. there's usually just one instance accessible for your current level, and if you're a lvl 34 Shammy, there's none right now. They're either too high or too low level).
In what way does *it* (HL2? Project Offset) solve lighting?
The latest real-time approaches for global illumination (e.g. PRT & spherical harmonics derived from cubic envmaps or irradiance volumes) are still just hacks. And this engine (while it looks nice) doesn't even mention these.
If you think OpenGL matrices are very straightforward, then you'll be pleased that D3D matrices work the same (apart from the inverted z-axis, i.e. left handed vs. right handed coordinates) and are actually even simpler, because you don't have to pay attention to the matrix stack anymore when you place your lights, set the camera transform etc.
Yes, for large badges, the differences are very small, but alas, many many objects consist of just a few triangles (think LOD), especially billboards.
As for memory, D3D gives you the option to do it the OpenGL way (POOL_MANAGED, usually vidmen with system mem backup) or do the backup yourself (POOL_DEFAULT, usually vidmem only.
Actually, for layering, I can't think of many issues that are problematic, assuming that we're talking recent hardware here (e.g. fully OpenGL 1.4 & DirectX 9 capable). The feature sets are very similiar. z-Buffer reads (btw. those can be quite useful in a GPGPU context) is the only thing where I find D3D lacking (oh, and I want to do 'render to vertexbuffer', but then, the OpenGL super buffers extension was announced at SIGGRAPH 2002 and *is still not available).
However, to get back to the topic of the original article, 'emulating' OpenGL 1.4 through Direct3D is likely not going to be much slower for current games because
a) Microsoft is working hard (or so they say, at least) on reducing the CPU costs associated with multiple DrawPrimitive calls and very little state changes in between (where OpenGL shines)
b) Many games are already 'batch-aware', further reducing the performance difference.
1) D3D is easy to program for, even if you just draw a single triangle (that's what the Draw*PrimitiveUP functions are for). A few features where D3D shines:
- No ModelView matrix, but seperate World (Geometry) and View (Camera) matrices. Understanding the ModelView matrix concept usually takes people years.
- Multitexturing: SetTextureStageState is *a lot* more intuitive than the mess that's ARB_GL_texture_env_combine/dot3/add etc.etc.
- Render to texture. Messy even with ARB_pixel_bufer_object (just see how long it takes Ryan Gordon to get it right).
Some features not in core D3D, but shipped with the SDK.
- Initialization. Yes, that's right. Gone are the days of enumerating pixel formats, now the SDK ships with a GLUT-like wrapper.
- D3DX: Literally saves you years of development time. From PRT calculation to utility functions for building procedural cubemaps, you can find here almost everything.
2) There are HUGE performance differtences
- D3D's batch performance *sucks*. That's why they invented stuff like instancing (which you hardly need in OGL, glDrawElements has very low CPU overhead)
- Memory management. OpenGL manages all memory for you, and keeps a host memory copy of your textures, display lists, etc. This, of course, sucks (I remember Tim Sweeney bitching about this when the original UT came out). Exception: the new buffer objects.
3) Another poster mentioned that you can layer OpenGL on top of Direct3D. WRONG. OpenGL provides read access to all buffers, Direct3D does not. Good luck finding a driver that still supports the D3D_FMT_LOCKABLE flag for z-buffers.
All that being said, I stick to OpenGL for portability (I wish there was D3D for Linux & OS X).
I don't think so. To extract a single file from a.tar.bz2 you need to decompress the archive up to that file (so, on average 50% the archive), and that can take a *very* long time (especially with bz2 compression). Of course, you don't need to store all data on disk, and throw it away instead as soon as you uncompressed it, but that only saves you some I/O (uncompressing is typically CPU limited).
Also, you cannot build an index, since a tar.gz is a gzip compressed tar. You'd need to create.tar.gz.mypack that scanned the.tar archive, computed the compression of each file, and then computed the chunk index, so you can save yourself some decompression. Better to use zip in the first place.
There's one thing that compressed tars are better at than zip files though: Small files. gzip/bzip can compress the tar stream, and split that into much larger chunks than each individual file is. zip has to process each file individually.
Slashdot Mirror
Pandemonium, and its successor, Pandemonium 2, did it right. The gameplay was still 2D actually, but the graphics (and the 'curved' structure of the levels) gave it an awesome 3D perspective (it really looked great on my Voodoo 1).
The clockwork level (which you get to play twice, and the first part, where the clockwork isn't in motion yet, is already difficult enough) still gives me nightmares.
You can buy your own fire bandages and resist/mana/mongoose/whatever-your-class-needs potions in the AH. They're cheap, and farming the money takes not much time.
Yes, I should have either writen 20:00 or 11:30 p.m. Which is likely responsible for your mathematical slip. from 8:00 to 11:30 is 3.5 hours, not 5.5 hours.
Many people complain that WoW either sucks up your whole time, or you don't get anywhere. That's not true, you can easily play the game two evenings / week and still see the whole end game content.
The solution? Find a group that's *organized* (i.e. has a webpage and a forum). Their raids have fixed schedules. You show up at 7:50 p.m., buff up, raid starts at 8:00 and at +/- 23:30 you can go to sleep. Since the big raid instances only reset once a week, you don't have to do more than two evenings (and if your group is getting really good, you can even clear MC in 4 hours), which you would have wasted with reading slashdot or watching TV anyways.
- Rhonac (60 Shaman on Thunderhorn EU).
I think the people who have only time for 15 minutes of sex a day are usually called "parents".
> That's really a thing of the past in DirectX 10
And if you believe that, I've got a bridge to sell to you.
It's not about what the card/driver *claims* it can do. It's about what it *can* do, and hopefully in a reliable and performant fashion. Mistakes happen, and buggy hardware and software gets released. But it doesn't necessarily get patched/fixed. That means it's the application programmers responsibility to work around the issues.
> A Direct3D programmer doesn't have to know whether they're using an Intel, ATi or nVidia chip, for example, in order for their code to work.
HAHAHA! Best joke I've heard in a while. You obviously haven't been programming with D3D a lot.
It's absolutely vital that you check Vendor ID, Device ID, and Driver version in order to work around the countless bugs, quirks, and performance holes in all the well known broken systems out there (unless you absolutely want to slap a BIG 'only supported on Card X with (at least) Driver Y' STICKER on your packaging).
While constructors and destructors are mostly syntactic sugar (just use CreateFoo() and DeleteFoo() functions), C++ has one thing C has not:
Exceptions
If they're used correctly (read Bruce Eckel's "Thinking in C++"), they provide an exceptionally (pun intended) powerful method for handling errors. C's setjmp/longjmp is vastly inferior.
- Andreas
> I liked the fact that it took me about 6 months to hit 60, because WoW was exceedingly boring for a lvl 60 toon.
It may come as a surprise to you, but for some people *it is fun* to see 20 or 40 people working together, play their classes well, and kill the uber bosses in Molten Core or Zul'Gurub (it's not just W00t-EPIXXX! - of course, we dont mind those either).
- Rhonac (Thunderhorn EU)
...they're hoping that someone posts a link to a repacement site...
Gold sellers are sending me mail in-game.
I can't believe this got modded to +5. Direct3D retained mode was generally frowned upon and completely ignored even in the days of DirectX 3. At least since version 6, Direct3D is a perfectly usable API and the TextureStageState setup as introduced in DirectX 7 just beats the crap out of OpenGLs glTexEnv mess.
Too bad it's not cross platform
1) Doom3 uses OpenGL
2) The problem with wrapping OpenGL is *not* performance. It's *extensibility*. With Microsoft controlling OpenGL on Vista, it'll be forever stuck at OpenGL 1.4, and vendors won't be able to provide any new extensions. That'll will effectively give Microsoft
control over the way hardware is developed. If the IHVs can't add a new feature of their cards to the API (e.g. through GL_ATI_someextension), there's no point in adding it. It'll go unused until Microsoft decides to update Direct3D.
Better yet, fuck the WASD key people, I like my arrow keys and that's how I'm programming it.
I program using the KJL; keys
The uncanny valley effect is about *robotics* and NOT computer graphics. It's the things that walk & talk and pretend to be human that give some people shivers, NOT things they see on a screen.
Heh, I'm not sure he'll already play video games at age 6, his mom might object strongly (although, racing games seem rather harmless). But maybe I can convince her by arguing that he won't have to 'compensate for his lack of gaming' when he's 12-14 years old.
As soon as the kid's there, there'll be no gaming time left...
(/me runs after his 9 month old)
I second that. Even for a single char, there's not enough choice (e.g. there's usually just one instance accessible for your current level, and if you're a lvl 34 Shammy, there's none right now. They're either too high or too low level).
So, that's why it takes so long to install games these days. They can show more ads that way!
Play indie games: Gish, Oasis, Zuma, GLtron, Threadmarks, Savage, Puzzle-Pirates etc.
In what way does *it* (HL2? Project Offset) solve lighting?
The latest real-time approaches for global illumination (e.g. PRT & spherical harmonics derived from cubic envmaps or irradiance volumes) are still just hacks. And this engine (while it looks nice) doesn't even mention these.
If you think OpenGL matrices are very straightforward, then you'll be pleased that D3D matrices work the same (apart from the inverted z-axis, i.e. left handed vs. right handed coordinates) and are actually even simpler, because you don't have to pay attention to the matrix stack anymore when you place your lights, set the camera transform etc.
Yes, for large badges, the differences are very small, but alas, many many objects consist of just a few triangles (think LOD), especially billboards.
As for memory, D3D gives you the option to do it the OpenGL way (POOL_MANAGED, usually vidmen with system mem backup) or do the backup yourself (POOL_DEFAULT, usually vidmem only.
Actually, for layering, I can't think of many issues that are problematic, assuming that we're talking recent hardware here (e.g. fully OpenGL 1.4 & DirectX 9 capable). The feature sets are very similiar. z-Buffer reads (btw. those can be quite useful in a GPGPU context) is the only thing where I find D3D lacking (oh, and I want to do 'render to vertexbuffer', but then, the OpenGL super buffers extension was announced at SIGGRAPH 2002 and *is still not available).
However, to get back to the topic of the original article, 'emulating' OpenGL 1.4 through Direct3D is likely not going to be much slower for current games because
a) Microsoft is working hard (or so they say, at least) on reducing the CPU costs associated with multiple DrawPrimitive calls and very little state changes in between (where OpenGL shines)
b) Many games are already 'batch-aware', further reducing the performance difference.
Wrong.
1) D3D is easy to program for, even if you just draw a single triangle (that's what the Draw*PrimitiveUP functions are for). A few features where D3D shines:
- No ModelView matrix, but seperate World (Geometry) and View (Camera) matrices. Understanding the ModelView matrix concept usually takes people years.
- Multitexturing: SetTextureStageState is *a lot* more intuitive than the mess that's ARB_GL_texture_env_combine/dot3/add etc.etc.
- Render to texture. Messy even with ARB_pixel_bufer_object (just see how long it takes Ryan Gordon to get it right).
Some features not in core D3D, but shipped with the SDK.
- Initialization. Yes, that's right. Gone are the days of enumerating pixel formats, now the SDK ships with a GLUT-like wrapper.
- D3DX: Literally saves you years of development time. From PRT calculation to utility functions for building procedural cubemaps, you can find here almost everything.
2) There are HUGE performance differtences
- D3D's batch performance *sucks*. That's why they invented stuff like instancing (which you hardly need in OGL, glDrawElements has very low CPU overhead)
- Memory management. OpenGL manages all memory for you, and keeps a host memory copy of your textures, display lists, etc. This, of course, sucks (I remember Tim Sweeney bitching about this when the original UT came out). Exception: the new buffer objects.
3) Another poster mentioned that you can layer OpenGL on top of Direct3D. WRONG. OpenGL provides read access to all buffers, Direct3D does not. Good luck finding a driver that still supports the D3D_FMT_LOCKABLE flag for z-buffers.
All that being said, I stick to OpenGL for portability (I wish there was D3D for Linux & OS X).
Leather goddesses of phobos.
It's been mentioned several times in this thread already, but once again:
- Yes, you can extract individual files
- No, the access is not random, you need to decompress the stream and parse the archive up to the target file.
For e.g. 1 GB of compressed e-mail, this is likely to take forever.
For a zip-file, extracting a small file from a 1 GB archive is instantly done.
I don't think so. To extract a single file from a .tar.bz2 you need to decompress the archive up to that file (so, on average 50% the archive), and that can take a *very* long time (especially with bz2 compression). Of course, you don't need to store all data on disk, and throw it away instead as soon as you uncompressed it, but that only saves you some I/O (uncompressing is typically CPU limited).
.tar.gz.mypack that scanned the .tar archive, computed the compression of each file, and then computed the chunk index, so you can save yourself some decompression. Better to use zip in the first place.
Also, you cannot build an index, since a tar.gz is a gzip compressed tar. You'd need to create
There's one thing that compressed tars are better at than zip files though: Small files. gzip/bzip can compress the tar stream, and split that into much larger chunks than each individual file is. zip has to process each file individually.