Jump to content
Sign in to follow this  
Atarius Maximus

Optimized Adventure Code

Recommended Posts

I spoke to Joel Park earlier this week, and he emailed me a copy of his optimized adventure code. This code frees up 313 bytes of space by removing the code for B&W, according to the old thread where Joel first mentions it (thanks for pointing it out, Nukey):

 

http://www.atariage.com/forums/viewtopic.php?t=10401

 

Joel gave me permission to post it, so I'm attaching it to this post for everyone to enjoy. Given the time, I should be able to use this to add a few new things to Adventure Plus! I'm excited about the possibilities. Any suggestions as to what to use the extra space for? :)

 

AM

adventureoptimized.zip

Share this post


Link to post
Share on other sites

Well, I'm not sure how that freed up space can be spent. I mean, can you throw in another castle? Some new items? A new type of monster? Or something completely new like a new type of building/room, or giving the Hero Hit points instead of one hit and your dead?

 

Advetnure is such a wonderful game to play with because its based on a very simple concept with SO MUCH room for expansion on the theme.

 

I love Adventure Plus! Can't wait to see what you do with this free space!

Share this post


Link to post
Share on other sites

Additional screens would definately be possible...since you would only need to add them in to the assembly and update the room index tables. New objects would be a bit more difficult...you would also need to create routines for them that did not confict with anything else (Ram would be the hardest part, since the existing code has that tapped out). Additional creatures would be the most difficult, since you would have the above problems PLUS additional timing issues to deal with. But if you were to remove the code for say, the magnet...I think you might be able to squeeze one in.

 

Rooms in the original Adventure code used 30 bytes (21 for the pattern and 9 for the index). Removing B/W support shaved 1 byte off from the index...so 313/29 = 10 additional rooms could be added to the existing 31. A new castle would be difficult to add, since the added portcullis is an object...requiring its own set of indexes.

Share this post


Link to post
Share on other sites
How about removing the skill levels and just have it one game?

 

Now there's an idea. How about having just one long and hard level (hehe... long and hard...). That would be neat.

 

Tempest

Share this post


Link to post
Share on other sites

Based on what Nukey Shay pointed out, my only changes would probably be adding rooms, although the suggestion of making only one game instead of three is a very good one.

 

I just took a few minutes to browse the code, and I noticed this at the bottom:

 

; here we count the unused bytes:

 IF ORIGINAL

   .ds 171, 0

 ELSE

   .ds 271, 0  ; I stopped at 100 extra bytes, you will find a lot more :-)

 ENDIF

 

Hmm...I wonder if the code he sent me actually only has 100 bytes freed up, or if he just never updated that line? :ponder:

 

Edit: Ok, Blonde moment. Maybe the "you will find alot more" refers to the extra 213? :dunce: I need more sleep.

 

 

AM

Share this post


Link to post
Share on other sites

I all the ideas are awesome! Like to see an update or two. I like the addition of new items and another dragon or two as well as a castle or secret room. :)

Share this post


Link to post
Share on other sites

Note about adding rooms:

10 additional rooms can be added if they are to be unique. You could reuse patterns of rooms by simply adding them into the room index and altering the linked room data...the upshot would be that you would save the 21 bytes each time you do this. Try this hack (I know it jumps a bit when you load it...is this due to the optimizations being utilized via ORIGINAL=0?). Anyway, in this example...moving south from the black castle or moving into the catacombs from the sides puts you in an "alternate" maze. These look identical to the originals, but are different rooms. An object dropped after moving south from the black castle would not be in the same room as when you reach that part of the maze after moving north from the lower-left screen from the yellow castle :) I added 8 rooms to the game, but only 72 bytes to the code.

So you could create a version that contains a "alternate universe" that is accessed by leaving the portal in the EE screen...for example. Or a lot of extra identical rooms like Indenture did.

 

What's up with the red dragon?? I dunno.

adhack2.zip

Share this post


Link to post
Share on other sites

Re: optimizations...

Yep...seems when I make ORIGINAL=1 (use the existing routines instead of optimized ones), no screen jitter occurs and the red dragon is OK. Is something amiss there? Or did I mess things up by allowing the screen index data to cross a page? The pixels are still a little off in the blue maze in either case (?). But it works.

 

Also, I changed the "bounds" data for random objects in both...but it still won't allow values above 1D. Is the random value already trimmed to 5 bits somewhere?

^Edit: found it...AND #$1F in the original code during the randomization routine

adhack3.zip

Share this post


Link to post
Share on other sites

Damn...I still can't get the randomize routine to place objects in the new rooms. I added an additional LSR below the seed, and updated AND to include the next bit...but still no go. What is wrong with this?

RandomizeLevel3:

      LDY    #$1E               ;For each of the eleven objects..

RandomizeLevel3_2:

      LDA    $E5                ;Get the low input counter as seed.

      LSR

      LSR

      LSR                       ;Generate a psudo-random

      LSR                       ;room number.

      LSR

      LSR

      SEC

      ADC    $E5                ;Store the low input counter.

      STA    $E5

      AND    #$3F               ;Trim so represents a room value

      CMP    Loc_2,Y            ;If it is less than the

      BCC    RandomizeLevel3_2  ;lower bound for object then get another

      CMP    Loc_3,Y            ;If it equals or is

      BEQ    RandomizeLevel3_3  ;Less than the higher bound for object

      BCS    RandomizeLevel3_2  ;Then continue (branch if higher)

But adding the additional bit also gives a lot of "invalid" possibilities, so maybe it does work...but the odds are too far against it to actually get one (?)

 

Anyway...copied rooms work great otherwise. Check out this example...it uses 4 blue mazes end-to-end (that's 15 added rooms). I call it "Marathon Adventure" :lol: The new maze groups are invisible, red, and black. Since it would give the bat and dragons a LOT of exit paths from the new screens, I changed the links for the new maze sections so that the screen with the north wall is linked to the screen with the south wall in the next group. If you wanted to use this method to increase the amount of rooms, you can also set the upper bits of the playfield control to add the barriers as needed (so that the screens aren't totally identical). In that sense, you could greatly increase the number of rooms by removing all the existing ones except the castle and ones with combinations of north/south exits...reuse all of them...and have a game where you would be "inside" the maze of screens (I dunno what that works out to be, but it would be a pretty big number of rooms since each one would only require 9** bytes...less the overhead of the few screens mapped).

 

**I thought that B/W info was removed? The bytes are still there (though the program doesn't use them) :?

adhack6.zip

Share this post


Link to post
Share on other sites

Found the buggy routine that moves the red dragon in the optimized version...but I haven't a clue what is wrong with it :P

Remove the IF ORIGINAL line next to MoveRedDragon: and all the code ELSE (next to MoveDragon:) to the ENDIF (below the ;count yourself :-) remark). Or instead, you can simply change the IF ORIGINAL line to read IF ORIGINAL = 0

 

For some reason, this section of optimized code keeps the red dragon from moving :?

 

Still dunno why the game is occasionally jittery after compiling, but it seems to help some by removing the IF ORIGINAL line right near the top (at the START: tag).

 

And the pixel problem still remains (where some are a bit "off" on some screens...like the blue maze entry)...but that's not such a big deal.

adv_opfix.zip

Share this post


Link to post
Share on other sites

My thought was with 313 extra bytes, why not see if Paul Slocum can cram some music into it? :D

Share this post


Link to post
Share on other sites

Adhack6 didn't take advantage of many of the optimizations (because I didn't find out what was keeping the red dragon from moving). With those in place, I could have added a bit more to that example.

Share this post


Link to post
Share on other sites
Based on what Nukey Shay pointed out, my only changes would probably be adding rooms, although the suggestion of making only one game instead of three is a very good one.

 

I just took a few minutes to browse the code, and I noticed this at the bottom:

; here we count the unused bytes:

 IF ORIGINAL

   .ds 171, 0

 ELSE

   .ds 271, 0  ; I stopped at 100 extra bytes, you will find a lot more :-)

 ENDIF

 

Hmm...I wonder if the code he sent me actually only has 100 bytes freed up, or if he just never updated that line?  :ponder:  

 

Edit:  Ok, Blonde moment.  Maybe the "you will find alot more" refers to the extra 213?  :dunce:  I need more sleep.

The 100 extra bytes refers to how much you gain by taking advantage of all the optimizations. The 171 in the "If original" field is how many bytes you end up with (at least) after the "standard" trimming occurs...even if "original" is set to one...the removal of the B/W routines (but not the bytes??) and the shortening of the easteregg message. Add them together and you get 271 bytes free. Apparently, he stopped counting at 313...because his message states that you will find more. At least that is what I think it means :D

 

Question: How can you tell if a section is going to be placed on a page break before you compile with Dasm? Is counting them manually the only way?

Share this post


Link to post
Share on other sites
Question: How can you tell if a section is going to be placed on a page break before you compile with Dasm?  Is counting them manually the only way?

:idea: Well, you can always write and use macros who will watch the critical sections for you.

 

Here is a link to [stella] where this was discussed already:

http://www.biglist.com/lists/stella/archiv...0/msg00148.html

Share this post


Link to post
Share on other sites

Thanks :) Any idea what goes wrong in the optimized MoveDragon routine? Or why those pixels are skewed in some screens?

 

BTW here is a more "extreme" example of using screen reuse. All the original Adventure screens have been removed, and five have been defined: UpperExit, TwoExit, CastleDef, LowerExit, and NoExit. For familiarity's sake, I kept the map layout for the 31 screens the same as Adventure's...and blocked off side areas of the various screens only by using the barriers (except for the castles...which have their own screen layout anyway). Those five screens also share upper and lower walls to save even more space. There is enough unused Rom area to add 68 additional screens (618 bytes/9 per screen) for a total of 99 :)

Simplistic screens, but with 99 of them you can make a pretty conveluted path.

The source warns of crossing page boundries but so far (so far) it doesn't seem like it's a problem :? If it becomes one, I suppose that the indexes could be altered to seperate the different types of values in their own tables (i.e. the color values for all screens in one table, B&W in another, playfield control in a third, etc.).

adhack9.zip

adhack9s.zip

Share this post


Link to post
Share on other sites

Yeah...it does mess up. I made a version that has all 99 rooms in it, but it gets screwy in the 65th screen (dunno if bit 6 has anything to do with this or not). To see this, travel north through the easteregg screen...you'll pass through 33 additional screens easily (you'll notice when it's approaching...I changed the walls white a couple screens from the max).

 

Still, 64 screens is pretty good :) And there would still be 315 bytes left over if you want to add some more room definitions at the end (enough for at least 15 custom screens). So that makes 16 (counting the castle) detailed screens/mazes, and 48 "bare bones" (using only panels and horizontal walls like this example).

adhack99.zip

Share this post


Link to post
Share on other sites

Now I remember that I had helped Joel a little bit with optimizing the Adventure code. So if you have problems with optimizations that Joel can't solve, please contact me (by email please).

 

:idea: Not moving red dragon problem:

In MoveRedDragon replace LDA #$03 with LDY #$03.

Share this post


Link to post
Share on other sites

Yup...I knew you had a hand in it, that's why I was wondering if it rang any bells. BTW I found the offending line for the red dragon:

 

(from the optimized "ELSE" portion)

MoveRedDragon:

      LDA    #<RedDragMatrix

      LDA    #$03

The second line should be loading the Y register (as it does with the other two dragons).

So the only problem that remains are those blasted pixels 8)

Share this post


Link to post
Share on other sites

Oops...you are waay too quick! I was just testing it :ponder:

 

(yeah yeah, sure)

 

Found another useless part of the program...

LDY    #$00    ;2

LDA    ($93),Y ;Get the object's room;5

CMP    $8A      ;Is it in the current room?;3

BNE    NoObject;If not, branch;2

LDA    $97       ;Get the object collided with;3

(the program already knows that a collision occured and which one it was...these lines are just overkill)

Savings of 10 bytes & 15 cycles :)

 

Chalk up another 32 bytes (that makes 650 free in adhack9)

 

BTW if you happen to find yourself inside a castle when its gate is closed, you can't get out! :lol: I always wondered what the game would do if that happened.

Share this post


Link to post
Share on other sites

Yes, it's still there...the "99" screen game example is the same as hack#9, just with more screens added above the EE screen. Just as with the original game, you can find the dot in one of the black castle's rooms...and you can use it to pass thru any panels that appear on the right. You can reach it pretty easy without the bridge (since these hacks aren't utilizing mazes).

The game will allow you to cross the glitchy 65th screen...and it will put you in the blue "maze" section if you leave upwards. No way to get to the remainder of the rooms (the actual #65 thru #99)...I just did it to see how many rooms the program would allow you to see.

 

I had a really neat idea about how to use all of this stuff, but I want to try out a few things first (toy with the enemies' behaviour a bit). I really gotta try to work out some different mazes as well (God I suck at making them)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...