i was wondering if anyone has experience or technical information for opengl 2.0 and directx 8.0b. what i specifically wanted to know or ask is trying to see which version of opengl roughly is equivalent to directx 8.0b or what version of directx is equivalent, again, ( roughly ) to opengl 2.0. now i know the two programming api's are a bit different such as opengl not supporting sound in which it would require something like opengl, but they do both have support for pixel and vertex shader and opengl being cross platform so i can hypothetically have a larger audience / support. so i researched GLSL, and the closest type of comparison i got was opengl 2.1 being similar to that of directx 9.0's shader and vertex model, but i was not able to find such information for opengl 2.0 that uses GLSL version 1.10.59.

other than the technicalities of these matters, it would also be important for me to know if opengl 2.0 is good to use / stable and also how much different opengl 2.1 is from 2.0. i understand that directx includes things such as directsound where opengl would require a third party source like openal for sound, however, these aren't much of a problem for me as so much the type of pixel shader / vertex shader support, efficiency, and capabilities. now you might ask, why use opengl 2.0 or directx 8.0b, the reason for that is that i would like to program a 3D game under windows 95 as a unique nostalgic project of my mine, and these two api's are the newest supported under windows 95. the geforce 6 series, particularly the geforce 6800 gt supports opengl 2.0 under windows 95 with it's forceware 81.98 driver and slightly older ones too. 

i'd being the directx 8.0a sdk + 8.0b libraries with visual studio 6.0 or opengl 2.0 + openal, glut, etc + visual studio 6.0. 

i looked at these models of opengl 2.1 vs directx 9 and 10 and the opengl 2.1 looked pretty nice, below is the image url - 

Roughly... GL1.x <-> D3D 1-8, GL2.x <-> D3D9, GL3.x <-> D3D10, GL4.x <-> D3D11, Vulkan <-> D3D12.

51 minutes ago, directx8.0a said:

opengl being cross platform so i can hypothetically have a larger audience / support

OpenGL has a common (text) specification, but is then implemented from scratch in each driver. That means that AMD's implementation is completely different to NVidia's implementation. It's very easy to write code that will work on a particular GPU under either Windows or Linux (portable), but won't run at all on a different GPU ;( 

D3D has a common core (written by Microsoft) which is always the same no matter who makes your driver/GPU. Also, Microsoft actually tests that drivers conform to their text specification, so you know that your code will work the same everywhere. Also, D3D9 runs very well on Linux under Wine, and there's open source projects that allow D3D11 and D3D12 to run perfectly on Linux these days too

Lastly, GL1 / GL2 / D3D8 are deprecated / unsupported by almost everyone these days. You won't get much support for them any more. You're much more likely to get decent support for GL3/4, Vulkan or D3D11.

51 minutes ago, directx8.0a said:

i'd being the directx 8.0a sdk + 8.0b libraries with visual studio 6.0 or opengl 2.0 + openal, glut, etc + visual studio 6.0. 

Are you targeting PC's from the 90's? If so, that development environment makes sense... Otherwise that is an extremely outdated set of tools, and you're going to spend a lot of time trying to make them be compatible with modern systems (and writing MSVC6 C++ code, which is NOT standard C++ at all!!) for no reason.

51 minutes ago, directx8.0a said:

i would like to program a 3D game under windows 95 as a unique nostalgic project of my mine, and these two api's are the newest supported under windows 95.

Ok. In this case you're going to have to deal with whatever windows 95 drivers / hardware you can actually dig up  It's likely you might run into driver bugs (e.g. a shader that should work, but doesn't) and you won't be able to just update the drivers to fix it  

Honestly, going for an API without shaders might be the best choice for Win95. Open GL1.x or D3D8 with the fixed function pipeline should be pretty stable. Or go fully old-school and write a software rasterizer  

If you want to get the most out of a GeForce 6800 in that environment, then yeah, GL2 is the way to go, along with all of the NVidia extensions that are specific to the 6800. Just keep in mind that this code won't be portable to other systems (or even to newer GPUs!).

45 minutes ago, Hodgman said:

Roughly... GL1.x <-> D3D 1-8, GL2.x <-> D3D9, GL3.x <-> D3D10, GL4.x <-> D3D11, Vulkan <-> D3D12.

OpenGL has a common (text) specification, but is then implemented from scratch in each driver. That means that AMD's implementation is completely different to NVidia's implementation. It's very easy to write code that will work on a particular GPU under either Windows or Linux (portable), but won't run at all on a different GPU ;( 

D3D has a common core (written by Microsoft) which is always the same no matter who makes your driver/GPU. Also, Microsoft actually tests that drivers conform to their text specification, so you know that your code will work the same everywhere. Also, D3D9 runs very well on Linux under Wine, and there's open source projects that allow D3D11 and D3D12 to run perfectly on Linux these days too

Lastly, GL1 / GL2 / D3D8 are deprecated / unsupported by almost everyone these days. You won't get much support for them any more. You're much more likely to get decent support for GL3/4, Vulkan or D3D11.

Are you targeting PC's from the 90's? If so, that development environment makes sense... Otherwise that is an extremely outdated set of tools, and you're going to spend a lot of time trying to make them be compatible with modern systems (and writing MSVC6 C++ code, which is NOT standard C++ at all!!) for no reason.

Ok. In this case you're going to have to deal with whatever windows 95 drivers / hardware you can actually dig up  It's likely you might run into driver bugs (e.g. a shader that should work, but doesn't) and you won't be able to just update the drivers to fix it  

Honestly, going for an API without shaders might be the best choice for Win95. Open GL1.x or D3D8 with the fixed function pipeline should be pretty stable. Or go fully old-school and write a software rasterizer  

If you want to get the most out of a GeForce 6800 in that environment, then yeah, GL2 is the way to go, along with all of the NVidia extensions that are specific to the 6800. Just keep in mind that this code won't be portable to other systems (or even to newer GPUs!).

thanks for the reply, although some of the things you mentioned are obvious and i already pointed out such as another source that placed directx 9.0 as similar to opengl 2.1, and so there are some questions unanswered. i did a quick google search on wikipedia on opengl, i didn't actually compare the 2.1 vs 2.0 there from before but it seems that 2.1 isn't much different from 2.0 from what is given in the site. 

when you say though that the code for gl2 won't be portable to other systems, why or how so? i would have though newer versions of opengl are backwards compatible all the way till opengl 2.0 or older? 

i also should mention that i may want to code / develop on windows 95 itself, although, my intention or incentive for that as a complete newbie is that logically speaking, if i were to develop on windows 95 since i would like the game to work on it, then it would ensure running it given what the operating system is built from and what it's capabilities are so you do not have to worry about making certain mistakes. 

although, realistically or hypothetically, windows 2000 would be a better choice. but this would be a team project of course, where i wouldn't be doing the coding myself, i'd have coders in the team, where i would simply be designing / supporting other elements like artwork, story, etc. this is why it wouldn't be necessary to code on windows 95 since you can do everything on the more stable windows 2000 system which i presume you would not run into any problems, with the assumption you make everything necessary to be compatible to work properly on windows 95 such as ANSI C, which i was also gonna see what limitations are there in that vs the full unicode support that 9x systems do not properly support. 

am i right or wrong that you can't develop unicode applications on w9x but that you can get unicode apps from other systems to work on 9x partially? i never understood these things. 

also with the whole visual studio 6.0 aspect, i've only been told that there is some directx 8 visual basic type of file that may not register on windows vista or newer till windows 10, but all that needs to be done is registering it via administrator mode, however, i also understand that there are many other implications or obstacles, and hopefully i can gradually get more answers or solutions to that. 

5 hours ago, directx8.0a said:

also with the whole visual studio 6.0 aspect, i've only been told that there is some directx 8 visual basic type of file that may not register on windows vista or newer till windows 10, but all that needs to be done is registering it via administrator mode, however, i also understand that there are many other implications or obstacles, and hopefully i can gradually get more answers or solutions to that. 

I had visual studio 6.0 running up until windows 7 and I think windows 8, quite a few people do for legacy apps. There is some small hurdle during install, I forget which but some googling will get you past it. There may be issues with particular service packs and versions of DirectX, do some googling on that and be careful which service packs you install, I have some vague memory of DX9.c being a last version supported at some point.

Win95 was rubbish for development of 3d, I have an inkling feeling that many 3d errors got you a hard crash (i.e. reboot). It wasn't until NT kernel and Win2000 that it became feasible to debug because they caught these errors without a blue screen of death.

You can probably get some of this stuff working in a virtual machine, just depends on what installation files you can get your hands on. Even via dodgy channels you might be hard pressed to find some of the SDKs etc, and I doubt you'd find them legit as a lot of companies don't offer downloads / support for anything over 6 months old. You might have more joy with old open source versions of things than the official MS versions (MingW?).

Bare minimum though you don't need visual studio, you need some old school windows headers and libs, and old school graphics API headers and libs, and a suitable compiler that will read these libs. There was a free set of bare minimum MS compilers and build tools in around 2003, these may work to make something for win95.

What you will be working against is that MS have actively tried to break backward compatibility of their dev tools / SDKs with older versions of windows.

As with Hodgman I would advise using fixed function pipeline rather than trying to deal with incompatibilities of shaders on 20 year old systems. Fixed function was still very much a thing up to somewhere around Dx9. You could use it on original xbox too, which was just a slightly modified dx8c or maybe dx9 I can't remember. A better hope may have been to develop for original xbox in fact, at least it had fixed hardware and a shockingly sensible design. I think there was a project to try and reverse engineer it for emulation, but unfortunately even the original designs seem lost in the mist of time.

On the OpenGL front a lot of ye olde school OpenGL you can still run now on modern hardware I think. That's both a plus and a negative of OpenGL, a lot of historical cruft. That's why they chucked out all the historical stuff for OpenGLES.

Overall though I wouldn't advise it, it wasn't particularly pleasant at the time and you might find some lack of something preventing it working, and no one will be interested in downloading what you make. If you want to have the same kind of fun limiting yourself and dealing with rubbish compatibility I'd suggest developing for mobiles on OpenGLES. At least then people will actually be interested in what you make. Other than that for old school I'd recommend working for a fixed platform emulator, not PC.

Also I wouldn't advise working on any of this as a newbie. It is not going to be easier than working with modern stuff, far from it.

9 hours ago, lawnjelly said:

I had visual studio 6.0 running up until windows 7 and I think windows 8, quite a few people do for legacy apps. There is some small hurdle during install, I forget which but some googling will get you past it. There may be issues with particular service packs and versions of DirectX, do some googling on that and be careful which service packs you install, I have some vague memory of DX9.c being a last version supported at some point.

Win95 was rubbish for development of 3d, I have an inkling feeling that many 3d errors got you a hard crash (i.e. reboot). It wasn't until NT kernel and Win2000 that it became feasible to debug because they caught these errors without a blue screen of death.

You can probably get some of this stuff working in a virtual machine, just depends on what installation files you can get your hands on. Even via dodgy channels you might be hard pressed to find some of the SDKs etc, and I doubt you'd find them legit as a lot of companies don't offer downloads / support for anything over 6 months old. You might have more joy with old open source versions of things than the official MS versions (MingW?).

Bare minimum though you don't need visual studio, you need some old school windows headers and libs, and old school graphics API headers and libs, and a suitable compiler that will read these libs. There was a free set of bare minimum MS compilers and build tools in around 2003, these may work to make something for win95.

What you will be working against is that MS have actively tried to break backward compatibility of their dev tools / SDKs with older versions of windows.

As with Hodgman I would advise using fixed function pipeline rather than trying to deal with incompatibilities of shaders on 20 year old systems. Fixed function was still very much a thing up to somewhere around Dx9. You could use it on original xbox too, which was just a slightly modified dx8c or maybe dx9 I can't remember. A better hope may have been to develop for original xbox in fact, at least it had fixed hardware and a shockingly sensible design. I think there was a project to try and reverse engineer it for emulation, but unfortunately even the original designs seem lost in the mist of time.

On the OpenGL front a lot of ye olde school OpenGL you can still run now on modern hardware I think. That's both a plus and a negative of OpenGL, a lot of historical cruft. That's why they chucked out all the historical stuff for OpenGLES.

Overall though I wouldn't advise it, it wasn't particularly pleasant at the time and you might find some lack of something preventing it working, and no one will be interested in downloading what you make. If you want to have the same kind of fun limiting yourself and dealing with rubbish compatibility I'd suggest developing for mobiles on OpenGLES. At least then people will actually be interested in what you make. Other than that for old school I'd recommend working for a fixed platform emulator, not PC.

Also I wouldn't advise working on any of this as a newbie. It is not going to be easier than working with modern stuff, far from it.

thanks for the info, i'm not sure if i mentioned this or not but i do want to make it clear that when i say develop for windows 95, it doesn't mean that it only works for windows 95. it just means that it can work on windows 95, but obviously for 99 percent of the people or more, they can and would run the game on operating systems such as windows 7 or windows 10. 

the part about it working on windows 95 was simply a unique aspect i had of testing the limits on certain software, however, the questions of opengl 2.0 compatibility remains unclear. i did do some google searching and i'm pretty sure people have got things working up to windows 10 with opengl 2.0 or even 1.4/1.5, and if they didn't work directly, there was some kind of update or file you would need as a small inconvenience to get them running for forwards compatibility. 

so far i have written down fixed function pipeline, mingW, and software rasterizer as relevant to the programming aspect, as well as using windows 2000 as a possible candidate for the development platform. 

I'm probably a developer who uses the oldest version of OpenGL for making commercial products. Right now I use OpenGL 2.1. I could not go any lower than that, I would say it's an absolute minimum for a game (and that's assuming you don't need anything fancy). Could not go for 2.0, 2.1 is the absolute minimum for me.

The most humorous part is I still (year 2019) get reports from players they can't run my games because they do not have hardware that supports OpenGL 2.1 Hillarious