Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store
  • entries
    40
  • comments
    39
  • views
    28,346

About this blog

RPGs for the VCS (CiE, Skyline) and other timewasters

Entries in this blog

Ursine Core 2.0 project on SourceForge

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
brpocock

brpocock

1

Skyline 1.1 work in progress

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
brpocock

brpocock

0

Hate It.

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 . . .
brpocock

brpocock

0

Dissatisfaction Report

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
brpocock

brpocock

0

closer

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.
brpocock

brpocock

0

Bigger isn't always better

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.
brpocock

brpocock

0

bumping demo release

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)
brpocock

brpocock

0

sprites suck.

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
brpocock

brpocock

2

Ursa script interpreter

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
brpocock

brpocock

0

judgement impaired

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
brpocock

brpocock

0

sprite boogies

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
brpocock

brpocock

0

mkmap

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 ...
brpocock

brpocock

0

future idea

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
brpocock

brpocock

0

Drawing List brainstorming

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
brpocock

brpocock

8

drawing list!

Sprite drawing list code is just about working -- some kernel timing problems were introduced with regards to background tiles not updating PF1/2 in time, but it looks like some quality time with the debugger is reducing those.   Sprites now are 8px x 8px using the same size pixels and venetian blinds as the background, mostly because the two different resolutions looked dumb, and made sprites like doors a little painful looking.   The sprite object model stuff is ironing out with regards to
brpocock

brpocock

0

tech details; reduced expectations

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
brpocock

brpocock

0

chugging along

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
brpocock

brpocock

0

Not quite dead yet

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
brpocock

brpocock

4

updated status, artist possible

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.
brpocock

brpocock

0

Little Dipper project a go

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.
brpocock

brpocock

0

Ursine things and more

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
brpocock

brpocock

0

RPG continuing on schedule; but not CiE

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
brpocock

brpocock

0

Minor Update

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.
brpocock

brpocock

0

real work

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.
brpocock

brpocock

4
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...