The Upward Spiral - nothing (verbosely)

RSS Bot · May 17, 2006

got little-to-nothing done on the game last night... but did have a verbose eMail exchange with Mayday nailing down most of the inventory stuff. The combat attack animations are also starting to sound pretty good.

Coded but not tested (OK, not even merged back in) the smooth movement for the player on the tile map. I'm a little nervous that freaky mad wiggling the stick left and right (or up and down) could accumulate some "error" drift where the player won't "land" on a tile squarely, but no real harm can come of it, so I'll scrimp on ROM for that. Doing tile-based and sub-tile moves is actually pretty nasty business. I have a TODO spike solution to see if tracking the movement as strictly screen-based, and then translating back to tiles, will shorten the ROM routines any. Complicating things is that testing for overflows and underflows takes an obnoxious number of compare-and-branch tests (luckily underflows can use beq or bmi depending on context, but overflows pretty much always require a compare).

Combat mode animations are shaping up. It's a little tricky because I have to do animations across five different "rows" (subprogram chunks) in the main field area, and some of them are keyed to various temporary data. For example, when the player gets hurt the "how many HP did you lose" display needs to levitate in a certain place.

Conceptually, I use a two-byte timer, one byte is animation_timer which counts deciseconds, one byte is frame_timer which cycles 0..5 (NTSC) or 0..4 (PAL/SECAM). For the purposes of transient animations like player/monster attacks and the like, I started sprinking individual countdown timers all over the place, but now I'm starting to think that it can run full-tilt off the animation_timer. Whenever the player makes his (her) inputs, and the game starts "running on autopilot" fora while, I can just zero both timers. Worst-case is that the animations could "skip" up to 5 (NTSC) or 4 (PAL) frames, or, that idle animations of the monsters could flip states back to animation frame 0 suddenly. Hopefully, the player would be so distracted by pushing the red button that s/he wouldn't notice?

Alternatively, I might create another decisecond countdown timer and do the shared timer thing with it, rather than abusing animation_timer. That's probably the route I'll start off with, as it's easier to merge from it back to the single-timer code if I decide it sucks, than to seek-and-split the single-timer code. But the dozen or so independent timers are just dumb.

Text-handling... I've got a nifty but evil piece of glue code to eliminate duplicate fonts! Yay. It does smash a lot of ZP RAM, but, as it turns out, I was being too paranoid about RAM. Imagine that? I actually had some RAM "left over." Kinda.

Tile drawing kernel has (above its stack/tempvars requirements) 2 bytes still free!

Combat kernel (without some of the animation code and some of the input code enabled) hit zero earlier, but the new text handling and some rethinks of how to handle colour lookups for monsters solved that quickly. Back-of-envelope answer is that with all the code re-enabled, some timers eliminated, and Ursa(*below) turned on, I should have 20-odd bytes free.

Oh, yeah, monsters are Ursa-driven now. I decided that most of their attacks were pretty basic and found ways to do some black magic. The Ursa routine basically drops a "trigger" code that gets picked up to run the animation and precompute the end results. That means "high-level" (ish) combat routines so I can pass the buck to Mayday on fine-tuning the figures there.

(By "high level" I mean, um, almost as bad as assembly, but much slower. )

So, some "architectural" level puzzles sorted out.

Oh! My stack problems are an off-by-one lookup in the map table logic, and when I nudged that by -1 some constants I broke something that depended on that off-by-one. Maybe tonight I'll get some time to examine that further as well as to check out the stack glitch/table glitch.

And, line (7,2) still bites. I haven't really taken a knife to it yet. We'll see.

http://www.atariage.com/forums/index.php?a...&showentry=1564