[TI ASM] stupid sprite..

Post by **benryves** » Tue 22 Aug, 2006 6:14 pm

King Harold wrote:yea aligned sprites, but if the offset falls off the right edge (and comes back at the left side) you only go 1 row down instead of 8 (so 11 (or 12?? confuses me a lil) times 8 (8 rows), and then you still have to add the offset on that row..

Yes, you go down one row. However, this y coordinate is later multiplied by 96*8, so you still end up moving down 8 pixel rows.

You can (if you really want) swap registers around and increment l (the y coordinate) by 8 each time, and only multiply by 12. I don't think it's really worth it, though.

This isn't TI-BASIC, this is Z80 assembly, loops are fine. Trust me on that.

I hope you never have to use the ldir instruction, as that's a "loop" - copying a picture to the graph buffer is a whopping 768 loops around!

Post by **tr1p1ea** » Tue 22 Aug, 2006 6:16 pm

Im getting a little lost by what you are trying to do here.

King Harold · Post by **King Harold** » Tue 22 Aug, 2006 6:21 pm

@ben: AARGH BIG BIG LOOP!! anyway, i didnt origionally need the y coord, but something that has something to do with it, namely a number being 8 times as big, uhm... my formula doesnt sound logical anymore..

@tr1p: trying to avoid having to input a number + 12*8 times the row number (which is a%12 right?), so the program should do it..

Post by **tr1p1ea** » Tue 22 Aug, 2006 6:23 pm

You want the user to enter a number from 0-95 which corresponds to a sprite in a PIC? Then you want to retrieve that sprite? Correct?

Post by **benryves** » Tue 22 Aug, 2006 6:25 pm

Actually, I'm overcomplicating issues. Here's a much, much easier version:

Code: Select all

    ld hl,plotSScreen
    ld de,12*8
    
    ; Now we loop around until the value is < 12
    ; (so we only have the x component left)

CalculateYLoop 
   cp 12 
   jr c,LessThan12 
       
   add hl,de ; Move down 8 rows
   sub 12 
   jr CalculateYLoop 
       
LessThan12

    ; finally, add the X offset

    ld d,0 ; Not really required, as 12*8 < 256
    ld e,a

    add hl,de

King Harold · Post by **King Harold** » Tue 22 Aug, 2006 6:26 pm

@tr1p: yes, exactly that, so should i go for bens solution? or a LUT? or that insane formula, or something else?
@ben: you made it look so simple..

how DO you do that? (uh wait a min untill i understand what EXACTLY you said in that code..)
edit: ah i see, but that's a loop untill a<12, which is fine but.. well.. ofcourse it'll work.. but i get the strange feeling that im doing something inapropiate when i code that..

Post by **tr1p1ea** » Tue 22 Aug, 2006 6:39 pm

You just have that BASIC mindset that looping to get something is bad. Provided you check that a <=95 then the loop can only ever execute 7 times, and its not doing a lot either.

King Harold · Post by **King Harold** » Tue 22 Aug, 2006 6:42 pm

well yes.. i know my thoughts arent allways reasonable, it wouldnt be my thoughts if they were, but there's still this thing about loops when there's a formula....

i guess i'll have to stop thinking for a minute and type that code in.

King Harold · Post by **King Harold** » Thu 24 Aug, 2006 9:13 am

ok i put it in, it works, i also made a not-aligned version (clipped aswell) but guess what, it doesnt work! i didnt expect it to ofcourse, but it doesnt even draw anything, quite depressing.. srl + rr is the way to shift sprites over a byte border isnt it?

Post by **qarnos** » Thu 24 Aug, 2006 10:40 am

King Harold wrote:ok i put it in, it works, i also made a not-aligned version (clipped aswell) but guess what, it doesnt work! i didnt expect it to ofcourse, but it doesnt even draw anything, quite depressing.. srl + rr is the way to shift sprites over a byte border isnt it?

It's probably not the only way but almost certainly the easiest!

With the shift instructions, you need to keep in mind how they affect the carry flag.

Within a byte, the bits are numbered 7, 6, 5, 4, 3, 2, 1, 0. Bit 7 is the highest bit (128) and zero is the lowest (1). From a graphics point of view, bit 7 is the leftmost pixel and bit 0 is the rightmost.

With all the different types of shift, the bit which is being shifted out becomes the new carry flag. So with SRL, the carry flag will have the same value as the low bit of the number you just shifted (bit 0). SLA has the opposite effect - bit 7 will become the carry.

The rotate instructions (RR, RL) do the same thing as a shift, but the "new" bit will take the value of the carry flag.

I hope this isn't too confusing. I'm not good at explaining things! I will do a little diagram of what happens:

Lets say you have two bytes you want to shift. They both contain 01010101 (in binary, of course!).

First, you shift the first byte using SRL:

Code: Select all

BEFORE:
Carry flag - unkown
  7   6   5   4   3   2   1   0
+---+---+---+---+---+---+---+---+
| 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 |
+---+---+---+---+---+---+---+---+

AFTER:
Carry flag: 1
  7   6   5   4   3   2   1   0
+---+---+---+---+---+---+---+---+
| 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 |
+---+---+---+---+---+---+---+---+

A zero was shifted into bit 7, since SRL will always shift a zero, and the 1 that was in bit 0 has been put into the carry flag.

Now, you RR into the next byte:

Code: Select all

BEFORE:
Carry flag - 1
  7   6   5   4   3   2   1   0
+---+---+---+---+---+---+---+---+
| 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 |
+---+---+---+---+---+---+---+---+

AFTER:
Carry flag: 1
  7   6   5   4   3   2   1   0
+---+---+---+---+---+---+---+---+
| 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 |
+---+---+---+---+---+---+---+---+

The carry flag was shifted into bit 7 and the 1 in bit 0 was, once again, shifted into the carry flag. So if you are shifting across multiple bytes, you would only SRL on the first, and RR on the rest. Just make sure you are not executing any instruction which will affect the carry flag in between the shifts!

I hope this helps, but knowing my crappy explainations, it won't!

King Harold · Post by **King Harold** » Thu 24 Aug, 2006 11:23 am

well that explaination wasnt bad at all, but i alrleady knew what they did, in fact, i thought of the srl + rr thing myself and then saw it was allready being used (!!!), but well atleast i was on the right track, but with "wrong" shifting it would most likely display atleast /something/ and currently it isnt displaying anything at all, it does something and then just exits (didnt forget grbuycpy though)

Post by **qarnos** » Thu 24 Aug, 2006 11:27 am

King Harold wrote:well that explaination wasnt bad at all, but i alrleady knew what they did, in fact, i thought of the srl + rr thing myself and then saw it was allready being used (!!!), but well atleast i was on the right track, but with "wrong" shifting it would most likely display atleast /something/ and currently it isnt displaying anything at all, it does something and then just exits (didnt forget grbuycpy though)

I can't count the number of times I have "invented" something and then seen someone else already doing it

Post the code you think may be the culprit and I'll take a look at it.

King Harold · Post by **King Harold** » Thu 24 Aug, 2006 11:33 am

Code: Select all

		bcall(_RclAns)
		ld hl,1
		bcall(_GetLtoOP1)
		bcall(_ConvOp1)
		ld (xpos),a
		bcall(_RclAns)
		ld hl,2
		bcall(_GetLtoOP1)
		bcall(_ConvOp1)
		ld (ypos),a
		bcall(_RclAns)
		ld hl,3
		bcall(_GetLtoOP1)
		bcall(_ConvOP1)
		push af
		bcall(_RclAns)
		ld hl,4
		bcall(_GetLtoOP1)
		bcall(_ConvOp1)
		dec a			;if you input 0 pic0 will be used
		cp -1
		jr nz,nonnegativename
		ld a,10
nonnegativename:
		ld (name+3),a		;save the name
		bcall(_SetXXop1)
		bcall(_StoX)
		ld hl,name
		bcall(_Mov9ToOP1)
		bcall(_FindSym)
		inc de			;skip size bytes
		inc de
		ex de,hl		;store in hl
		pop af
		ld de,96
calulateYloop:			;stuff takes care of alignment
	cp 12
	jr c,lessthen12
	add hl,de
	sub 12
	jr calulateYloop
lessthen12:
	ld e,a
	add hl,de
		push hl
		pop ix
		ld b,8
		ld hl,ypos
		ld e,(hl)		;x should be in d and y in e 
		inc hl
		ld d,(hl)
		ld a,%11111111	;set bitmask
		ld (clipmask),a	;save it
		ld a,e
		or a
		jp m,cliptop
		sub 64
		ret nc			;trying to draw offscreen..
		neg
		cp b			;takes 4 T states, cp 8 takes 7
		jr nc,horizontalclip	;no need for vertical clipping
		ld b,a			;bottom clip (loads new number of rows)
		jr horizontalclip
cliptop:
		ld a,b
		neg
		sub e
		ret nc
		push af		;stores neg-ed new number of rows
		add a,b
		ld e,0			;sets y to 0..
		ld b,e
		ld c,a
		add ix,bc		;move pointer
		pop af			;pop neg-ed number of rows back into a
		neg			;neg back
		ld b,a			;real number of rows in b
horizontalclip:
		ld c,0
		ld a,d
		cp -7
		jr nc,clipleft
		cp 96
		ret nc			;off the screen..
		cp 89
		jr c,draw		;no need for horiz. clipping
		and 7
		ld c,a
		ld a,%11111111
rightclipmask:
		add a,a
		dec c
		jr nz,rightclipmask
		ld (clipmask),a
		ld a,d
		jr draw
clipleft:
		and 7
		ld c,a
		ld a,%11111111
leftclipmask:
		add a,a
		dec c
		jr nz,leftclipmask
		cpl
		ld (clipmask),a
		add a,96
		ld c,12
draw:
		ld h,0
		ld l,e
		ld d,h
		add hl,hl
		add hl,de
		add hl,hl
		add hl,hl
		ld e,a
		srl e
		srl e
		srl e
		add hl,de
		ld de,PlotsScreen
		add hl,de
		ld d,0
		ld e,c
		sbc hl,de
		and 7
		jr z,aligned
		ld c,a
		ld de,11
rowloop:
		push bc
		ld b,c
		ld a,(clipmask)
		and (ix)
		ld c,0
shiftloop:
		srl a
		rr c
		djnz shiftloop
		xor (hl)
		ld (hl),a
		inc hl
		ld a,c
		xor (hl)
		ld (hl),a
		add hl,de
		inc ix
		pop bc
		djnz rowloop
		ret
aligned:
		ld de,12
drawloop:
		ld a,(ix)
		xor (hl)
		ld (hl),a
		inc ix
		add hl,de
		djnz drawloop
		ret	
		
		
name:
	.db PictObj, tVarPict, tPic0, 0
ypos:
	.db 0
xpos:
	.db 0
clipmask:
	.db 0

the name thing seems to work on its own (i stored it in X aswell to be sure it really did what it was supposed to do), the clipping should work.. and the shifting should work.. so.. i dont know what is going wrong or where (maybe got a few registers confused somewhere, cant find one but you never know)

Post by **qarnos** » Thu 24 Aug, 2006 12:03 pm

That's one heckova routine!

I'm not sure how much help I can be, but:

1. Are you sure you are loading the x and y co-ordinates the right way around? I'm not familiar with the TI pic format, but it looks like you are loading Y first then X. Is this the way it is stored?

2. after [leftclipmask:], does A still contain the x co-ordinate?

3. after you have calculated the offset into plotsscreen you are subtracting 12. Was that intentional?

I will load it up into PTI tomorrow and take a closer look, but it's getting late over here!

One final thing (I love optimising!). In this segment of code:

Code: Select all

      and (ix)
      ld c,0
shiftloop:
      srl a
      rr c
      djnz shiftloop

srl a can be replaced by rra, since before you get to [shiftloop:] you perform and (ix) which will zero the carry flag and since C was zero and you shift no more than 8 times, rr c will never set the carry flag.

rra is only 4 T-states compared to 8 for srl a.

Code: Select all

      and (ix)
      ld c,0
shiftloop:
      rra
      rr c
      djnz shiftloop

King Harold · Post by **King Harold** » Thu 24 Aug, 2006 12:14 pm

1. doesnt matter which way you load it, since i load them seperately (it didnt like being loaded like a 16 bit reg)
2. d and e are supposed to hold x and y (d=x e=y)
3. am i? (sub 12 is part of the thing that calcs the aligned position in the source picture.. or atleast it should do that)
and i optimized that little thingie you mentioned
thanx for reading that annoying code all through