pouët.net

Scali, you're spot on about the bad state of tutorials and modern GL, this DOES also include expensive text books. In fact, the only two books I've found worth a damn are the latest edition of the Super bible, and the 'gold book' on OpenGL ES 2.0.

Previously I wrote stuff for DOS, then used Direct Draw before learning GL in '99, a HDD crash killed my enthusiasm for quite a while.. I nearly lost everything I'd ever done, recovered a few bits..

I came back to graphics programming via a funny path, I started out wanting to learn OpenGL ES (using a Windows library to simulate) as I have an idea for something I want to try on tablets (I'm waiting for a truely open linux tablet), and have ended up using Modern GL.

Modern GL is darn unwieldy you're almost forced to write a scene manager. Its a real struggle to not get sucked into writing a *spits* 'engine' to distract you from actually writing "cool shit".

A bit OT.. but this 'API' choice, and maze to navigate must really be detrimental to the demo scene?

Do not listen to anyone who tells you a "go with" bla bla bla thing.

Choosing a API totally depends on what you want to achieve, what hardware you have and bla bla bla.

Some things one might want to consider (list is incomplete and maybe a bit biased):
- Are you going to do something on Android/Apple devices later? -> OpenGL
- Linux? MacOS? $RandomOSwhichIsNotWindows? -> OpenGL
- Do you have some Windows Phone thing and want to develop for that? -> DX
- Sizecoding? DX/GL APIs are quite good for sizecoding - OpenGL will need, well a bit more care if you target windows, since you have to use wglGetProcAddress("STRING") or do some fancy stuff to import the newer GL Functions...
- Debugging Comfort? -> Nice with both, DX has some pretty neat visual studio integration; with some effort you can also have nice OpenGL error handling/debugging stuff (look at the "new" debug extension things). Also knowing the proper tools helps.
- Performance? Well, both are good, next paragraph might be interesting.
- Compute Shaders? Both APIs have it in their latest versions.
- Bugs? Both APIs have them. Especially shadercompiler bugs can be quite nasty.
- Special Features: Sometimes a special feature is only supported by one of the two APIs (e.g. scattered writes from all shaderstages are not supported in DX11 - should be in DX11.1 iirc, in GL 4.3 they are supported).
- Vendor support? This one might be nasty, if you want latest GL stuff, well that's way better supported on NV. AMD/ATI is a bit with supporting the latest OpenGL stuff. NV is not so great when it comes to DX11.1 - seems they still don't support it.
- Make it run on almost all windows desktop machines with sufficient hardware? Possible with both. See Vendor support, Bug stuff and so on - might be easier with DX and totally depends on what you are doing.

I use DX and GL at work, most of the time we use the DX versions of our prototypes for performance measurements, since they seem to be faster most of the time (that's totally implementation (both driver and your code) depended.).

For demoscene stuff I code GL most of the time - when we started writing larger shaders, the NV GLSL shadercompiler was magnitudes faster than the DX one, it's a bit better now, but if I recall correctly at least the NV shadercompiler is still a bit faster than the HLSL one.

If you can't decide - knowing multiple APIs isn't bad either.


That knowledge might be VERY handy at some point:
Want to debug with some simple visualization and you do not have a huge framework that nicely encapsulates "everything" - e.g. line drawing? Hack it together with oldschool GL and glUseProgram(0).

For math libraries - there are good libraries which get the job done properly. For GL prototypes I use glm, which is really convenient. For DX there are DX Math things - which are "ok" to use too. If you are going to do something size limited... well you should take care what you use - everywhere.

you don't have to rewrite anything if you don't even start with fixed function. as the OP has not started anything yet, there is nothing to rewrite.



nice... just learn legacy api... NO! go the right way, use the current apis. not only fixed function opengl is slow (and someone already mentioned that for dx 9 as well, at least for shaders), not knowing a little about the math behind it and how and which matrices you need to multiply makes it hard to understand what's going on anyway. there is good documentation available on that topic, so why not just learn it right from the beginning instead of getting used to the legacy api and then facing the problem.

Some personal recommendations:
As already mentioned: Use something somewhat current, DX9 might be great for some special sizecoding/4k things but is not really worth it nowadays and with oldschool GL you don't have shaders and all the fancy things...

Something that has been mentioned between the lines here:
If you want to do computer graphics coding, you will most probably see a lot of equations, linear algebra and stuff - before diving into the coding part, it's really helpful to refresh your math skills (You can also do that by playing around with the code and directly seeing some visual results of some function etc.).
It is more important to understand the algorithms and math behind the different methods than being able to use a certain API. The math skills you will acquire might be the most valuable thing in the whole process.

If you fear dealing with matrices and vectors - you know where to start.

I'd hate to repeat myself over and over again, but I clearly said that starting out with D3D9/D3DX was a good way to learn about matrices and other math, because you don't have the bootstrapping problem of having to do everything at once.
Aside from that, the D3D SDK explains all the matrix math and how the matrices are applied in different stages of the pipeline, so you get all the information you need to get started.
First get something on screen, then try to convert the fixedfunction stuff to shaders.

If you start with D3D10+ or modern OpenGL, you can't get anything on screen until you actually know how to write the shaders, which just makes it a lot more difficult for beginners.

+1 for going exclusively with modern APIs. GL4-core etc. Fixedfunction GL has waaay more global state - horrible to learn, horrible to work with. Newer stuff is simpler to use, easier to learn, and harder to mess up.

Progress \o/

If you're starting to learn now, then consider what kind of software you'll want to code and for what kind of devices *in a couple of years*. No point learning something, then at the point when you're starting to really master it you want to code for something else and you start again :)

Apart from that, what everyone else said. Learn the latest APIs (DX11, OpenGL 4, OpenGL ES 3). If you're planning on sticking with PC/Windows, DX11 is a good option (I'm ignoring windows phone there, since it has such a tiny market share it's not worth considering at this point). Anything else, OpenGL (ES if you want to support mobile/tablet/webgl, regular if you want to stay only on the desktop).

This tutorial might be a place to start with modern gl: http://www.arcsynthesis.org/gltut/index.html

I consider - what you recommend - harmful.
A waste of time: D3DX is dead, deal with it. The latest DX SDK uses DirectXMath.
Using glm or the DirectXMath stuff is not much harder then doing it with the old deprecated and dead D3DX stuff.

I for myself like the combination of glm & OpenGL - since you will basically use the same math functions in your CPU code as in you GLSL code - and you can quite easily convert a piece of GLSL code to CPU code and vice versa.

There are tons of good ways to learn the required math, writing a simple software rasterizer might also be a pretty good exercise. Reading the math primer of some random computer graphics book might also help way more than learning something basically dead. Writing your own small vector math library isn't a bad decision either.

thank you las, this is exactly what i wanted to say.

Well, I don't.



So? I never said that you should continue using D3D9/D3DX after you learnt the basics. I just said it was a good place to start.



Then you will agree that after you learnt the basics with D3D9/D3DX, it is trivial to move to glm, DirectXMath or whatever other up-to-date library you may want to use when the time comes.



Okay, so you're arguing against using a somewhat outdated, yet well supported and well-documented API... but writing an entire software renderer from scratch (and then tossing it out because you will use modern D3D/OGL) is not ... harmful?
Sense is none.



Again, complete nonsense. Yes, D3D9 is somewhat outdated, but the pipeline and mathematics are well-documented, and they are still every bit as valid for modern D3D/OGL as they were for D3D9.

Start here for example: http://msdn.microsoft.com/en-us/library/windows/desktop/bb173466(v=vs.85).aspx
Even if you want to write a software renderer, there's a ton of useful information in there.
Coordinate systems, transforms, lighting mathematics etc. It's all there.

i have the feeling someone likes directx here! ;)

Funny, I had the feeling that there were a bunch of OpenGL-fags who couldn't give credit where credit is due.
But if you must be an OpenGL-fag, and ignore my advice to start with D3D, you could start with my open source OpenGL renderer: http://sourceforge.net/p/bhmfileformat/code/ci/default/tree/BHM3DSample/
It's not as nicely documented as D3D9/D3DX, but it will get you started with more or less the same basic functionality (easy texture loading, a simple math library, shader compiling helper functions etc), and all that in a modern OpenGL form, which can be ported to Android or iOS easily (I've already done that myself, but not included that code on SF).

this thread will be useful : https://www.pouet.net/topic.php?which=138&page=11#c382080

redo: I advice you to use OpenGL, because <lot of awesome text>.

oh yeah, nice again... since you pretty much said: "oh noez, after using fixed pipeline legacy old fashioned stuff it's hard to do modern stuff". so you say it's a good idea to learn the legacy api just to relearn everything later?



pretty simple it should be, but why not doing it with glm/directxmath right away if it's basically the same?



why is an excersize for the math harmful? it is not the case, that you learn about matrix calculations or projection matrices in the lagecy apis, because you just define a frustum and the whole matrix is calculated by the lib for you. so you learn close to nothing...

Thanks to all people, for their knowledge and help in choosing API. I will take the modern OpenGL because I have basics of it including shaders, buffers, glm. There are also shadertoy, GLSL editor in chromeexperiments and many more. Special thanks for long and interesting(in depth going) answers like las,... I have learning material as well,
http://www.opengl-tutorial.org/
http://arcsynthesis.org/gltut/
http://ogldev.atspace.co.uk/index.html

That was about OpenGL. I didn't say it was hard, I just said that you had to rewrite your code anyway, if you moved from legacy OpenGL to modern OpenGL.
So you might as well go from D3D9 to modern OpenGL, or D3D10+.



I'm not saying you should learn the entire API. I'm saying you should play around a bit with it and learn the basics of 3D rendering, maths, shaders etc. This won't require you to learn all that much about the API, or write all that much code. Especially if you use all the sample code included in the D3D9 SDK. So 'relearning' is not such a big deal.



As I said, there is the bootstrapping problem. In D3D9 you can start by just feeding some matrices to the pipeline, and the fixedfunction pipeline will do the rest, and you get things on screen.
Then you can start playing around with the matrices, moving functionality to vertex shaders etc. It's just a more gradual approach, with more feedback along the way.



Again, look at the link I posted above. Yes, the lib will do everything for you, but Microsoft's documentation tells you EXACTLY what the lib does. It tells you how the matrix is calculated, and what the ideas behind these calculations are (viewing frustum, clipping planes etc). So you can read their explanation, and once you understand it, you can steal their code and use and modify it for your own shaders.

I get the distinct impression that you've never even bothered to look at the D3D9 documentation, else I wouldn't have so much trouble explaining why it is such a nice resource for beginners.

Good luck!

Its ever growing, but i bung all kinds of GL related links on this page here for later reference or review.. the last thing i implemented in my personal framework was support for render to buffer.

http://www.protopage.com/canopyseer#Untitled/Development

I wouldn't recommended my route however. I'm being a bit of a masochist and outside GLEW everything, including math is done by hand, I'm also avoiding C++ and trying to use a lightweight simplified set of helper routines that mostly just use little structs and linked lists to manage everything. I'm only creating helpers for things I have a genuine need for, as and when I need them.

Thanks

You can for a 3D API but you forget to explain the reason you need that...

do you need this for games, democoding, live shows, visualisation software, ... ?

You can => You ask
(stupid pouet.net interface, that in 2013, still not allow edit...)

great thing it preserves all the drunk postings and stuff :D

I wanna it for games, democoding, maybe visualisation.

Look at the market shares of personal computing devices and platforms. What percentage uses some flavour of OpenGL? How about DirectX? Anyway. After reading all these comments, do you think you'll win much by making the "right" choice? How many days has this bullshit thread been going? That's the number of days spent not actually learning anything.