Well, you all have some good points.
WarrenM, if I'm going to trust that you are actually being serious that the system clock can tell you if it's a 256-color mode, can you please explain how that exactly works? How does the year have anything whatsoever to do with bit depth of the desktop?
As to the other ideas, I don't know ... I don't like the idea of using separate bits of different code for each platform. To me, that is not truly cross-platform. I am using BlitzMax because it provides cross-platform capabilities and I don't in any way shape or form want to have to maintain *any* amount of windows or linux or mac specific code that only applies to that platform. To me that is undermining the whole cross-platform philosophy and I would like to keep my software as cross-platform `pure` as possible - that is, I should not have to change it or do anything to the code or make certain bits of code activate or deactivate to make it work on the different platforms.
That said, there are of course some features of the different platforms that I am okay with `taking into account`, for example on Windows when you minimize a program you see part of the title text of the window in the task bar, whereas on the Mac for example you just get an icon, so it would be a good idea to adjust the title text when the window is miminized. But that doesn't require any `if platform=this then do that`stuff, it's one piece of code that applies to all. It's okay that BRL has provided the `?` compiler directive and all that, but I really really hope I never have to use it. And I'm sure many people would not think twice to use it, but that's not my choice.
So I also don't want to pursue an idea of testing the display depth that only works on one platform. Not only does that encourage BRL to make the cross-platform nature of BlitzMax `impure` but it also sets things up for being inconsistent which defeats the point of it. Okay so Linux gives you the desktop mode as mode 0 in the list of graphics modes, but the other two platforms don't so I'm not going to touch that.
As a cross-platform developer I should not have to make considerations for having any knowledge of what a given target platform is capable of or how certain things have to be achieved. I should not have to know nor keep track of pieces of information such as that Linux's mode 0 is the desktop mode. As soon as you start down the road of needing to know all these little platform-specific quirks, it's a bottomless pit of incompatibility and your whole cross-platform integrity goes down the poop chute.
So if it's going to be a solution, it has to be the same solution that works on all three platforms in the same way producing the same results with no need to know what the platform is or adapt to its individualistic behavior. Stepping up from single-platform development to cross-platform is a matter of moving from living in a box of individuality and separation, to removing all the barriers and approaching unity.
With regard to detecting the desktop, what I currently do is open a small window (may be hidden) on the desktop using MaxGUI or whatever, then use OpenGL to tell me the bit depths of each color component. I'm just going to assume that if it tells me there is a 15/16/24 or 32-bit display, that IS what the display is, and that IS what the context supports, and that IS what OpenGL is going to render in, regardless of whether there is some other uncontrollable unspecified translation from that down to the final 256-color desktop display. Since we can't predictably and accurately sense what the display *actually* is, and only what we internally know it to be, I'm just going to have to trust the information and go with it.
Yes, you can run an OpenGL app with a 256-color desktop. In this mode, on my system at least, it reports that you are actually working with a 15-bit doublebuffered display. You can open a window and draw graphics and it will appear to be drawing everything at a 16-bit color resolution, but it will then dither down the output to 256-color paletted using the desktop's palette. Also if the desktop is 16-bit, I can still use 32-bit textures and they will be rendered appropriately and be converted down to 16-bit on the fly. So it apparently doesn't matter what the desktop depth is, you have to go with what OpenGL gives you, which is probably totally implementation specific. If the display doesn't open and the desktop is 256-color, I will probably just report that the mode didn't work, not that it was because it was 256-color, but just because it generally didn't work.
I think if a graphics card supports actual 256-color indexed mode in the OpenGL driver, then you actually would get a 256-color indexed OpenGL context, and maybe it would return -1 or something for color depth (I noticed the stencil buffer returns -1 in a 256-color desktop, so maybe that is an indicator - or maybe that just means stencils aren't allowed in that mode?).
Anyway, bla bla bla.
WarrenM, if I'm going to trust that you are actually being serious that the system clock can tell you if it's a 256-color mode, can you please explain how that exactly works? How does the year have anything whatsoever to do with bit depth of the desktop?
As to the other ideas, I don't know ... I don't like the idea of using separate bits of different code for each platform. To me, that is not truly cross-platform. I am using BlitzMax because it provides cross-platform capabilities and I don't in any way shape or form want to have to maintain *any* amount of windows or linux or mac specific code that only applies to that platform. To me that is undermining the whole cross-platform philosophy and I would like to keep my software as cross-platform `pure` as possible - that is, I should not have to change it or do anything to the code or make certain bits of code activate or deactivate to make it work on the different platforms.
That said, there are of course some features of the different platforms that I am okay with `taking into account`, for example on Windows when you minimize a program you see part of the title text of the window in the task bar, whereas on the Mac for example you just get an icon, so it would be a good idea to adjust the title text when the window is miminized. But that doesn't require any `if platform=this then do that`stuff, it's one piece of code that applies to all. It's okay that BRL has provided the `?` compiler directive and all that, but I really really hope I never have to use it. And I'm sure many people would not think twice to use it, but that's not my choice.
So I also don't want to pursue an idea of testing the display depth that only works on one platform. Not only does that encourage BRL to make the cross-platform nature of BlitzMax `impure` but it also sets things up for being inconsistent which defeats the point of it. Okay so Linux gives you the desktop mode as mode 0 in the list of graphics modes, but the other two platforms don't so I'm not going to touch that.
As a cross-platform developer I should not have to make considerations for having any knowledge of what a given target platform is capable of or how certain things have to be achieved. I should not have to know nor keep track of pieces of information such as that Linux's mode 0 is the desktop mode. As soon as you start down the road of needing to know all these little platform-specific quirks, it's a bottomless pit of incompatibility and your whole cross-platform integrity goes down the poop chute.
So if it's going to be a solution, it has to be the same solution that works on all three platforms in the same way producing the same results with no need to know what the platform is or adapt to its individualistic behavior. Stepping up from single-platform development to cross-platform is a matter of moving from living in a box of individuality and separation, to removing all the barriers and approaching unity.
With regard to detecting the desktop, what I currently do is open a small window (may be hidden) on the desktop using MaxGUI or whatever, then use OpenGL to tell me the bit depths of each color component. I'm just going to assume that if it tells me there is a 15/16/24 or 32-bit display, that IS what the display is, and that IS what the context supports, and that IS what OpenGL is going to render in, regardless of whether there is some other uncontrollable unspecified translation from that down to the final 256-color desktop display. Since we can't predictably and accurately sense what the display *actually* is, and only what we internally know it to be, I'm just going to have to trust the information and go with it.
Yes, you can run an OpenGL app with a 256-color desktop. In this mode, on my system at least, it reports that you are actually working with a 15-bit doublebuffered display. You can open a window and draw graphics and it will appear to be drawing everything at a 16-bit color resolution, but it will then dither down the output to 256-color paletted using the desktop's palette. Also if the desktop is 16-bit, I can still use 32-bit textures and they will be rendered appropriately and be converted down to 16-bit on the fly. So it apparently doesn't matter what the desktop depth is, you have to go with what OpenGL gives you, which is probably totally implementation specific. If the display doesn't open and the desktop is 256-color, I will probably just report that the mode didn't work, not that it was because it was 256-color, but just because it generally didn't work.
I think if a graphics card supports actual 256-color indexed mode in the OpenGL driver, then you actually would get a 256-color indexed OpenGL context, and maybe it would return -1 or something for color depth (I noticed the stencil buffer returns -1 in a 256-color desktop, so maybe that is an indicator - or maybe that just means stencils aren't allowed in that mode?).
Anyway, bla bla bla.