Timings on the first row are perfect, and the HMP0/1 bugs are basically flushed out finally, so that's all good. There's still some crap involving line (7,2) on each row, but there should be sufficient SLEEP cycles now that I don't use WSYNC to make up for it. A new bug that crept in somewhere there, though, is that the cursor pointing into the map data seems to be drifting.
Here's the lowdown. There's a big macro that draws a line. Lines are grouped into triples, and odds & evens. So, t
Got my HMOVE's almost all striking at the right timings, but not my PF2's, and somewhere in there I really walloped the HMP0 when I shouldn't have. But, notice where the HMOVE bars are(n't). So, 20 minutes' work in Stella debugger knocked out most of the problem... and the remaining stuff should be as easy (...?!) to clear up. I hope.
In redoing some "far call" text subroutines I suddenly realized I was waay over-engineering things. (C=128 users will recall how bad the KERNAL ROM far call routine was? Yeah. That bad.)
So, I needed to crib together my module organization anyways, so here it is for posterity.
Most of the modules are major game modes/screens. They're modal, and basically "jump/goto" one another, so I don't need "subroutine" semantics. Their communications are entirely through the player's persistent data
Probably too many WSYNC's as placeholders in the vblank, but the combat kernel (still sans major improvements blogged earlier today) rolls my B&W test TV. (A 12" "LLOYDS" branded NTSC.) The 11" colour set -- a more modern (early '90s) Panasonic set -- displays a fine and steady picture, but it would be more tolerant of bad signal, being more recent. I think.
Note to self: adjust timing of vblank to use INTIM* rather than just throwing a shitload of WSYNC's in there.
PS: Note[2] to se
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 n
Last night's efforts. Ignoring the rest of the screen, which I've blocked out for the moment, notice that these trees are drawn "perfectly." Every PF2 hit is exactly on cycle, and the HMOVEs also. (There's an HMOVE on every scanline, but always at cycle 73.)
The rest of the screen is fouled up because my "bad line" (triplet 7 line 2 on each row, i.e. scanline 24 of each 24-scanline row) is still not cleaned-up. Now that I have the timing "perfect," though, I can try to re-arrange some of the
This is me tuning the bad lines. See the missing pixel in the forest? Center of screen, where PF2 is about to reflect itself. naughty, naughty pixel.
The pink "spots" are a decoration. Decorations on the map exist at 12x8 px per tile, i.e. they're drawn using P1 at double-clocks and 2 line resolution. (Tiles themselves are 4x8 pixels, using 4-clock-wide playfield pixels times 3 lines resolution.) Later on they turned into a cheesie picture of an house. Then, something disrupted .y during my
In case anyone's watching ...
Re-introduced colour code and came up with some nice optimizations based on the "tiledraw.o" test. The current test kernel in that series, "tiledraw3.o" is coming along.
One annoyance? branches in the P0 draw routine taking a hit for the carry in PC (i.e. crossing a page boundary) may require some of my sleep nop's to be replaced with page alignment spacers. Keeping that working will be sheer Hell.
Theory: if I need to add some bytes but not cycles to ge
Oh... and my Internet connection is somewhat back up, but mail probably won't work for a day or so yet because the cable bastards changed my IP address and my DSL won't be installed until at least Monday.
A while back, I posted some of my Perl utilities. Well, I finally got the 48-column sprite stuff into mkart, so, here's the latest.
Oh, and this fixes a bug with 8-column sprites too. (The "bitmap pictures" weren't written to the comments field.)
ramcart_disk.zip
I haven't done playfields yet, and I need to for the Combat system in CiE, but ... just hasn't been urgent enough to get written.
Oh... and mkmap is under the scalpel due to the epiphany and 24lk ... the new one has to d
First, because I was having "attachment issues" earlier, here again are:
The kernel test image: tiledraw.bin
And a screenshot of it courtesy of Stella:
So, what does this show?
First, there's a map of tiles: it's an 8x8 grid of 4x8 tiles. Each pixel is a playfield pixel wide and 3 scanlines tall.
Second, there's a little crappy player sprite. He's just animating as though he were walking. He's 8x12px and is one player pixel wide by 24 scanlines tall.
The player is rotating thr
It's been a long time a-coming but something "clicked" in my head Friday and I managed to get the above entry (lovely grid pattern that's stable) drawing. The idiots at the cable company have somehow managed to fry my connection at the moment, so I may have to burn a CD-R and sneakernet it to a Panera to get anything uploaded.
The biggest fallout is that I've gone from a "2lk" format for the tile artwork (as shown in the yellow photo) to a "3lk" format for the playfield, with a "2lk" format
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord