Then you'll be happy to know that this is changed in DX10. I don't understand what you mean with this statement. No, you can use OEM ICDs for windowed applications but these applications won't be able to use the new compositing effects (the new eye candy) and will revert to something like XP look and feel, surely not the end of the world. This only affects the windowed application, it's not like the compositing effects are disabled for the entire OS when an OEM ICD is loaded. There is a lot of windows customers and developers who rely on OpenGL for their applications, why would microsoft wan't to make their life hard and potentially lose them as customers? Microsoft aren't idiots, they realize that if they cripple OpenGL in windows there's a chance that some of their customers migrate to mac or linux/unix. You come across as quite rude, I don't know if that's your intention but that is how at least I percieve it. /mr n00b
You're making very reasonable arguments, but this actually isn't entirely true. The way the situation was last year, it really looked like MS was trying to kill OpenGL. The GL support for Vista that has been announced now (1.4 w/o extensions emulated in D3D OR full GL without compositing desktop, both of which really suck IMHO) has been a result of pressure from IHVs. In fact, the DCC/CAD argument has been primarily an argument of IHVs, not MS. Fortunately, MS can only restrict the driver so much, and they can't afford to look like they are obviously trying to kill OpenGL. So if the IHVs can find a way around something, and MS can't find a good reason to prohibit it (not to mention the fact that they can't start unraveling work that's already been done on Vista), they really have no choice but to allow it. In fact, the GL situation at this point may be even better than has been announced up to this point. We'll just have to see how things pan out. In the meantime though, I don't want the MS picture to start getting too rosy IHVs have had a large part in this. STEERING THIS THREAD BACK ON TOPIC: DragonsIOA mentioned shaders in his last post. Just to throw my two cents in, I really think MS did a way better job on implementing high level shading languages than OpenGL did. Since I'm using GL for my project, my plan at this point is to use Cg and compile to the arbvp1 and arbfp1 profiles. This is a bit limiting since I don't get the full instruction sets, but compiling to asm profiles is the way to go for a full fledged game. So, for anyone concerned with the shader situation in OpenGL, there's an option to think about.
Your using OpenGL with ASM, ASM is one hard language, but it is the fastest and I have seen an example that uses OpenGL with ASM
Forget assembler, I doubt that anyone uses it novadays for game development, or any development besides maybe some driver coding. The goal is to make game in reasonable time, and to be able to maintain the code. If you go the asm route, well, maybe you'll get praises of some adolescent wannabe h4x0rs, but it'll be living hell to find bugs in that code.. BTW what's the game you're going to code? -find the tools appropriate for the task, not otherwise cheers, Arkadesh
I would code the game in C++, but learning ASM is more of hobby project for me, its just that it runs faster then anything else, of course it is really hard.
Well, faster than anything else is disputable... programming the CPU directly isn't that easy and predictable as it used to be in the early days, when the asm ruled. Now, there are way too many processors, pipelining isn't straightforward, and usually it's better to leave the job to the compiler. But if you like it... who cares cheers, Arkadesh
I think you guys are misunderstanding how the shader asm works. The shader asm is not opcode, nor is there any one-to-one mapping of asm to opcodes. The asm is just a programming interface/language; the actual binary compilation of the shader happens at runtime in the video driver. This means it is mostly pointless to code shaders in asm for "speed" since the order of your instructions is mostly ignored. The driver will take your instructions and compile them into optimized opcode when you run your app. The Cg compiler simply takes high level Cg code and compiles to this asm interface. There is no way for the Cg compiler to be "worse" than the asm since neither is opcode (unless of course the Cg compiler happens to add instructions or something, and even then the driver compiler would probably rip them out). The only reason I'm using Cg is just because it's easier to write in high level language, and the Cg runtime makes handling stream and data bindings WAY easier. As a side note, this does mean that anyone who thinks Cg is "bad for ATI because it's NVIDIA blah blah blah" is talking out of their ass and doesn't know how Cg works
Ah, somehow I've thought that ProgrammingFreak is referring to programing in asm calling OpenGL from it, not about the shaders... But could be I've misunderstood, as I haven't traced the whole thread too carefully cheers, Arkadesh
On the Mac side I wasn't too impressed with Cg. The compiler produced code that had excess instructions and temporaries and I was able to produce much more efficient code by hand. Plus I didn't really like the Cg function set. The standard ARB functions fit in better with the rest of the OGL calls. Of course, on the Windows side where you may be targeting more than just OGL, and more than just arbvp1/arbfp1 Cg is probably the better choice. It's mostly a preference. There's little real difference between HLSL and GLSL. Random ranting: Use OpenGL! Don't contribute to the MS monopoly! Yadda yadda yadda!
Well said. Asm is cool, I can apreciate why you want to achieve something with it. Being "mildly" faster (at certain things only) doesn't offset making it slower to develop / test / refactor with (for the most part). But, hey - it's a free world - oh and didn't get the impression he was just talking about shaders, I thought "whole game" , so my post is kind of irrelevent
Then this is a very valuable resource for you: http://win.asmcommunity.net/board/ It's offline right now and will be for some days because of repeated DoS attacks, so the admin is changing the host company (which proved to not be really helpful). Been in that board for years (under another name) and I can guarantee you it's an excellent board.. thus don't be discouraged if the site is down, whatever is the number of trials you make. It will come back online sooner or later, and you'll find there all the help you may require with your project (I've done OpenGL and DirectX in asm too, so if you want help, PM me as well).
Yes, I do need a lot of help with ASM as it is really hard, and I have only found programming with the windows API for it
BTW, ProgrammingFreak - you seem to consider portability to be important factor, and in that case asm is a big no-no. cheers, Arkadesh
Oddly enough, this is less true now than ever now that Macs are in the process of being switched over to x86 chips. I mean, yeah, if you want ultimate portability to consoles and all sorts of niche devices or older Macs, asm is a no-no... but moving forward (since the Mac switch will take some time) the "Big 3" operating systems in wide use are all going to be primarily x86 based for most users. I don't really have a point here, this fact just amused me in a sick way.
Well C++ is for portability, while ASM is for speed, of course you can get good speed with C++, but ASM if faster obviously
ProgrammingFreak: I am a long assembly programmer and have not diminished my amount of asm with time, but beware: just coding in asm doesn't make programs faster, it can even make them slower. A skilled asm programmer can outperform any great compiler, but it takes work, it's not automagic. Also, expecially in asm speed=unreadability, thus you may want to use it only where it really matters.. for the rest why not use C or C++. You will still have all your chances to learn and improve asm till advanced because you'll code in asm the tricky parts of your programs that really need optimization, it would be a complete waste of your time to develop in asm e.g. initialization routines. Spend the time where it's most useful, e.g. optimizing inner loops. Maybe link OBJs, if you don't want to use the inline assembler of some C or C++ compilers. PS: the win32asm board seems back.. pay a visit there NOW!
Offtopic Well, Mac OS is in the Big 3 in the same way the Judaism is one of the Big 3 monotheistic religions, along with the Christianity and the Islam.