Note: Yes, I realize this is really terrible code Sad

I tried to get the enemies set up in Raven, but for some reason they just sit there. The data structure looks like:
Code:
EnemyArray:
   .fill (3*6)*3,0 ; | X acceleration{3 bits}, Y acceleration{3 bits}, health{2 bits} | Y pos | X pos | etc
And the code is:
Code:
UpdateDrawEnemies:
   ld hl,EnemyArray
UDEnemiesLoop:
   comparehl(EnemyArray+51)
   ret z
   ld a,(hl)
   and %00000011
   jr z,UDEnemiesSkip
      ld b,3
      call iRandom
      dec a
      ld b,a
      ld a,(hl)
      and %11100000
      srl a \ srl a \ srl a \ srl a \ srl a ;%11100000 into %00000111
      sub 3
      add a,b
      push af
         push hl
         inc hl \ inc hl ;Points to the X position
         ld b,a
         ld a,(hl)
         add a,b
         cp maxX
         jr c,$+3   ;If the new X value is over the allowed amount (or less than 0) don't save X
         ld (hl),a
         pop hl
      pop af
      add a,3
      sll a \ sll a \ sll a \ sll a \ sll a ;%00000111 into %11100000
      ld b,a
      push bc
   ld b,3
   call iRandom
   dec a
   ld b,a
   ld a,(hl)
   and %00011100
   srl a \ srl a ;%00011100 into %00000111
   sub 3
   add a,b
   push af
      push hl
      inc hl   ;hl points to the Y position
      ld b,a
      ld a,(hl)
      add a,b
      cp maxY - 8
      jr c,$+3 ;If the new Y value is over the allowed amount (or less than 0) don't save Y
      ld (hl),a
      pop hl
   pop af
   add a,3
   sll a \ sll a ;%00000111 into %00011100
   pop bc
   or b
   ld b,a
   ld a,(hl)
   and %00000011
   or b
   ld (hl),a
   
   ;call CheckColllision
   inc hl
   ld a,(hl)
   ld e,a
   inc hl
   ld a,(hl)
   inc hl
   push hl
      ld l,e
      ld b,7
      ld ix,EnemySprite
      call iPutSprite
   pop hl
   jr UDEnemiesLoop
UDEnemiesSkip:
   inc hl
   inc hl
   inc hl
   jp UDEnemiesLoop
Quote:
comparehl(EnemyArray+51)


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:
   instruction
   instruction
   push hl
      instruction
      instruction



Code:
      instruction
      instruction
      pop hl
   instruction
   instruction
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?
_player1537 wrote:
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.
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?
_player1537 wrote:
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.
_player1537 wrote:
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.
DrDnar wrote:
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:
ld a,100
cp 55
jr c,$+3
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 Very Happy

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 Very Happy 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.
_player1537 wrote:
Really? Cool Very Happy 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. Smile A simple bounding box check is probably the easiest way to go.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 3
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement