Page 1 of 2

Bug

Posted: Tue 29 Mar, 2005 3:08 pm
by merthsoft
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)...

Posted: Tue 29 Mar, 2005 7:01 pm
by DJ_O
I guess you are talking about the garbled sprite 0 bug:
Image

Look how the garbled sprites act when you move the cursor. :shock:
Has this been fixed in the recent version of xLIB?

Posted: Wed 30 Mar, 2005 5:08 am
by tr1p1ea
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.

Posted: Wed 30 Mar, 2005 3:26 pm
by merthsoft
Whoa, with page two it replaces the screen with a bunch of the sprite that you are using as the omnicalc sprite...

Posted: Wed 30 Mar, 2005 5:31 pm
by tr1p1ea
Perhaps Omnicalc uses the saferam areas?

Posted: Wed 30 Mar, 2005 5:37 pm
by DJ_O
I think it use ApdRAM or something like that

Posted: Wed 30 Mar, 2005 7:23 pm
by Gambit
Yes, like I said somewhere else, Omnicalc does indeed use saveSScreen for the sprite( function; that's why I'm so frustrated w/ ZGreylib :x

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

Posted: Wed 30 Mar, 2005 8:36 pm
by DJ_O
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

Posted: Wed 30 Mar, 2005 9:23 pm
by merthsoft
I don't know anything about ASM, so don't kill me for this, but is there any way to make your own saferam?

Posted: Wed 30 Mar, 2005 9:36 pm
by Gambit
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.

Posted: Thu 31 Mar, 2005 4:43 am
by tr1p1ea
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.

Posted: Thu 31 Mar, 2005 1:34 pm
by DJ_O
That might be an idea, as diortem opnly takes up 10 kb of RAM

Posted: Thu 31 Mar, 2005 2:47 pm
by merthsoft
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...

Posted: Thu 31 Mar, 2005 10:24 pm
by dysfunction
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.

Posted: Fri 01 Apr, 2005 3:30 am
by tr1p1ea
Well i dont think that anyone needs to yell at Michael_V :).