Frame Step Widget

Another one of my debugging objects.

This simple widget allows you to Pause, and then Frame Step, an application at runtime by using Keyboard keys instead of the mouse buttons on the MMF2 debugger.

This is a great tool for when you want to test Frame-precise, pixel-perfect collisions in your application or game, but still need to have full use of the Mouse cursor in the frame.

Simply press [Page Up] to pause the application. Once Paused, press [Page Up] again to advance by one MMF2 frame/loop. Hold the [Page Up] key for slow motion. When you are done, press [Page Down] to resume the application.

Your widget is very clever! It never crossed my mind that this is possible this easily. I'll definitely be using this a lot!

Just a sidenote, why do you go for so dark comments? The high contrast kind of ruins the flow of reading the events (and not just as a subjective opinion, but also design guidelines about how colours and contrast are used to achieve a good flow and make things easy to percieve). Something that "breaks" the flow as much as black background and white text would, if used at all, should be dedicated to some kind of meta header under which you put another level of headers, under which normal events and comments goes.

Thanks.
About the comments, there are many reasons for a dark background.

• 99% of the time, I am looking at my own comments, so I make them most visible to myself.
  
• Light text on a dark background causes less strain on the eyes. You will save your vision in the long run if you use a darker workspace in general. Think of old computer screens; there was a reason they used white text on black background, even when they could have used black text on white (because it hurts your eyes).
  
• My windows theme is much darker than the default themes, for the same reasons above. So the contrast isn't very high on MY machine. It may appear different on others' machines.
  
• In larger applications, I use comments like these to separate groups of events without using groups. I use them like a "horizontal rule" in HTML. Using white comments, they sometimes blended into the events at large. So by using a dark color they pop out and are more noticable.
  
• I've been using this comment scheme in all of my applications since 2009, and I find it most practical for my own personal use. It also gives my mfa's a sense of style. At a glance, I can tell if a certain app is made by me or another MMF2 user.
  
• I use commenting VERY heavily in my applications. I make them very descriptive too. I like to be able to look at the source of a 5 year old application and be able to read (in English) what the events are doing, instead of having to decipher the code step-by-step in the event list editor. So yeah, I tend to write paragraphs in my comments. :grin:

Well... there's my reasoning! I've switched to a darker workspace a while ago, and I would never go back! I find that I don't get dry eyes, bloodshot eyes, or have the need to "re-adjust" my vision as often as with that piercing white screen of old.

A computer screen is not a piece of paper. I find it hard to read small black text on a white screen.

Quote:

---

I use commenting VERY heavily in my applications. I make them very descriptive too. I like to be able to look at the source of a 5 year old application and be able to read (in English) what the events are doing, instead of having to decipher the code step-by-step in the event list editor. So yeah, I tend to write paragraphs in my comments. grin

---

I agree with that point 100%, it's nice to see someone who properly comments MMF2 programs, I wish more people practiced this!

I didn't realize that part about the dark theme you use. Of course I can see how it totally makes sense if your comments match what the events actually look like. I guess a good solution would be if the user didn't set the colour and font properties of every individual comment, but if MMF would have a bunch of comment types that could be customized, to allow "dark" and "light" (or any other kind) prests on a per-user basis, so that people with different themes can share code easier without going crazy. MMF3 perhaps :)

I should probably stay on topic more. Great widget! I've been needing this feature! \o/

I used to comment extremely heavily, but I don't anymore. Sometimes it can be hard not to comment for commenting's sake.
Sometimes comments aren't necessary at all, such as situations like this: http://ftp.jacobpariseau.com/commentsnotnecessary.png

Well, comments are meant to make the code easy to follow, and it indeed doesn't make sense to comment something that's completely obvious for the sake of commenting, though it can make sense in a widget where you really want to explain to the most beginner user how you're thinking. In your case, I would probably have put a single "Keyboard -> Velocity" comment at top, just so that I don't have to hover to figure out what pressing the button changes, but I guess that's just taste and probably don't make a real difference.

Just generally speaking, I'd be happier if people in this community commented too much, rather than too little though :)

I agree. I just like commenting heavily in full sentences. It helps me.

For that example, instead of "Keyboard -> velocity" I would have written "When Player presses Arrow Keys, increase velocity". Both comments get the same point across, but I like to write in full sentences. It saves me time in deciphering what exactly the event is doing. Is the arrow key increasing, decreasing, changing, stopping, or jumping in velocity? Are the Keyboard keys arbitrary, or are they ordered (like WASD or Arrow keys)? These are the questions I ask myself when reading my own code. So I also like to answer my own questions.

Leave no question unanswered!

I wouldn't do that for such a simple event where it's obvious what it does by just looking at it. Commenting too much will also make the code uncomprehendable since there's text all over the place, and I've learnt that commenting needs a good balance too.

I mean, when you code in C++ for example, the general idea is that the code should speak for itself so much that it's completely understandable by just looking at it (then comment anyway when there's something that needs to be explained). Events are not optimal for this, since you need to hover the mouse over the conditions to see them unless you're in event list mode, but in some way this is still true. Smaller comments and less reading can provide a better overview; I can just hover with the mouse if I'm unsure about something. Today I think of a comment as a tag for the event. An exaple is "Transform Knytt to Ball" instead of "Create a ball where the Knytt character is, transfer X and Y speeds from the Knytt to the ball and copy the direction, remove the Knytt since it's no longer neeeded". Sure, it doesn't explain the entire process, but it's so much more easy to "read" the event list when you can see what all the events by just having a quick look. This is a lot more comprehendable than my earlier projects where I overeexplained everything, killing off the overview I get with shorter comments.

While the comment "When Player presses Arrow Keys, increase velocity" explains more, it doesn't take a split section to interpret, and it doesn't provide any information you couldn't easily figure out anyway.

Great widget and clever use of the pause application action (which I didn't even know it existed). The only thing I find annoying is that once that the application is paused, we can framestep with any keyboard key. And this conflicts with possible keyboard controls. I couldn't get my head around to solve this problem. :(

Yeah, that is the only problem. Trust me though, I TRIED to find a way around this. The limitations with MMF's pause application feature prevented a simple work around.

I use this odd behavior to my advantage though. It makes it easier for me to time Jumps in my game by being able to simply press Jump to have the frame advance at the same time (instead of having to move my character AND press PgUp at the same time to advance).

What you call a glitch, I call a feature! :grin:

I agree, the pause application feature is somewhat limited. We should be able to unpause the application with a different key than the one used to pause the application.
In the meantime I'll still make use of this widget. :)

I guess an inverted frame step feature can be done by just using this single event:

Repeat while "Page Up" is pressed - Pause application until any key is pressed.

That means that any other key unpauses the frame stepping.

Yeah, I tried that too. So if my game uses keyboard controls the application unpauses, which is bad (accroding to me).

Oh, yeah, that makes sense. I didn't realize it'd be possible to combine the frame step feature with other keypresses.

In that case, I'd probably set it up like this, so that you pause and unpause the frame step feature with the same key.

Well, nice try Nifflas. :) But in your example it is possible to framestep with any keyboard key. And that's what I found problematic in JimJam's original widget.

If we had 3 actions similar to the debugger ones it would be nice: Pause, Step and Play. Or if through the MMF preferences, we could bind the various debugger buttons to keyboard keys, that would solve MY problem. :D

Quote:

---

Well, nice try Nifflas. smile But in your example it is possible to framestep with any keyboard key. And that's what I found problematic in JimJam's original widget.

---

"Nice try" is not applicable because I was not trying to change that. I just wanted a single key instead of two to to begin/end frame stepping.

Quote:

---

Originally Posted by Olivier

If we had 3 actions similar to the debugger ones it would be nice: Pause, Step and Play. Or if through the MMF preferences, we could bind the various debugger buttons to keyboard keys, that would solve MY problem. :D

---

Yeah I agree. I looked at Nifflas version and modified it a bit.

I modified the widget so that it ONLY steps when you press Page Down, and no other key. The trick is that you have to press Page UP to pause, Page Down to step, and press Page UP and DOWN simultaneously to unpause. Its not very elegant, but it gives the desired effect of having one button to pause, one button to step, and still allow you to press keyboard keys WITHOUT stepping or unpausing.

Though since the application is paused, I don't really see what effect pressing keys would do... But regardless it gives the results that Oliver wanted. Albeit in a clunky kind of work-around way. I'm sure it could be done better; I just modified the action to a specific key instead of "any key".

I left my original widget to be able to Step with any key because I found that to be more useful.

I'm amazed JimJam, and I wish I could find a solution myself. :D Thank you very much for having solved my problem.

No problem. ;)

I hope this debugging widget will be as useful to you and others as it has to me.

I never got why it's a problem though, why is it so bad if you can frame step with any key?

I find it pretty nice to use the game function keys to e.g. frame by frame move a character or test other keyboard triggered features.

Framestepping with any key (and thus with game contols) can be useful, but sometimes it may be annoying; For example when the Esc key activates the pause function.
Now we have both systems so everyone is happy, especially me.