BlitzMax with two graphics cards on OS X Leopard
Archives Forums/BlitzMax Bug Reports/BlitzMax with two graphics cards on OS X Leopard
| ||
| All full screen samples fire a compile error "invalid share context" on Leopard when two graphics cards (nVidia 7300GT) are installed. Windowed samples still work fine. |
| ||
| By the way, Eschalon: Book I also crashes when it tries to initialize full screen mode; windowed mode is fine. On further note, I have three displays connected to those two cards, which probably influences the behavior. I could really use working multi-monitor support. ;-) |
| ||
| A small update: This problem does not occur with BlitzMax on Vista on the same hardware. I haven't tried GNU/Linux, maybe somebody else wants to do that. |
| ||
| well maybe apple just has no SLI capable drivers but two single GPU and in that case you can not have it on both. |
| ||
| Those cards don't run in SLI mode on Vista either, so the problem is probably somewhere else, presumably in the OS X-specific code where BlitzMax initializes the fullscreen mode. Since non-BlitzMax apps don't have a problem with doing that on OS X on that machine, it seems the bug is in BlitzMax. For now, it would be ok to just see a fullscreen app work on the primary display. Of course, on the long run, proper multi-display support - as e.g. pyglet offers it - would be even nicer. |
| ||
| Did you test it on Windows in OpenGL or DX? DX allows quite a lot of stuff as it handles many things internally. Stuff that OpenGL will not allow just like that, stuff for which you would have to write handling code in your application. I think thats exactly what happens here as BM will choose 1 single gpu as its primary device and just use that. But Vista / DX seem to share it depending on the position. On OpenGL (at least on OSX) you have to do that yourself if you want 3D accelration or create it on all which BM does not do. It uses the primary as any game, thats it. (with sli or virtual sli both together could form a single device) The problem is not multi monitor support here but that you try to handle 2 distinct GPUs instead of a single one. But some way to define the "fullscreen" on a multi screen system would be nice and definitely needed for a 2008 pure game oriented language. |
| ||
| The problem is that BlitzMax apps simply crash on OS X when you have two graphics cards and go full screen with your app. And by full screen I simply mean what the Digesteroids sample game does, for example; so I'm not talking about anything fancy. This one liner is all the code that you need to reproduce the problem and run into the 'invalid shared context' error: Graphics 1024,768,32,60 The OpenGL driver on Windows works properly on my setup - the screen that I assigned as primary device in Windows' Display Control Panel goes fullscreen, the two others go dark, as it should be. On OS X, the program simply crashes instead. So what I think what happens is that BlitzMax's OS X drivers don't properly recognize a two cards setup and try to initialize them as one card, which leads to the shared context crash. My reference to pyglet was only a wishful-thinking feature-request, by the way. From what I've seen so far, it looks as if they've covered this entire multi-screen/multi-graphics card thing quite nicely with their feature set. |
| ||
| Well BMs driver on any OS only takes the primary graphics card (you can choose yourself which you want there are functions for that). Its the OS responsobility to handle multiple cards -> unified screen situations correctly without crashing the application not the app as this is definitely a driver and OS level context handling thing. Something you definitely should not have to touch in your application. But simplest way around it on OSX would be borderless windowed fullscreen instead of real fullscreen. |
| ||
| The funny thing is that only Blitzmax apps have that problem; Doom 3, UT2004 or whatever else run nicely in fullscreen. Eschalon: Book I goes to Nirvana like all samples. So I still think that there is something wrong in the Blitzmax code. Anyway, using windowed mode as you suggest is a good workaround. |
   |