So, here's the latest brainstorming with regards to drawing lists for sprites.
Sprite positioning, due to tight kernel timing constraints, are based upon every scanline whacks of HMOVE. That means the HMPx settings are limiting the difference of horizontal positioning between subsequent sprites in one player graphic.
Put another way, the number of lines without graphics for GRPx is equal to the difference in horizontal position between two sprites sharing that player graphic.
I'm usi
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
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
Annoying, but happening anyways.
Too frustrating to fix up the tile drawing so scratched around some support and infrastructure stuff. Have a really interesting idea for a playfield conversion program based mostly on SpiceWare's dragon converter. Might monkey with that tonight but I think I know someone who has other plans for my time.
Well, there's been a few things happening in the real world; among others, I've had my house burnt down by what appears to be arson, and my car stolen and totaled.
However, I'm recovering nicely and resuming work on the game engine. Honest.
My Atari 2600 survived :-) as did my EPROM burner. Ironically, my EPROM eraser didn't.
I don't think I lost any computer data. I'm searching through backup CD's trying to reassemble the project.
So, what you saw in August is about the state of
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
There are now sprites. kinda.
Except the drawing-list computations have obviously got a major error, because what should complete inside of 5 scanlines is taking more like 100 on (every other field?)
And I'm pretty sure the drawing is incorrect inside the kernel too, but the timing isn't tweaked yet so it looks all sketchy anyways.
Tonight I might get time to frell around with this properly.
(Looks like one of those bpl/bmi stupid things that mess with me. Screenshot didn't catch
I haven't really been checking in over here, lately, but if anyone noticed that the old Ursine Core / Skyline site went down ... I've moved the work-in-progress on Skyline 2600 over to SourceForge.
Sidereal.net's server is still (apparently?) in the server farm waiting to be extracted from the flaming ruins, but this seemed like as good a time as any to dust off my TODO file and rewrite the kernel ...
The project is at http://SourceForge.com/projects/ursinecore but I haven't created a re
Imaginary cartridge format with 2k + 2k banking:
Current memory footprint of map kernel, for each level/group of levels: 4k (code + data)
Splitting code+data into 2k+2k ...
Table: number of levels/groups, amount of ROM required:
1 4k 4k
2 8k 6k
et cetera.
Clearly a winner, even if part of the data area held duplicated code, or if part of the code area were wasted, making data have to be split across more banks.
This also would open up to having variations of
The last revisions to the map compiler before final release are in source control. I hope.
Untested, because it influences multiple levels per ROM bank and boss missile on map blips and that code isn't in the 6507 stuff yet.
Perl on a 64-bit CPU is so much easier to hack than 6507 assembler running through m4 and dasm.
That is, sadly, the first major component to have a 1.0 tacked on it.
Good night ...
Sprite handling judgement code is getting wacky. The judgement logic was sucking down too much RAM to compile ... so now I have an abbreviated version of the drawing list being used to set up sprites, which takes longer, and then expand it into the drawable version at the last moment, after doing judgements, and reusing the same RAM.
Need to hack on this a bit more for it to generate a valid drawing list, and then implement the RESPx stuff.
Just for fun, I frelled up something in the pla
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
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.
The sprite judgement simplifications triggered by (among other things) trying to get a 6507 to divide by 7 repeatedly in VBLANK have begun ...
The new judgement system is inspired by an "all or nothing" approach: either draw the full sprite, or don't try. I also got rid of the temporary drawing list expansion, and some more convoluted logic, by making the drawing-list into two byte-lists, one for a sprite index, one for a positioning code. During judgement, the positioning codes are Y values
Began a major rewrite of ursac -- the Ursa script compiler -- some time ago. It's a lot cleaner code than the first go. It's also more practical for the type of game Little Dipper has become. It'll need reworking for Big Dipper, if that project ever flies.
Among other things:
Global default includes file rather than hardcoded enumerations (res/global.ursa) -- mostly just needed for defining global flags set
File inclusion (include file. => res/file.ursa)
Special binary modules sup
got a note from a potential artist, confirming that he's available on this kind of schedule for this kind of brutal slave labour.
updated project status in margin here. basically chugging along despite setbacks. new binary hopefully in 2 weeks.
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
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
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
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
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
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord