Updated schedule information:
OK, here it goes.
We're calling the new RPG core "the Ursine Core," since the URSA scripting language is really the heart and soul of it (even if the tile-based board-drawing stuff is the meat of it).
The Ursine Core needs some game data to get a playable demo together, so we're forking the data projects.
The CiE game design and development is proceeding with Mayday; that schedule is unknown but will definitely miss the October deadline by a good mar
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
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.
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.
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
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
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
For what it's worth, some tech notes as it stands today:
Tiles don't flicker. Sprites do -- horribly, right now -- I hope to reduce it with a sort of drawing list system if I can optimize it into the kernel.
To free up cycles, there are venetian blinds :-(
Background tile maps are 8×6 tiles, each of which is 4×8 background pixels, each of which is 2|3 scanlines tall. Two scanlines draw, the third doesn't.
Sprites are the same size as background tiles but are 8×12 px using 2 scali
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
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
I know that practically nobody downloaded Skyline 1.0, perhaps because of the utter lack of interesting storyline, so while I have planned some code improvements for Skyline 1.1, the biggest improvements --- more game. More maps, more dialog, more character interactions.
Total game-data redesign
Throwing away the 1.0 game world and starting over
Some characters/puzzle elements may be re-used, but totally revamped
More text, less wasteful graphics
The hoped-for changes:
Do aw
Due to scheduling difficulties, the CiE game is being indefinitely delayed.
However, a RPG will be produced, and I'm taking efforts to prevent it from slipping too far from the original CiE release schedule. The code will be mostly the same, but the game data itself will be different.
CiE is still planned for a later release, using the same game engine, possibly with some incremental improvements.
The new game data is being rushed into production but is based on an existing RPG game
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.
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
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
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
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
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 ...
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
Haven't had much time to post -- nor to make huge strides in coding -- but game progressing approximately on cue. More significant announcements should follow this one shortly, hopefully by the end of the week.
Just in case anyone's reading this, the Little Dipper project (still untitled) is definitely a go, in parallel with CiE and the Ursine Core.
A bit more complex than I'd hoped but better than derailed.
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
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.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord