MaxCoderz

merthsoft · Post by **merthsoft** » Tue 29 Mar, 2005 3:08 pm

I've mentioned this to you before, Tr1p, but I was able to use a simple solution, now it matters a little bit more...
If you have a matrix that has zero in it (the matrix being your map), and you use the omnicalc sprite routine, it messes up, here's some code...

Code: Select all

{1:Asm(prmXLIB
{2,0:Asm(prgmXLIB
While 1
{4,0,0,12,8,0,11,0,7,0,0,1:Asm(prgmXLIB
Repeat getKey
End
Real(20,0,8,0,8,8,0,0               "Omnicalc's sprite
Repeat getKey
End
End

If you use a matrix that is half filled wiht ones, and half filled with zeros, and you make sure your picture has the two sprites, this'll show you the error... My zero is a blank sprite, and my one is a block...
The reason I have the Repeat getKey is so that it will draw the tile map, then wait, then draw the sprite, wait, and update the tile map...

Two simple solutions are to use XLIB's sprites, or not use zero in the matrix, which I might do (the latter)...

DJ_O · Post by **DJ_O** » Tue 29 Mar, 2005 7:01 pm

I guess you are talking about the garbled sprite 0 bug:

Look how the garbled sprites act when you move the cursor.

Has this been fixed in the recent version of xLIB?

Post by **tr1p1ea** » Wed 30 Mar, 2005 5:08 am

Hhhmmm... I have heard of this bug but i have no idea why it happens. Perhaps something it messing with the sprite data.

Have you tried it whilst using sprite page 2? Does the bug still happen.

The pc with the xLIB source is in the shed and has no net access :S.

merthsoft · Post by **merthsoft** » Wed 30 Mar, 2005 3:26 pm

Whoa, with page two it replaces the screen with a bunch of the sprite that you are using as the omnicalc sprite...

Post by **tr1p1ea** » Wed 30 Mar, 2005 5:31 pm

Perhaps Omnicalc uses the saferam areas?

DJ_O · Post by **DJ_O** » Wed 30 Mar, 2005 5:37 pm

I think it use ApdRAM or something like that

Gambit · Post by **Gambit** » Wed 30 Mar, 2005 7:23 pm

Yes, like I said somewhere else, Omnicalc does indeed use saveSScreen for the sprite( function; that's why I'm so frustrated w/ ZGreylib

edit: Omnicalc uses the beginning of appBackUpScreen too... Michael took all our safeRAM

DJ_O · Post by **DJ_O** » Wed 30 Mar, 2005 8:36 pm

Hmm I never tried page two yet because of the APD thingy. Maybe I could manage to deal with one sprite sheet at time. I am keeping all xLIB version on my websites including 0.1a because some people might want to use only the features of an old version or dont want to modify their programs too much when upgrading to a new xLIB version

merthsoft · Post by **merthsoft** » Wed 30 Mar, 2005 9:23 pm

I don't know anything about ASM, so don't kill me for this, but is there any way to make your own saferam?

Gambit · Post by **Gambit** » Wed 30 Mar, 2005 9:36 pm

Not "quickly"; appBackUpScreen and plotSScreen are fixed system RAM areas that TI allocated. I suppose you could make an AppVar or something and store the picture there... but only as a last resort.

Post by **tr1p1ea** » Thu 31 Mar, 2005 4:43 am

Well it appears that Omnicalc is the source of the problem.

This represents a real problem as now i dont really have any decent saferam areas. The only easy way around this would be to simply include 2 screen buffers in xLIB, this would of course drive the size up 1536 bytes.

DJ_O · Post by **DJ_O** » Thu 31 Mar, 2005 1:34 pm

That might be an idea, as diortem opnly takes up 10 kb of RAM

merthsoft · Post by **merthsoft** » Thu 31 Mar, 2005 2:47 pm

Or just tell everyone that they can't use sprite 0 if they use Omnicalc...
And then tell them to yell at Michael for taking all the good safeRAM...

dysfunction · Post by **dysfunction** » Thu 31 Mar, 2005 10:24 pm

I think forgetting about sprite 0 is the best idea... besides, I usually leave sprite 0 blank anyways so that a matrix filled with zeros (the default of course) would generate an empty map.

Post by **tr1p1ea** » Fri 01 Apr, 2005 3:30 am

Well i dont think that anyone needs to yell at Michael_V

.

MaxCoderz

Bug

Bug