MaxCoderz

Crosspost from United-TI, pictures might not work.

Touhou Project 83+ (updated August 18th)
A port of the famous Japanese danmaku (bullet curtain) shoot 'em up game. The game is made primarily for the 83+. It should work on the 83+SE, 84+, 84+SE and nSpire (with 84+ keyboard) because of backwards-compatibility. However, support for fast mode or special 84+ features isn't planned.

A movie of typical gameplay of the original can be found here.

First public alpha
touhou.8xp (7.02k )

Current features
* 8 directions of movement
* Sweet splash screen
* Precise physics engine with fixed speed (no lag if suddenly a lot of bullets appear)
* Support for up to 32 enemies at the same time.
* 16 billion directions of enemy movement
* Custom enemy patterns
* Shoot and kill enemies
* Support for 8-pixel wide sprites
* Getting shot by an enemy
* Multi-screen levels.

Planned features
* Custom bullet patterns
* Awesome boss fights
* 16-pixel wide sprites
* Multiple difficulties
* Nice story with a big focus on the characters (expect something cheesy)
* Full screen boss pictures
Maybe:
* Weapon upgrades
* External level support
* High scores
Definitely not:
* Greyscale

Screenshots
Movement and shooting


Menu + diagonal movement


Patterns and bullet hell


Enemy-bullet collision, explosions


Levels, player-enemybullet collision.


Character graphics
Forest Magician


Ice Fairy


Lunarian Nurse


Moon Rabbit

Alternate look:


Chinese Girl (not included)


Strange Magician (player) dancing

Looks fantastic leofox, great work and is shaping up to be one of the must have calc shooters! .

Yes, this looks very good... Seeing the menu; is this made in basic

He didn't write it in BASIC, it is indeed ASM, but he chose to use the TI-OS menus out of laziness.

kv83 wrote:Yes, this looks very good... Seeing the menu; is this made in basic

Haha, that would be amazing for basic indeed. I just took an ASM lib that copies the BASIC menu, like unknown_one said, because i'm lazy. (actually I believe that using external routines where possible greatly reduces development time and increases stability overall)

I might be making a custom menu one day.

Ah! Well, non the less good to see you working on something and i'm very impressed by the screenshots and pictures. Keep up the good work!

Is it even possible to do Bullet Hell on a slow LCD screen? The slow LCD screen made me cancel my smoothscrolling grayscale DW2 project for the TI83.
I'd think you'd need to have bullets draw as short, thick line segments, then count the collision only when the far endpoint touches you instead of the whole thing. That way they can be visible on the screen by the time they strike you.
Also maybe use a black background so you can play with lower battery power remaining.

Dwedit wrote:Is it even possible to do Bullet Hell on a slow LCD screen? The slow LCD screen made me cancel my smoothscrolling grayscale DW2 project for the TI83.
I'd think you'd need to have bullets draw as short, thick line segments, then count the collision only when the far endpoint touches you instead of the whole thing. That way they can be visible on the screen by the time they strike you.
Also maybe use a black background so you can play with lower battery power remaining.

omgdwedittalkingaboutmygamemuststaycalm

It's going to be a serious challenge to make a bullet hell that works on the small screen, I didn't have any trouble with the visibility yet though. Lucky for me, most Touhou games work with slow bullets (just a large amount) so there won't be much blur either way. I checked on-calc, there is some blur, but if you decrease the contrast for a bit it's visible enough.

Collision detection is sucky enough as it is, I don't really feel like changing anything though.

New screenie showing how the engine handles up to 175 bullets and 12 enemies at the same time:

You have to use FF3 or Opera, or the screenie will look shitty. I'm guessing the FPS is between 6 and 10, which is a bit choppy but still playable.

It might look like I disabled collision but the checks are still there, I just disabled the "jp c, playerHit" somewhere to make sure I don't die every two seconds. This is as slow as it's ever going to be.

Holy!... That place has more lead than a toy from...well I won't go there.

Keep 'em coming! Keep 'em coming!

I still have no idea how it would be possible to dodge those bullets on hardware. The bullets are there and gone again before they've even faded onto the screen.
I think the effort is great and all, it just looks like it would fail miserably if anyone tried to play it anywhere other than an emulator. LCD blur is a bitch.

Dwedit wrote:I still have no idea how it would be possible to dodge those bullets on hardware. The bullets are there and gone again before they've even faded onto the screen.
I think the effort is great and all, it just looks like it would fail miserably if anyone tried to play it anywhere other than an emulator. LCD blur is a bitch.

The screenshot is nothing more than an engine test. The level would be really impossible because the gaps between the bullet streams are a bit smaller than the hit box. Real sick levels would have way different patterns, with slower bullets.

Of course, even if the bullets are actually a few pixels behind to what the game thinks, it wouldn't be impossible to take that into account when playing would it? It would be a bit harder but not impossible.

I've never had any of the problems you described on real hardware, the game plays fine and is actually a bit easier than on emulator. I think the key lies in good level design, not in shitty routines that try to determine where the bullet is on the screen.