Re:Mass media distribution
on
The Next Net
·
· Score: 2, Informative
Korea is a lot more densely populated than the USA, or most of the western world, as far as I know. It makes a big difference on returns if the infrastructure you're laying down is reaching 10 times as many people per unit length.
That doesn't explain the excellent, although probably not quite as good, internet connectivity in Sweden and the Netherlands.
Sorry, I don't know whether they had the scanline blanking capability. I suspect that even if they did, the owner didn't know about it. I don't quite understand how this feature is works, I'd appreciate it if you could explain it in a bit more detail. Surely only outputting every other scanline would essentially make the picture a bit darker, but not change much else? Or is this intended to combat some kind of after-glow effect of the phosphorus?
Do note that my last try with this was a couple of years ago, I seem to remember trying it with Unreal Tournament and Quake 3. More recent devices and software might be better. I'd give the concept another try, but I'm running a TFT these days, which is fast enough for gaming but probably wouldn't cope well with significant image changes for each frame.
A friend of mine has shutter glasses, and they really didn't do much for me when I tried them. The constant flickering - remember, you now only have half the refresh rate - gave me a headache, and the sense of depth was very weak.
I suggest that before buying shutter glasses, one should check these things. I know I'm very sensitive to flickering, anything below 85Hz is useless to me. In "real-world" seeing I don't work off the stereoscopic vision for depth perception, I expect that this causes the weak improvement. (You can test this easily by closing one eye for an extended period of time. Some people start "grabbing air", while others just carry on as normal)
Meh, I'll bite. Direct3D uses OOP to the extent that it's actually useful. The various graphics resources (geometry buffers, textures, shaders, etc.) are logically represented as objects. The various different classes of textures are implemented as derived classes that inherit from a 'base texture' class. I suppose instead of calling Direct3DDevice::SetTexture(int, Direct3DBaseTexture*) they could have made SetTexture() a polymorph member function of textures, but either way works practically equally well, and the texture stage index makes more sense in the context of a device than a texture directly.
Contrast this with doing the same thing in OpenGL: 1. (if necessary) switch to the correct OpenGL context. 2. (if necessary) switch to the correct texture stage. 3. Bind the texture.
To me, that's an obvious win for the OOP (Direct3D) version, but there you go. OK, so (1) will only be necessary in very special circumstances, but (2) is practically always necessary, avoiding it tends to be more work than not.
The point of a production library is not to demonstrate design patterns, but to apply the most appropriate techniques to whatever it is abstracting. If you consider a library's API incomplete or inferior just because it doesn't utilise polymorph multiple inheritance from virtual template base classes, you might want to consider a career as a computer science professor, a few of them will actually agree with you.
I'm also not really sure what C++ features you're missing. OK, so instead of exception handling they use return values, which I personally consider more appropriate in this case. Feel free to disagree on that point.
You still failed to miss the point I was trying to make: OpenGL's could benefit a lot from a better API. As it is, all the newer features are added-on hacks that add obfuscation by introducing statefulness at the API(!) level.
I see a contradition here, emphasis added: ...I still find that it's not only easier to use but generally much faster. I just hate being forced to put absolutely everything into a stupid primitive list.
Care to explain how OpenGL immediate mode is faster than Direct3D Vertex Buffers?
Disclaimer note: I've used both, and am currently using OpenGL due to its open nature.
Light-hearted flamebait: In addition, if you think OpenGL is easier to use than Direct3D you clearly haven't understood OOP or C++.
A 2-socket motherboard, one single-core CPU, one dual-core CPU, perhaps? According to AMD, that kind of stuff is going to be possible with the upcoming multi-core Opterons.
If you re-read my post, you will notice that I'm aware of this. I just have never seen/heard the development branch referred to by version number. All I seem to hear about is "pre-release 2.10" or so. Oh well.
Well, they recently switched to a 6-month release cycle if I remember correctly, and odd minor numbers are development versions. Having said that, my housemate is a GNOME hacker, and he's never mentioned 2.9 (or 2.7, or 2.5), only 2.8 and 2.10. (or 2.4, or 2.6) Not quite sure what's going on there.
Well, if you look at the specs of today's GPUs, they already feature 8-16 pixel processors and 2-8 vertex processors. (numbers somewhere in that order of magnitude) Therefore, they already have multiple cores in a sense. What ATI and nVidia are doing is increasing the complexity of each pixel/vertex pipelines to add features, and adding new pipelines, and widening the memory bus to increase speed. You'll notice that clock speeds are in the 300-500MHz range, presumably for the same reasons why dual-core CPUs (will) have lower clock speeds than their single-core counterparts.
You're not allowed to do that with Firefox, or any Free Software; doing so would be misappropriation.
The difference between art and software is that Software is a process, a medium. Software does stuff on, and to your computer, so you want to know exactly what it does. Who knows, it might wipe your data, or other evil things. Art isn't going to do that, as it is in itself complete. Of course, art must still be presented on a medium. Films on reels, DVDs, or VHSes. Paintings on canvas or paper, or more obscure substances. Video Games on software. Yes, there is overlap. Choosing the right tools or media (lens, camera, film vs. hardware, software) is part of creating that art.
The problem with 'liberating' art like software is being liberated by the Free Software movement is that it would ultimately dilute the experience. Software, in general, serves a specific purpose, it solves a specific problem, but the purposes vary across the spectrum. Morphing software into other software to solve similar problems is considered a good thing, and is hard to argue against.
Art provokes thought and gives entertainment. It's hard or impossible to morph it into something else, as it will lose its vital distinction, and hence be diluted. This is why parody is so hard to do.
If it didn't, wouldn't that technically be a violation of the GPL? Even if it can't run other apps out-of-the-box, you can sufficiently hack the kernel so that it will. If you can't hack the kernel, then it's a GPL violation.
MFC is history anyway. Just something to think about.
Well, half the jobs advertised at gamesindustry.biz at least mention, if not require, knowledge of MFC. It's horrible and outdated, but is what everyone knows, and everyone uses.
I've mentioned some reasons why you might choose Direct3D over OpenGL in a few other posts in this forum. Another is that most games use existing engines that are using, guess what, Direct3D. It's certainly not cheap to migrate an engine from D3D to OpenGL.
For new engines and games, yes, by all means, go for it. I'm going ahead with a good example, and using SDL/OpenGL for graphics, OpenAL for sound, SDL_Net/Net2 for networking, SDL/FastEvents for threading and events, and PhysFS for file access. There is some platform specific code because of an OpenAL quirk, compiler quirks, and the whole GLX/WGL/AGL windowing system dependency in OpenGL, but that's not out of choice but necessity.
What's more, it's all GPL, but I can only afford to do that because I'm at uni and my parents pay for food, rent, and bandwidth. No URLs yet because I don't want people whining about it not running properly yet. If you're really interested, e-mail me, there's no actual secret.
Vertex buffers: Reading this it sound like display lists would be a better fit for this.
The trouble with them is, because they store state information and such, they tend to be very bad for multi-pass operations, as you pretty much have to keep multiple copies of the same geometry around. I've already got more geometry than I'd like to have, so storing distinct copies of it for cel shading and shadowing/lighting is just not an option.
Features: It is similar, but still means you have to call completely different functions to do stuff. This makes any sort of data-driven model quite hard to do.
Statefulness: For example, functions that operate on a texture of a certain stage in the multitexturing pipeline operate on the *current* one, whichever that may be. So you have to set the current texture stage of the API, do all your state changes, move to the next stage, etc. The changing of the current stage only affects the state of the API, it doesn't actually affect rendering in any way.
In D3D the SetTexture() and SetTextureStageState() functions take a texture stage number argument, so the same call, called at any point, will always do the same thing. This isn't the case for OpenGL!
Extensions: Nothing stops them from implementing them, no, but it just so happens that they don't, for the most part. In particular, anything shader-related is not implemented by the competitor. (NV_register_combiner, for example)
Vertex buffers: Vertex arrays do the same thing as DrawPrimitiveUP() (or so). Vertex buffers store the vertex data in the most convenient location for the hardware. In OpenGL, this might be ARB_vertex_buffer_objects, NV_vertex_array_range (older drivers), ATI_vertex_array_object (again, older drivers, plus some other extensions that build on this as well), compiled vertex arrays, and so on. They're all ever so slightly different, the drivers have their unpublished implementation quirks in different versions, etc. I hear OpenGL 2.0 improves this, which sounds good.
Another example are render-to-texture operations. In Direct3D you simply set the render target to something. In OpenGL, it depends whether you're in Windows/WGL, X11/GLX, or MacOS/AGL, plus there are extensions (WGL_ARB_render_texture, GLX_ATI_render_texture) in addition to the basic P-buffer extensions, which accelerate render target switches on certain hardware. So I have different renderpaths for different OSes, for different hardware. Lovely. Yeah, you can conditionally compile the OS-specific stuff, but it shouldn't be necessary.
Codepaths: yes, but in Direct3D those different codepaths share quite a bit of code, whereas the codepaths in my current OpenGL code are completely separate, because vertex submission, shading, etc. have to be handled differently for everything.
OpenGL might be lovely for Hollywood CGI type stuff where you have ONE set of hardware and need the finest-grained control possible, but for games which are supposed to suppord a vast array of hardware, Direct3D is just nicer.
I am using SDL for windowing, threading, timers, events, etc. However, SDL itself only provides 2D graphics capabilities, for 3D you have to use OpenGL. Yeah, you don't have to worry about contexts and so on, which is nice, but it still means you have to use OpenGL.
Meh, DirectInput is pretty primitive and could easily be ported to any platform. Hardly any developer uses DirectSound directly, most of the time they use sound middleware such as Miles Sound System, which, if I remember correctly, supports a bunch of different platforms and sound APIs.
DirectPlay is probably the only one of these that is an issue. The Cedega guys have managed to port that as well, though. Now, if they just had a more permissive license!
The problem is that the developers are more or less at the whim of the publishers, and resources are spent on fixing bugs rather than porting to platforms that may or may not increase profits. ID have loads of money anyway, so they don't really care, and it also helps engine sales.
One problem is that OpenGL (pre 2.0, haven't looked at that yet) is horrible to work with if you actually want to get stuff done. I'm using it in a game right now, and let me tell you, using a library with a stateful API is no fun. Direct3D does a great job of abstracting things like geometry submission (Vertex Buffers) away, and things like shaders are backwards compatible. For example, on Direct3D, a Radeon 9800 can use GeForce3-class 1.1 pixel shaders; in OpenGL they are a NVIDIA-specific extension. If you want your game to be successful you have to cater for ALL hardware out there, and D3D just makes this so much easier.
Having said that, I still use OpenGL, as I run Linux, and don't like the closedness of Direct3D.
Many games are developed in a cross-platform way to start with. Unix and Windows are quite similar compared to, say, Windows and the PS2! All system-specific calls are hidden behind APIs and libraries anyway, adding a Unix version isn't so hard. Of course, until someone can prove to the publishers that porting to Linux or Mac yields more sold units, the situation won't change.
Slashdot Mirror
Korea is a lot more densely populated than the USA, or most of the western world, as far as I know. It makes a big difference on returns if the infrastructure you're laying down is reaching 10 times as many people per unit length.
That doesn't explain the excellent, although probably not quite as good, internet connectivity in Sweden and the Netherlands.
~phil
Sorry, I don't know whether they had the scanline blanking capability. I suspect that even if they did, the owner didn't know about it. I don't quite understand how this feature is works, I'd appreciate it if you could explain it in a bit more detail. Surely only outputting every other scanline would essentially make the picture a bit darker, but not change much else? Or is this intended to combat some kind of after-glow effect of the phosphorus?
Do note that my last try with this was a couple of years ago, I seem to remember trying it with Unreal Tournament and Quake 3. More recent devices and software might be better. I'd give the concept another try, but I'm running a TFT these days, which is fast enough for gaming but probably wouldn't cope well with significant image changes for each frame.
~phil
A friend of mine has shutter glasses, and they really didn't do much for me when I tried them. The constant flickering - remember, you now only have half the refresh rate - gave me a headache, and the sense of depth was very weak.
I suggest that before buying shutter glasses, one should check these things. I know I'm very sensitive to flickering, anything below 85Hz is useless to me. In "real-world" seeing I don't work off the stereoscopic vision for depth perception, I expect that this causes the weak improvement. (You can test this easily by closing one eye for an extended period of time. Some people start "grabbing air", while others just carry on as normal)
~phil
Except for the very first prime number, which is 2, of course. Which makes the whole thing odd again.
~phil
Hah, international waters! It doesn't apply!
~phil
Xbox 3? More like Xbox 2 - they'd better save up that valuable letter Y for their portable Y-Boy.
~phil
Meh, I'll bite. Direct3D uses OOP to the extent that it's actually useful. The various graphics resources (geometry buffers, textures, shaders, etc.) are logically represented as objects. The various different classes of textures are implemented as derived classes that inherit from a 'base texture' class. I suppose instead of calling Direct3DDevice::SetTexture(int, Direct3DBaseTexture*) they could have made SetTexture() a polymorph member function of textures, but either way works practically equally well, and the texture stage index makes more sense in the context of a device than a texture directly.
Contrast this with doing the same thing in OpenGL:
1. (if necessary) switch to the correct OpenGL context.
2. (if necessary) switch to the correct texture stage.
3. Bind the texture.
To me, that's an obvious win for the OOP (Direct3D) version, but there you go. OK, so (1) will only be necessary in very special circumstances, but (2) is practically always necessary, avoiding it tends to be more work than not.
The point of a production library is not to demonstrate design patterns, but to apply the most appropriate techniques to whatever it is abstracting. If you consider a library's API incomplete or inferior just because it doesn't utilise polymorph multiple inheritance from virtual template base classes, you might want to consider a career as a computer science professor, a few of them will actually agree with you.
I'm also not really sure what C++ features you're missing. OK, so instead of exception handling they use return values, which I personally consider more appropriate in this case. Feel free to disagree on that point.
You still failed to miss the point I was trying to make: OpenGL's could benefit a lot from a better API. As it is, all the newer features are added-on hacks that add obfuscation by introducing statefulness at the API(!) level.
by Anonymous Coward
Good work stuffing your foot in your mouth.
*chuckles* Ah, kids these days.
~phil
I see a contradition here, emphasis added:
...I still find that it's not only easier to use but generally much faster.
I just hate being forced to put absolutely everything into a stupid primitive list.
Care to explain how OpenGL immediate mode is faster than Direct3D Vertex Buffers?
Disclaimer note: I've used both, and am currently using OpenGL due to its open nature.
Light-hearted flamebait: In addition, if you think OpenGL is easier to use than Direct3D you clearly haven't understood OOP or C++.
~phil
A 2-socket motherboard, one single-core CPU, one dual-core CPU, perhaps? According to AMD, that kind of stuff is going to be possible with the upcoming multi-core Opterons.
~phil
If you re-read my post, you will notice that I'm aware of this. I just have never seen/heard the development branch referred to by version number. All I seem to hear about is "pre-release 2.10" or so. Oh well.
~phil
Well, they recently switched to a 6-month release cycle if I remember correctly, and odd minor numbers are development versions. Having said that, my housemate is a GNOME hacker, and he's never mentioned 2.9 (or 2.7, or 2.5), only 2.8 and 2.10. (or 2.4, or 2.6) Not quite sure what's going on there.
;-)
Oh what the hell: KDE rules!
~phil
You could probably use the code in a closed-source app, but you'd have to buy an explicit license for doing so.
~phil
Well, if you look at the specs of today's GPUs, they already feature 8-16 pixel processors and 2-8 vertex processors. (numbers somewhere in that order of magnitude) Therefore, they already have multiple cores in a sense. What ATI and nVidia are doing is increasing the complexity of each pixel/vertex pipelines to add features, and adding new pipelines, and widening the memory bus to increase speed. You'll notice that clock speeds are in the 300-500MHz range, presumably for the same reasons why dual-core CPUs (will) have lower clock speeds than their single-core counterparts.
~phil
You're not allowed to do that with Firefox, or any Free Software; doing so would be misappropriation.
The difference between art and software is that Software is a process, a medium. Software does stuff on, and to your computer, so you want to know exactly what it does. Who knows, it might wipe your data, or other evil things. Art isn't going to do that, as it is in itself complete. Of course, art must still be presented on a medium. Films on reels, DVDs, or VHSes. Paintings on canvas or paper, or more obscure substances. Video Games on software. Yes, there is overlap. Choosing the right tools or media (lens, camera, film vs. hardware, software) is part of creating that art.
The problem with 'liberating' art like software is being liberated by the Free Software movement is that it would ultimately dilute the experience. Software, in general, serves a specific purpose, it solves a specific problem, but the purposes vary across the spectrum. Morphing software into other software to solve similar problems is considered a good thing, and is hard to argue against.
Art provokes thought and gives entertainment. It's hard or impossible to morph it into something else, as it will lose its vital distinction, and hence be diluted. This is why parody is so hard to do.
~phil
If it didn't, wouldn't that technically be a violation of the GPL? Even if it can't run other apps out-of-the-box, you can sufficiently hack the kernel so that it will. If you can't hack the kernel, then it's a GPL violation.
~phil
MFC is history anyway. Just something to think about.
Well, half the jobs advertised at gamesindustry.biz at least mention, if not require, knowledge of MFC. It's horrible and outdated, but is what everyone knows, and everyone uses.
~phil
I've mentioned some reasons why you might choose Direct3D over OpenGL in a few other posts in this forum. Another is that most games use existing engines that are using, guess what, Direct3D. It's certainly not cheap to migrate an engine from D3D to OpenGL.
For new engines and games, yes, by all means, go for it. I'm going ahead with a good example, and using SDL/OpenGL for graphics, OpenAL for sound, SDL_Net/Net2 for networking, SDL/FastEvents for threading and events, and PhysFS for file access.
There is some platform specific code because of an OpenAL quirk, compiler quirks, and the whole GLX/WGL/AGL windowing system dependency in OpenGL, but that's not out of choice but necessity.
What's more, it's all GPL, but I can only afford to do that because I'm at uni and my parents pay for food, rent, and bandwidth. No URLs yet because I don't want people whining about it not running properly yet. If you're really interested, e-mail me, there's no actual secret.
~phil
Vertex buffers: Reading this it sound like display lists would be a better fit for this.
The trouble with them is, because they store state information and such, they tend to be very bad for multi-pass operations, as you pretty much have to keep multiple copies of the same geometry around. I've already got more geometry than I'd like to have, so storing distinct copies of it for cel shading and shadowing/lighting is just not an option.
~phil
Features: It is similar, but still means you have to call completely different functions to do stuff. This makes any sort of data-driven model quite hard to do.
Statefulness: For example, functions that operate on a texture of a certain stage in the multitexturing pipeline operate on the *current* one, whichever that may be. So you have to set the current texture stage of the API, do all your state changes, move to the next stage, etc. The changing of the current stage only affects the state of the API, it doesn't actually affect rendering in any way.
In D3D the SetTexture() and SetTextureStageState() functions take a texture stage number argument, so the same call, called at any point, will always do the same thing. This isn't the case for OpenGL!
Extensions: Nothing stops them from implementing them, no, but it just so happens that they don't, for the most part. In particular, anything shader-related is not implemented by the competitor. (NV_register_combiner, for example)
Vertex buffers: Vertex arrays do the same thing as DrawPrimitiveUP() (or so). Vertex buffers store the vertex data in the most convenient location for the hardware. In OpenGL, this might be ARB_vertex_buffer_objects, NV_vertex_array_range (older drivers), ATI_vertex_array_object (again, older drivers, plus some other extensions that build on this as well), compiled vertex arrays, and so on. They're all ever so slightly different, the drivers have their unpublished implementation quirks in different versions, etc. I hear OpenGL 2.0 improves this, which sounds good.
Another example are render-to-texture operations. In Direct3D you simply set the render target to something. In OpenGL, it depends whether you're in Windows/WGL, X11/GLX, or MacOS/AGL, plus there are extensions (WGL_ARB_render_texture, GLX_ATI_render_texture) in addition to the basic P-buffer extensions, which accelerate render target switches on certain hardware. So I have different renderpaths for different OSes, for different hardware. Lovely. Yeah, you can conditionally compile the OS-specific stuff, but it shouldn't be necessary.
Codepaths: yes, but in Direct3D those different codepaths share quite a bit of code, whereas the codepaths in my current OpenGL code are completely separate, because vertex submission, shading, etc. have to be handled differently for everything.
OpenGL might be lovely for Hollywood CGI type stuff where you have ONE set of hardware and need the finest-grained control possible, but for games which are supposed to suppord a vast array of hardware, Direct3D is just nicer.
~phil
I am using SDL for windowing, threading, timers, events, etc. However, SDL itself only provides 2D graphics capabilities, for 3D you have to use OpenGL. Yeah, you don't have to worry about contexts and so on, which is nice, but it still means you have to use OpenGL.
~phil
Yep, they suck. ATI are also atrociously slow at supporting new versions of X. (no 3D acceleration on my SUSE 9.2 :( )
My next card will be a nVidia.
~phil
Meh, DirectInput is pretty primitive and could easily be ported to any platform. Hardly any developer uses DirectSound directly, most of the time they use sound middleware such as Miles Sound System, which, if I remember correctly, supports a bunch of different platforms and sound APIs.
DirectPlay is probably the only one of these that is an issue. The Cedega guys have managed to port that as well, though. Now, if they just had a more permissive license!
~phil
The problem is that the developers are more or less at the whim of the publishers, and resources are spent on fixing bugs rather than porting to platforms that may or may not increase profits. ID have loads of money anyway, so they don't really care, and it also helps engine sales.
~phil
One problem is that OpenGL (pre 2.0, haven't looked at that yet) is horrible to work with if you actually want to get stuff done. I'm using it in a game right now, and let me tell you, using a library with a stateful API is no fun. Direct3D does a great job of abstracting things like geometry submission (Vertex Buffers) away, and things like shaders are backwards compatible. For example, on Direct3D, a Radeon 9800 can use GeForce3-class 1.1 pixel shaders; in OpenGL they are a NVIDIA-specific extension. If you want your game to be successful you have to cater for ALL hardware out there, and D3D just makes this so much easier.
Having said that, I still use OpenGL, as I run Linux, and don't like the closedness of Direct3D.
~phil
Many games are developed in a cross-platform way to start with. Unix and Windows are quite similar compared to, say, Windows and the PS2! All system-specific calls are hidden behind APIs and libraries anyway, adding a Unix version isn't so hard. Of course, until someone can prove to the publishers that porting to Linux or Mac yields more sold units, the situation won't change.
~phil