Graphics system compatiblity

[TheExDeus]

We have come to a point (we came to it before actually) where not only compatibility with GM:S hurts us, but sometimes even compatibility between our graphics systems hurts us. Like if we want GL3 and D3D11 support GL1 and D3D9, then we cannot in most cases improve those two systems. We are stuck with crappy FFP functionality. And while 99% I can remake in shaders and thus make it look virtually the same, there are bigger problems with D3D and GL, which at the very core actually incompatible (although GL4 and DX11 is a lot closer together).

So the question I ask is this:
Should we create graphics system specific functions? Like would it be valid, to have a specific function in GL3 that isn't in GL1 or D3D9? That is actually already the case with shaders. The GL3 shader code will never run on GL1 and all the functions I made for the shader system will never be compatible with GLSL1.0. Recently I added some culling functions in GL, which I can run in both GL1 and GL3, but Robert said he doesn't have that capability in D3D. While I proposed a way he could do basically the same thing, it might not be identical, and in some other cases we might not find a solution at all.
Right now there are stuff like "d3d_set_point_size" which I myself added because I needed it. And I still need the functionality, but in GL3 it's done via shaders. So unless I implement this in our GL3 default shader, I won't be able to support that function in that form. But then the shader gets more and more bloated for functions people will almost never use. And I don't even need it in my default shader. I need it in a custom one. So there is no reason to have that function in GL3, but there could be a different one - d3d_enable_point_size - because in GL3 you glEnable() point size and then use gl_point_size in vertex shader to specify the size. So both systems will have the same functionality, but will use two different functions and will require different ways to use them.

So this is why having several graphics systems is such a pain. This is probably why YYG just writes one GL code and uses Angle. My propositions:
1) Keep GL1.1 compatible with older GM (so 8.1 or less). So you can load an older GM game and run it without much hassle.
2) Keep GL3.3 at least partly compatible with GM:S. This will never be possible, but we can reduce the amount of problems users might have when converting their projects. But this even include things like shaders, which are mostly compatible between ENIGMA and GM:S. But other than that, we shouldn't strive for 100% compatibility. Only when it makes sense.
3) Both systems could have functions that are not in the other. But to reduce confusion we must show that the project uses functions not available in that graphics system. We could of course make it just error out, but I would suggest it runs anyway and just trow a warning. Although erroring at compile time is also an option, because I expect users to use only one graphics system for their projects and save using EGM, so their choice of graphics system is always saved too.

I will personally work only on GL3.3 and improve that. I implement something in GL1.1 only if it's very easy to do so. Otherwise I will leave empty functions with printf warnings or not code functions at all (so it errors when used), but this requires separate headers. As I won't implement graphics system specific functions in "general" headers.

[Josh @ Dreamland]

> Should we create graphics system specific functions?
Absolutely. I avoid actively encouraging this because doing so is a bad habit, but there is no reason to tax the performance of a system to try to be completely compatible with another. Please document or otherwise annotate functions that are specific to your system. By annotate, I mean use a flag that gets preprocessed away. I suggest creating a top-level annotations.h:

Code: (cpp) [Select]

#ifndef E_ANNOTATIONS_H
#define E_ANNOTATIONS_H

#ifndef JUST_DEFINE_IT_RUN
#define E_ANNO(x)
#else
#define E_ANNO(x) // TODO: Someone actually handle this in JDI
#endif

#endif

Then you would just use, eg,

Code: (cpp) [Select]

E_ANNO("SYSTEM_SPECIFIC")
void draw_enable_dither(bool enable);

E_ANNO("SYSTEM_SPECIFIC")
void draw_enable_stipple(bool enable); // How the hell was this ever a thing?

You can be as creative as you want. Eg, feel free to use E_SYSTEM_SPECIFIC as a full annotation, or name the annotation function something witty and descriptive, like $. I don't care how you annotate it, just be consistent and make sure it's easy to swap that shit out. You only need to annotate the headers that are included from the main source.

In the GNU implementation, shit is annotated with __attribute__, which I believe has a relative coming to the C++ specification in short order. Don't quote me.


As for your other proposals, I agree with keeping GL1.1 more GM-like; GM was raised around GL1.1 capabilities. I am also inclined to agree with (2), but don't want to commit to it because people can't seem to grasp what "compatibility when convenient" entails. You have my remarks on (3).

[Goombert]

Bout time you gays start waking up to what I been sayin.

Anyway his concerns arise from the following commit which I decided to peruse. He added a function to control the front face orientation in GL, which is not possible with D3D9 from what I gather but is possible with D3D10 and 11. My suggestion was to simply avoid adding these functions until a specific need arises or a user requests the function for a particular purpose, which he has yet to demonstrate either.
https://github.com/enigma-dev/enigma-dev/commit/cf65415fc9b039645600c03d96d6bcb77b668592#commitcomment-7197110

Regardless, if Josh is happy, then so be it, your wish is my command.

[Darkstar2]

Ideally is to cut the umbilical cord of GM, and be unique, but in practice many would not like that.....why not break ENIGMA into 2 separate projects as was suggested before ?  From what I recall most of these functions you lot are talking about are 3D stuff majority of people using GM and ENIGMA don't use.  The majority of people use said tools to make 2D stuff not 3D...... Nothing wrong in his suggestion or having graphic system exclusive functions, after all I would hope that most people have computers supporting both GL3 and D3D9

[TheExDeus]

You can be as creative as you want. Eg, feel free to use E_SYSTEM_SPECIFIC as a full annotation, or name the annotation function something witty and descriptive, like $. I don't care how you annotate it, just be consistent and make sure it's easy to swap that shit out. You only need to annotate the headers that are included from the main source.

I like the E_ANNO idea, and I can put anything in it, not only "Graphics system specific", but maybe even on how to replicate the functionality in other systems? Then it will get bloated though. But if I got you correctly, then JDI would use this trow errors? And you said I have to do this in headers - so I put all platform specific functions in their own headers inside the graphics systems folder and do it there? So that the function doesn't even appear in the code editor unless the correct graphics system is enabled? Because right now many system specific functions are in General, and they just have empty implementations. I guess I will have to clean that up.

Bout time you gays start waking up to what I been sayin.

You are the one bitching when I add something to GL that can't be done in D3D. I have personally stated my thoughts on GM compatibility for years now (them being that I don't care about it).

Ideally is to cut the umbilical cord of GM, and be unique, but in practice many would not like that.....why not break ENIGMA into 2 separate projects as was suggested before ?

But then who will maintain the one which is compatible with GM? We already have relatively few dev's here, and I don't know many who would want to work on that. I sure as hell won't.

[Josh @ Dreamland]

> I like the E_ANNO idea, and I can put anything in it, not only "Graphics system specific", but maybe even on how to replicate the functionality in other systems?
Try to be consistent, but yes.

> Then it will get bloated though. But if I got you correctly, then JDI would use this to throw errors?
Correct. I will have to modify JDI to support these annotations, but that has already been on my radar. I expect to get a lot of use out of that ability.

> And you said I have to do this in headers - so I put all platform specific functions in their own headers inside the graphics systems folder and do it there?
In this case, yes. These annotations don't typically belong in shared headers unless the headers are to be shared between small numbers of systems which both implement non-uniform functionality. This should be unlikely.

> So that the function doesn't even appear in the code editor unless the correct graphics system is enabled?
> Because right now many system specific functions are in General, and they just have empty implementations. I guess I will have to clean that up.
Right. I'm generally opposed to empty function bodies; I really hate linker errors, though. I'd prefer they just not be declared in systems that don't do anything for them, unless they're still applicable for a system. For instance, it's OK if d3d_enable didn't do anything on some embedded system, as long as you could do everything you'd be able to do after calling that function.