Note: Yes, I realize this is really terrible code

I tried to get the enemies set up in Raven, but for some reason they just sit there. The data structure looks like:
Code:
And the code is:
Code:

What is comparehl?

It compares hl to what ever is inside the parenthesis. That should be the only macro in that code. .fill is just a way to specify lots of data.

Without looking too closely at the code yet, your indentation is driving me bonkers. I indent on push, outdent on pop, like this:


Code:



Code:

I had meant to have it be wavy (just because), but I couldn't have instructions on the far left, so I outdented that part too.

Edit: Just to double check some thing, "sll a" will multiply by 2, right? Also, "cp 100 \ jr c,Larger_Than_100" is that correct?

Well, you should do it my way, so that you'll know if you have too many pushes or too many pops. So yes, you have quite a few inefficiencies. For starters, you can load from (hl) to any register, such as ld e,(hl). However, the same is not true of de or bc. Interestingly enough, most things that you can do with hl, you can do with ix, like ld e,(ix), but it takes one extra byte per opcode.

That one extra byte is used for things like "ld e,(ix+128)", right?

That's correct - ix can be indexed. For that matter, so can iy, but TI camps iy for flags.

Also, incase this part was missed because of the edit:

Just to double check some thing, "sll a" will multiply by 2, right? Also, "cp 100 \ jr c,Larger_Than_100" is that correct?

I also went through the Asm28days instruction set, and found an instruction that (seems to) does the same thing as sll a, although it still didn't fix it.

Sla is what you want. sll puts a *one* in the rightmost bit, so sll is like n<-n*2 + 1. Please note, you should not use sll or srl, because they are "undocumented instructions" for the Nspire, and make the Nspire crash. Alternatives:

srl a --> or a \ rr a
sll a --> scf \ rl a

SRL is not undocumented. Just SLL (a.k.a. SLIA) is undocumented.

Whoops, my error. Thanks for catching that, DrDnar.

For those who care, I found the error. The problem was that I was using jr c,$+3 instead of jr nc,$+3. I was basically doing this:
Code:
Which, as you can guess, constantly left my enemies in the same position. I have also added a part where it randomly sets the enemies velocities (seperately) to 0. This helped a lot because they really liked hugging the right wall. So, with that done, I can move onto collision detection

Edit: Btw, for my own reference, and to give you all something to look at, here's a current screenie without collision (of which I just caused an endless loop >.>)

How do you handle the bullet's path and collision detection?

The bullet goes straight up, always. And then for collision, I'm planning on using a "bubble" around the enemy which will help determine if a bullet has hit it. So far, I think I need to debug/destroy my current code because it doesn't seem to work. Though I haven't messed with it since my latest post.

Edit: You might be more interested in the structure of the enemies movement for your bullets (I assume is why you asked). Then you can set the velocity for the X and Y and have an optional Health/Damage/Is_Flying bit or two.

That's looking really great, tanner! Keep up the awesome work.

Nice tanner! I like the enemy movement!

woah, the control looks nice and fluid. good job

Really? Cool All I do is move one pixel every frame. NoteToFutureSelf: When doing collisions, check from the bullet rendering code because it will generally have less work to do.

Correct, good thinking. A simple bounding box check is probably the easiest way to go.