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
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
Tracked down a bogus hit on BRK (executing a $00 data byte) as the last culprit ... but sprite drawing time is still abyssmally wrong somehow ... I'm also vaguely suspicious that setting breakpoints in stella's debugger doesn't work as I think that it should, as I'm sure I'm missing some hits . . .
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
Haven't had time to really fix this up. There's an infinite loop inside the sprite handler, apparently incurred as a side effect of moving that subroutine into its own memory bank.
The revised layout goes something like this: Banks 0 to 5 are map screens (game play screens); bank 6 contains sprite judgement/drawing-list creation, the interleaved (every third scanline) map venetian blinds code, and sprite graphics; bank 7 contains the Ursa interpreter, scripts, Ursa-injected bitmaps, text-dra
OK ... she fits. With no space to spare in the ROM, as it should be. Now, if she would also actually run after my latest hack-and-slash memory-bank re-org, I'd have something to show you, but I haven't :'( ... today (Thursday) I'll debug the bitch's sprite code Once And For All.
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
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
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
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
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.
End of map data
included endbank.s
Regular straight-ahead ROM ends at
$10138
Skipping ahead to bank switch code
segment: bankers fed0 eqm vs current org: 10138
endbank.s (17): error: Origin Reverse-indexed.
Aborting assembly
Yeah. That's right. It doesn't effing fit.
.
.
.
I'll make it fit, damn it.
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 ...
The "15..20 Sept" release should happen this week-end with a playable screen, God willing. Real life interfered, as it has a nasty habit of doing.
Ordered some blank carts though, for the debut party, so ... (knock on wood)
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
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
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
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.
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
Hm. I seem to have lost a previous blog entry.
Anyways, Skyline (Project Little Dipper) is moving along nicely. Niceish. It's not kicking me in the nuts as much as it had been.
Display is stabilised. Sprite drawing lists are a bitch. Display still has some weak and screwed up stuff happeneing but it'll be sorted.
Release Party is BOOKED for Sunday, 21 Octoer, 2007, in Jacksonville, FL. If you may be in the area, please join us! It's also a 30th anniversary Atari 2600 party (costume b
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
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.
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
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord