"danmaku" sounds so much like Damakaru on IRC O.o (randomist/insanity nickname the last time I saw him), I hope you finish this project though, this sounded rather promising. I can't wait for screenies when possible.

As for name, I might try to get some ideas in the next days, altough I can't promise anything

Sounds great, I would love to see something more on this as the plans/features

I would drop grayscale support if I was you since it might be hard to make it look good on all calcs at once and slow the game down. No grayscale would speed up things signifiantly

If you can keep the GS without sacrificing speed all the better. Im sure it'd still be fine without tho.

I've gotten character display and movement has now been coded in and it successfully works inline with the scoreboard, so the player can only really move at each refresh cycle (your dx and dy will be used to calculate movement steps for each refresh cycle). Coding some sort of collision detection shouldn't be too difficult, since the code will be much similar to the routine used to handle rendering bullets (the hitbox will be 2 by 2 pixels at the approximate center of the sprite). I should also be able to code it inline the scoreboard routine so that it, too, will have virtually no impact on the speed of the program.

With writing stuff inline with the scoreboarding routine, I'm exploring what other aspects of the game can be crammed within the wasted clockcycles used to update the scoreboard, such as rendering enemy sprites, player bullets, and such. Keep in mind that the spot that displays the score already uses its wasted clockcycles to calculate each digit to the score.

Now, for those that are unaware, clockcycles are "wasted" because the LCD requires some amount of time of delay before it'll accept more data or instructions. This equates to roughly 60 clockcycles if the processor runs exactly at 6Mhz since the documentation for the LCD states that a 10 µs delay is required between data writes, but most of my sources agree that it's safe to pick a delay around 65 to 66 clockcycles. If you wanted to be lazy, you'd just make the processor do meaningless work just to wait out that delay and continue to update the screen.

Between just writing the data (assume 42 clockcycles because an out instruction takes up 11 and the worst way to feed that data would take up 13), writing an entire column (64 bytes) would produce a waste of around 2688 clockcycles. There are four of these columns, so in updating the scoreboard, you'd burn off 10752 clockcycles doing absolutely nothing.

In order to keep the timings in my program tight enough to actually work, I intend (and have been partially successful) in utilizing most of those wasted clockcycles in performing something of some use. If you remember from the top of this post, you'll already know what I've done with it so far.

Doing it this way *does* require a bit of memory for all that code, but the speed benefit is way worth it, especially because I'm writing a FlashAPP for this game.

----------
In summary...

Not a whole lot got done except moving a character sprite and drawing it across the screen.

Grayscale is getting iffy unless I allocate a third buffer for the contents of the screen inbetween updating.

TI-83+SE/84+ support is *NOT* planned until I can get interrupt timings down for that.

I'm trying to get the biggest bang for my buck when it comes to spare time between screen writes.

A request for backgrounds (64 pixels wide) flies out to whoever wants to do it.

Cherry flavoring has been added.

I made one slight improvement in the game, but that improvement forces me to keep the grayscale. What I did was that when the player "focuses", it switches the player sprite to the gray buffer so that the hitbox, whenever I get that coded in, will be easier to see against the player sprite. I did it this way because in the original game, focusing causes the player's hitbox to become visible. Now, it's just a matter of coding in the actual collision and then we'll see how things progress.

This complicates things now that I have to redraw the gray buffer each time now, but I sure hope I can get it worked out.

I have collision detection and all those goodies associated with the hitbox programmed in, and I must say. It looks pretty!

When I put in the code that handles what you do if you get hit (like decrease your life, cause you to explode, whatever), I'll go ahead and post another screenshot of the game so far...

... and maybe a copy of the game in that state. More details about that when it becomes available.