Graphics failure
BlitzMax Forums/BlitzMax Beginners Area/Graphics failure
| ||
| Dear community, With SDL now being available, I would like to be able to query blitzmax to see if it can do DX accelerated and then ask it if OpenGL accelerated is available. So it tries DX, and if that fails, it tries OGL and if OGL fails or IS NOT accelerated, then it switches to SDL. I would like to check because if both DX and OGL fail, it's likely blitzmax will throw an error instead of letting me choose to use SDL. Your thoughts? |
| ||
| I've been pondering this too. I use the D3D driver by default, and I would like to drop back to the OpenGL one if D3D drivers are not available. I just can't see any way to predict it. I tried testing to see whether the resolution I use is available, but I rather suspect that will come back as positive on machines which aren't going to run the game properly anyway. |
| ||
| Thing is, a lot of OpenGL drivers will run in software, so a benchmark is also a very good idea when doing the initial startup test. You could check if DX works fine, if not, check OGL, if ogl is slow, then compare to SDL. This is because opengl often works under software - painfully slowly too - when the SDL option would be very fast. All we need are reliable checks we can make ourselves. |
| ||
| More ill-informed ramblings... Experimenting with DXDiag's Display tests plus RegMon from www.sysinternals.com it looks like you can read the Registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Direct3D\Drivers\SoftwareOnly" (using the Win32 API's RegistryOpenKey and RegistryQueryValue functions) to determine whether you're in software mode or not (hardware 3D acceleration being available should give a value of 0, software 1). It can also be used to set the mode -- DXDiag updates in real time to reflect this when you edit the value in RegEdit; this is NOT a good idea, other than for testing on your own machine! Fiddle at your own risk! Stick to only reading the key. For OpenGL, I guess you could check to see if you can open "opengl32.dll" via LoadLibraryA if you want to be really careful, then open your display, and use this to try and determine whether it's accelerated: "5.040 How do I know my program is using hardware acceleration on a Wintel card?". Yikes. It doesn't seem like you can check with OpenGL until you have a display, or at least not via any official method. |
| ||
| Many thanks James! Not trying to detract from your sterling efforts but this is something BlitzMax needs to be able to handle... would appreciate it if you could put in a good word for it. For example: test = Graphics 640,480,0... Returns false if it failed to start up for any reason. |
| ||
| (using the Win32 API's RegistryOpenKey and RegistryQueryValue functions Sounds great, James, but how does one go about accessing those Win API calls exactly? I've looked in User32, GDI32 and Kernel32 and I can't find anything resembling them. I tried the MSDN too, but can't find anything that looks useful from BMax. |
| ||
| I believe that this method of fiddling in the registry is bad news. For starters, the registry is depreciated in longhorn: there will be no registry. Much like unix and mac systems at the moment. Therefore (I know this sounds lame) it's best if Mark and the team make graphics() return a boolean if it managed to start up. I won't be accessing the registry at all in my game: I think it's a recipe for disaster to be honest (and not at all cross platform compatible) That said, I really appreciate your kind help James. |
| ||
| For starters, the registry is depreciated in longhorn: there will be no registry. Do you have a source on that? It would seem pretty insane to drop any support for the registry, bearing in mind how many programs rely on it. |
| ||
| Just beta tester talk. Unix and Mac don't have a registry. It's considered far more stable not to have one. As windows registry gets fuller, the system tends to slow down a lot. It is abused a lot. If the registry is corrupted, you kiss the entire windows installation goodbye, and have to recover it. The registry was a terrible idea. |
| ||
| Thats why registry defrager are really recommended for fast boot ups (as well as a real defrager as the windows one doesn't win any price for really used systems ... replaced mine with Diskeeper) Sybixsus: Why shouldn't they drop it? Actual program may be executed within a "sandbox" anyway for stability and compatiblity reason (as they rely on GDI which is replaced with WGF) and there is no reason the sandbox shouldn't emulate a registry for this old apps. |
| ||
| Sybixsus: Why shouldn't they drop it? Actual program may be executed within a "sandbox" anyway for stability and compatiblity reason (as they rely on GDI which is replaced with WGF) and there is no reason the sandbox shouldn't emulate a registry for this old apps. I said dropping all support for it would be insane, not stopping using it for the future. Fish's implication was that using the registry was a problem because Longhorn was just going to drop it completely. Longhorn will probably drop a lot of things, but I doubt to the point where programs which use them will have problems running. |
| ||
| There is no Longhorn, its called Vista... Get with the times ppl. |
| ||
| tell this MS and their longhorn alpha build 4074 I downloaded 4 days ago ;-) |
   |