Simple Debugers Display.(declined), should be good for something..

just something i whipped up in about 5 minuts. i think it may help with static engens.

Attached File ( Number of downloads: 20 )
 Debugersdisplay.zip

WELL!?!?

Erm... not really useful, most people that makie static engines have to use counters anyways, so they could just change those to numbers.

Nope, not very useful at all.

eh... ok...
i figured it might help people figure out how TGF default engines work..

oh well... only took me 5 minuts anyway..
(yeah...i agree with you all)

Those people suck, Alterable Values

Using counters all the time eventually produces engines with this off the screen:



This post has been edited by Draco Icebane on Mar 23 2004, 10:40 PM

Draco...shut up... Counters are more useful in more complex engine, because you can have unlimited number of them, this only happens if you don't organize it well

This post has been edited by Banana Head on Mar 24 2004, 03:50 PM

Hey, Draco, I'm sure no one uses that many counters.


And if you're going to complain about counters, some people might change their static engines from counters, which you'll be able to jump your maximum height no matter how slow your computer is, to timers...



BWA HA HAAAAAAAAAAAAA!

Alterable values are the way to go. You can stick what they all do in a TXT or HTM file and use the Search command to figure it out instead of moving your mouse over your table of Counters trying to remember the grouping system you used because you haven't worked on your engine for months.

You get three Alterable Values for every type of Active Object. Not sure about your method, but I always have more than enough Alterable Values to make my engine because I use the values of the collision detectors and scrolling object and whatnot. More complex engines are usually done in MMF, which gives roughly 26 values per object, meaning if you run out you can try making an Active Object that you store out of the way (with what it does in the afore mentioned TXT or HTM file) and get 26 more counters, whose ranges you don't have to set. And the SoL command can set the Alterable Values before any other events check to see what they are. MMF also allows you to specify what the beginning value of an Alterable Value is, just like a Counter except it doesn't take up an object slot.

Counters are there solely for display purposes. Invisible counters are completely useless, you can use those if you want, but that's pointless, Alterable Values are cleaner and take up a third as many object slots.

And if you NEED an infinite number of counters/values/strings/whatnots for your engine, you should stop and think exactly how well it'll run on computers that aren't new-straight-from-the-1337-factory

I'm not saying to use Timers. I hate Timers, they're awful.

Alterable values are more useful for an object-oriented approach (which goes hand in hand with MMF's object bahaviors). Values or counters that may be associated with an object are part of that object, and that just makes everything easier to comprehend. Plus if you have many duplicates of an object, like ... 50 goombas, each goomba has their own set of values.

On the note of a text file, I just make a group of comments that gives a description of what every value does. Because every value and flag is associated with a particular object, there's little need for searching.

On the subject of the debugger. It's a start, but most of the values are really useless. For a static engine, the real useful values are the X and Y movement biases (or Z, Pocket Mario use dthe Z axis in the overworld).

While we're on the subject of debuggers, something that's very useful that I employed in Pocket Mario but havn't seen anywhere else is a realtime collision status block. There's a group of colored blocks up in the corner representing the different-colored detectors, and the status changes depending on what's being overlapped. I had a different state for overlapping 'nothing', 'backdrop', 'active object', and 'backdrop and active object'. Probably one of the most useful debugging features for figuring out why the player object gets stuck or behaves oddly on various platforms. It's also useful to be able to toggle the visibility of individual detectors just to see what they're digging into.

2 other bits I found to be pretty important was the 'Crash Data' and the 'magic key'. Crash is probably a bad word for it, but upon pressing a key the game freezes and a textbox listing various alterable values, counters, or toggle states can be invaluable for figuring out stubborn problems. Why did Mario freeze after the ground pound? Conflicting flags in my case, I would have had a hard time figuring it out without seeing all the states. And the Magic Key is something I stuck in to reset all the player and global flags to the off possition, which 95% of the time fixes (and more importantly confirms) a flag-related problem in the engine.

Granted, those debugging sollutions are somewhat dependant on your engine design, what works well for me might not work at all in another engine (lik the magic key). But whatever, maybe you'll get some ideas from it.

Z axis... I take it you use the X for his horizontal walking, the Y for his jumping, and the Z for his vertical movement? That's what I tried to do, I should expand on that a bit until I get it to work.

I used Y for jumping in the 2D engine, but I used Y for vertical movement and Z for jumping in the isometric engine. At least form what I remember, I could very well have the two backwards.

"I'm not saying to use Timers. I hate Timers, they're awful."


I know. I was making a point there.

Me too.

You'd best have the two backwards else you're using them wrong, Z is in-out.

It hardly matters, X is the only one that really doesn't change. I actually started with a 2D overhead rather than true isometric, so it would have made perfect sense for me to make Z the vertical (jumping) axis.