Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store

brpocock

Members
 View Profile  See their activity

  • Posts

    304

  • Joined

  • Last visited

 Content Type 

Blog Entries posted by brpocock

  1. brpocock
    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 real "web site" for it again, just yet.
     
    And, while I'm logged in here, "hello!" to everyone.
  2. brpocock

    sprites suck.

    By brpocock,

    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 the sprite field no matter how many times I tried :-( but there's a black rect flickering around looking like a trapezoidy thing in the midst of the crazy rolling.)
  3. brpocock
    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!)
  4. brpocock

    Not quite dead yet

    By brpocock,

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

    real work

    By brpocock,

    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.
  6. brpocock
    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, the main drawing loop for one row then just calls that macro 24 times:

    row_start: DRAW_LINE(0,0,0) ; Triplet 0, first line, this line is even DRAW_LINE(0,1,1) DRAW_LINE(0,2,0) ; Triplet 0, third line, this line is even DRAW_LINE(1,0,1) DRAW_LINE(1,1,0) ... DRAW_LINE(7,2,0)
    OK, so far so good, right? Line (7,2) -- which currently bears the lovely debugger breakpoint convenience label of "seven2" -- is a "no draw" line which prepares for the next row. So, really, I'm drawing 23 lines.
     
    Depending on which line I'm on, I precache various data like the tile pointers for the next row or the bitmaps for the next line triplet. Even and odd lines alternate updating decorative tiles (P1) or the player (P0) as appropriate. There are tile ID pointers in RAM for "this row" and "next row" (copied over in (7,2) after being decoded during the row), and the triplets precache bitmap data for the next triplet, and alternate between an "odd triplet#" and "even triplet#" bitmap buffer for drawing PF1/2 left/right. (e.g. during line triplet 1 I precache the bitmaps into the "even" buffer while drawing from the "odd," then in line 2, precache "odd" while drawing "even").
     
    During this maddening mass of multiply-indirect lookups, I have to hit PF2 exactly at the middle of every scanline and HMOVE exactly at the end. (I can't spare any screen lines to use RESP1 to position decorative tiles -- other than the top row -- so I have to use HMP1 to move the P1 position if there's a decorative tile on a lower line not in the same column.)
     
    The important thing I have working, now, is that the PF2 and HMOVE always hit at the right time. It's a tiny thing to have no HMOVE bars, and in fact, I'd probably be just as happy to have them all the way down, but once you're into that kind of cycle-exact timing mess to do reflected asymmetric playfield, you might as well go full monty.
     
    "seven2" however is not always exiting at precisely the right cycle. Also, I advance the pointer into the map at various times in the loop, basically every time I pull a tile ID out of the map I "inc" the map cursor, and at the end of a row I have to skip over some colour and decorative tile data to start the next row. Well, somehow in all that mess, I'm getting the map cursor off by one (and I haven't looked at it closely enough to figure out just how), so it'll start pulling colour data in as though it were tile ID's, thus looking up garbage data in ROM instead of valid bitmaps, and likewise getting decorative tile bitmap pointers instead of colours, and so on. Basically the whole "wild pointers are bad" "well, no shit" story.
     
    So, that's the last real hold-up on the tile-draw, although i've got an open "RFE" to try the cleaner (pixel-based rather than tile-plus-pixel-offset based) joystick code out and see if it's reliable. I expect it actually will be.
     
    Combat kernel is due for some pretty significant overhauls and then the connections between them all have to be stitched back in. The next time I test on the hardware I should be seeing the pieces working together. A public alpha test is not far in the future.
     
    Given the amount of time I'm actually hacking on this, though (a couple of hours a week... I spend more time in the forums here probably, at 10 minutes a spell) "not far in the future" probably means early August for a real playable demo with all the major pieces intact. Some of that depends on Mayday's equally mad schedule, though. It would help to have some map data or graphics or scripts to all this
     
    And, to that end, I need to write a new map coimpiler to handle the changes I made going to the "24lk" format.
     
    Kernel size has actually grown a bit from the timing fixups, but there are a lot of NOP's that I can probably compress some work from (7,2) into them now. If so, I may even be able to update some of the graphics during (7,2) as well. It does annoy me to have "dead lines" all over the screen, even if they should blend in with the background nicely in the real world, I guess.
  7. brpocock

    distractions

    By brpocock,

    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 self: buy another EPROM, I don't think that leg is going to grow back
     
    (It's been years since I pried one of these babies off, sorry baby... lucky I bought a spare before, but still sadness.)
  10. brpocock
    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 on the sprite overlays (not shown). Moving around a few details, that makes fora 24-scanline-tall row. I might be able to afford one extra branch-and-test after the 12th row to reduce the ROM footprint. I'm also contemplating the evil but fun option of splitting the kernel between ROM banks: i.e. having the ROM data for different parts of the map in different banks with a bank switch occuring within the kernel itself. It'd save a lot of ROM, and is just nutty enough that it might work.
     
    The ill-defined concept would go something like this: the tile maps (which tile art goes on which spaces on the display) and the tile bitmaps for the upper 12 scanlines (4 logical lines) are stored in bank (n), with the kernel code to draw the upper 12 scanlines. After the 12th scanline, though, the kernel does a bankswitch and continues the 13th line (line 12) in bank (n+1) where we have the bitmap data for the lower halves (4 logical lines) of each tile.
     
    The breakthrough that made this possible? Pre-OR'ing tiles. The compiler now handles arranging every used combination of tiles in advance. More work for the PC compiling the game... less work in realtime. And, not a bad overall impact on slated ROM sizes.
     
    Travel test kernels for your viewing pleasure coming shortly.
     
    PS: the screenshow appears below not above on this blog format. Or just click on Saturday's date on the calendar. It's totally unimpressive.
  11. brpocock
    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 through some different colours, that's actually because I'm incrementing his "defense" points and it's doing a colour lookup to determine what type of armour he's wearing.
     
    What you do not see in the still is that every (n) frames the screen seems to jump, I think the sound code is spiking it over a threshold during the game logic section, I'll have to scatter some WSYNC's around more liberally to get rid of that. I think it's every 16 frames or so... for reference, the walking action changes every 4 frames I think.
     
    There's no music in this demo but I think I left the music playback code in. The movement code is stubbed out mostly because I was rapidly changing the map formats to do this new 24-line-kernel version and I kept breaking the "am I walking into a wall or not" logic.
     
    The TO DO list is much shorter now. I want to try to do the dual-banked version of the kernel to see if I can work colour changes back in. Oh, and the size isn't terrible either. The whole unrolled kernel is "only" about 1k long, with a total code length of about 1.5k. That leaves a "lot" of room (for a VCS game) for data.
     
    Oh, the player's positioning logic is accurate to 2 vertical lines, so he can "slide" between tiles in a fairly natural way.
  13. brpocock

    drawing list!

    By brpocock,

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

    future idea

    By brpocock,

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

    mkmap

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

    sprite boogies

    By brpocock,

    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 playfield logic and introduced one of those off-by-one errors that take forever to trace down, which means each playfield tile is being drawn out of phase by one lineset ... a macro run wild probably.
     
     
    EDIT/PS:
     
    OK, it's 3:30 AM in Florida, and I hate maths.
     
    So.
     
    Sprites either do, or don't, draw. None of this partial drawing stuff. I think Thomas's suggestion feels right about constant flicker, and in this case, all or nothing drawing is probably psychologically better.
     
    The "score" is no longer a score, since we just claim the slot or don't -- so I'm (ab)using cur_score to mean post-drawing repositioning lines. Sorta.
     
    Much optimisation will likely happen here shortly, in the mean time, here's the pig sty:
     
    I'll have to rethink the judgement code further, I almost posted it before realizing that it totally disregards realigning the temporary drawing list workspace properly and basically clobbers itself as it runs :-(
     
    It will probably be rewritten tomorrow morning while Chris is in class. For now, bed time.
  17. brpocock

    judgement impaired

    By brpocock,

    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, afterwards, they're converted to X codes for RESPx/HMPx adjustments. The X values have to be recomputed as the list is being chained together, since they're all relative anyways.
     
    Here's the "first" draft of the new judgement code. $1 is 1 or 2 for each drawing list. (The subroutine/macro is expanded twice.) Note that a sprite could potentially be drawn on both lists, if it's very lucky, but that would mean there was nobody else who wanted that slot anyways. Also, there are any number of inefficiencies here, probably.
     
    Yeah, there are TODO's still -- I have to run in the middle of a rewrite :-( as usual. You (for certain values of "you") get the gist.
     

    sprite_judgement: ;; ;; Sprite handling: judgement code ;; ;; This is unrolled twice, with different postfixes to expand ;; it into drawlist1 and drawlist2. define({[MAKE_DRAWING_LIST]}, {[ subroutine ;; clear the drawing list ldy #DRAWING_LIST_LENGTH lda #$ff ldx #0 .clear_drawing_list: sta drawlist$1-1,y stx drawlist$1pos-1,y dey bne .clear_drawing_list if [ $1 == 1 ] ;; if this is an odd field, inject the player-character lda field_counter and #1 beq .skip_player lda #0 sta drawlist1 lda player_y sta drawlistpos1 ;; fall through and consider the first non-player sprite as usual .skip_player: endif ;; set the current search sprite to the next sprite in cycle, ;; and bump the start_sprite index. ldx start_sprite lda num_sprites inc start_sprite cmp start_sprite bne .start_ok lda #1 sta start_sprite .start_ok: ;; if slot 0 is open, claim it lda drawlist$1 cmp #$ff bne .consider_sprite stx drawlist$1 lda sprite_y,x sta drawlist$1pos jmp .consider_next_sprite .consider_sprite: lda sprite_y,x sta my_y ldy #DRAWING_LIST_LENGTH clc ;safety .walk_list: lda drawlist$1pos,y ;his position adc #8 ;his height in linesets cmp my_y ;; am I after him? then it's too late, since we're going ;; backwards, I don't get a slot here. bpl .consider_next_sprite ;; who's before him? cpy #0 ;anybody before? beq .try_to_claim dey ;; am I before the guy before? then I need to keep walking the list lda drawlist$1pos,y cmp my_y bmi .walk_list ;; I fall between the slots, that's good, let's try to claim it iny .try_to_claim: ;; We want this slot, but will we fit with horizontal repositioning? sty want_slot ;; Repositioning in scanlines -- 8px per HMPx or 48px per RESPx ;; Following sprite lda drawlist$1,y cmp #$ff beq .no_following tay lda sprite_x,y sbc sprite_x,x bpl .sign_ok eor #$ff ;invert to positive number bpl .sign_ok ;always taken .no_following: lda #0 .sign_ok: sta tmp0 ;the number of clocks by which to move, so far ;; TODO: make sure that this occurs before sprite starts ldy want_slot beq .no_prior dey lda drawlist$1,y cmp #$ff beq .no_prior tay lda sprite_x,y sbc sprite_x,x bpl .sign_ok_too eor #$ff bpl .sign_ok_too .no_prior: lda #0 .sign_ok_too: adc tmp0 ;total number of movement clocks ;; TODO: make sure this occurs before the following sprite starts .claim_it: ;; TODO: move up subsequent sprites in the list lda my_y ldy want_slot sta drawlist$1pos,y stx drawlist$1,y .consider_next_sprite: inx cpx num_sprites bne .consider_sprite .no_slots: ;; This drawing-list is full. Stop looking at it. ]})
     
    EDIT: lda #1 after bne .start_ok -- don't consider the player-character, it's special-cased on odd fields.
    EDIT2: correct slot 0 claiming for new RAM layout
  18. brpocock

    Ursa script interpreter

    By brpocock,

    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 supported: currently just for password-entry, everything else (so far) is stock for Skyline -- use module. do module. -- for example: use numeric_password_entry. do numeric_password_entry. -- The "use" declaration will be monitored by mkmk (Makefile generator), the "do" verb is an actual runtime command to call the exported method (ursa_do_$x)
    Syntax is more COBOLish than BCPLish now.
    Some example statements ...
     

    # these two are equivalent say: HELLO, WORLD. . # as: say "HELLO, WORLD.". # Menus... ask "WOULD YOU LIKE TO PLAY A GAME?"; for "YES", let_us_play; for "NO", you_are_boring. # Maths set my x to 8. set my reflection to true. set my x to player_x. set r0 to r0 + 4. # Assembly-type maths load r0. add 4. rotate left. rotate right. subtract 3. store r0. # Note that carry is cleared and ignored. # Flags. if my reflection is true, label_to_jump_to. if bit 3 of r0 is false, label_to_jump_to. set bit 2 of r0 to true. # Comparisons compare my x to player_x; when lesser, label_to_jump_to; when greater, some_other_label. compare r0 to 8; when equal, label_target. # bpl, bmi, bne, beq analogues. # zero test if r0 is zero, label_to_jump_to. # Object classes dispatch table class zombie: when hit, zombie_hit. when bump, zombie_bump. when lighted, zombie_lighted. when become, become_zombie. class done. # Invoking an object method zombie_hit: if friend is zero, zombie_hit_player. # ignore non-player sprite collisions done. zombie_hit_player: set player_hp to player_hp - 2. become zombie_attacking. done. class zombie_attacking: when become, become_zombie_attacking. when alarm, zombie_done_attacking. class done. become_zombie_attacking: set my reflection to false. set my graphic to zombie_attacking. set my timer to 1. done. zombie_done_attacking: become zombie. done. show picture skyline.png with caption: BY BRUCE-ROBERT POCOCK AND CHRISTOPHER BURLINGHAM .
     
    The ursac rewrite is back burner, but progressing, so hopefully some scripting capabilities of a minimal sort will make it into next week's "playable" pre-alpha.
  19. brpocock

    bumping demo release

    By brpocock,

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

    Bigger isn't always better

    By brpocock,

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

    closer

    By brpocock,

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

    Dissatisfaction Report

    By brpocock,

    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-drawing, and the status screen. I fully expect to shift that around a bit, such that bank 6 ends up being bank 7 most likely, and banks 0 .. n are map screens while n+1 .. 6 are Ursa banks.
     
    The Ursa interpreter, thank God, is flawless, but it's only running with the barest essential functionality, which (as it turns out) is sufficient for theoretically doing the main menu, simple NPC interactions, and NPC (monster) control sequences of the usual sorts, e.g. "walk toward the player without walking through walls." I'm working on a slightly more intelligent NPC script to implement a "right-hand rule" but really want to see the sprites actually functioning before messing with that any further.
     
    Besides which, the ursac rewrite was put on hold to get sprites done. The new parser is a bit more LALR and a bit more flexible in its string injestion, which is the more important part.
     
    String display is still basic 48px 12-column display; I toyed with 24-column and such and decided to KISS; there wasn't any real need for any of the game displays. Note that letters M, N, Q, and some punctuation are still double-column-width characters because I wanted legibility ...
     
    On the personal side, while I'm still ardently hoping to get this project released in a fully playable form in less than a month, the toll of having been beat up pretty good while breaking up an attempted murder two weeks ago, and the discovery yesterday that a friend of mine is on hospice care and not expected to be around many days more, along with all the usual madness of trying to juggle 3 jobs and an hobby like this, are making it sadly likely that a playable demo level might be all that's ready in time for the 30th anniversary :-( Nonetheless, I'm still rather proud of the architecture of the engine and hope that by year's end the Skyline game, at least, will be fully finished and polished. Regardless, I'm aiming to have "as much as possible" working perfectly in time for the 21st, and the release party will go on in whatever form the game ends up.
  24. brpocock

    Hate It.

    By brpocock,

    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 . . .
  25. brpocock
    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 away with "missile stuck" / "missile loss" problems when using items (item-in-use sprites getting stuck or disappearing)
    Do away with "picture roll" due to Ursa script execution times -- I'm changing the script interpreter to have a timeout and interrupt scripts when it falls behind, rather than letting the picture roll. If the script interpreter falls too far behind, it'll even interrupt drawing of frames until it recovers ...
    Additional Ursa commands
    Additional compression of data sets (less spacing data) -- might also do a more highly compressed form for storybook graphics to save ROM
    Code improvements ... ? general performance
    Some administrative-type changes:

    New developers' web site with development Subversion and Wiki system (Trac) --- this will allow Skyline (and any offshoot projects that might crop up ... I have some awkward ideas in that regards ...) to share a public Subversion repository and bug tracker, general wiki.
    New authoring toolkit (web-based) --- allow game designers (not programmers) to enter data using web-based forms and get back a binary cartridge image --- this would involve a text editor and a simple pair of sprite/tile editors --- and be a massive improvement over the current ASCII forms. This is my #2 priority behind actualy bug fixes/performance issues in the code, as it will make it possible for me to do the additional design work. Stuff like picking NTSC, PAL, and SECAM colors for every tile are exceptionally awkward using text editors and look-up tables, and a nice EcmaScript application to do that stuff for me would be fantastic.
    Specific apps: tile editor, sprite editor, and map editor, and a general text editor for editing Ursa scripts.



    Thanks again for everyone's support, and hope 1.1 will be less of a disappointment to you all.
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...