This week, I continued my work on Director ImGui debugger from last week. Working on ImGui has been bit of a fun exercise since, it is an open canvas. There are a lot of opportunities to improve upon, and it all depends on what a developer might find useful while working on Director engine.<\/p>\n
First of all, there were a bunch of impurities with the ImGui debugger. e.g.<\/p>\n
getHandler<\/code> function. Instead of searching for the handler in all casts, we can single out the cast that has the handler in it.<\/li>\n- When displaying Prop list in the execution handler window, there was a missing line, which I promptly added.<\/li>\n<\/ul>\n
And a bunch of other small stuff, too small to be worth noting here.<\/p>\n
Another feature that was stubbed in the debugger was being able to load and save the current state of the debugger into a persistent file. So, we can save a position in the game we are currently working on, and load the same position every time we start\u00a0 a debugging session.
\nWe went with the JSON format to store the state. We are currently storing the following things (and loading them back):
\n1) Window Positions
\n2) Score frame number
\n3) Windows that are open\/closed
\n4) Global, Local and Watched Variables
\n5) Breakpoints
\n6) Log
\n7) Colors
\nHere, @OMGThePizzaGuy and @lephilousophe showed me `ImGui::SaveIniSettingsToMemory\/ImGui::LoadIniSettingsFromMemory` which made my job much easier.<\/p>\n
In the Watched Vars window, I am also showing Local Variables and Global Variables with different colors. On top of that, Local Variables that are out of scope are shown with different color.<\/p>\n
All variables are now shown with `renderVariable()` which allows variables to be clicked on to add them to the WatchedVars list and also show their current value.<\/p>\n
Previously, the Scripts window only showed the handler being executed at that moment. However, for better navigation, @sev suggested that all the scripts from the same lingo context should be shown in the same window. This took me a while. Since, now not only was I rendering multiple (ImGui) widgets for multiple (Director) windows, I was also showing rendering multiple handler in the same Scripts widget. This caused a bunch of problems with stepping over e.g. pressing step over caused the script to move multiple steps forward, and with showing the current line in the handler (with a little yellow arrow), because the _state->_dbg._isScriptDirty<\/code> was getting set to false<\/code> immediately after the first script was rendered. Also, the scroll to the current line was also not working. This took some time and debugging to fix.<\/p>\nWhen @sev started review on my PR, he immediately pointed out that I was making a separate ImGuiState::state<\/code> for each window, which in hindsight I realized was a mistake. So, I reworked it to only make a separate instances of the objects that are needed to hold the execution context of a window. This also took a while to get right. There was a bunch of unexpected behavior including, the scripts were not showing up the first time the ‘step’ button was pressed in the control panel.<\/p>\nI also fixed a deprecation warning that occurred while compiling the Director engine. I had to create a custom copy constructor for the MacWindow<\/code> class since the synthesized copy constructor was calling a deprecated copy constructor for the ManagedSurface<\/code> class. Instead I had to use a copyFrom<\/code> method as suggested.
\nThere was another instance of use of deprecated method operator=<\/code> for the ManagedSurface<\/code> class, used copyFrom<\/code> there as well.<\/p>\nOverall, a somewhat normal week. I hope to make even more improvements to the ImGui debugger. e.g. Adding a trace for watched variables is next on the list.<\/p>\n","protected":false},"excerpt":{"rendered":"
This week, I continued my work on Director ImGui debugger from last week. Working on ImGui has been bit of a fun exercise since, it is an open canvas. There are a lot of opportunities to improve upon, and it all depends on what a developer might find useful while working on Director engine. First […]<\/p>\n","protected":false},"author":27,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12],"tags":[],"class_list":["post-97","post","type-post","status-publish","format-standard","hentry","category-week-10"],"_links":{"self":[{"href":"https:\/\/blogs.scummvm.org\/superlemon\/wp-json\/wp\/v2\/posts\/97","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.scummvm.org\/superlemon\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.scummvm.org\/superlemon\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.scummvm.org\/superlemon\/wp-json\/wp\/v2\/users\/27"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.scummvm.org\/superlemon\/wp-json\/wp\/v2\/comments?post=97"}],"version-history":[{"count":3,"href":"https:\/\/blogs.scummvm.org\/superlemon\/wp-json\/wp\/v2\/posts\/97\/revisions"}],"predecessor-version":[{"id":102,"href":"https:\/\/blogs.scummvm.org\/superlemon\/wp-json\/wp\/v2\/posts\/97\/revisions\/102"}],"wp:attachment":[{"href":"https:\/\/blogs.scummvm.org\/superlemon\/wp-json\/wp\/v2\/media?parent=97"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.scummvm.org\/superlemon\/wp-json\/wp\/v2\/categories?post=97"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.scummvm.org\/superlemon\/wp-json\/wp\/v2\/tags?post=97"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}