Adventure: Odyssey (New Adventure Hack)

[Nukey Shay]

BTW START should have read StartGame...sorry about that

[EarthQuake]

It's quite alright, I eventually figured it out anyways

One more room and everything will be exactly like the version of Odyssey I attached in my first (...erm, second) post.

The real test will come when I "unshare" the rooms, and create some more of my own. If everything works exactly the way I think it will, everything will be fine.

[EarthQuake]

I'm wondering, how the easter egg room works. If you take out the barriers in the corridor and travel over to the next screen, you'll find yourself on the opposite side of the corridor. I take it, that if you have the "dot", then it simply takes you to another screen instead of the one it links to.

What if I removed the easter egg room (to use for other rooms)? Where would I end up if I took the dot across the barrier?

[EarthQuake]

Nevermind, after exploring the source for a while, I found where it manually switches to the secret room. I can change it to whatever room I want now.

[EarthQuake]

I'm really not in favor of the editing feature disabled... I've never had a triple post, let alone four of them in consecutive order...

 

Anyways, I've fully tested this to make sure it wasn't something stupid on my part.

 

;Room differences for different levels (level 1,2,3)

RoomDiffs:

      .byte $10,$0F,$0F           ;Down from Room 01

      .byte $05,$11,$11           ;Down from Room 02

      .byte $1D,$0A,$0A           ;Down from Room 03

      .byte $1C,$16,$16           ;U/L/R/D from Room 1B (Black Castle Room)

      .byte $1B,$0C,$0C           ;Down from Room 1C

      .byte $03,$0C,$0C           ;Up from Room 1D (Top Entry Room)

 

Can you explain this to me? I would like to be able to change room $1F (that I added on) to room $21 (which I also added on) on game one. I've tried adding to the values above, which does nothing, and changing the values, which messes stuff up, but nothing seems to work. By the way, the room connected to $1F is $05.

 

Thanks.

[Nukey Shay]

Do you remember that I mentioned you can't have rooms be numbered $80 or higher? There's why. What happens is that a direction is read...and if it IS $80 or higher, it will read the room number from that table instead (it holds a room for game 1, 2, and 3).

 

Let's say that we are in the room that has the right barrier (directly above the red room in game 1 or above the catacombs in 2/3). The program will look at this line when we are in that room...

 

       .byte <BelowYellowCastle,>BelowYellowCastle,  $D8,$0A,$A1,$08,$02,$80,$03     ;01; (Top Acess) Reflected/8 Clock Ball

 

See that $80? It's right were thr direction for DOWN is. So if we moved down off this screen, the program sees that $80, SUBTRACTS $80 from it, and uses that an offset in RoomDiffs. A value of $80 would be an offset of zero, for example...and then the (game level -1) is added to that.

 

So the program will fetch the new room number from the RoomDiffs table instead. If we are playing game 1, it would read the very first byte...2 = 2nd, 3 = 3rd....

 

;Room differences for different levels (level 1,2,3)

RoomDiffs:

      .byte $10,$0F,$0F           ;Down from Room 01

 

See? In game 1, you end up in room $10...and the other 2 levels you are sent to $0F instead.

 

That's why the directions that are $80 or higher go up by 3 each time (there's 3 bytes in each of the rRoomDiffs table). First is $80, then $83, then $86, etc. You can add in more level differences if you want...UP TO 43 rooms can have differences ($80/3).

[EarthQuake]

Nice to see your face again Nukey, have a nice weekend?

 

Okay, so I got game differences straightened out, both for items and rooms (Thanks).

Now I'm just wondering about something I came across while in the source.

As you probably know there is a null object. Is this a remnant of something that was going to be? Or does it actually have connections with the bridge? If you'll notice, it shares the same low byte $B9 as the bridge does, and since the bridge is a pretty complex object, I figured it might have something to do with it. If it doesn't, I'd lke to make this into a pickupable (word?) object.

 

How could I go about getting a low byte for it to use? Without that number, it's useless

 

;Offset 0 : Low byte object information (moveable stuff)

...

      .byte $BC, $00, NullCurr,

[Nukey Shay]

You don't want to define anything for the null object. The reason it's in there is because the display kernal needs to display 2 objects on EVERY screen. So what happens in screens that have no objects or 1 object is that the unfilled slot is filled with the "null" object's vectors instead. This object will appear at the same X/Y that the bridge uses...and because there's no GFX info for it, it will be invisible and impossible to bump into (in fact, if you add GFX to make this object visible, if you bump into it the bridge's X/Y will be thrown off...even if it's on a differenct screen).

[Nukey Shay]

BTW there is already 19 free bytes of ram IIRC...so there's really no need to mess with the null object anyway. With 19 free bytes, you can add up to 6 additional objects (each one uses at least 3 bytes of ram...1 for the room it's in, and 2 bytes to hold the X/Y). Since castle gates are always in the same position, only 1 byte of ram is needed for those (to hold it's state of whether it's opened or closed) - but a corresponding key would use 3 bytes of ram. Dragons use 5 bytes (room, X, Y, direction, and state)...and the bat uses 7 (same as the dragon...plus 1 to hold the object it's carrying, and 1 to hold it's "fed-up" counter).

[EarthQuake]

I see now...

It would explain all the weird behaviors I discovered in my "tests".

So in order to add a new object, I need to define it's location here:

 

;Object locations (room and coordinate) for game 01.

Game1Objects:

      .byte $15,$51,$12           ;Black dot (Room, X, Y)

      .byte $0E,$50,$20,$00,$00   ;Red Dragon (Room, X, Y, Movement, State)

      .byte $01,$50,$20,$00,$00   ;Yellow Dragon (Room, X, Y, Movement, State)

      .byte $1D,$50,$20,$00,$00   ;Green Dragon (Room, X, Y, Movement, State)

      .byte $1B,$80,$20           ;Magnet (Room,X,Y)

      .byte $12,$20,$20           ;Sword (Room,X,Y)

      .byte $1C,$30,$20           ;Challise (Room,X,Y)

      .byte $04,$29,$37           ;Bridge (Room,X,Y)

      .byte $11,$20,$40           ;Yellow Key (Room,X,Y)

      .byte $0E,$20,$40           ;White Key (Room,X,Y)

      .byte $1D,$20,$40           ;Black Key (Room,X,Y)

      .byte $1C                   ;Portcullis State

      .byte $1C                   ;Portcullis State

      .byte $1C                   ;Portcullis State

      .byte $1A,$20,$20,$00,$00   ;Bat (Room, X, Y, Movement, State)

      .byte $78,$00               ;Bat (Carrying, Fed-Up)

 

How exactly does it know which line has which object? All those bytes just indicate room and coordinates...

 

...



      .byte $A1,$00,                  <KeyCurr,>KeyCurr,            <KeyStates,>KeyStates,            $CB,$00     ;#0F Secret Key         87  (78)

      .byte $B9,$00,                  <ChalliseCurr,>ChalliseCurr,  <ChalliseStates,>ChalliseStates,  $CB,$00     ;#10 Chalice            90  (80)

      .byte $B3,$00,                  <MagnetCurr,>MagnetCurr,      <MagnetStates,>MagnetStates,      $00,$00     ;#11 Magnet             99  (88)

      .byte $BC,$00,                  <NullCurr,>NullCurr,          <NullStates,>NullStates,          $00,$00     ;#12 Null               A2  (90)

      .byte $XX,$00,                  <NewObjectCurr,>NewObjectCurr,<NewObjectStates,>NewObjectStates,            $00,$00     ;#13 new object!

 

Of course I have to define the object above, but what is XX? Would it be $CE in this case?

 

If the item is only going to be in one place the entire game, then I don't need to add it here:

 

Loc_1:

      .byte $B9                   ;

Loc_2:

      .byte $13                   ;Chalise

Loc_3:

      .byte $1A                   ;

      .byte $A4,$01,$26           ;Red Dragon

      .byte $A9,$01,$26           ;Yellow Dragon

      .byte $AE,$01,$26           ;Green Dragon

      .byte $B6,$01,$26           ;Sword

      .byte $BC,$01,$26           ;Bridge

      .byte $BF,$01,$26           ;Yellow Key

      .byte $C2,$01,$26           ;White Key

      .byte $C5,$01,$26           ;Black Key

      .byte $CB,$01,$26           ;Bat

      .byte $B3,$01,$26           ;Magnet

 

Correct?

[Nukey Shay]

...And how much did you risk?  Awww...

 

 

All of the existing tables would need to be reorganized. In addition, there are a LOT of lines that need to be changed in the program itself (which is probably why nobody ever got around to updating the source code so that it is completely reverse-engineered).

 

In the middle table you mentioned, the first 2 bytes is the memory location that the program needs to index to get all of the object's information from the running game. Most objects, this is held in Ram (the Chalise, for example, is $00B9...that's why it's first 2 bytes are $B9 and $00). When an object is held by the player, the ram location that the object uses is not stored, but the OFFSET used in this table! The chalise's offset is $80...because it's data in this table begins at the 128th ($80) byte. And objects must be inserted into the game at specific points...all dragons, keys, and gates must be grouped together consecutively and the null object must appear on the list LAST (that way, if all previous compares "fall through", the null object will be chosen automatically). So if you add in a key, for example, all of those offsets that appear in the game "hard-coded" will have been shifted up. Since each object uses 8 bytes in this table, the index value goes up by 8 bytes on each row (in the original game, the invisible surround uses index $00, and the null object uses indes $90). So all of those lines will need to be changed if ram is reorganized to add in new objects. Take a look at this line, for example...

 

       LDA    $9D                ;Get the object being carried.                                            ;3

      CMP    #$50               ;Branch if it is the bridge.                                        ;2

 

The castle gates are listed before the bridge...so if you added a new castle gate...the bridge's offset would NO LONGER be $50...it would be $58. So the corrected line would read...

       LDA    $9D                ;Get the object being carried.                                            ;3

      CMP    #$58               ;Branch if it is the bridge.                                        ;2

 

And that is just 1 example. There are checks done to see if the player is carrying the sword, chalise, if a key hits a gate, etc.

 

 

The first table you mentioned is the initial values given to all of the objects in the game...and all of those 49 values are copied from that LOC table directly to memory exactly in the order shown...starting at memory address $A1. The routine that does this is here...

 

       LDY    $DD                ;Get the level number.                                                    ;3

      LDA    Loc_4,Y             ;Get the low pointer to object locations.                                 ;4

      STA    $93                                                                                           ;3

      LDA    Loc_5,Y            ;Get the high pointer to object locations.                                ;4

      STA    $94                                                                                           ;3

      LDY    #$30               ;Copy all the objects dynamic information.                                ;2

SetupRoomObjects_2:

      LDA    ($93),Y            ;(the rooms and positions) into                                           ;5

      STA.wy $00A1,Y            ;the working area.                                                        ;5

      DEY                                                                                                  ;2

      BPL    SetupRoomObjects_2                                                                                         ;2

So if more objects are added, it's no longer copying only 49 pointers (that LDY #$30 above). But however many bytes are there.

 

A lot of editing to do

[EarthQuake]

Perhaps I should finish what I have instead of creating more work for myself.

You know this game inside and out which kinda makes me glad I ran into you. Otherwise I'd probably be making a space invader hack.

[Nukey Shay]

Not really...there's quite a lot about it that I don't understand. Joel Park would probably know more about it...since he and Thomas were the ones that reverse-engineered it to this point. The bad thing is that there are still so many pointers that have not been labelled...so adding anything gets to be a real chore.

[EarthQuake]

This just keeps getting better and better.

First I run out of bytes to add in my last room (I checked over and over, btw, there is only 4 bytes or so left), so I decide to go with your 8K adventure source so I wouldn't have space constraints.

 

So after I get it all figured out how to compile, there is a syntax error in the code of the second assembly.

 

It says the error is here:

 

MoveObjectDelta_2:

      DEY                       ;Count down the delta.                        ;2



 IF ORIGINAL

      BMI    MoveObjectDelta_7                                                 ;2

 ELSE

      BMI    MovementReturn       INY                                          ;2

 ENDIF

 

Of couse you can see that the next to the last line has the error, but since I know next to nothing about assembly, I've been unabled to figure out what to do with the "INY".

I've tried moving it after and before the 'MovementReturn', and even deleting it altogether, but each time the ROM doesn't even play (although it compiles perfectly).

I tried looking in the old 4k source for a solution, but it seems you or someone else has changed it, so it' completely different:

 

MoveObjectDelta_2:

      DEY                       ;Count down the delta.                                                     

      BMI    MoveObjectDelta_7                                                                              



      LDA    $9B                ;Get direction wanted.                                                     

      AND    #$80               ;Check for right move.                                                     

      BNE    MoveObjectDelta_3  ;If no move right then branch.                                             

      INC    VBLANK,X           ;Increment the X coordinate.                                               

 

Any help would be greatly appreciated

[Nukey Shay]

There was one error in the optimized replacement code (besides the missing semicolon that you caught)...

 

BallMovement_3:
;using BIT to check the flags instead of AND (again)...

 IF ORIGINAL

      LDA    CXP1FB                                                            ;3

      AND    #$40               ;Get ball-player01 collision.                 ;2

      BEQ    NoCollision        ;If no collision then branch.                 ;2

 ELSE

      BIT    CXP1FB                                                            ;3

      BVC    BallMovement_3     ;If no collision then branch.                 ;2
;2 bytes saved

 ENDIF

The branches don't match. The original code branches to NoCollision...but the optimized replacement goes to BallMovement_3 (which is directly above the comparison...causing an endless loop).

 

Here's a replacement file that puts both assemblies into 1 (so you no longer need to compile them seperate and paste all of those equates). The way that this works is that ORG sets up the order of the memory pages, and RORG tells Dasm the -real- addresses to put the data into.

 

In addition, it fixes the outside chance that a real console might boot from bank 1.

 

I also trimmed out all of those IF/ENDIF lines...it was getting pretty messy anyway

adventure_8k.zip

[EarthQuake]

Bad news, everything I've worked on since monday is gone. I can't find my source files... Either I deleted them, moved them somewhere, didn't save my changes, or overwrote them. I just don't know.

 

Lesson learned: BACKUP, SAVE OFTEN, AND BACKUP SOME MORE.

Either way, the release of anything playable has been set back two more days. Sorry for that.

 

The good news is I can take advantage of Nukey's newest enhanced 8k source.

[Nukey Shay]

That reminds me...I'll post the newest one (a few more code optimizations done to it...and I edited those missing tags described in the other post)...