Calculator Community > CaDan SHMUP
Yet another shooter
DJ Omnimaga:
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
kalan_vod:
Well I will enjoy it either way, and seeing how things are working out for tr1p1ea and his 8 levels of GS running at 4 levels of GS...I am really excited to see what this looks like!
TIfanx1999:
If you can keep the GS without sacrificing speed all the better. Im sure it'd still be fine without tho.
Iambian:
At the moment, the bullet rendering and movement engine is now working fantastic for 2x2 sized bullets and linear paths, respectively.
Right now, I could simply add in your character, collision detection, and then call it an asteroid dodging game in about fifteen minutes or less, but I know I plan on having a better game than that, so... I'll need more time to actually code in that part.
Grayscale (of some sort) has not been sacrificed as of yet, so there still might be hope. Then again, I haven't done any backgrounds so that might still take some time.
Still... any suggestions of any names? I just thought up of "Touhou7i", considering that this game will be be based off of the 7th project and the "i" would indicate it starting in the imaginary direction (lol).
EDIT: Just did some screenshots.
This screen shot shows off some nice, even movements and teh large number in the scoreboard : http://img239.imageshack.us/my.php?image=ptiani1ps9.gif
This screen shot shows off the engine when it's totally maxed out. The scoreboard has been changed to reflect the remaining bullets on the screen, divided by 2 : http://img185.imageshack.us/my.php?image=ptiani2nh0.gif
Iambian:
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version