C# demoes with source or other frame works
category: code [glöplog]
What hardy said, I don't have a real engine/fw - it's more like a scaffolding, doing the meh parts and let's me do my thing - codewise it's not that shiny, but it's trimmed to be fast and just to enable me doing things.
Not sure how much of it is transverable to c#, but I have one "main class" - where i define my scene time offsets, which are given to my scenelist class that just makes sure stuff is initialized in time and deleted when it's not needed, that one calls init/render on my scene - and that's about it.
Things I abstracted away are sound (a fucking nightmare in JS) and the actual sync code - just because they'd suck to do over and over again.
I think what I want to tell you that keeping it barebones enables you to do things beyond your engine, if you want to fade scene into each other it's easier to be a bit off OOP and more dirty - just abstract what sucks and build from there :)
Also, there's no-one peeking at your code - so just get your gloves and code what you have in mind. For the next demo you'l already know what to improve, we won't be able to tell you that - as hardy said - we're only able to show you our way, it might not be the one that suits you =)
Not sure how much of it is transverable to c#, but I have one "main class" - where i define my scene time offsets, which are given to my scenelist class that just makes sure stuff is initialized in time and deleted when it's not needed, that one calls init/render on my scene - and that's about it.
Things I abstracted away are sound (a fucking nightmare in JS) and the actual sync code - just because they'd suck to do over and over again.
I think what I want to tell you that keeping it barebones enables you to do things beyond your engine, if you want to fade scene into each other it's easier to be a bit off OOP and more dirty - just abstract what sucks and build from there :)
Also, there's no-one peeking at your code - so just get your gloves and code what you have in mind. For the next demo you'l already know what to improve, we won't be able to tell you that - as hardy said - we're only able to show you our way, it might not be the one that suits you =)
The thing is, it seems to me you don't really have a clear idea on what you actually really want as far as the actual DEMO goes.
What that results in is that you're gonna have a sparkly shiny framework you can't ever finish (because when's a framework really ever finished?), but you never make a demo with it because "it's not ready yet".
So just start working towards a demo instead, think up something you actually want to do and then start figuring out what tech you need for it. The rest will take care of itself along the way.
What that results in is that you're gonna have a sparkly shiny framework you can't ever finish (because when's a framework really ever finished?), but you never make a demo with it because "it's not ready yet".
So just start working towards a demo instead, think up something you actually want to do and then start figuring out what tech you need for it. The rest will take care of itself along the way.
@xoofx thank you for the presentation link
That gave some great insight into SharpDX, and since you are the creator of SharpDX I want to ask this question.
Are you supposed to translate c++ with directx11 code into C# and SharpDX like one on one or should you use another principle?
I would think that there is the C# way of doing things.
@Hardy & @mog
What you are saying seems to be, just get going and learn from the mistakes. But what I thinking is this. Learn from what others have made and don't make the same mistakes.
Maybe I can give a concrete examle to something simple that buggers me.
I would like a scene view, with a free cam being able to use the mouse and keyboard to move freely arround the world. Then how would I make that.
Then my idea would be see what others did. Because they can show you how to do this in C# and using SharpDX. For instance i read something about not using C# events with SharpDX as it slows things down, so then what should I do? Again Nuaj, might show me how.
Doing it myself means this. Looking at C++ code and then trying to figure out how to do the same in C# and SharpDX. But they are not a one to one translation. So Basically I would have to become better at C++ and C# in order to understand how to make the translation, when all I wanted was to use C# and SharpDX for this simple example.
That is what my current problem is and are.
That gave some great insight into SharpDX, and since you are the creator of SharpDX I want to ask this question.
Are you supposed to translate c++ with directx11 code into C# and SharpDX like one on one or should you use another principle?
I would think that there is the C# way of doing things.
@Hardy & @mog
What you are saying seems to be, just get going and learn from the mistakes. But what I thinking is this. Learn from what others have made and don't make the same mistakes.
Maybe I can give a concrete examle to something simple that buggers me.
I would like a scene view, with a free cam being able to use the mouse and keyboard to move freely arround the world. Then how would I make that.
Then my idea would be see what others did. Because they can show you how to do this in C# and using SharpDX. For instance i read something about not using C# events with SharpDX as it slows things down, so then what should I do? Again Nuaj, might show me how.
Doing it myself means this. Looking at C++ code and then trying to figure out how to do the same in C# and SharpDX. But they are not a one to one translation. So Basically I would have to become better at C++ and C# in order to understand how to make the translation, when all I wanted was to use C# and SharpDX for this simple example.
That is what my current problem is and are.
Quote:
What you are saying seems to be, just get going and learn from the mistakes
Well, exactly - thing is, we all build our engines to suit us, if I give you mine you'd definitely think it sucks - you have to find your way. You will make mistakes, you will make things that you'll laugh about in a couple of months - but hey, that's what every coder feels like.
For the cam stuff, you need two modes - demo and demoMaking - look into https://github.com/kusma/rocket/tree/master/example_bass maybe this gets you an idea you didn't have before :)
@MRLB, basically, there is not lots of resources for what you are asking. If you know nothing about Direct3D11, you will have to learn how the API is working, and most of the resources out there are in C++, so yes, basically you need to understand a bit of C++ (but not so much, when just dealing with DirectX API). You should definitely read a book like "Introduction to Game Programming with Direct3D11" by Luna. Then you can go through some tutorials like Rasterteks DirectX 11 Tutorials. Someone even made a translation of these samples in "SharpDX for Rastertek tutorials". But they are still raw Direct3D11. The Toolkit in SharpDX is abstracting a bit of this, but there is not so much documentations (apart from all the samples and the sourcecode available).
If you find this route too difficult, well, just try to learn with XNA, there are plenty of resources out there. You won't find a framework with the method "DrawMySceneWithBeautifulEffectsPlease()". But as others said, you will have to get your hands dirty in order to learn, otherwise you can sit on top of your question for a while without coding anything.
If you find this route too difficult, well, just try to learn with XNA, there are plenty of resources out there. You won't find a framework with the method "DrawMySceneWithBeautifulEffectsPlease()". But as others said, you will have to get your hands dirty in order to learn, otherwise you can sit on top of your question for a while without coding anything.
Quote:
<3!But as others said, you will have to get your hands dirty in order to learn, otherwise you can sit on top of your question for a while without coding anything.
@mog thank you for the link ill look more into that
@xoofx
I bought the book and coded from that book. I also programmed raster tek tuts in cpp and lately sharpdx. But again it seems like a C# implementation of C++. Is that the correct way to do it?
Maybe the toolkit will give an idea of how to make a framework.
XNA seems like an engine. That is not what I want. I want to make my own framework, otherwise i could just use unity to make a game. But that wont teach me what I wanted to learn in this project. When I look at how things are done in the book and then som sharpdx samples, they are not at all the same.
And yes the purpose was to learn directx11, but doing so withoug using C++.
I exactly want to get my hands dirty, thats what I have been trying for a long time now, and then we have a loop :)
@xoofx
I bought the book and coded from that book. I also programmed raster tek tuts in cpp and lately sharpdx. But again it seems like a C# implementation of C++. Is that the correct way to do it?
Maybe the toolkit will give an idea of how to make a framework.
XNA seems like an engine. That is not what I want. I want to make my own framework, otherwise i could just use unity to make a game. But that wont teach me what I wanted to learn in this project. When I look at how things are done in the book and then som sharpdx samples, they are not at all the same.
And yes the purpose was to learn directx11, but doing so withoug using C++.
I exactly want to get my hands dirty, thats what I have been trying for a long time now, and then we have a loop :)
Loop is all you need :)
Quote:
XNA seems like an engine. That is not what I want. I want to make my own framework, otherwise i could just use unity to make a game
XNA is actually more a kind of framework than an engine (it doesn't provide scene management, integrated physics...etc.). But otherwise, as I said, the SharpDX Toolkit should give you enough insights about a framework on top of Direct3D11, but you will see that this is a substantial task even for a XNA like framework. It covers everything from content management, GPU resource constructors helpers, get/setdata on various resource, handling of all Views, effect framework (rebuild from scratch, because we cannot use legacy D3DX as It is not accessible on WinRT, WP8), texture loading (using WIC and custom DDS loader), font loading (using XNA xml description), model loading (using assimp for the model compiler), dynamic recompilation of shaders at runtime, msbuild task to automatically convert font/model to Toolkit format, + the various support of the different windows system (Desktop, WinRT, WP8). There is several months of work worth on in it
@xoofx
thank you.
I will have a look at the toolkit source you mention. It seems to be doing what I want. You have rebuild the effect framework. Is that nessesary on win7 as well? cauld I use the effect framework
in SharpDX instead i.e. the legacy one?
would there be any speed benefits to using the legacy effect framework?
I am on win7, so for my self I do not care about win8 yet.
Is it the same thing with the DDS loader? could I use the legacy one?
About assimp, if you use assimp, and I have not looked in the source yet, I would think you utilize everything, thus if I build my own I could just use only what I need right?
This dynamic recompilation of shaders, really makes me drool, that is awesome as I would like to be able to edit my shaders and the the result right away :)
For this thread I would also like to mention I had a look at anx framework and delta engine. I thought the delta engine costs money, but it is actutally Open source :)
Anyways, from I can see of it looking at the directx11 implementations they have. I seems like at slick and self explainable piece of work also.
thank you.
I will have a look at the toolkit source you mention. It seems to be doing what I want. You have rebuild the effect framework. Is that nessesary on win7 as well? cauld I use the effect framework
in SharpDX instead i.e. the legacy one?
would there be any speed benefits to using the legacy effect framework?
I am on win7, so for my self I do not care about win8 yet.
Is it the same thing with the DDS loader? could I use the legacy one?
About assimp, if you use assimp, and I have not looked in the source yet, I would think you utilize everything, thus if I build my own I could just use only what I need right?
This dynamic recompilation of shaders, really makes me drool, that is awesome as I would like to be able to edit my shaders and the the result right away :)
For this thread I would also like to mention I had a look at anx framework and delta engine. I thought the delta engine costs money, but it is actutally Open source :)
Anyways, from I can see of it looking at the directx11 implementations they have. I seems like at slick and self explainable piece of work also.
Weird to see how things evolved... few years ago, people would laugh at you claiming you are doing a demo in C#
c# is still killing y6our performance ;)
real democoders go c++ and use no OO at all.
real real democoders go c64 and assembler using no high language at all.
real real real democoders go washing machine processor and do their complete own thing outta this!
FUCK THAT!
everyone is allowed to code in whatever language/platform he likes ;) its just the demoscene...no rulez! only thing wanted: make demoshock to demosceners brain!
real democoders go c++ and use no OO at all.
real real democoders go c64 and assembler using no high language at all.
real real real democoders go washing machine processor and do their complete own thing outta this!
FUCK THAT!
everyone is allowed to code in whatever language/platform he likes ;) its just the demoscene...no rulez! only thing wanted: make demoshock to demosceners brain!
@norecess
there was a time when people laughed at those using C++ :)
I do not hate C++, it is just that C++, there is a time an place for using that. Use the correct language for your needs rather than trying to make everything with C++.
I also understand that Fortran should be faster than C++. At least with nummerical algorithms.
@hardy
I laughed :) at the washing machine thing hehe. And I think I would be cool to make a demo in C#. Not Java but C#. Nummerical computations are horrible in jave IMO.
there was a time when people laughed at those using C++ :)
I do not hate C++, it is just that C++, there is a time an place for using that. Use the correct language for your needs rather than trying to make everything with C++.
I also understand that Fortran should be faster than C++. At least with nummerical algorithms.
@hardy
I laughed :) at the washing machine thing hehe. And I think I would be cool to make a demo in C#. Not Java but C#. Nummerical computations are horrible in jave IMO.
@MRLB C# for tools / authoring / etc, C++ for run-time.
i am coming from amiga to your hearts. i just spread my juice all over both of you! :p
concrete: i started coding on 68k assembly, when i started coding on PCs i used c++, i had to have a laugh about myself once i released my first prod...c++! ;)
i dont fuckin care anymore nowadays...every language has its pros and cons...whomever wants to code in lisp, coblt or even BrainDead (yes, its a language!), DO IT! ;)
as long as a demo is the endproduct i have to laugh AT THAT in the end! ;)
concrete: i started coding on 68k assembly, when i started coding on PCs i used c++, i had to have a laugh about myself once i released my first prod...c++! ;)
i dont fuckin care anymore nowadays...every language has its pros and cons...whomever wants to code in lisp, coblt or even BrainDead (yes, its a language!), DO IT! ;)
as long as a demo is the endproduct i have to laugh AT THAT in the end! ;)
HINT: i am still using c++ nowadays, without any OO-stuf at all, not needed for demos, would slow stuff down maybe, never tested, never touched, just never needed anyway!
@xoofx: While we have your attention: Did you ever come up with a way to do 64k D3D or OGL comfortably in C# ?
@hardy
Well you must be old school then :)
C++ must really be high level for you then :) for me it is an outdated language.
Obj C is more up to data than C++. Just thinking about the compiler.
Obj C allready uses lvvm well it did years ago :)
Maybe vs2012 has a full implementation of the c++11 spec.
Anyways, backward compatibility fucks a language up.
coming to think about it. could you use C# for making a synth or a DAW without getting laggin in the sound or playback in the DAW?
Well you must be old school then :)
C++ must really be high level for you then :) for me it is an outdated language.
Obj C is more up to data than C++. Just thinking about the compiler.
Obj C allready uses lvvm well it did years ago :)
Maybe vs2012 has a full implementation of the c++11 spec.
Anyways, backward compatibility fucks a language up.
coming to think about it. could you use C# for making a synth or a DAW without getting laggin in the sound or playback in the DAW?
I use C++ because I can write low level-ish code which compiled with optimizations will be turbo fast and then use some OOP at the same time.
So if I was ever to write a synth, C++ it is.
So if I was ever to write a synth, C++ it is.
For synths speed = sound quality. I think Kb mentioned in his V2-articles, that some highlevel language for structure or control if you want, and assembly for heavily used "inner loops" is what to aim for.
Yup, as always its down to the quality of the compiler.
But often decent 'C' code will compile to be on-par with asm until you go into ultra-optimisation mode.
All too often these 'managed' high-level languages do introduce not only a performance overhead, but a memory overhead and dependencies on all kinds of libraries too - meanings its often a hassle to get them on someone elses machine and they tie you in or limit you platform wise.
For GUI development high-level languages help no end. (Some said on here elsewhere, perfect for demotools)
I'm not against OO, I'm currently sat here at work making an OS X app, which is my first ever Obj-C and first ever Mac app. My background is low-level hardware drivers, originally dos and dos protected mode, windows 3.11 drivers in asm, through all flavours of Windows, and Win32 API and MFC apps, and I write & design APIs for developers both our own, and customer facing to use.
But, Frameworks come and go and introduce problems of their own. We used to use driver::works to speed up some driver development but it had some bugs that we had to find & fix, it probably helped get the product out faster, but we paid for it down the line. We have also used GUI frameworks which go out of vogue or have bugs of their own.
So from my experience if you're writing "in the now" it doesn't matter, but if you want your code to still be useful and relevant in 2 years, then it might be worth thinking again or at least abstracting it enough so you can reuse/refactor it, depends what your goals are.
But often decent 'C' code will compile to be on-par with asm until you go into ultra-optimisation mode.
All too often these 'managed' high-level languages do introduce not only a performance overhead, but a memory overhead and dependencies on all kinds of libraries too - meanings its often a hassle to get them on someone elses machine and they tie you in or limit you platform wise.
For GUI development high-level languages help no end. (Some said on here elsewhere, perfect for demotools)
I'm not against OO, I'm currently sat here at work making an OS X app, which is my first ever Obj-C and first ever Mac app. My background is low-level hardware drivers, originally dos and dos protected mode, windows 3.11 drivers in asm, through all flavours of Windows, and Win32 API and MFC apps, and I write & design APIs for developers both our own, and customer facing to use.
But, Frameworks come and go and introduce problems of their own. We used to use driver::works to speed up some driver development but it had some bugs that we had to find & fix, it probably helped get the product out faster, but we paid for it down the line. We have also used GUI frameworks which go out of vogue or have bugs of their own.
So from my experience if you're writing "in the now" it doesn't matter, but if you want your code to still be useful and relevant in 2 years, then it might be worth thinking again or at least abstracting it enough so you can reuse/refactor it, depends what your goals are.
Well for starters without thinking of 64k demoes or something, I thought about trying it out in python first then maybee C#.
It would all depend if I playback is lagging or not. If not then no need to go further I would think.
For my it would be about making a synth that could make the sounds I want to make rather than something optimized for speed thing. Where I would guess you must comprimise
quality for speed?
@punqtured
Cool :)
Sometimes if the loop is not big maybe you can just write it out. For the assembly part. I would first compile the asm and then optimize that. However my skilz in asm is nil :)
I can read some parts of it but I have no real experience with it.
@Canopy
Since we in todays world can swim in memmory, why not use it and get better sound or speed?
When get to the part, in my big plan :), to make a synth I would make it for my machine only. Using frame-works will maybe let me get to the good parts where I want to code, rarter than boring stuff. So I am all for using Frame works. But code is a living thing, so if some frame work is out of data you can just use one that is up to data at that time.
I would say that is still faster than making everything yourself.
Speaking of iPhone apps. Apple do not care about backwards compatibility. So even if you make your own frameworks or tools, you will have to update them soner or later, when Apple dicides to make new changes :)
I hope you have a lot of fun making an app. If you don't know, Apple already inforces MCV pattern on you, so from the start you already have OOP :)
So from my experience, making an app that is usefull in 2 years is kind of impossible, since Apple changes the policies all the time. Which means you will never be out of a job hehe.
Making a synth, the front-end for 'creation' should of course being OO, and if used in a game or demo share an underlying framework with "tighter" code to playback efficiently. The rule is, only optimise when you know there's a problem, dont pre-optimise unless you have fore-knowledge that its really worthwhile.
btw. I'm not making a phone app, but a desktop Mac OS X application (corporate business stuff for my day job). :)
As far as the demoscene goes, Apple's OS X supports OpenGL and iOS supports OpenGL ES, as does Linux and pretty much every Android phone/tablet out there along with the SoC devices like the Raspberry Pi.
None of these platforms support DirectX/XNA. I used to code direct to framebuffer under DOS and use DirectDraw for framebuffer under Windows. I'm now learning GL as I want have my demo's and interactive things based off of my code run on both desktop GL and lower performance class devices like Rapsberry Pi and tablets that support OpenGL ES.
Obviously not all these platforms don't have the performance of Windows desktop GL running with the latest ATI/NVidia cards but they also don't have oodles of memory or CPU cycles to waste.
Also, coming soon are more devices using OpenGL like the Ouya and SteamBiox, plus whilst on PS3 it wasn't the main draw, there are also rumours OpenGL (ES?) will be the defacto graphics API n the dev side for PS4.
I believe these are the two emerging platforms which have common use of the two closely linked version of OpenGL are pushing PCs and laptops out of peoples homes which is why i'm learning and putting my energy there. (and also, OpenGL will of course run on PCs..)
(*Two emerging platforms, because 1) Is SoC classed non-PC performance comparable like iPad and Raspberry Pi, and 2) PS4 (if opengl is true), Steambox and to a lesser extent the Ouya)
btw. What I don't have sorted yet, is the other parts of the puzzle, particularly sound but I have a way to go before I tackle that part, also I will concede that OpenGL SDK support and documentation is pretty bad, as is the state of a lot of so called authoritative guides on the subject. I've learned only the newer "blue book" (Superbible) for desktop GL and for ES the "gold book" (OpenGL ES) are of use.
btw. I'm not making a phone app, but a desktop Mac OS X application (corporate business stuff for my day job). :)
As far as the demoscene goes, Apple's OS X supports OpenGL and iOS supports OpenGL ES, as does Linux and pretty much every Android phone/tablet out there along with the SoC devices like the Raspberry Pi.
None of these platforms support DirectX/XNA. I used to code direct to framebuffer under DOS and use DirectDraw for framebuffer under Windows. I'm now learning GL as I want have my demo's and interactive things based off of my code run on both desktop GL and lower performance class devices like Rapsberry Pi and tablets that support OpenGL ES.
Obviously not all these platforms don't have the performance of Windows desktop GL running with the latest ATI/NVidia cards but they also don't have oodles of memory or CPU cycles to waste.
Also, coming soon are more devices using OpenGL like the Ouya and SteamBiox, plus whilst on PS3 it wasn't the main draw, there are also rumours OpenGL (ES?) will be the defacto graphics API n the dev side for PS4.
I believe these are the two emerging platforms which have common use of the two closely linked version of OpenGL are pushing PCs and laptops out of peoples homes which is why i'm learning and putting my energy there. (and also, OpenGL will of course run on PCs..)
(*Two emerging platforms, because 1) Is SoC classed non-PC performance comparable like iPad and Raspberry Pi, and 2) PS4 (if opengl is true), Steambox and to a lesser extent the Ouya)
btw. What I don't have sorted yet, is the other parts of the puzzle, particularly sound but I have a way to go before I tackle that part, also I will concede that OpenGL SDK support and documentation is pretty bad, as is the state of a lot of so called authoritative guides on the subject. I've learned only the newer "blue book" (Superbible) for desktop GL and for ES the "gold book" (OpenGL ES) are of use.
hehe well yes I thought it was iPhone. My brain is sort of linked to iPhone when ever I hear ios :)
I started with OpenGL on Linux. Then found out the horror of gettings things to work and that you had to use other supporting libs for loading glsl or window creating like glut.
Not to mention you need a math lib also.
An then there is directx11 where you have everything you need. And since its on windows the drivers are optimized the most compared to Linux.
Basically it seems to me that OpenGL is lacking behind with the design an microsoft is moving forward. So thats why I am focused on Directx11.
I can always come back to OpenGL at a later time when I want to target other platforms like you :)
OpenGL ES seems to be a redesign of OpenGL so maybe its more modern.
for me right now, it is about to get started and make my little tool so that I can hopefully soon make a demo, and learn from that, like how much code does it take to implement a, b, c etc. and when I now that, I can go more low level if I want
The books you mention are great for teaching the basics.
What I did a while ago was to search for a lot of recommend Open source games to read the source code.
I dont know what you are trying to learn about OpenGL but my plan was to use the games and learn how they use OpenGL in a OOP manner, not using glut :)
I started with OpenGL on Linux. Then found out the horror of gettings things to work and that you had to use other supporting libs for loading glsl or window creating like glut.
Not to mention you need a math lib also.
An then there is directx11 where you have everything you need. And since its on windows the drivers are optimized the most compared to Linux.
Basically it seems to me that OpenGL is lacking behind with the design an microsoft is moving forward. So thats why I am focused on Directx11.
I can always come back to OpenGL at a later time when I want to target other platforms like you :)
OpenGL ES seems to be a redesign of OpenGL so maybe its more modern.
for me right now, it is about to get started and make my little tool so that I can hopefully soon make a demo, and learn from that, like how much code does it take to implement a, b, c etc. and when I now that, I can go more low level if I want
The books you mention are great for teaching the basics.
What I did a while ago was to search for a lot of recommend Open source games to read the source code.
I dont know what you are trying to learn about OpenGL but my plan was to use the games and learn how they use OpenGL in a OOP manner, not using glut :)
Yeah the supporting stuff around GL is a bigger put off for people i'm sure. It's certainly made me think twice, and if it weren't for my cross-platform ambitions I would have jumped ship to DirectX/XNA long ago.
But OpenGL is moving, Lots of desktop OpenGL has been heavily deprecated to make people use more streamlined / hardware friendly methods that have been going in since 2.1 and it has lots of new features to match DirectX structures. (vendor driver quality is another issue ATIs DLL crashes if you do things wrong, but they do provide the brilliant gDEBugger tool too)
With OpenGL ES 2.0 they have helped on this front with EGL and there are rumours something EGL like is coming for desktop GL too. (ES is based upon the parts of desktop GL 2.1 that haven't deprecated). Plus OpenGL (4.2 i think) has a compatibility profile for OpenGL ES 2.0.
Stories like this also help with OpenGL momentum : http://www.extremetech.com/gaming/133824-valve-opengl-is-faster-than-directx-even-on-windows.
I really believe that we're on the edge of a shift away from Windows and towards OpenGL as every other platform under the sun uses it.
For my own stuff, I've also forgone GLUT and am only using GLEW, linked via a static library, all my window management is my own, under windows 've also got the window and its message pump in its own thread, with a rendering context and the main rendering loop in another.
I've got a super light weight bit of code that gets me going without dragging in too any other libraries and also have this cross building for OpenGL ES under windows for the AMD and Mail SDKs (but i'm not focusing on that). Down the line I'll port it to linux under virtualbox and to the Raspberry Pi (my low powered SoC test target platform) but I've done my ground work and am using my base code to actually make stuff now.
But OpenGL is moving, Lots of desktop OpenGL has been heavily deprecated to make people use more streamlined / hardware friendly methods that have been going in since 2.1 and it has lots of new features to match DirectX structures. (vendor driver quality is another issue ATIs DLL crashes if you do things wrong, but they do provide the brilliant gDEBugger tool too)
With OpenGL ES 2.0 they have helped on this front with EGL and there are rumours something EGL like is coming for desktop GL too. (ES is based upon the parts of desktop GL 2.1 that haven't deprecated). Plus OpenGL (4.2 i think) has a compatibility profile for OpenGL ES 2.0.
Stories like this also help with OpenGL momentum : http://www.extremetech.com/gaming/133824-valve-opengl-is-faster-than-directx-even-on-windows.
I really believe that we're on the edge of a shift away from Windows and towards OpenGL as every other platform under the sun uses it.
For my own stuff, I've also forgone GLUT and am only using GLEW, linked via a static library, all my window management is my own, under windows 've also got the window and its message pump in its own thread, with a rendering context and the main rendering loop in another.
I've got a super light weight bit of code that gets me going without dragging in too any other libraries and also have this cross building for OpenGL ES under windows for the AMD and Mail SDKs (but i'm not focusing on that). Down the line I'll port it to linux under virtualbox and to the Raspberry Pi (my low powered SoC test target platform) but I've done my ground work and am using my base code to actually make stuff now.