I’ve recently started deploying the application I’m building with Cinder to various older laptops. On my oldest DELL m17x (recently updated to Windows 10), the application crashes immediately. I’ve replicated the issue with an empty cinder application, so I can at least confirm that the execution ends prior to entering any application code; i.e. it doesn’t even get to enter setup() before things go sideways.
The machine has a horrid hybrid graphics card that has no windows 10 drivers for it, so I’m pretty sure it’s running on MS default display drivers. So my shot in the dark would be that the OpenGL initialization fails. But for me, the important thing is that I’d like the application to at least somehow state this. In the windows event viewer I can confirm that it crashes, but i’m left with some crash dump files I’m not too familiar with.
The docs state that Cinder logs by default to the console, but unfortunately the application crashes prior to even creating that console window. Here I’m also confused by the fact that if I run the program from cmd.exe this doesn’t act as a console window? As in, Cinder doesn’t write to this window by default, only the new console window it spawns. Perhaps it’s not possible to have a cinder app write directly to the console line without creating its own console window?
So to sum it all up - does anyone have any suggestions for how to debug this issue further?
Sounds like the GPU does not have support for OpenGL 3.0+ and therefor can’t create the GL context. See if you can run an old Cinder v0.8.6 application on it. If so, that confirms my hypothesis.
Anyway, just debug the application (remotely if necessary) and set a breakpoint in the prepare function of your App, or in the App’s constructor. Then step through it. Make sure to include Cinder as part of your solution, so that you can also easily step through Cinder’s code. You’ll probably find that the application crashes as soon as OpenGL is about to be initialized.
@paul.houx - I suspect that your suspicions are correct as I can indeed execute an older build (using cinder 0.8.6).
I currently don’t have vs2013 installed on that old machine and would intentionally prefer to not do it, just to keep it ‘clean’. Remote debugging is currently proving difficult as I mentioned in my original post.
Is there a way to get Cinder to output exceptions directly to the command line I run it in? Cinder doesn’t even get the chance to instantiate its own console window before things go sideways.
So my current understanding is that it is not possible to pass Cinder any log output method prior to it initializing OpenGL, which in turn causes an exception and shuts down the application.
In other words, as it stands most people will probably be fooled into thinking nothing happens when trying to execute a Cinder 0.9.0 compiled application on a platform which does not support OpenGL 3.0+.
I’d much prefer to have the application somehow report this problem to the user, but this is apparently impossible without messing about with the Cinder source?
Logging works from anywhere, including the prepareSettingsFn passed into the CINDER_APP() macro, the app’s constructor, and also shutdown.
Have you tried stepping through the init process to see where it is failing (most likely in app::RendererGl)? I agree that it would be nice to get a decent report on why it is failing even if the drivers aren’t up to par, but last time we discussed this I’m not sure if we found out how to do that.