Awesome, thanks for that. I'll accept it momentarily.

Thanks
Download link to TWHG.zip

My pleasure; you also helped me to debug the additions and changes to the file archives upgrade, which helps a lot.

Thanks and you're welcome at the same time, however one would say that.

To Do:
• Circular enemy movements
• Different enemy speeds (three or four)
• Door/key
• After Door/key is added, ability for multiple doors/keys
• Checkerboard pattern seen in the background
• Optimize for speed, 83+ mode is kind of slow
• Somehow get the editor in a smaller size so it can be a program (possibly with a bunch of features removed or something)

I'm trying to implement circular movement currently, but I have almost no idea of how to do it.

ThePenguin77 suggested it at first

...but I have no idea how this works.
Anybody know how?

EDIT: yay, I'm an Advanced Newbie now!!
EDIT2: nvm about the circles, I think it's taken care of now. Thanks Cooliojazz.

EDIT3: Be sure to vote in the poll for what you want to see. I'll let the poll go for a week or so.

OK, I'll anticipate a problem happening before it happens.
@ Alberthro or whoever knows: How do you sign an app?
I've tried wabbitsign, rabbitsign, and the utility included with axe parser and none of them worked for me.
What are/is the best program and what is the syntax using 010A.key?
nvm, got it working
btw sorry for the double post, but the last one was getting kind of large

Rather than triple-post, I'll just edit this one.
I'm currently implementing circles and differentiating enemy speeds.
Also, the level format has changed due to things being added. The levels are 96 bytes larger.
I plan on writing a utility to convert the vars to the new format, we'll see if that happens or not :P

Okay, so I've pretty much abandoned putting in circular enemy movements for now. Currently I have different speeds implemented (hardly could have been easier), the level format change complete, a utility that converts an existing level to the new format, and some door/key code done.

triple post...oh well

It's ok; you spaced them out over several days. I'm glad to hear that you're still making progress with this, and I hope that you'll honor us with an updated upload and screenshots at your leisure.

Thanks, I wasn't sure about the posts.
As for an update, expect it to happen late this week or early next week, on a weekday. The code needs some serious cleaning since I tried circles

As long as there's about 18-24 hours between your posts, you're fine. Indeed, if it's a very important update, even 6 to 12 hours is acceptable, at your polite discretion.

Sounds good on the update timetable; I agree that it's important to publish clean, well-tested code rather than push out a possibly-buggy product.

I just remembered, I need to update the poll. Common sense didn't come in on my part to make me realize that optimizations and seperete versions come at the end. Also, "different enemy speeds" will be taken out, since that's added already.
A question, though. How do I edit the poll? I remember going and editing the first post (the one that started the topic), but I don't see anything poll-wise there.

Aye, that's because you're not allowed to edit the poll once users have voted (the idea, I think, was people might be unhappy with results or remove an option and re-add it, effective zeroing out the votes and invalidating the results). I'll edit it for you with those changes.

Thanks Kerm

BIG UPDATE.
Multiple enemy speeds are finished. Enemies can now go (in relation to normal speed, 1 pixel per frame) 1X, 2X, 4X, and 8X.
Also, DOOR AND KEY is added and working.
And it's still under 8811 bytes...phew!
Can't upload now, but Monday, I can.

Now to work on multiple doors/keys...

Is 8811 bytes the limit on an Axe program? Also, can multiple enemies move at different speeds, or is the enemy speed a difficulty level type thing, where all the enemies either move at slower or faster speeds?

8811 bytes is the executable code limit for an ASM program (but don't quote me on that, I don't know the term exactly)
And enemies are completely independent of each other, meaning that any enemy can go at any of the speeds, regardless of what the others are doing.

$C000 - $9d95 = $226b = 8811, so you're right on the money. The calculator's have special protection that prevents them from executing in the $C000-$FFFF block, something I discovered through much confusion and pain while writing DCS5.

Great...I have the update working, TiLP installed, everything ready to go...then I find out I left my link cable at home.
Dang.
So...in the next few hours, provided my stepdad isn't home, I should be able to get the update up.

Good luck, I hope you succeed, although your conditional phrase makes me worry if all is well.

Things are...normal.
Turns out I won't be able to get it up today.
Now I know better to bring a spare cable with me, tomorrow.

Idea in the meantime: "playback" of respawns. One of the annoying things I rediscovered is when there's an enemy on the respawn point and you somehow get sent to the respawn point, you pretty much get spammed with up to 6 deaths. The spawn point would change to the one before. I'm thinking of having 5 playbacks max.

Well, "respawn rewinding" (as I've decided to call it) is giving me a bit of trouble as of yet. It doesn't crash or anything, it goes to the first and/or every fifth point. It works fairly well, it just goes to the wrong point. It's kind of confusing.
Also, the next update will be the last one that's a program before it becomes an app. While I was adding the respawn rewind, the size went past the limit, even >9000 bytes.

hmm...I just got the files off my calc. But apparently, I go tthe thing off of it something like a week ago. Wow...
I feel smart now.
Anyways, I plan to make a few levels and screenies (as per request ) and post it. Soon...

I hope you're able to fix the playback feature; that sounds really cool to me!