Fix single stepping on the debugger.. for Construct 2

There are several times where I'm trying to figure out how a certain object works or how to implement some complex game logic. When writing regular code I'll turn to the debugger or old trusty print statements. Don't get me wrong... I think Construct is awesome and I get by with only print statements, but it would be less frustrating if we could single step in the debugger when troubleshooting.

Unfortunately, I don't think this will eliminate many questions since most beginners will probably never bother using the debugger or will just ask questions instead trying to figure out on their own. So I guess this is mostly a Construct 2 request.

I have better proposal, maybe. UltraExplorer (http://www.mustangpeak.net/ultraexplorer.html) has in-built debugger (reporting tool). In case of crash - it pops up. I think, games, created by Construct, should also have some kind of such feature.

P.S. scidave, can I ask you to post any crash log from Construct debugger, just wonder how it looks.

Yaraslau Windows already has a built in just-in-time debugger called DrWatson. During a crash, by default, it will post a minidump of the crash info to c:\documents and settings\All users\Application Data\Microsoft\Dr Watson. You can then read the crash dump with the free debugger Windbg. It also dumps a .txt file that is readable by any text editor.

Unless, you are good at reading crash dumps, the minidump info is not particularly helpful though. I would think that this would help the Construct developers, but they have told me it is that useful. I would agree that it isn't as nice as having the actual .cap.

If you have ever had Construct crash on you search for drwt32sn.log and user.dmp and you will see what crash dumps look like.

Crash dumps are completely useless to Construct users though, so an improved debugger would be good for Construct 2.

Yes, agreed. Would love to have a better runtime debugger for Construct 2. I don't know why a user would care about crash dumps besides curiosity.

Ashley I am curious why crash dumps aren't useful for the developers though. For some of these intermittent bugs that we have trouble duplicating, I would think a crash dump would provide value to the developer. Just wondering how the testers can better help the developers eliminate bugs.

Crash dumps don't provide information on why the program went wrong, it's just a big dump of the state of the memory and system when the problem happened. It's probably useful to hardcore assembly programmers who deal with the machine-level instructions, but Construct is written in much higher level C++, so finding anything useful in a thousand pages of binary that actually related to the problem at all is definitely finding the needle in the haystack.

Fixing problems is 1000x easier if the developer can reproduce the problem and debug the entire execution of the program, to watch the steps that happen and lead up to causing the problem. A dump of the system state doesn't really help with that.

Yaraslau Windows already has a built in just-in-time debugger called DrWatson. During a crash, by default, it will post a minidump of ........................

Hm, debugger in Windows is intended for debugging devices and drivers (if I'm not mistaken). Certainly, such dumps are useless for Construct.

I managed to crush UltraExplorer. Look at it here (as example):

disasm

<img src="http://i30.tinypic.com/2upqvkx.jpg">

stack dump

<img src="http://i26.tinypic.com/2m2t1xi.jpg">

cpu regs

<img src="http://i27.tinypic.com/34xhovc.jpg">

hardware

<img src="http://i26.tinypic.com/i72anp.jpg">

processes

<img src="http://i26.tinypic.com/kdjvd0.jpg">

modules

<img src="http://i25.tinypic.com/15i6e80.jpg">

call stacks

<img src="http://i26.tinypic.com/zwdklz.jpg">

general

<img src="http://i32.tinypic.com/2z40qi1.jpg">

Suppose, something like this will be implementing in future.

Hm, debugger in Windows is intended for debugging devices and drivers (if I'm not mistaken). Certainly, such dumps are useless for Construct.

Actually, the Windows debugger (Windbg) debugs user mode applications (like Construct) just as easy as devices and drivers. I use it all the time for this. It will do everything that Ultraexplorer does and more. You can use it as a just-in-time debugger (not just to deal with crash dumps).

However, I don't see the point in adding any of this functionality to Construct (whether it be Windbg or Ultraexplorer). Users don't need to debug crashes and they don't need to see call stacks, dissasembly, and registers, etc.... What they need is a simple "source code"/event debug capability where they can single step events and step into Functions, etc.. A very small subset of what a normal debugger can do.

I don't think users are interested in doing the debugging, it requires a high level of technical expertese. Those who are interested can always download the source code and build debug builds themselves, using the full Visual Studio debugger, which is very good.

I think what is needed most for debugging is not a crash report. There are so many ways my games go wrong without crashing.

It would be nice to be able to highlight the line of code that construct is about to execute, like in visual basic. With the stroke on the keyboard, the program goes on to execute the next line of code.

That way, we can see exactly what line is being executed at what time, and what state the variables are in. Once my games get to 100+ lines, this feature would be very helpful.

It would also be useful as a tool to teach newcomers about programming logic - how simply swapping the position of two lines can mean the difference between working and busting the game.

All in all, love using Construct 2.

thanks Scirra!