No real update yet. The code that renders and moves player bullets seem to be working and I intend on letting the player shoot pretty soon, although it'll be at nothing at the moment. That'll be the next thing to be coded, but I still have to write a clipping sprite routine that works on a 64*64 pixel buffer as opposed to the more traditional 96*64 pixel buffer. It *should* be easier, but let's see how well things pan out.

After that, I'll be coding in a scripting system so that stages and enemies (including bosses) can be "coded" in. The system'll be flexible enough to allow loading of external levels (though I may not do that yet) and the ability to challenge individual spellcards in the practice mode. Timing won't be as much of an issue since I totally neglected a completely free slot in my interrupt timing scheme.

Luck or not, the project can be completed as the scheme stands. The foundation is solid enough...

... though don't expect the game to work on anything higher than a TI-83 Plus when this is completed, since the game requires interrupt timings found only on that calculator. A work-around for a higher calc would probably be to use a crystal timer to simulate timings similar to that found on a TI-83 Plus.

EDIT: I'll also be adding in a LOL-type internets story at the suggestion of Drak (#lobby) and a "Nullity" game mode which is reserved for only the masochistic professional (or professional masochist, whichever floats your boat. 1 life, no bombs. Potential Youtube vids, anyone?)

Looks nice for what's done at the moment. I like what I'm seeing. Can't wait to see if Celtic III will render it the same way

( if you're wondering what Celtic III is, inquire within )

Please do continue to work on the game. It appears promising.

So... here's the current status of the entire project:

I've gotten "enemy bullets" to rain down in a hell of ... whatever. That's what this type of game is supposed to be. You can actually play as far as dodge the crap that's being flung at you, but you still can't shoot back at anything, let alone being able to shoot! That's what's being planned. So far, up to 8 enemies are planned to appear at the same time but if given the time to do so, I might expand it to 16. As far as dodging goes, the engine's capable of flinging 128 of those deathballs at you simultaneously. No worries, since you can hold the MODE key down to "focus" your player to make it easier for you to dodge all that crap. Player spell cards / bombs aren't fully implemented, but you should be able to see the beginnings of such. Thing about the bombs is that so far, they're only usable when the "Border of Life and Death" is running (time between you get hit and the time you die). A quick edit can change this to an "anytime" type of deal.

Didn't feel like reading that mess? This screenshot says a bit of it (though the scoring system is still being used as a debugger) : http://img184.imageshack.us/my.php?image=img3ba4.gif

This .gif is best viewed in Firefox.

Indeed, the screenshot I'm seeing three posts above appears impressive. Great work, tifreak.

But... why didn't you ask *me* to do the sprite routine?
- Was I not available at the time?
- Did you think I was too busy?
- Did you think I couldn't do it?
- Did you think I was just gonna rehash Celtic III?
- Was the Mastermind gonna blow up the world if you asked me?

The following is another screenshot of the game. This time, it demonstrates the circular bullet movement routine and ... I'm out of time. Just see for yourself.

http://img505.imageshack.us/my.php?image=ptiani1un5.gif

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.

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.