+Atarius Maximus Posted September 27, 2003 Share Posted September 27, 2003 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 Quote Link to comment Share on other sites More sharing options...
StanJr Posted September 27, 2003 Share Posted September 27, 2003 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! Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 27, 2003 Share Posted September 27, 2003 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. Quote Link to comment Share on other sites More sharing options...
Vic George 2K3 Posted September 27, 2003 Share Posted September 27, 2003 How about removing the skill levels and just have it one game? Quote Link to comment Share on other sites More sharing options...
Tempest Posted September 27, 2003 Share Posted September 27, 2003 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 Quote Link to comment Share on other sites More sharing options...
+Atarius Maximus Posted September 27, 2003 Author Share Posted September 27, 2003 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? Edit: Ok, Blonde moment. Maybe the "you will find alot more" refers to the extra 213? I need more sleep. AM Quote Link to comment Share on other sites More sharing options...
ATARI TROLL Posted September 27, 2003 Share Posted September 27, 2003 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. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 28, 2003 Share Posted September 28, 2003 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 Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 28, 2003 Share Posted September 28, 2003 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 Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 28, 2003 Share Posted September 28, 2003 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" 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 Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 29, 2003 Share Posted September 29, 2003 Found the buggy routine that moves the red dragon in the optimized version...but I haven't a clue what is wrong with it 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 Quote Link to comment Share on other sites More sharing options...
ATARI TROLL Posted September 29, 2003 Share Posted September 29, 2003 so far the adv6 version plays quite nicely. Look for to the epic sagas of Nukey! Nice work by the way! Quote Link to comment Share on other sites More sharing options...
MegaManFan Posted September 29, 2003 Share Posted September 29, 2003 My thought was with 313 extra bytes, why not see if Paul Slocum can cram some music into it? Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 29, 2003 Share Posted September 29, 2003 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. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 29, 2003 Share Posted September 29, 2003 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? Edit: Ok, Blonde moment. Maybe the "you will find alot more" refers to the extra 213? 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 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? Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted September 29, 2003 Share Posted September 29, 2003 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? 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 Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 29, 2003 Share Posted September 29, 2003 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 Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 29, 2003 Share Posted September 29, 2003 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 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted September 29, 2003 Share Posted September 29, 2003 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). Not moving red dragon problem: In MoveRedDragon replace LDA #$03 with LDY #$03. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 29, 2003 Share Posted September 29, 2003 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 Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 29, 2003 Share Posted September 29, 2003 Oops...you are waay too quick! I was just testing it (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! I always wondered what the game would do if that happened. Quote Link to comment Share on other sites More sharing options...
ATARI TROLL Posted September 29, 2003 Share Posted September 29, 2003 I did manage to get stuck. Nukey, is the secret dot and room still available in the adv99 version? Just curious! Cheers Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 29, 2003 Share Posted September 29, 2003 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) Quote Link to comment Share on other sites More sharing options...
Room 34 Posted September 29, 2003 Share Posted September 29, 2003 I like the extra-glitchy room to the left of the 65th room. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 29, 2003 Share Posted September 29, 2003 Enter that one at your own risk...I got stuck in those black pixels Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.