So, this is a new game I'm working on, MoneyWalrii. It was inspired by CodeWalrus's need for money.

Essentially, you are a human who throws money at a walrus. It will be my first XLIBC game with sprites and such, so please bear with be as I ask a multitude of questions.

First question: I don't really understand how to get sprites into a program. I have Tokens and I have converted my sprite to Hex, but now, how do I get that Hex to become a sprite in the actual program? May I have some example code with an explanation?

Thanks in advance!

Oh, yeah, if this is to promotional, I don't mind if someone deletes the thread, I'll just not post about the game, just ask questions somewheres else.

EDIT: Hmmmm... Could I use the Celtic sprites? I'm probably going to display 7 sprites at once.[img][/img]

You've done something wrong, then .-. xLIBC tilemaps aren't in hex, they're saved into Appvars to be transferred to the calculator.
Also, I don't know if you did this correctly or not, but you can't just send a single sprite to the calculator and expect xLIBC to work with it-- you have to use Tokens' sprite editor to make a 128x64 image (it always has to be that size, regardless of how many sprites you have), then save as 'xLIB tiles (.8xv).'

Yeah, I was doing that wrong. DJ helped me figure that out on codewalrus. But after I make the spriteheet, and I insert it into the program, it become hex. Unless I'm using the wrong editor?

Why are you inserting it into the program? Within TokenIDE's sprite editor, press Ctrl-Alt-S [Command-Option-S on mac] and in the dropdown select 'xLIB tiles (.8xv)', then save.

Ok, I get it now. I though you had to insert it and then export as a 8xv.

EDIT: So, I got all the backgrounds and sprites all set up (or so I thought) but when testing, nothing happens except for a small black rectangle appearing in the top left hand corner of the screen

Here's my code and the files.
OUTDATED!


Code:


The files:
Program
Sprites
Background

Any suggestions?

EDIT 2: It appears that the walrus sprite isnt drawing correctly for some reason. I think most of the error are when I call the data and accesinight g the sprites fromthe appvar.θ[/b]

I think the real(4 isn't correct.
To draw a sprite in the top left corner:

Code:

What PT_ said is correct, except it takes the Width and Height arguments in 8x8 chunks-- so an 8x8 sprite would be 1,1 for width and height, a 16x16 sprite would be 2,2, an 8x16 would be 1,2, and so on.

Also, you need to specify what sprite you're drawing! After the 'pic-index' argument, add a number from 0 (top-left sprite) to 128 (bottom-right sprite); if you have a 16x16 (size 2x2) sprite, you'll need to have 4 extra arguments, 24x24 (size 3x3) would need 9 arguments, and so on. Remember, the 'sprites' are 8x8 chunks of pixels, and they're sorted column-first.

Lastly, it really shouldn't be necessary to use a full-size 32-color image... if you exported it from Tokens as a regular 80x60, though, then you want to use real(5,2,0. Otherwise, I'd really recommend going back into Tokens and re-exporting as an 80x60.

So too to draw just one sprite, after real(…………,0 I need 9 arguments of something? Would it be 1,2,3,4... or something else?

EDIT: I got the background working, now its just the sprite I'm having problems with. (not surprisingly) I don't think, as I said above, I am designating the right pic index.



Currunt code:


Code:


Files:
Sprites
Background
Program

You want to draw a sprite at (1,1), width 3 sprites, height 3 sprites, offset (0,0), transparent index 7, update = yes, picindex start 0, sprites 0 and 9? That all seems right except the PicIndices; surely 3x3 sprites is 9 sprite indices, not just 0 and 9.

Edit: Okay, you fixed that. Then there must be something wrong with how you're loading the spritesheet.

Edit #2: Your .8xv is "MNSPRT", but you're trying to load "MWSPRT". Proofread your code!!

So using this diagram, its seems that I want to display sprites 1 and 4?

-------------
| 1 | 4 | 7 |
-------------
| 2 | 5 | 8 |
-------------
| 3 | 6 | 9 |

Again, a sprite is 8x8. If you want to display a 24x24 combination of sprites, you need nine 8x8 sprites, so you need to specify 9 sprite indices (as you eventually did, once I spoonfed the example on the Wiki to you).

No, that is saying the order you put the sprite indices from your tilesheet.

Ok, so I got it fixed and all.

Great work, and nice job persevering. You're well on your way to creating a very nice-looking TI-84+CSE game.

Thanks!
But, I still am having problems displaying the sprites, I can't seem to get the hang of pic indexing. I'll probably be able to understand better tomorrow when my brain is freshened up.
Once I understand that, I should be able to finish this up fairly quickly.

You should be fine keeping the 'PicIndexStart' argument at 0, as it does exactly what it sounds like it does: sets the first sprite in the map. For instance, if you set it to '8', then the entire first column (remember, the image is eight tiles/sprites tall) will be ignored and drawing Sprite 0 will draw the first tile of the second column.

The other pic index arguments just tell it which tiles to draw.

I get that part, its just the numbers after PicIndexStart that haven't made sense to me yet. (PicIndex0 and so on) Anyways, as not to fry my brain I'm not gonna try to understand anymore today. (Unless someone has a really good way of saying it.

Ok, so I think I've gotten that figured out. I now have a loop that displays the sprite and changes sprite positions, but whenever the sprite is displayed, it changes from one side of the screen to the other. So it shows the background, then it doesn't. Why does this happen? I have the updatelcd set to 0, same as the background. I also tested the loop without anything but the real( command, and it does the same thing.

Remember the UpdateLCD argument: If it's set to zero, xLIBC will update the other half of the LCD and if it's set to 1, then xLIB will update it *and* switch view to the other half of the LCD. That's if you don't use that real(8,1 command, though. Basically, make sure that only the very last thing to be drawn on the screen has UpdateLCD set to 1. Everything else should be 0.