Thanks
I've been having an interesting time with that, actually.
First, I tried to use L1 and a variable to store/recall the variables, but it seemed to recall the wrong one or something.
Then I shot for a lower target, using four variables for two points. But then, no matter what happened, it would 9 times out of 10 recall the wrong one.
Rather than inadvertently messing up the source doing something different, I decided to just let it be the way it is for now.

So I'm pretty much where I was on Saturday.
But I've made some interesting levels so far.

Edit:
I ran into some problems making screenshots, namely the school library.
Apparently they were doing a re-take of the CAHSEE. This just keeps getting delayed more and more...
Good news is, no school tomorrow or Friday (holiday tomorrow, furlough day Friday)!
So unless something happens out of the normal, I should be able to get it up later today or tomorrow.

UPDATE! Version 0.6
As most of you probably know, this update includes different enemy speeds and door/key.
Screenshots



Time to explain things.
The level editor.
As most of you probably know, and can tell from the screenies, the things added are different enemy speeds and door/key.
Different enemy speeds.
You place the enemy as normal, but instead of pressing 2nd to confirm, you press the desired speed instead.
Supported speeds (in pixels per frame): 1X, 2X, 4X and 8X
1:normal [2nd]
2:2X press 2
4:4X press 4
8:8X press 8
Door/key.
Like placing a block, press [GRAPH]
The door appears.
Place the key as desired, comfirm with 2nd or GRAPH
Note that it's not fool-proof, that it's possible for a door or key to get overwritten.
For door/key to work, there has to be both a door AND a key.
I think that's about it.
Oh, the levels have to be imported using the program. Just press MATH at the level select screen.

TWHG Vpoint6.zip

I must say, you're doing a most excellent job on this! I fixed up your screenshots for you; they look great.

Thanks, I was wondering what the problem was with them...
it's right?

Also, TWHG Vpoint6.zip

Very nice. And the problem was that you had spaces in your image urls; I changed them to %20 (which is the same as space).

Oh, that's why. Got it.
And thanks

Okay, I made some more levels

Minor update: I finally figured out the root of the xor parenthesis bug. The cause isn't taken out yet, but it works properly now.

The solution to the xor bug, I've found, isn't quite right. The enemy that starts at the far upper-left corner (if it's there) is always a frame ahead. You can't tell if you don't look too closely though.

Also, the game engine is getting a re-write, saving 20-25 lines of code and about 100 bytes. So, the next update may still be a program.

Can you explain what the "xor parenthesis bug" is?

Look at the far left, there's an enemy that looks like a pair or parenthesis and moves twice as fast as it should.

Ah, I see the problem. Actually, it seems like over the iterations the two enemies that are overlapping get one pixel further apart each time they bounce.

That's just wabbit messing up the graphics. What's happening is that for some reason, it updates and draws the same enemy twice. So the enemy moves twice as fast as it should. The way the enemies are drawn is pt-change( , "xor". So, two little circles are xored on top of each other, one of them one frame off (which isn't the case with higher speeds btw) makes: a pair of parenthesis.

I seriously doubt that it's Wabbit's fault. More likely is that either you have an OBOE, or (less likely) that Quigibo made a mistake.

It doesn't do the graphic err that happens on the computer on the real calc.

What's an OBOE?

An off-by-one error, unfortunately common and usually hard-to-resolve. Do you happen to use an interrupt of any sort in your code?

If I did use an interrupt, I would probably know what one is. So, unless I inadvertantly used one, then no.
And it's not always off by one. It's as far off as the speed is. So if it's 2X speed, it's off by two.

EDIT: 84 posts, woo

Nice. Look carefully at that screenie, though - isn't it off by two at some points? Or am I misunderstanding something?

Notice how the one that seems to be off by two is gray. If I had set the screenshot settings to black/white (no gray), it wouldn't have what looks like another one. Because it moves twice as fast as the speed it's supposed to go at (1 pixel per frame) it moves two pixels per frame. It's always off by the same amount, buggy or not. What you see in the screenie is a graphic thing.

The problem that caused the bug was something in the level loading code--it copies the location of the enemy twice for some reason. Like I said, before, I haven't figured out the root of the problem exactly, just added a workaround.

The problem's solved, at least temporarily, anyway. It doesn't do the xor thing anymore.


As of now, most of the engine re-write is complete. I'm trying to figure out how to have more than 9 levels without having to define a truckload of strings. And I have a fairly good idea of how I might go along with that. Just need to look at some old source...

Ah, thanks for explaining that error more, and I'm glad that it's repaired. Surely you can pack together multiple levels with some kind of delimiting character, no?