When I called a 32x32 sprite that borders the bottom of the page, the very bottom line has extra pixels in it. This did not happen on the latest Celtic and xLib releases.

Here's the code I used:


Code:


Using this image as Pic0:


You can see on this gif capture I took from wabbitemu:


Thanks for looking into it.

Incidentally, I'm sure that this is a side effect of some code I added to Iambian's DRAWSPRITE to prevent a similar error from sprites extending into the final (nonexistent) row of Pic variables. I'll take a look at send you a fixed beta when I figure it out so you can check it out and verify the fix, if you don't mind.

sweet. sprites I have WILL be able to extend into that row though, right? Squirtle was just a bit short in this case.

Ok, KermM asked me to post this up, since there seems to be some variance in belief among community members. Pics with 64 rows CAN EXIST. Everyone knows how the 64th row and 96th column are generally unavailable to coders.

Unfortunately, because of this, many libraries I have used will NOT create a Pic variable encompassing all 64 rows. xLib's real(9) and Celtic3's identity(1) will only save pic data up to 63 rows. Those libraries will only display up to 63 rows. RecallPic will only display 63 rows of any Pic.

In fact, the only tool at my disposal capable of saving a 64-row picture is TI-Screenview, a program bundled in with TI-Connect. Give it a BMP with 96x64 dimensions and it will save a LEGAL Pic variable (1-10) with 779 bytes, instead of the normal 767 bytes regular Pics have.

Here is where I have an issue. I need that last row to store two rows of 32 by 32 sprites, otherwise that bit's gonna get cut off. I can create legal variables with 64 rows, but TI-Screenview will not create illegal variables. Any existing library will only store 63 rows of any picture. I need far more than 10 illegal variables with 64 rows.

So, I want to save legal 64-row pics to my calculator via TI-Screenview, and transfer them over with asm library commands to create illegal 64-row pics. No libraries exist that will do that yet.

I need this before I can carry on with my work.

Now, through experimentation, I have figured out a way how to RECALL a 64-row pic to the screen using an xLib command.


Code:


This recalls a sprite from a pic that is 12 bytes wide and 64 units tall. it draws it at (0,0) so the entire screen is covered, making it the only way to draw a 64 row picture to the graph screen.

If anyone can help me create illegal pic variables with 64 rows, I would be extremely grateful.

Thanks.

This is gonna take a lot of thinking. Anyone have any suggestions on this?

I'm not convinced a lot of people have seen this topic besides you and I.

I have seen it, I simply lack the ability to help. =/

This is why I looked for the small icon pics used in the newer Pokemon games to use. They are 32x32, but don't fill out the entire section of it, so many are 20x20 and less.

Hopefully someone can write you up something soon to help out.

wait, so why is that an issue? I don't think that has anything to do with my problem :/

I meant I did it with the small icons because I knew if I went with the full 32x32, I wouldn't have the room for half the stuff I wanted to do, like with a battle engine and such.

Only meant it in that way. I don't use pics to store the sprites, since there are only 10 normally available. I stored all my sprites in modified hex as an appvar to pull the data from.

yeah, I knew that, but space isn't really a problem for me right now.

Based on JoeYoung's feedback, Doors CS now has two concessions to users that want to use 64-row picture variables:

(1) Using the real(9) command now allows storage of both 63-row and 64-row picture variables. If used as real(9,0,C), it will store 63 rows into Pic C, creating a 756+11 = 767 byte variable. If used as real(9,0,C,1), it will store 64 rows into Pic C, creating a 768+11 = 779 byte variable.

(2) Using sprite-based commands like real(1) that use the sprite buffer, and attempting to buffer into the 64th row of a Pic variable, will now succeed if the Pic variable has 64 rows, or truncate to the 63rd row if the Pic has 63 rows. No extra arguments are necessary to take advantage of this behavior.

Enjoy.