Dave C

Update - after taking a little break I've come back and made some refinements based on the Twitch feedback... diagonal movement player should leap backwards after charge attack more horizontal range of movement game speeds up as more enemies pass player moves more slowly while charging Some other ideas haven't been implemented yet make couch compliant (all control from joystick, no reset switch) more points / based on hit accuracy / Joust-style hits enemies should be going other direction being chased / chasing of enemies (both?) enemies have no weapons - look like you are hitting them on the nose Some glitching is happening on hits - I only just noticed it. I wound up spending a chunk of the dev time reorganizing the data + code to stay in the 2K range. Originally I had separate graphics for the player and riders and switched to using the same graphics + reflection I think there's now enough room to tune the gameplay - and maybe some minor graphics tweaks On Javatari and GitHub https://javatari.org/?ROM=https://github.com/DChristianson/legendary-spear/releases/download/v0.9.0/LegendarySpear_NTSC.bin https://github.com/DChristianson/legendary-spear

Awesome! Thanks for the bump, hope to watch live but I'll have some tricky timing with work tomorrow. Looking forward to it!

Those are really good ideas. Just pushed a new version that adjusts the point values as well as the damage. Also messing with having the rocks be ... almost the same speed. They now move at a speed based on where they are on the screen vertically, trying to go for kind of a parallax effect. Big problem now is I'm right at the limit for 2k. I'm sure I can squeeze more out of it but I'm starting to feel a little caged in. I didn't start with the intention of making a 2k game but now I feel compelled... https://github.com/DChristianson/legendary-spear/releases/tag/v0.8.1

Yes I originally was studying the various multi-sprite kernels I found here and got onto this track of wanting to try to make a demo of two big sprites moving around seemingly independently which led to this size/shift approach. In case anyone wants to play around with it I wrote this (python) script to generate code for this style of sprite from image files. It's a little bit hardwired to work with aseprite files r/n but it wouldn't be a stretch to adapt it to work directly with png / etc. https://github.com/DChristianson/legendary-spear/blob/main/scripts/spritify.py Basically if you pass it an image > 8 pixels wide and supply the --bits 8 option it will interpolate the image into 8 bits and emit the appropriate multi-resolution sprite code (nusiz and hmov jammed together in 1 byte - the kernel uses the low bits for NUSIZ and high bits for HMP). Note it will straight up fail if you give it an "impossible" image (for instance if getting to the next line means shifting more pixels than you can shift in an HMOVE)

Thanks. Reading the Stella programming guide it looked like lda $00 would read CXM0P - which made me wonder if a pla (with SP of $ff) should be expected to return the same value of the lda. Either way I'd rather use CLEAN_START and it will save me a few instructions - thanks!

Note: I'm assuming this is all old news (I can see threads about the stack on these forums and various stack manipulations in old games)... anyway... Working through some code I've been working I realized I had a bug where I wasn't initializing the stack pointer ...In the case of the code I had written ...somehow in Stella this all turned out to somehow do what I had originally intended... so I didn't notice at first... What I'm wondering about is if the stack is pointing at 00 (i.e., not RAM) are pha/pla going to have the same effect as lda/sta. When I wrote some test code (below) the pla and lda never return the same value. With actual hardware I assume the TIA wouldn't know/care whether an lda/pla is trying to address it...? lda #$ff ldx #$00 txs pha pla lda $00

Ah, I didn't realize PAL60 was a thing, very interesting. I could potentially do PAL50 in a cheap way by making the horizon at the top of the screen bigger. Potentially I could do something more substantial like make the playfield bigger and/or adjust timing but timing is already a little weird, and changing the graphics / adding riders could run me up against RAM/ROM limits (currently using almost all of both). I've updated the post with NTSC and PAL60 versions. Github repo is here: https://github.com/DChristianson/legendary-spear

Nice. I'll work that into the build. I had thought maybe I'd have to do more than change the colors, but if it works this way even better.

Update: I've made a few minor tweaks for stability, I'm calling this version the final release. - one more fix... one more version... I did do a little work towards having a splash screen / thinking about different gameplay elements but ultimately that will have to be a new game (or maybe a Director's Cut?). In the meantime I'm mocking up some ideas for a new project, can't decide on whether it should be 2600, 8-bit or ... This is a Stampede-like side scroller I've been working on off and on, finally made a push to kind of bring it all together. Comments appreciated. Since I've only ever run it on Stella and Javatari kind of wondering if it actually works on real hardware... thanks Update 2022-01-15: "v1.1" - fixing bug reported by SpiceWare (massive instability in dev mode) Update 2021-12-31: "v1" - minor stability cleanups Update 2021-10-10: "release candidate 2.1 2.5" - tweaked game end to try and prevent too-quick restart Update 2021-10-09: "release candidate 2" - difficulty level adjusted, added charging and hit mechanic Update 2021-10-03: "release candidate 1" - difficulty level adjusted, awards given for high score ... Update 2021-09-11: added gameplay tweaks, and basic sound Binaries attached but the GitHub Page always has latest binaries and code. LegendarySpear_NTSC.bin LegendarySpear_PAL60.bin