[TI ASM] stupid sprite..

[King Harold]

i have this code, for aligned sprites, mainly made by myself but i got some help from learn asm in 28 days, but it only displays 2 rows, and basically only a part of the 2nd row, which is very odd, i dont have a clue why this is happening, oh and i use stuff like ld a,0 because it didnt work and sometimes i just dont trust those optimisations (they sometimes set flags differently)..
have been trying to figure out why it wasnt working for 4 hours i see now, didnt find anything that looks like it's making trouble

Code: Select all

	ld hl,name
	bcall(_Mov9ToOp1)	
	bcall(_FindSym)
	inc de
	inc de
	push de
	pop ix
	ld hl,PlotsScreen
	ld a,0
	ld b,8
	ld de,12
putloop:
	ld a,(ix)
	xor (hl)
	ld (hl),a
	inc ix
	add hl,de
	djnz putloop
	bcall(_GrBufcpy)
	ret
name:
	.db PictObj, tVarPict, tPic0, 0, 0

edit: huh wait no! why am i not increasing ix by 12?! omg am such an idiot

[benryves]

How is this not working? From what I can tell, it finds pic0 and copies the first eight bytes (64 pixels of the top row) into an 8x8 region at the top left of the display?

Maybe that's the bug - you're doing this:

Code: Select all

Pic0:
+-------
|abcd..
|
|

Output:
+-------
|ab..
|cd..
|::
|

I think you need to increment IX by 12 as well, maybe?

[King Harold]

yea i realized that just when you posted..
im an idiot..

it works fine now.. omg i really am an idiot

[chickendude]

If it works, you can hardly call yourself an idiot

Also, did you ever finish your AppVar program?

[King Harold]

yea released it on ticalc after loads of testing, i could give it a few more functions though, but dont worry its still my main project i just thought i'd get some experience with sprites..
i need to do something like this:
ld de,88*int(a/12)+(a%12)
though, but uhm well i suck at assembly math..
any tips? (x times 88 is ofcourse 8x+16x+64x but int(a/12)? and a%12?)

[tr1p1ea]

Why exactly do you need that exact calculation?

[King Harold]

well, (doesnt it look familiar somehow?) i asume you're using it in xlib, i need it to make the offset-input somewhat user-friendly (aligned sprites, so not too many of those annoying shifts and masks, but an annoying calculation which looks nearly as bad)
like 0 - 11 should stay the same, 12 - 23 should become 88 higher next line 2*88 higher etc
that's the right formula isnt it?

[benryves]

Multiplication by fixed numbers is very easy. The easiest multiplication is by powers of two. For example:

Code: Select all

add a,a ; Once: x2
add a,a ; Twice: x4
add a,a ; Three times: x8
add a,a ; Four times: x16
add a,a ; Five times: x32
add a,a ; Six times: x64
; (and so on)

If you wish to multiply by a non power of two, you'll need to work out the powers of two that make up that number, then calculate them and sum them. For example, multiplication by 12 is [x2]+[x4]+[x8], so:

Code: Select all

; a = a * 12
add a,a ; a = a * 2
ld b,a ; b = a * 2
add a,a ; a = a * 4
ld c,a ; c = a * 4
add a,a ; a = a * 8
add a,b ; a = a * 10 (a*8+a*2)
add a,c ; a = a * 12 (a*8+a*2+a*4)

I'm a bit worried by that calculation you provided, as it looks like it's the way you calculate the address of the byte you start copying to when drawing a sprite, and the division and modulo 12 looks wrong. Maybe I'm assuming too much - what are you trying to do? Usually with sprites you only have to deal with multiplications by 12 and division/modulo 8.

EDIT: Oh, I see.

Let's do this more easily: let's say you want to take an (x,y) and want that to end up as the correct location.

Obviously, one x moves you one byte, but each y coordinate needs to move you down by 8*12 = 96 bytes. This is easy enough, as seen above - 96 = 64+32:

Code: Select all

; a = x
; l = y

    ld h,0
    add hl,hl ; *2
    add hl,hl ; *4
    add hl,hl ; *8
    add hl,hl ; *16
    add hl,hl ; *32
    ld d,h \ ld e,l
    add hl,hl ; *64
    add hl,de ; *96 :)

    ld d,0 \ ld e,a
    add hl,de ; hl = l*96+a

    ld de,plotSScreen
    add hl,de

; hl->address on screen to draw sprite

I'm not sure why you'd want to use a single value to determine location (as opposed to just using an (x,y) coordinate), but with the above you should be able to work it out (though it could be a bit messy what with dealing with 12, not a tidy number).

[King Harold]

a few posts back i allready said i was going to calculate 88a as 64a+16a+8a, but yes i really do think that formula is right, modulo 8 is for sprites that have to be shifted over a byte border, i however need to shift over the screen border or so to speek. (im not being an idiot again am i?)

[tr1p1ea]

Ahh yes i see what you are doing. I think i just used a LUT . Shifting over a byte border ... but i thought these were aligned?

[benryves]

(im not being an idiot again am i?)

No, just doing it in a rather interesting (and complicated) way

Possibly the simplest way to do this is to calculate an x,y coordinate first (set a y counter to zero. Now, check the input value - is it >= 12? Subtract 12 and increment y, repeat until it's < 12. The value left over is x) and then multiply back up to a location using those x,y values.

Code: Select all

	ld l,0
	
CalculateYLoop
	cp 12
	jr c,LessThan12
		
	inc l
	sub 12
	jr CalculateYLoop
		
LessThan12

Knowing me, I have the flags all wrong. It's something like that, though (long live trial-and-error coding).

[King Harold]

@ tr1p: oh yes i could do that.. would probebly be faster wouldnt it..
i guess this is just my BASIC instinct, trying to make everything into an insane formula because in basic THAT is faster, and much smaller, and it looks mroe professional, no offence tr1p its not like a LUT isnt professional in asm
@ben: yea but i was kinda avoiding long repeats they take so much time.. (uhm yea if you count the Tstates.. but then my BASIC instinct starts yelling at me NOT TO USE LONG REPEATES..)

[tr1p1ea]

LUT's are faster in BASIC too, but the space they usually take up make it not worth it. I still dont get why you need to do shifitng if this is for aligned sprites?

[benryves]

@ben: yea but i was kinda avoiding long repeats they take so much time.. (uhm yea if you count the Tstates.. but then my BASIC instinct starts yelling at me NOT TO USE LONG REPEATES..)

Going around a loop with five instructions in it a maximum of 8 times is a lot? Have you underclocked your calc to 2Hz?

[King Harold]

@tr1p: 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 and LUTs are faster in basic too, but hardly ever worth it)
@ben: im allergic to it, it doesnt feel right after 2 years BASIC programming, its a BIG voilation of BASIC optimization