MaxCoderz

all sprites on the bottom of sprite sheet have the bottom clipped off. i found this the hard way. i am making two suggestions.

instead of calling 84 and having it show a demented sprite, skip 84-95 where they are, and call it from where the current 96 would be.

HAVE THE ABILITY TO USE MORE SPRITES!!!!!! 288, 256 working sprites for a game of my caliber needs more.

i guess you can think of me as a tester, but the longer i wait for the fix, the longer i cant prgm zelda

It is impossible to have more than 256 tiles in 1 map without some MAJOR modifications. You can have more than 256 sprites etc ... just you cant have more than 256 'different' tiles in the same tilemap.

The bottom row getting clipped off is not my fault, it happens because when you save a PIC file the tios doesnt save the bottom row.

You can have more than 256 tiles and sprites in your game ... you just cant use them all at the same time.

i guess ill hv to make a lot of changes...

i know its not your fault that they get clipped, im saying completely deny the user the use of those spots, since they are useless anyway.

good luck if you ever change this prgm

I'm confused, Why can't you have more than 256 tiles in 1 map? i mean your using a matrix right? So why the 8 bit limit, your in fp country, no?

it reads in from the varkiable ypou store the sprite number to and lds it into a. a doesnt really accept values greater than 255 so you have a limited range. a really easy way to fix this is if the number you input is greater than 255 it loads from a different picture. maybe?

If you try loading a greater value I'm sure tr1p has a check that prevents it from accepting greater values, OR it just rolls over to 0. Then again I havn't really looked into xLIB so I wouldn't know.

yeah but what it SHOULD do is get the integer answer of (numberentered)/(255) and use that as the picture variable. like TIBASIC or asm load into hl and check the h for the pic number w/e you get the picture.

i've tried using a number greater than 255 and i know exactly what it does. it keeps minus-ing 256 til it gets in range. so 300 would yield pic sprite number 44 (asuming my math funct. is on today....)

but it SHOULD nvm no one seems to get it.

are you trying to say x=sprite
x-int(x/256)->x
(in basic)

He means values 0-255 (or 1-256, I dunno how it works) would be Pic0, the next 256 would be Pic1, next 256 would be Pic2; they'd just roll onto the next pic if you exceed the value. Right? That'd be nice actually..

???? first off, thats what he has; second, only 84 sprites are allowed per page

Guys, have you heard of mod?

Number mod 256 = some vaule between 0 and 255

Second, if I was tr1p I would just use TI pretty little _ConvOp1. That takes a value in op1 and puts it into DE. Then I would just use E and ignore D.

On any picture there is 96 tile(screw the last line thing), so

E div 96 = pic num
E mod 96 = tile num.

I don't know if later is what tr1p is doing but I still can't believe people are getting so huffy about it.

My point was, being in FP numbers I don't see a reason why he couldn't exceed 256 tiles with only minor modification.

course we know mod x%a = remainder of x/a. but i wasnt sure if people would understand.

@DA (and all) That is EXACTLY what i meaant. great minds think alike?

As crzybl said: When you go past the allotted number of sprites on Pic1 (8x12=96, minus 1 since it starts at 0) so when you go past 95 (I think) it goes to Pic2 etc.