EarthQuake

Thanks so much for the information! Not once did I think of checking the subroutines I added jumps to. You are correct that X is being modified by RoomNumToAddress, but I did not realize Y was being used for anything outside of the routines. I've preserved both X and Y throughout the routines and things actually work better now. Also, as is, the surround recoloring skips the screensaver code. Would it be wise to branch to it after the surround has been recolored or would that mess up the recoloring? Actually, looking through all of this, am I just making this overly complex and difficult? Basically, what I need to do for the color-specific flashing is: See if the color value's luminance is $F. Strip the luminance if it is. Get the LoCnt and strip it of it's hue. Merge the two, it uses the passed color value's hue, and the framecounter's luminance. As I look at the code, I think I didn't quite get it right. I made this into a beast that doesn't even do it properly. I think if I rework the routines, I should be able to get the full range of hues. Also, since I have two unused bytes of RAM left in the program, would it be better to use one of those for storing X/Y? Or hell, even both? Makes the code less shorter having to constantly save and restore X/Y.

Actually I have discovered some things. The "Magic Number" is in fact the number of luminosity values the color will cycle through. Changing it to $0F (16) will make it cycle through two different colors, such as $1F which will display yellow ($10) through orange ($20). Also, I have noticed, that there are only 8 different cycling color variations. This went unnoticed at first. The second half of the values are simply repeats of the first 8. I tried shifting the bits around with ASL and LSR, but again, it messes up the "speed" of the cycling and sometimes results in crashes. If I can't find a solution, I'll just have to settle for the 8 different color cycles plus the original full-color one, which is quite okay by me. 0 Gray - Gray 1 Yellow - Orange/Gold 2 Orange - Red/Rose 3 Red - Purple 4 Pink - Blue 5 Purple - Teal/Cyan 6 Indigo - Green 7 Blue - Brown/Gold Gives me all the colors of the spectrum I need.

Here are my entire updated ChangeColor routines: ChangeColor: STA Temp ;Save A for later. ;3 <- added CMP #$CD ;Does the object use color $CD? ;2 <- added BNE ChangeColor_1 ;If so branch. ;2 <- added LDA CurrentObject ;Get current object. ;3 <- added CMP #SurroundNumber ;Is it the surround? ;2 <- added BEQ SurroundColor ;Branch if it is. ;2 <- added ChangeColor_1: ; <- added LDA Temp ;Restore A. ;3 <- added LSR ;Is bit 0 of the color set? ;2 BCC ChangeColor_3 ;If not, skip the flashing routine. ;2 LDA Temp ;Load original color. ;3 <- added AND #$0F ;Remove the hue nybble so we can compare it. ;2 <- added CMP #$0F ;Branch if resultant luminosity is $0F. ;2 <- added BNE ChangeColor_2 ;2 <- added LDA Temp ;Load original color. ;3 <- added AND #$F0 ;Remove the luminosity nybble. ;2 <- added STA Temp ;We don't need Temp anymore so save new value to it. ;3 <- added LDA LoCnt ;Use frame counter for color. ;3 <- added AND #$07 ;Set magic number. ;2 <- added ORA Temp ;Adjust object hue using new Temp color. ;2 <- added JMP ChangeColor_3 ;3 <- added ChangeColor_2: ; <- added LDA LoCnt ;Use frame counter for color. ;3 ChangeColor_3: LDY HiCnt ;Get the input counter. ;3 BPL ChangeColor_4 ;If console/stick moved recently then branch ;2 EOR HiCnt ;Merge the high counter with the color wanted. ;3 AND #$FB ;Keep this color bug merge down the luminance. ;2 ChangeColor_4: ASL ;And restore original color if necessary. ;2 ChangeColor_5: RTS ;6 SurroundColor: ; <- added LDA PlayerRoom ;Get current room. ;3 <- added JSR RoomNumToAddress ;Convert to room address. ;6 <- added LDY #$03 ;Set up pointer to room data table. ;2 <- added LDA (CurrentObject),Y ;Use the background color from the table. ;3 <- added JMP ChangeColor_5 ;3 <- added They work fully as intended and do several things. First, the most important thing, is by giving an object a color value of $CD, the object will be invisible (by matching the background color) no matter which screen the object is on. While this is not immediately useful except as a novelty feature, it is vital in conjunction with the screen-dependent background colors I implemented. The surround will always use the background color if it's color is set to $CD. This allows the surround to have it's own color for each screen, extending the graphical capabilities of the game. The second part of the code checks if an object has an odd number, and if it does, it does another check to see if the lower nybble (the luminosity value) is $F. If it is, it takes the upper nybble (the hue value) and uses that to enhance the color flashing by limiting it's range of colors to that hue. This allows the game to have 17 color flashing effects: one that cycles through all the colors (like the chalice did), and 16 others for each different hue supported by Adventure. So for example, if you wanted your gold key to pulsate with a shower of golden colors, you would set it's color value to $1F. The code is probably really inefficient, because I've been writing my own assembly for like 2 weeks now, but it does exactly what I intended it to do and without no side effects. Keep in mind, despite having 5 dragons, 5 portcullises, and a buttload of other stuff, the game experiences no problems with timing.

So I've made this really neat addition to the ChangeColor routines. For objects that are supposed to flash, I've been able to narrow down the range of colors the object cycles through depending on it's original color value. For example, if an object is $11 (an odd yellow number), then it will cycle through various shades of yellow. It works like this: LSR ;If bit 0 of the color is set ;2 BCC ChangeColor_2 ; then the room is to flash. ;2 LDA Temp ;Load original color. AND #$F0 ;Remove the luminosity nybble. STA Temp ;We don't need Temp anymore so save new value to it. LDA LoCnt ;Use frame counter for color. ;3 AND #$07 ;Set magic number. ASL ;Prevent game from crashing. :) ORA Temp ;Adjust object hue. LSR ;Speed up flashing due to the ASL. There are a few instructions in there which don't make sense to me. Before, I was just ANDing and then immediately ORing LoCnt, but it kept crashing on me in the middle of the game, so I shifted the bits long enough to perform the OR operation (where the crash was occuring). Also, I have no idea why $07 seems to be the "magic number". It's the only value I can AND without it changing the flashing behavior. The code is a bit bloated, but it works great despite being so mysterious to me. No more crashes or oddities. The only thing left to do is check if the original color has $F for the lower nybble and skip the added code if it doesn't. This would allow me to use the hue-based flashing code to only apply to objects with a color such as $CF or $4F. Sometimes I wonder if these minor little additions are going to be worth it in the end. EDIT: Actually, the LSR and ASL no longer seem required. I'm not getting the crashes without them.

That's really neat, heh. Although I seriously cannot figure out a need for so many objects, especially considering how they flicker if too many objects are on-screen. But by all means, keep hacking away. You'll have this down to like 1KB free in a couple of months.

Ah, thanks for the info. I did some searching on Ebay, but I never even came across a boxed version, so I wasn't aware if it originally came shrink-wrapped or not. Just looking for an unopened box in mint/near-mint condition.

Haha, that is incredible. I remember when the source with 313 free bytes was simply unheard of. I wish Warren could see this, of course he probably could have done better if he wasn't under any time constraints. Since every Adventure thread seems to go horribly off-topic with tons of technical jargon, I might as well ask about this... How does the flashing routine in ChangeColor work? Specifically, what range of values do HiCnt and LoCnt hold? I'd like to restrict the range of colors that it cycles through, but I'm not having much luck not knowing what the counter holds at this point. If the color comes from LoCnt, where does HiCnt come into play?

A very common game, but I haven't been able to find this shrink-wrapped. I'd be willing to pay $40-50, but since I'm not sure on it's value, I might go higher or cut some trades. I have a habit of collecting sealed packages for all my favorite games on various platforms, but this is one of the harder ones to find. PM me if you think you could help out. Thanks.

It might be wise to leave this as something that can be enabled or disabled. Since you're optimizing the source code to the game, it would probably be preferable to most if they could actually compile the game and have a working clone of Adventure. I'm not sure if the original game is already compromised (like, is random number generation the same?), but it would be best not to force anything onto users of the source code that wasn't like it was in the original Adventure. EDIT: Oh, and this could not only have a visual impact on the game, but it might interfere with the secret room or passing through dragons and such. Don't get me wrong though, I think I would prefer ghostly objects as opposed to ones that blink in and out of existance. All of your other plans seem absolutely superb.

By the way I figured out one cause for the portcullis' not to work. If you rearranged things in the main game loop to optimize it, calling the portcullis routine too late in the loop will recreate the exact problem you had. In my case, I placed it right before the main game loop returns to the beginning, right after the last PrintDisplay. Atwwong! I see you buddy!

So in essence you break up the room data table into 8 or 9 smaller tables that should give a boost in performance? While it may be nice having faster execution, it would really make things harder to modify. What sort of speed improvements are we talking about?

Something neat I just thought of was to create additional obstacle-like objects to act as magic barriers. They use a bitmap that is a solid block of pixels, and when positioned, stretched, and/or colored correctly, you can have walls that blend in with the playfield, but will flash when two or more objects are present on the screen, allowing you to pass through. If placed on the sides of the screen, they can act as a quick hack to creating assymetrical playfields (provided the neighboring screen blocks passage). This does carry the side effect of getting stuck if objects leave the screen. It takes 65 bytes of ROM and 4 unused object to create 4 different types of barriers. If multiple barriers of the same variation is needed, more can be added for an additional object number each. Here is the bitmap: GfxWall1: .byte $FF ; XXXXXXXX (Vertical wall, two middle map units tall) .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX GfxWall2: .byte $FF ; XXXXXXXX (Vertical wall, one middle map unit tall) .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX GfxWall3: .byte $FF ; XXXXXXXX (Horizontal wall, middle of room) .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX GfxWall4: .byte $FF ; XXXXXXXX (Horizontal wall, top or bottom of room) .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX .byte $FF ; XXXXXXXX .byte $00 ; (33 bytes) If you want a thin barrier that extends to two middle screen pixels (remember the first and last line is shorter), then add a dummy object (similar to the Author object), make it use GfxWall1, and set it's coordinates for the screen you want to use. For a shorter variation that is only one middle screen pixel tall, use GfxWall2 as the bitmap. For barriers that lay horizontally, use GfxWall3 so the object is one middle map pixel tall and set that objects size to $07 (which stretches it x8). If you want a horizontal barrier that can be used on the top or bottom line, do like the previous horizontal barrier, but use the GfxWall4 bitmap. By setting the color to the color of the room where the objects will appear, you can make them hidden under normal circumstances. Of course you can modify the bitmap to suit your needs, but this one covers multiple variations. And a screenshot:

I'm not quite sure what changes you made to the hack, but I seem to like it more than the original. I like some of the screens like the ones with the lake (that was brilliant), and the different types of trees you came up with. Some were just too abstract I think, but it didn't turn out that bad. Just think of the type of detail you could get if you doubled the vertical resolution. I think this hack's best quality is the open-endedness of it. It's hard to find items, yet the openness of the screens balance this out. I would really like to see what you can do with this using Nukey's high-res bitmap code.

Got 'er! Yeah, it was just as I suspected, but checking for some obscure color value was the perfect plan, Nukey. The user can't choose any odd numbers to begin with, so if they want the room/object to flash, they can just click on a checkbox, which in turn assigns the value $CB to the room/object. So if I reserve, say $CD, for the surround color, everything will be good later down the road. Thanks Nukey, despite the confusing post war we just had.

Oh so I should check it's color as well as it's number, and use some arbitrary, yet obscure color value to compare with (since I won't be using the surround's color value for anything else). I'll try it and see what happens. I really am hoping I was correct in assuming it was changing room $00 because it has the same number as the surround.

I've pretty much got everything sorted out. The only problem is that room $00 is using the wrong playfield color. Everything else works like a charm. Although I think you might have already solved the problem... where does the $FF value in your code come from? Oh, here is the routines I used. Keep in mind efficiency wasn't really my goal. I just wanted to get it to work and clean it up later. I used the Temp variable to restore A to it's original value after I was done changing the color of the surround. Any reason this code might affect room $00? ChangeColor: STA Temp LDA CurrentObject CMP #SurroundNumber BEQ Testies LDA Temp LSR ;If bit 0 of the color is set ;2 BCC ChangeColor_2 ; then the room is to flash. ;2 LDA LoCnt ;Use frame counter for color. ;3 ChangeColor_2: LDY HiCnt ;Get the input counter. ;3 BPL ChangeColor_3 ;If console/stick moved recently then branch ;2 EOR HiCnt ;Merge the high counter with the color wanted. ;3 AND #$FB ;Keep this color bug merge down the luminance. ;2 ChangeColor_3: ASL ;And restore original color if necessary. ;2 ChangeColor_4: RTS ;6 Testies: LDA PlayerRoom JSR RoomNumToAddress LDY #$03 LDA (CurrentObject),Y JMP ChangeColor_4 The code does work. It just has the side effect of changing room $00's playfield color somehow.

Actually, I am having a problem. The new code I added checks if an object is the surround before recoloring it. However, since the surround has an object number of $00, it affects the title screen since it is also $00. The ChangeColor routine is used by both, for recoloring the screen and objects to use the color cycling effect you see on the chalice. How can I differentiate between a room and an object? Is there a simple way of doing it, or am I going to have to use some bitwise trick to check it? EDIT: Actually, something more sinister is going on here. Room $00's colors seems to take on colors from room $01, making it a solid color using the playfield color from that room. Setting the darkness bit on room $00 makes it so the background is visible, but the colors are inversed. After hitting the game reset button and after visiting a dark room, the colors are more normal, but are still incorrect (using another room's colors). I'm not quite sure what's going on... Perhaps it has to do with the initial location of the surround when the game starts. EDIT 2: Fixed part of it (I was checking the Surround's room instead of the Player's room in the ChangeColor routine). Room $00 now behaves more normally, but it's still a solid color (at least the colors are correct and it's not gathering information from other rooms.

Woot! I finally got the surround recoloring working! There is still an issue with room $00, but it might have to do with some of my constants being set incorrectly. Time to get bustin on this program now. In the picture below, the playfield and background both use the playfield color from the room data table. The surround is actually white, but it is changed to use the background color from the room data table. Took me enough tries, but I got it.

Well considering the source code for this program is based off the Odyssey source, it's still coming along.

Well, I've figured out how to control which difficulty levels can be randomized, but that only covers object placement. I might be able to modify the seed for the random number generation, which will allow you to have several binaries each with their own possibilities. I'm not sure how else I could make the game more random other than that. But if I think of something, I'll make an effort to include it!

Oh it will be! CYOA (Create Your Own Adventure) was a program that basically just replaced things in the original Adventure and spit out a binary. You couldn't add stuff and you were limited by the restrictions of the original game. What I'm aiming for here is an application that uses a flexible modified source code to let you create something a little more adventuring. Right now the features look something like this: Easily modify any of the graphics including rooms. Up to 128 rooms should be possible (although 64 is more practical). Connect those rooms however you like. Establish room connections dependent on difficulty level. Ability to choose background colors for rooms. Up to five dragons are supported. Modify dragon movement and biting speeds. Additional portcullises are planned. Enable or disable any object in the game. Easily position any object's locations and what rooms they can appear in. Up to four difficulty levels which are somewhat configurable. Specify starting and winning rooms for each difficulty level. Option to enable new sound effects. This is a pretty big and ambitious list (and incomplete), so I can't guarantee anything. I will have to do things one at a time, starting with the more important stuff. Getting the room connections to work will be the largest task, and difficulty room differences to work will probably be the hardest task. Before I can really work on the program in it's entirety, I need to finish the source code and make it so the program can easily modify it (using IF/ELSE directives and moving all variables to a general location so they can be switched on or off). Right now I'm trying to get the source code in a state where dark rooms are automatically set up for the user, but I'm still having trouble with changing the surround (without changing the other items). I'll start working on the program more and more as I get more things working in the source code. There are a lot of details I need to plan out before I jump in head-first.