brpocock

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 current format for Little Dipper project, title "Skyline," is much closer to The Legend of Zelda (original TLoZ for NES, and the SNES and Game Boy/GBC/GBA variations) than to Ultima or Final Fantasy; i.e. action RPG rather than menu-driven. No specific combat mode, just walk around and use items in the game world in real time. FWIW. If Big Dipper/CiE gets back into gear, the menu-based combat stuff -- some of which I think could be pretty cool -- will come back into play.

P.S. to my just-prior notes. Hitting a RESPx line as I've just declared would require it to be on a venetian blinds line (skipped line), since timing is too tight when drawing the playfield to wedge them in at specific clock-points. That means potentially costing two additional sleep lines after the prior sprite. Also, hitting RESPx for both player graphics at once would be impossible (at the same 1/3 marker). That just means that I'll need to detect this (relatively unlikely) circumstance and introduce one extra sleep line for one of the player-graphics, costing an extra couple of lines. Oh -- and, of course, the first sprite in each player graphic is positioned using RESPx precisely, since I have a few lines before I start drawing the playfield to "waste."

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 kernel in different 2k banks. Specially, I'd love to split out the venetian blinds lines so that they occur on odd frames in the first line of a triplet and in even frames on the last line, giving a banding effect that would be less noticeable I think. More like the "bad video-radio link" effect from Star Wars, with 50% effective reduction in intensity on two out of every 3 lines, the centre line being more firm.

OK ... I did some math and I'm leaning towards your interpretation on RESPx hits. Each HMPx hit could potentially yield effectively +/- 7 clocks movement. (Yes, 8 one way, 7 the other, the math is easier pretending orthogonality.) The effective sprite positioning range is based upon 9 columns into which the first pixel of a sprite might go ... a sprite could be left of the playfield proper, or hanging off the right edge, as long as one pixel is within the playfield boundaries, and I'm being cheap on the logic and not trying to mask the part falling into the blank PF0 areas, although the omnipresent HMOVE bars do that very thing on the left ... So 9 columns times 4 playfield pixels of 4 clocks each ... minus one playfield pixel at the far left, since the 8 pixels double clocked sprite would be completely outside of the playfield at that point ... so that's (8 * 4 * 4 + 3 * 4 ) = 140 clocks potential display range. Worst-case scenario is moving from a sprite at position 0 to a sprite at position 139, giving a requirement to whack HMOVE 20 times. That's 20 scanlines wasted, or about one row (6 rows of 24 scanlines each in the "24-line kernel." Yes, it's insane.) Giving the option to whack RESPx at the 1/3 marks -- i.e. at positions 46 or 93 -- makes the maximum possible distance required about 46 clocks, which could be done in 7 lines, plus the one line for the RESPx. This would alter the drawing list to resemble the C code: struct drawing_list_entry { bits verb : 2; /* enum 0, 1, 2, 3 */ union direct_object { struct resp_hit { bits position : 1; bits unused : 5; }; struct hmp_hit { bits hmp_value : 4; bits repeat_count : 2; }; struct draw { bits start_line : 3; bits num_lines : 3; }; struct sleep { bits sleep_lines : 6; }; }; bits sprite_index : 3; bits wasted : 5; } In a perfect world I could only include the sprite_index value after drawing starts, only wasting 5 bits when in a draw phase. In my world, I probably can't afford that logic. This upsets the tea table in a beneficial way. Thanks for the brainstorming assistance. With any luck, I'll have a stable sprite drawing kernel later this week, as time permits. (80 h/w at first job and about 20h/w at second job get first priority.) Incidentally, I have on paper (!!) the status screen display code rewritten to use missiles to show boss locations on the level map ... I have to key it all in to get the damned centre-of-screen timings worked out, since the "keys you are holding" and "map of the level" displays are in a split screen, but I think it will work. I think I'll have a "you are here" dot as well. I'm cheating and just setting COLUPF to blank out the map if you don't have the map item for the current level. Incidentally, all level-specific variables are wiped out by leaving the level (dungeon), so you will have to more or less play through the levels in order, making the overworld map not entirely useful, but . . . there's 128 bytes of RAM, damn it.

This puzzled me until re-reading. You're refering to the non-player sprites, i.e. that they will have more visible flickering due to the fact that they may enter/leave "bad areas" vertically causing such flicker? I see the point, there. I think I'm taking that to heart, in a way: I'll try to work in that the player-character only gets preferential treatment on odd frames, or something to that effect, giving it a guaranteed 50% display time with fair competition for the other 50%.

I've played around with something like this, but it's been inefficient on the overall. It may work its way back in, but I don't have much time in kernel for branching and such, and the kernel is unrolled, so any variation would have to be replicated 8 or 24 times. Not to say something with RESPx won't make it in -- just that it seems unlikely. That would be nice, but there are 48 effective lines per screen, so that would be 96 bytes of RAM right there... of course, that's impossible.

still getting my ass kicked by kernel timings, but who isn't? One way or the other this will be released 21 October. Playable alpha release due later this month -- beta around first of October -- not guaranteeing bug free by the anniversary but close. Club Sappho's at Metro nightclub -- where The Loft used to be -- 8pm to closing (2am) -- I'll have it on the 2600 (four switch model) hardware. I got a tweak from general manager that we might get moved to Club Shadows, but that would mean getting a 30' movie projector to play on, so yay. Depends on some stuff happening to Sunday nights' schedules. Hope to see you there. p.s. development crap in my blog incl. August pre-alpha test kernel demonstrating tile draw functionality p.p.s. Real Artists Ship. (-Steve Jobs)

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 using a judgement code to evaluate each sprite for potential inclusion in the two lists for GRP0 and GRP1 each frame. In order to present the minimum flicker, each sprite in turn is given first chance to draw, more or less guaranteeing that for n sprites over n frames, each sprite will be fully drawn at least once within those n frames. There's one exception: the user-player-sprite, i.e. the player-character, is always given first priority on the GRP0 player. Thus, the player-character will not flicker, ever. The judgement process first walks the drawing lists looking for an open slot. An open slot is decided by having no current sprite drawing lines mapped to it. (Repositioning lines and sleep lines are the other two possibilities.) When an open slot is not found, we consider the lists to be solved and continue to drawing the frame. When an open slot is identified, each sprite is judged by looking at its horizontal and vertical positioning. If its vertical positioning is within the opening, then a computation is made to determine the number of lines needed to reposition GRPx from the prior sprite, to the sprite under consideration, and then to the subsequent sprite. If too much horizontal repositioning is required, no sprite lines could be drawn, so its value is zero. If the sprite would have visible lines, then the number of visible lines is recorded as well as the sprite number, unless a previously considered sprite would have had more lines drawn. (i.e. the first sprite found with the most lines possible visible.) Logically, that push breaks down to pseudocode like if (best_lines_seen < this_lines_seen) { best_lines_seen = this_lines_seen; best_sprite = this_sprite; } The lists could potentially display as many as five sprites for each player graphic, if they are aligned vertically, but that situation is very unlikely. The static-length sprite and drawing-list arrays are undecided slightly as I'm tweaking the RAM usage heavily, but I hope to handle eight on-screen sprites and therefore eight drawing-list entries gracefully. That's the number of hardware sprites on my alma mater Commodore VIC-II chip, and seems to be a comfortable number of moving objects at the very large scale of the 8x6 display grid. Again, sprites are guaranteed first shot once for number_of_sprites frames, so with eight sprites including the player-character, each sprite would be guaranteed a full draw at least once per 7 frames, or (worst-case) appearing about 1/7th to 1/8th of every second (PAL, NTSC). Not great, but that's a worst-case scenario of all seven non-player-character sprites occupying the same vertical area as the player-character, which is thankfully unlikely. All this drawing-list processing makes use of INTIM for vertical retrace handling and if I find it running away may get capped off periodically (every n frames use a simpler but less fair mechanism) if the script handler starts to suffer on CPU cycles. (Remembering that Ursa scripts are running under the vertical retrace as well to control these NPC sprites!)

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 Ursa. The Ursa script interface to sprites for their controller scripts got a Hell of a lot simpler once I started thinking modally. Thus, instead of putting mad logic into something like zombie_controller I instead have zombie_wander, zombie_attack, zombie_hurt, zombie_die, i.e. I'm using the controller script index pointer to also "remember" the controller script's mode. This saves a lot of RAM -- at least one and possibly three bytes per sprite -- and reduces wastage for sprites like doors and particle effects (projectiles, only, at the moment, but I'd like to have time/space to do things like monster_dies_goes_poof). Ironically, the game boards themselves are problematic -- I'm almost starting to fear having the core code all working but the game boards in need of work! Text drawing was removed a while back in a refactoring and I really, really, really need to replace it. There's no rocket science involved but it's important to the whole RPG theme! Player inventory and costume handling are absent. In the vein of TLoZ, I'm considering adding a "compass" type item alongside the "map" item for each level. The code to use missiles to do so is trivial but to colour coordinate it would be rough since the keys on the left of the map are drawn as P0/P1. The password-continue stuff has been drastically simplified by just using prefab passwords. A look-up table of valid passwords has a block of variable values associated with it which can be blt into RAM. The downside, of course, is that one can't just 'save progress anywhere.' Instead, you get a continuation password upon completion of each level. The levels have design elements guaranteeing that they can't be completed out of order, but it is a limitation that I'd rather not have had to use. What else? . . . There's still no attract nor win animation, but the plans for those make use of the text drawing routines and some simple bitmap display logic, and I haven't written that yet, so I've just been ignoring it. The kernel timings are, as they have since day one, driving me slightly more insane, but I think that's the price of any complex 2600 game. If not for TIA timings, where would the challenge be? Oh -- there's still no sound. Some sound or other will make it in, but it will be uninspirational. :-( Also, joystick movement is too quick, I need a debounce counter. It's OK for debugging but almost useless for game play to move so fast. And so it continues ... the time growing short.

Blogged some stuff. Release on track -- give or take.

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 scaline height pixels. One playfield colour per row :-( Might get it up to 2 but nowhere close to the 6 I'd once thought possible (but never thought likely) One background colour per screen. Stats area always has black background. Border around map area. PF0 always zeroed. Sprites have HMOVE bars and there are HMOVE bars on rows without sprites in some of the drawing list attempts. Sometimes I just go nuts and have nothing BUT HMOVE bars during the map drawing. Stats screen has an overview map generated automatically. If the map item is found for a level, it displays. To fix: one level per memory bank. Should support multiples but aforementioned overview maps broke that functionality until I fix it. That's a Perl problem really, but also will need some logic in the stats/inventory subscreen. 8 keys per level. Various items, some with "ammo." No magic system, but there is a fashion system. (Yes, really.) For now, hardcoded background tile images into mkmap compiler. Future direction, split them out and allow more flexibilitiy. Missiles and ball totally unused. Thoughts about using ball for doors but never tried implementing yet due to madness of cycle counts. Using sta WSYNC still but believe it unecessary once sprite code stabilises. Math is not my friend. Data structures for artwork are interleaved and inverted, e.g. align 256,0 tile_bitmaps: tile_bitmaps_odd: ;;; line 7 o7_box_left___blank: dc.b 128 o7_box_left___box_u_left: dc.b 143 o7_solid___solid: dc.b 255 o7_solid___half_round_left: dc.b 243 o7_solid___blank: dc.b 240 o7_brick_wall___brick_wall_right: dc.b 255 o7_half_round_left___half_round_right: dc.b 60 o7_blank___blank: dc.b 0 o7_box_bottom_left___box_bottom: dc.b 255 o7_box_top___box_top: dc.b 0 o7_box_bottom___box_bottom: dc.b 255 o7_box_top_left___box_top: dc.b 128 o7_brick_wall_left___brick_wall: dc.b 255 o7_brick_wall_right___blank: dc.b 240 ;;; line 6 o6_box_left___blank: dc.b 128 o6_box_left___box_u_left: dc.b 136 o6_solid___solid: dc.b 255 o6_solid___half_round_left: dc.b 247 That's from the test kernel whose screenshot I posted earlier tonight. Headaches: Doing what I'd like to for (mostly) flicker-free sprites costs too many kernel cycles or sucks down more RAM than available. Absent: MemCard support (lost my demo unit in the fire, sadly) or any other continue mechanism. That's a pain in the ass given the scale of the game. Ursa script interpreter still has braindead errors that I keep finding that cause it to do things like wild jumps sometimes. Working on that. None of current stuff tested on real hardware. Stella only stuff right now. That will probably introduce new problems with numbers of lines but I think that's the worst to worry about.

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 ball, theme: videogame characters) and happens to be my birthday. The Skyline binary will be released to AtariAge on or before that date. A stupid kernel test binary is attached to scare people.

ps -- aim BruceRobertP usually half-available on mobile during days if anyone having trouble reaching me -- my web colo is down since 3 July and don't yet know why, so eMail is out right now -- also, my handle here at GMail.

updated blog -- progressing -- release party 8pm on 21 October at Metro, Jacksonville, FL. New title is Skyline, and Real Artists Ship. 6 undefined symbols from machine-generated code going through ... today's bottom line sad statistic.

Long time since I've updated here, but sincce my web colo is down, it's a good time for a status report. Little Dipper -- now officially titled SKYLINE -- is on track. Major infos: Skyline is an Action RPG, meaning real time, along the lines of classic/Game Boy Zelda titles. I've sacrificed some colour and background detail operations to permit more insane sprite-handling -- nothing too special, but a different format for the VCS. "Real Artists Ship" (Steve Jobs) The release party for Skyline will be held at the Metro Entertainment Complex on 21 October, 2007, to co-incide with my 30th birthday, and the month of the 30th anniversary of the VCS. The party was booked in The Loft, one of our bars, bt The Loft will be clsibg this month in preparation for the 1 August opening of Club Sappho, a new lesbian bar, so the precise location within the complex is TBA for now. Party runs from 8p to 2a. Anyone near Jacksonville, FL is of course welcome to attend. RSVP:s encouraged but not required. The new Skyline designs and such are beig done by myself and Ricky "Black Cat" Harnden. The Ursa and map compilers are pretty fantastic -- it even does tile usage determination -- and the new kernel mods are about 6 critical bugs and 5 or 10 FIXME's from running. MemCard support is dropped for now (the fire ate mine :-( ) along with a few other things, due to time onstraintts also. Looks like 32kiB. Alpha will, of course, be posted ASAP -- since a lot of code is Perl-generated and m4-compiled, just building is rough, but progress seems fast -- if sporadic. The rest is history I suppose ... we'll see if it's anything worth playing. Oh, as for plt, there isn't much of one -- but it does involve Nazis and vicious dogs and drag queens. Before tryingbto make that make sense, ask why a plumber is chasing a bunch of mushrooms and turtles. Besides, I'm writing what I know -- I'm the barback manager for a queer bar now, may as well embrace it in the game. btw, personal note to all expressinng concerns, thanks, alive and well and recuperated more or less from job layoff/landlady arson/car theft bull$#!^ of the past year. Apologies if I missed typos -- posting from my NDS. Inventory/stats and text/menu code are major hurdles once the core game kernel rewrite is done. Build utilities are almost worth being proud of now. Sound is for $#!^. I'll be doing something like raffling off a few copies of Skyline and t-shirts or sommat at the release/birthday party. Yay Café Press. If Albert is still interested, the game should make its way into the AtariAge store. Thanks all -- more to come -- I'l try to start updating here more often, too.

If you have copy of the code, posting it wouldn't hurt -- or just let me know what the date stamp on it was -- I'm still "sorting through the ashes" finding backup files to see how much was lost.

Not quite dead yet. Sorry, winter sucked for me. Recovery in progress.

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 art still.

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.

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.

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 margin. Real life happens. A second game, as-yet untitled, is being developed to use Ursine Core. There's no working title so for the Hell of it I'm calling it the Little Dipper. I've tentatively contacted some folks about taking over the design and scripting for Little Dipper. Assuming that I get a confirmation shortly, I'll attempt to "re-rail" Little Dipper development to something approximating the original schedule. My hope is that a new designer and/or design team will be in place by 20 July. In the 10 days remaining in July, then, we should have some loose outline stuff for a few test levels and that should enable testing the compiler code and getting a visual test demo cartridge up. With some slippage time for padding let's call that mid-August. Working rapido, then, we should have an alpha test tape ready in mid-September and go to beta in mid-October :-/ missing the original deadlines rather severely. I'm forking all the project-planning materials right now so the web site and Bugzilla are offline. Bringing them back online prolly this weekend with the project more cleanly divided out.

To echo my blog... CiE, as such, is delayed; but the RPG engine is being used for an alternative game with the same mechanics, and CiE is still in production, just not on original schedule. Details and discussion in my blog. Thanks all.

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 design from my personal library, and is unrelated to CiE... I may be bringing on an assistant designer to flesh out scripts and conversations in time. Thanks to all who've been emotionally(?) supporting this project; an updated schedule should be forthcoming soon.

Short version? 128 mode, if you're targeting the 128, since all of the hardware is available: virtual memory mapping for multiple zero pages and stacks, dual monitors, dual CPU's, and the rest. I'm kinda amazed that more people don't use the Z80A CPU to boost the speed of some types of operations on the 128.