kudos, assert/abort, baby pics
Posted: Thu Nov 17, 2011 04:43
First of all, kudos to all who have laboured to bring cegui to life over the years. I needed a gui for my opengl project and cegui 0.7.5 is serving well.
Second, I just went through a week of intense debugging my opengl+cegui+sdl+pthreads + etc. game-ish app when a race condition reared its ugly head. Well, if only it had properly reared its head I might have found it sooner. To make a long story short, the app had no problem on linux, but, in my Win32/mingw port sometimes SDL video (needed for the joystick?!) would grab the Windows Device Context (?) before a cegui notifyDisplaySizeChanged call. (At least I think that is what was happening - I could be wrong here! I watched it call notifyDisplaySizeChanged then die with an exit code of 3 - but it could have been things other than cegui) That happened in weird combinations of things which affect timing, as race conditions can manifest. Eventually (after much swapping of this and that: like various freeglut mingw libraries), I was able to fix/workaround the issue. (Ended up sticking with the freeglut dll that comes with cegui mingw) I think one little thing that might have helped me out some is not using assert/abort in the gui code. It would die, no error message, nothing in the log, with an exit code of 3. I haven't followed that issue from notifyDisplaySizeChanged to the assert/abort but maybe just doing a fflush(stdout) somewhere in there might help (Windows often needs an extra flush). Or logging the error before the assert (if you must assert/abort). But again, all good now as I managed to suss it out.
edit: If I had set up a signal handler for the abort it should have both core dumped and flushed. Which would have sped me along, no doubt. Sigh.
And third, here are some pics of my cegui-based Windows and linux creation, a loose recreation of a classic robot toy from ... the olden days. http://victoriafamilyrobotics.net/vfr1/gallery It walks and talks and stacks blocks.
Second, I just went through a week of intense debugging my opengl+cegui+sdl+pthreads + etc. game-ish app when a race condition reared its ugly head. Well, if only it had properly reared its head I might have found it sooner. To make a long story short, the app had no problem on linux, but, in my Win32/mingw port sometimes SDL video (needed for the joystick?!) would grab the Windows Device Context (?) before a cegui notifyDisplaySizeChanged call. (At least I think that is what was happening - I could be wrong here! I watched it call notifyDisplaySizeChanged then die with an exit code of 3 - but it could have been things other than cegui) That happened in weird combinations of things which affect timing, as race conditions can manifest. Eventually (after much swapping of this and that: like various freeglut mingw libraries), I was able to fix/workaround the issue. (Ended up sticking with the freeglut dll that comes with cegui mingw) I think one little thing that might have helped me out some is not using assert/abort in the gui code. It would die, no error message, nothing in the log, with an exit code of 3. I haven't followed that issue from notifyDisplaySizeChanged to the assert/abort but maybe just doing a fflush(stdout) somewhere in there might help (Windows often needs an extra flush). Or logging the error before the assert (if you must assert/abort). But again, all good now as I managed to suss it out.
edit: If I had set up a signal handler for the abort it should have both core dumped and flushed. Which would have sped me along, no doubt. Sigh.
And third, here are some pics of my cegui-based Windows and linux creation, a loose recreation of a classic robot toy from ... the olden days. http://victoriafamilyrobotics.net/vfr1/gallery It walks and talks and stacks blocks.
