This looks cool.  Good luck!

lol DJ.

Thanks for the support. Anyone who is interested in helping me test the alpha release can email me at [email protected]. I won't be done for a while, but I'll be needing testers. You will need a TI-83+/TI-84+ or compatible and a link and a friend to play with.

Also, here is another feature I plan on adding:

Without another calc detected, the program goes to a repair section. This will be calc specific. There will be one release for the 83 and another for the 84:

TI-83: Winning fights earns you repair points, which you spend to repair systems damaged in battle.

TI-84: Repairing systems takes a specified amount of time. Repair time elapses while the program is running in repair mode (You should know why this can't be done on the 83).

That makes me wish someone else where I live cared about calcs so I could play this

Nice to hear

Unfortunately, it is pretty much the only way in Celtic III and xLIB. I think Celtic III has another sprite command, though:

|05             | identity(5,"HEXSTRING",x,y,w,h,logic,flip,update_lcd)
|               |
|  PUTSPRITE    | Works just like the xLIB command real(1,...) except that
|               | the Pic and the coordinates on that Pic file are not
|               | defined.
|               |
|               | Instead, a string consisting of hex digits is used to
|               | define the sprite as inline data. For example, if you
|               | wanted to draw a black 8*8 block at the top-left corner of
|               | the screen with XOR logic and drawn immediately...
|               |
|               | identity(5,"FFFFFFFFFFFFFFFF",0,0,1,8,3,0,1)
|               |
|               | Useful for those that want to display sprites without the
|               | use of bulky image files.
|               |
|               | For large sprites, each byte goes LEFT first, then DOWN,
|               | so specifying "80FF0180000180000180FF01" would relate to
|               | such a perfect box 3 bytes wide and 4 pixels down.
|               |
|               |
|               |
|               |
|               |
|               |
|               |
|               | Note that any missing arguments will default to the value
|               | of zero (0) instead of 32 as in xLIB.
Otherwise, if you absolutely want to stick to xLIB here's the xLIB command in more detail, explained in Celtic III readme (since Celtic III offers 99% backward xLIB compatibility):
|01             | real(1,x,y,w,h,pic_n,pic_x,pic_y,logic,flip,update_lcd)
|               |
|  DrawSprite   | Draws a sprite on the screen at (x,y), being the top-left
|               | corner of the sprite.
|               |
|               | W = width in bytes. i.e. 1=8pixels, 2=16pixels, etc to 11=.
|               | H = heigth of sprite in pixels.
|               |
|               | pic_n refers to the pic # to source the sprite from. Pic1=1
|               | , Pic9=9, Pic0=10. Use your imagination for other numbers.
|               |
|               | pic_x and pic_y are the top-left coordinates to start
|               | sourcing the sprite from. pic_x MUST be 0 thru 11 as they
|               | are "aligned". On-screen, this is a multiple of 8.
|               |
|               | "logic" is a number 0 thru 3, refers to sprite drawing
|               | method to employ.
|               | 0:Overwrite
|               | 1:AND
|               | 2:OR
|               | 3:XOR
|               |
|               | If 4 is added to "logic", the sprite will be inverted.
|               |
|               | If "flip" = 1, horizontal flipping is applied to sprite.
|               |
|               | If update_lcd is set to something other than zero, the LCD
|               | will be updated along with the sprite draw.
Also keep in mind xLIB  doesn't work on OS 2.53 MP or higher on the 84+. Celtic III does, however.

http://www.omnimaga.org/index.php?action=downloads;sa=view;down=479

Also avaliable on United-TI forums, but you must register an account to download their copy.

Well pics are not that bad, except for the fact you can easily overwrite them. The trick is to group them. A game that use pics doesn't necessarly make the entire game bad, if that's what you imply. In fact, as proof they aren't that bad, 7 of them made Ticalc.org front page news before:

http://www.ticalc.org/archives/news/articles/14/145/145426.html
http://www.ticalc.org/archives/news/articles/14/142/142801.html
http://www.ticalc.org/archives/news/articles/13/139/139347.html
http://www.ticalc.org/archives/news/articles/13/131/131953.html
http://www.ticalc.org/archives/news/articles/12/124/124432.html
http://www.ticalc.org/archives/news/articles/12/122/122186.html
http://www.ticalc.org/archives/news/articles/11/119/119577.html

If you absolutely don't want to use pics in your own, though, I think Celtic has hex commands. However, I never used them. For hex conversion, you would need to use a hex converter like this:

http://www.omnimaga.org/index.php?action=downloads;sa=view;id=520

There's an on-calc one somewhere that someone recently posted on the forums but I forgot its location due to the post rate, I'll try to find it later. There's also the sprite editor included with Axe Parser, which converts sprites to HEX.

Thanks Gale. Once the program is done and uploaded, I will provide the link. Also, to coordinate movement between calcs, I will be using an assembly subroutine, not the calc's TI-Basic commands, for exactly the reason you say.

Well, of course, for the most seamless linking, you would be better to write your entire code in assembly. But, if your like me and cannot program in assembly, the one I'm using is vComm. You can find it in the TI-file archives.