i was wondering if developing a game using the fixed function pipeline in the older supported opengl / directx api's such as opengl 2.1 or directx 8.0a would allow being forwards compatible with newer graphics cards / operating systems? for example, if i had a windows 10 system that used something like the gtx 1660 ti graphics card, would my game still work properly on the windows 10 system? the reason why i would rather use the fixed function pipeline is because from what i was told elsewhere in my thread and others, that it may be more compatible and less likely that i would encounter drawing problems / non working pixel / vertex shaders, and so i can still do what i wan't such as making realistic water, lighting, shadows, etc. i can go as old as opengl 1.4 or directx 8.0a, although i prefer opengl 2.1 or directx 8.0a + 8.0b libraries for this custom project. 

i feel like the question(s) for all this are very straightforward but i haven't really gotten a straightforward response anywhere to see if this project i have in mind or methodology can be done or not.

I used to use OpenGL 1.x / GLUT to do prototypes, but now I do them in Unity (using "Gizmos"). If you want to talk about cross-compatibility, Unity supports like a dozen platforms, and it's tested to the hilt.

The simple answer is that even _if_ a future OS/driver breaks support for existing fixed-function APIs, you can always emulate those APIs on newer hardware. 100% for sure, OpenGL 1.x and DX8 still work in Windows 10 with the latest hardware, at least for now.

To be clear, no hardware today supports those fixed-function APIs. They all emulate them in the driver layer by mapping the fixed-function calls to builtin pipelines and shaders that implement the old fixed-function features. If in some future the drivers drop that back-compat support, you could always replace your use of fixed-function APIs with the appropriate modern APIs/shaders yourself.

That said, there are enough popular OpenGL/DX9 apps that I doubt back-compat will be severed entirely anytime soon on mainstream platforms (Windows). I'm surprised Apple hasn't already killed complete OpenGL support, but even if they do, there's already libraries that implement OpenGL over Metal (and over DirectX, for Windows) so you'll be fine.

Just be sure to cleanly separate your use of the API from the rest of your game and it'll be "easy" to port the graphics layer to a newer API if and when it becomes necessary.

All that said, if you're wanting fixed-function graphics without having to write shaders, and would be considering using raw DX8 as an option, perhaps consider something like https://github.com/Microsoft/DirectXTK instead. It is a wrapper over D3D11 that provides a bunch of "basic" rendering support (just as easy or even easier than the equivalent DX8) while also letting you explore and grow into full D3D11 down the road if you want.

Your worries of compatibility are probably unfounded. Unless you're doing something particularly fancy, the basics of vertex buffers and basic shaders will be quite reliable. Every single piece of up-to-date visible software running on your desktop/phone/tablet/smartwatch right now depends on the modern graphics APIs and features being quite stable.

4 hours ago, SeanMiddleditch said:

The simple answer is that even _if_ a future OS/driver breaks support for existing fixed-function APIs, you can always emulate those APIs on newer hardware. 100% for sure, OpenGL 1.x and DX8 still work in Windows 10 with the latest hardware, at least for now.

To be clear, no hardware today supports those fixed-function APIs. They all emulate them in the driver layer by mapping the fixed-function calls to builtin pipelines and shaders that implement the old fixed-function features. If in some future the drivers drop that back-compat support, you could always replace your use of fixed-function APIs with the appropriate modern APIs/shaders yourself.

That said, there are enough popular OpenGL/DX9 apps that I doubt back-compat will be severed entirely anytime soon on mainstream platforms (Windows). I'm surprised Apple hasn't already killed complete OpenGL support, but even if they do, there's already libraries that implement OpenGL over Metal (and over DirectX, for Windows) so you'll be fine.

Just be sure to cleanly separate your use of the API from the rest of your game and it'll be "easy" to port the graphics layer to a newer API if and when it becomes necessary.

All that said, if you're wanting fixed-function graphics without having to write shaders, and would be considering using raw DX8 as an option, perhaps consider something like https://github.com/Microsoft/DirectXTK instead. It is a wrapper over D3D11 that provides a bunch of "basic" rendering support (just as easy or even easier than the equivalent DX8) while also letting you explore and grow into full D3D11 down the road if you want.

Your worries of compatibility are probably unfounded. Unless you're doing something particularly fancy, the basics of vertex buffers and basic shaders will be quite reliable. Every single piece of up-to-date visible software running on your desktop/phone/tablet/smartwatch right now depends on the modern graphics APIs and features being quite stable.

thanks for the info, although, i should have maybe put a link to my other to thread which explains why i have this particular project / goals in mind. the thread is below, my intention was to see how far one can possibly go with older software capabilities, fixed function pipeline being one of them and allow the developed app to work all they way from windows 95 till windows 10. i wanted to create something partly nostalgic but also unique and sort of one of a kind in a way such as more realistic looking water which would have not looked at realistic or nice back then.

and so directx 8.0b or opengl 2.0 came to my mind since these worked on windows 95 if one was using a newer gpu such as the geforce 6800, and then i was told about the fixed function pipeline, and although i still like to do the programmable shader thing in either or, the fixed function pipeline thing may be more "compatible" and offer less "bugs". note, when i say working on windows 95, it does need mean people should use it, it just means it CAN work on windows 95 if someone wanted to do something nostalgic or unique, but the majority of users would play the game on systems like windows 7 or 10. 

with that being said, if i did went ahead and used the fixed function pipeline, would it "better" to use directx 8.0a + 8.0b libraries for this very specific project or opengl 2.0 + glut and openal, and of course, the question of cross platform is unclear, however, from my research on visual studio 6.0, it doesn't appear to be a good IDE, so it's possible, hypothetically if this project was ever made into something bigger, a more likely development setup could be a C++ ide + opengl 2.0, openal+glut/freeglut, or directx 8.0a + 8.0b or just 8.0a or even 7.0a + c++ ide.

On 4/27/2019 at 9:13 PM, directx8.0a said:

Aunque gracias por la información, debería haber puesto un enlace a mi otro hilo para explicar por qué tengo este proyecto / objetivos en particular en mente. el hilo está abajo, mi intención era ver qué tan lejos se puede llegar con las capacidades de software más antiguas, una de ellas es la tubería de funciones fijas y permitir que la aplicación desarrollada funcione desde Windows 95 hasta Windows 10. Quería crear algo. en parte nostálgico, pero también único y único en su clase, como un agua de aspecto más realista que no habría sido tan realista o agradable en ese entonces.

y así me vino a la mente directx 8.0b o opengl 2.0, ya que funcionaban en Windows 95 si uno estaba usando un gpu más nuevo, como el Geforce 6800, y luego me informaron sobre el canal fijo de la función, y aunque todavía me gusta hacer el Lo programable del sombreador en cualquiera o bien, la función de canalización de función fija puede ser más "compatible" y ofrecer menos "errores". nota, cuando digo que trabajar en Windows 95, es necesario que la gente lo use, simplemente significa que PUEDE funcionar en Windows 95 si alguien quisiera hacer algo nostálgico o único, pero la mayoría de los usuarios jugaría el juego en sistemas como Windows 7 o 10. 

dicho esto, si continuara y usara el canal de funciones fijas, ¿sería "mejor" usar las bibliotecas de directx 8.0a + 8.0b para este proyecto muy específico o opengl 2.0 + glut y openal, y por supuesto, la pregunta? Sin embargo, de mi investigación sobre visual studio 6.0 no está claro cuál es la plataforma cruzada, no parece ser un buen IDE, por lo que es posible, hipotéticamente, si este proyecto se hiciera algo más grande, una configuración de desarrollo más probable podría ser una C ++ ide + opengl 2.0, openal + glut / freeglut, o directx 8.0a + 8.0b o solo 8.0a o incluso 7.0a + c ++ ide.

The short answer: Yes, you can, and, you do not have problems with compatibilitie with the currents OS, but, you must use OpenGL, because the Direct3D old drivers not works really fine, because the brands as NVIDIA and ATI mix the drivers in the start of Direct3D 8 between Win9x/NT and XP, but... OpenGL doesn't work well at all on Win9x, Microsoft had gotten a hand so that environments that worked with OpenGL would not work totally well, in addition, there were also arrangements with certain brands such as NVIDIA to slow down the OpenGL drivers for Win9x in the late 90's.

That is why the short answer is that you can, but, you will have to decide how to handle yourself, and depending on which driver each user has, it is likely that the engine will work better in OpenGL or Direct3D, therefore, you will have to implement a Render with the two APIs, that's why in the late 90's and during the first half of the 2000's games like Half Life, had an implementation of OGL and Direct3D. (removing the obviousness of all the software rendering problems that benefited Direct3D in Windows, and the durability of old cards such as NVIDIA TNT, Voodoo, S3 models, which only had support for OpenGL 1.1 / 1.2 and had only the API of Direct3D 6 that was terrible in design terms's, admitted even by John Carmack.).

In a more short answer: Yes, and, the compatibility problems are much more likely to be in the same old operating system you're working on, let alone developed in Win9x; therefore, it is certain that in operating systems such as Windows 10 you have almost no problems running it, at most compiling it and organizing the project itself.

Greetings.