Re: A89: Programming Problem
[Prev][Next][Index][Thread]
Re: A89: Programming Problem
Okay, I've just tried it again, putting 00 behind each index, but the
same problem occurs: there's this really ugly line growing out of the
ball as it moves around the screen. Just as a test, I shrank the
program to just display the ball and then quit:
>>> >> ----------------------------CODE--------------------------
>>> >> #define SAVE_SCREEN
>>> >>
>>> >> #include <nostub.h>
>>> >> #include <graph.h>
>>> >> #include <system.h>
>>> >> #include <sprites.h>
>>> >>
>>> >> int _ti89;
>>> >>
>>> >> int _main()
>>> >> {
>>> >> static unsigned int ball [] = {0x3c, 0x7e, 0xff, 0xff, 0xff,
>>> >> 0xff, 0x7e, 0x3c};
>>> >> int key, x = 50, y = 50;
>>> >> void *kbq = kbd_queue ();
>>> >>
>>> >> ClrScr ();
>> Sprite16(x, y, 8, ball, LCD_MEM, SPRT_XOR);
while (OSdequeue (&key, kbq)) ;
>>>
>>> >>
>>> >> return 0;
>>> >> }
even just doing this, the ball displays with a funny 3 pixel line
sticking out of the left side of it... I don't know what's causing
it, cause I sure as hell didn't put it there (at least I don't THINK
I am :)
thanks for all you help,
Nathaniel Gibson
ngibson@ptd.net
>I've tried that but then the sprite looks really ugly, nothing like
>what was intended. I think it's because Sprite16 expects and
>unsigned int, but to do it that way, I need to redefine the array as
>an unsigned long int. Any thoughts?
>
>Nathaniel Gibson
>ngibson@ptd.net
>
>>ok. to bad. There really should be a sprite8 routine.
>>But thats your problem anyway.
>>put your sprite-data in the left part of the sprite instead (just
>>add 00 at the
>>end of every number, 0x3c becomes 0x3c00 and so on)
>>and let it go from 0 to 151. that should work. but it's an ugly sollution :)
>>
>>//Olle
>>
>>Nathaniel Gibson wrote:
>>>
>>> No, there isn't a Sprite8 routine, and I'm not well-versed enough to
>>> write one myself. I understand that I'm moving a sprite that is
>>> actually 16x8, that's why the check in the x direction is at 0 and
>>> 143, and not 0 and 151. The problem is Sprite16 doesn't accept a
>>> negative number for the location of the sprite, otherwise I would use
>>> -8 and 143.
>>>
>>> >Same problem as someone else here had before.
>>> >you define a 16x8 sprite, but only write sprite data in the
>>>right half of it.
>>> >the left half of the sprite is all blank.
>>> >(thats why it is called sprite16, it handles 16pixel wide sprites)
>>> >Your program thinks it moves around a 16x8 sprite.
>>> >Isn't there a sprite8 or something like that, to use?
>>> >then you should use that when moving 8x8 sprites, and define
>>>your sprite data
>>> >array as char instead of int.
>>> >
>>> >//Olle
>>> >
>>> >Nathaniel Gibson wrote:
>>> >>
>>> >> I wrote the program below just to see if I could get a ball to bounce
>>> >> around the screen. Everything works except for when the ball hits the
>>> >> left side of the screen: it looks like it hits 8 pixels too soon. Can
>>> >> someone please tell me what I'm doing wrong? I think it has something
>>> >> to do with the way Sprite16 processes the sprite, but I'm not sure.
>>> >>
>>> >> Thanks in advance,
>>> >>
>>> >> Nathaniel Gibson
>>> >> ngibson@ptd.net
>>> >>
>>> >> ----------------------------CODE--------------------------
>>> >> #define SAVE_SCREEN
>>> >>
>>> >> #include <nostub.h>
>>> >> #include <graph.h>
>>> >> #include <system.h>
>>> >> #include <sprites.h>
>>> >>
>>> >> int _ti89;
>>> >>
>>> >> int _main()
>>> >> {
>>> >> static unsigned int ball [] = {0x3c, 0x7e, 0xff, 0xff, 0xff,
>>> >> 0xff, 0x7e, 0x3c};
>>> >> int key, x = 50, y = 50, xChange = 1, yChange = 1;
>>> >> void *kbq = kbd_queue ();
>>> >> long int j;
>>> >>
>>> >> ClrScr ();
>>> >>
>>> >> while (OSdequeue (&key, kbq)) {
>>> >>
>>> >> if ((x == 0) || (x == 143)) xChange *= -1;
>>> >> if ((y == 0) || (y == 91)) yChange *= -1;
>>> >>
>>> >> x += xChange;
>>> >> y += yChange;
>>> >>
>>> >> Sprite16(x, y, 8, ball, LCD_MEM, SPRT_XOR);
>>> >> for ( j = 0; j <= 50000; j++) ;
>>> >> Sprite16(x, y, 8, ball, LCD_MEM, SPRT_XOR);
>>> >> }
>>> >>
>>> >> return 0;
>>> >> }
References: