A89: Re: C question... actually two C questions...

[Prev][Next][Index][Thread]

A89: Re: C question... actually two C questions...


> Whenever I attempt to use Sprite32 to draw a four level
> grayscale sprite (32x32), TI-GCC gives me an error on
> compilation. What seems to be the problem here? Can't
> Sprite32 handle grayscale sprites?

I haven't used it, but after glancing at the documentation it appears that
Sprite32 _can_ handle grayscale sprites, but not natively.  Meaning you have
to take your grayscale sprite, split it into two layers, and draw each one
separately on its own plane - the routine does not handle these by itself.

I suggest making a function of your own to handle this.  I'm assuming that
your grayscale sprites follow the "standard" format, with the dark plane
data followed immediately by the light plane data.  This routine will call
Zeljko's Sprite32 _twice_ - once for each plane.  I'll spit out a little
code now that should at least give you a rough idea of what I mean, and if
we're really lucky it might actually compile and work right "out of the box"
(it's starting to work right on the first try fairly consistently now =)

/* gray_sprite_32
**
** This declaration will probably be split into multiple
** lines when emailed.  be sure to remove the linebreak.
**
** Note that our declaration is similar to that of Sprite32,
** but it does not use a pointer to the mem address in the
** input (instead using GetPlane() to get the address)
*/
void gray_sprite_32(int x, int y, int height, unsigned long *sprite, int
mode)
{
    Sprite32(x, y, height, *sprite, GetPlane(1), mode);
    Sprite32(x, y, height, *sprite+height, GetPlane(0), mode);
}

On a side note, I must say that I love the GetPlane implementation - when
the input is a contant, it will simply evaluate to a memory address that
contains the pointer; when it is variable, it expands to a simple macro.
And it hooks into the inline ASM grayscale routine beautifully.  I worship
Zeljko's C skills =)

> That's sort of necessary for making any games...

Go tell that to the 82/83(+) guys =)

> Second of all, does anyone know if there's a way to
> accept user input like one would from DOS on the
> PC only on a TI-89? Is that how people work high
> score input (probably not)?

You need to use an input routine where someone can just type in their name
and/or initials and a pointer to that string is returned.  I wouldn't
suggest writing your own if you don't mind the TIOS windows - create a
simple dialog using the routines in dialogs.h - you want to call
DialogNewSimple(), DialogAddRequest(), and then DialogDo().  The string that
is input will be returned in the RequestBuffer that you pass into
DialogDo().  If you want example code for that, just ask.

> One more quick one that's been on my mind...

Pat Davidson criticises me for saying 3=4, and then you get away with asking
3 questions when the subject line says 2.  How fair is that?

> Is there a better way to detect keypresses then using
> a loop and saying Do ... While(RowRead... blablabla ?

Depends, what do you mean by better?  As I said, if you're looking for
aesthetic appeal, look elsewhere.

But as it is, most of the time your main loop is exited by either an exit
button or a special condition such as the player losing.  And you usually
want to run through that loop at least once.  That's what the do-while loop
was designed to do - I don't see anything wrong with it at all.

If, on the otherhand, you're just waiting for any keypress, try this
snippet:

while(read_keyboard_row(0))
    continue;

I don't like the "magic number" zero in there, but I don't feel like writing
out ROW_1_MASK & ROW_2_MASK & ROW_3_MASK & ROW_4_MASK..., and I can't decide
on a better name to use ("ALL_ROWS_MASK or ROW_ALL_MASK sounds icky.  And
programming is an ART! =P)

    -Scott


    -Scott