EarthQuake

Haha, sorry. It's pretty much a rule now that whenever an Adventure-related thread pops up, we both take control of it and flood it with 4 pages of source code modifications and discussion. And even if the thread is about source code modifications, you can sure bet it'll go insanely off-topic within a few posts. But if you still want to rename it, then be my guest.

Slight problem I think... I tried it out, and my magnet was running away from things.

It's called a mod tracker. MOD, IT, XM, and S3M are some different types. Basically, the file has the sound samples included in the file and they are arranged in a similar fashion to MIDIs, so that they sound the same no matter what sound card you use. And because of their nature they can be very small in filesize.

For general listening purposes, MIDIs aren't the greatest choice, but when used in games and such, they work quite well. Doom, a game I mod frequently, uses MIDIs (actually MUS, which is a variant of it) as it's primary source of background music. You would be absolutely surprised of the complexity and quality of some MIDIs that people produce. A good MIDI doesn't require a good sound card, generally speaking. In Doom, it is usually more acceptable to use MIDIs for music because of the MUCH smaller filesize. Usually each new level in one of these mods will have it's own music for that level. So if the mod has 10 new levels, would you prefer 300 KB of music, or 30 MB when MIDI can just be as effective as MP3s or OGGs? Here are some MIDIs that I have thrown together. They are my first attempts, but I've got good reactions to them so far. Basically, MIDIs are a great compromise when it comes to quality versus size. Also, some people produce MIDIs for older games which don't support MP3 or any other format. So asking why people still compose MIDI is like asking why people still create Atari 2600 games. Oh, did I mention how much easier it is to compose a MIDI rather than an audio file?

This is a really nifty program! However, anyone who wants this on a cart is probably either a collector or wants the program as some novelty item. I can actually see someone messing around with this on their VCS just for fun. Is the binary available? You could probably include a link so people can try it out (even if it's not new).

Hehe.

Yes it does. Oh, I just noticed the scanline count. Before I changed that, it was still displaying 262. It's down to 261 now, so yeah I need to bump it up a notch. Thanks so much. I'd celebrate this occasion, but given the past several times I thought I had things working, I was usually abruptly disappointed. I'm gonna wait a few days before I crack open the champagne.

Hands off the source code! I don't want any leaked betas going around.

Here's the source code if you want to take a looksies. Pay no attention to the nonsensical room layouts or objects strewn everywhere. I haven't really started on that stuff yet. I had to modify a bit more than you stated to get it to work, but I probably just missed something minor. I'll poke around with it some more and see what I come up with.

Got 'er... Well almost. There are now problems with objects having the first row of pixels being clipped off (shot #1). This only affects one of the player sprites. When another object comes onto the screen, the sprites swap and the object I just brought onto the screen has the first line cut off. Also, the null object likes making an appearance when no objects are on the screen (shot #2). I can bump into it and move it around too! It is somehow gathering one of my fire sprite bitmaps which are just below it's graphic definition, but I'm not sure where the huge block of pixels above it are coming from. I looked around but couldn't find any reason for either happening. I did run into some problems with the PosSpriteX routine. It was different in your version (and renamed), so I just copied it over to mine since the only thing that referenced it was the kernal. Also, I love how you fixed the skewed scanline at the bottom. I always wondered why that was there in Adventure. EDIT: Whoa, wait a second. Variable-resolution screen bitmaps? OH MY GOD I LOVE THIS KERNAL.

This is getting to be overwhelming. I'm not sure if I'm really up to finishing this hack anymore... It's just out of my league. I wanted to do thing to set it apart from other hacks, and here I am getting stuck on the most insignificant changes. This is why I doubt my future as a programmer. I don't think I have the patience for it.

By the way, an observation I made... By rearranging things in the main game loop, I can affect how easily the rumbles are induced. Like, if I cram too many routine calls in one area, the rumbling starts when I carry the key a good 3/4ths of the screen across. I have arranged things so that this doesn't happen unless you are at the very edge of the screen. Is this an indicator that I'm packing things tighter? EDIT: Heh, you tend to pop out of nowhere like that. No, I assumed you would have left the kernal untouched, but I will definitely check it out now that you mentioned it! Will I be able to plug it in, in place of the old?

Thanks a lot man, I'll try that out. I managed to reproduce the rumbles. They now occur on one of my screens where a portcullis is present. If I move a key to the rightmost side and stand near it, it starts shaking by one scanline. Weird thing is, if I unlock the portcullis, and go back to my original position, it doesn't rumble anymore. So I started to think if it was the portcullis routine and I moved that around with no success. So I really hope this is what finally fixes this damned thing. I think I spent literally my entire week off implementing and debugging the color stuff I added. Haha, oh man... EDIT: And the results... Are disconcerting. This change saves at least 24 cycles. Still not a slight change in the rumbles. The SetupRoomPrint call has to be the source of the problem. If I comment out both calls to ChangeColor, the screen doesn't roll. If I comment out just one, the problem still exists. Seriously, this is sort of ridiculous. I wish I had some idea of what to do short of removing something... I swear to God, if I get this working, people better be going "Hey! Look at that flashing key! It's green and green only!"

Oh shit! Sorry, didn't realize this was half way down the page when I replied! Please delete, lock, or ignore.

I'm impressed. I really am, but as much as I'd like to use your code in Odyssey, at this point I think it would be more trouble than it is worth. I'm also not fond of having to edit rooms in the new source. It seems like it would be even more difficult to connect rooms and such having multiple seperate tables. It was always troublesome in the past just having to edit the table itself. But with all the problems I've been having lately with cycle times, it really is tempting. I ran into another crash shortly after I fixed my SetupRoomPrint table, and when I went to see what could be causing it, I got more screen rumbles (despite the 20+ cycle savings). Talk about being disappointed. I rearranged the main loop a bit, which seemed to fix the problem. I've been testing like crazy and no rumbles so far. The crash still worries me though. I can't get it to happen anymore, which means either it's really rare and difficult to pin down, or it has been miraculously fixed. I don't think moving routines in the main loop would fix a crash (unless a certain routine relies on a register to have not changed). But so far so good. Sometime I'm going to try to get a thread stickied with all your adventures with Adventure so that other people who dare to adventure into the depths of Adventure's workings will have plenty of references and guides to work with. Since Adventure seems to be one of the most hacked games, it might be worth it to have a reference guide dedicated to it. And since you're the man when it comes to Adventure, it would be pretty much all about you.

Got 'er How does this code look? There is only one call to ChangeColor when dealing with backgrounds, and the rumbles are completely gone as I expected! I still have a lot to learn about program flow, but I'm definitely getting my hands dirty. Do you see anything that might be off? SetupRoomPrint: LDA PlayerRoom ; Get current room number. ;3 JSR RoomNumToAddress ; Convert it to an address. ;6 LDY #$00 ;2 LDA (CurrentObject),Y ; Get low pointer to room graphic. ;5 STA RoomLo ;3 INY ;2 LDA (CurrentObject),Y ; Get high pointer to room. ;5 STA RoomHi ;3 INY ;2 LDA (CurrentObject),Y ; Get room color. ;5 JSR ChangeColor ; Change if necessary. ;6 STA COLUPF ; Put in playfield color register. ;3 INY ; ;2 <- added LDA (CurrentObject),Y ; Get background color for this screen. ;5 <- added STA Temp2 ; Store background color in RAM for later. ;3 ;Now check if room is dark... INY ; Set up pointer position for reading the control byte. ;2 <- added LDA (CurrentObject),Y ; Get the room's playfield control. ;5 <- added AND #$04 ; Check if this room is dark. ;2 <- added BEQ SetupRoomPrint1; Branch if it is not dark. ;2 <- added LDY #$02 ; Else, set up pointer position to get playfield color. ;2 <- added LDA (CurrentObject),Y ; And load that into the background color. ;5 <- added JMP SetupRoomPrint2 SetupRoomPrint1: LDA Temp2 SetupRoomPrint2: JSR ChangeColor ; Change if necessary. ;6 <- added STA COLUBK ; Set the playfield color register ;3 <- added Oh btw, the rest of SetupRoomPrint2 is the same. I just moved the two above lines to it.

Actually, I know exactly what I need to do to stop the rumbles. When I did the background loading, I added an additional call to ChangeColor. This is my killer. Before I added the new code to handle the backgrounds, I had roughly 32 cycles free. ChangeColor uses more than 32 cycles in cases when the program flows through the entire thing, so the only way to prevent the rumbles is reorganize the background loading code so it only needs to call ChangeColor once.

Actually this works for me. I bumped it up a notch, but it's now displaying a constant 263 scanlines. What does this mean in terms of hardware compatibility? Will it work on a 2600 with a NTSC television? Btw, without changing the scanline count, the program bounced between 262 and 263 scanlines during the rumbling. Also, it only seems to happen when a dragon (the yellow one in my tests) is in it's biting state and only in a dark room. I can't get it to jump to 280 anymore. EDIT: OH! It also occurred to me that I could do some optimizations to the SetupRoomPrint routine itself. Remember I added some instructions to change the background color. I actually forgot to go back and see how I could reorganize it. There's a good bit of redundancy that might be using up more cycles than needed. SetupRoomPrint: LDA PlayerRoom ; Get current room number. ;3 JSR RoomNumToAddress ; Convert it to an address. ;6 LDY #$00 ;2 LDA (CurrentObject),Y ; Get low pointer to room graphic. ;5 STA RoomLo ;3 INY ;2 LDA (CurrentObject),Y ; Get high pointer to room. ;5 STA RoomHi ;3 INY ;2 LDA (CurrentObject),Y ; Get room color. ;5 JSR ChangeColor ; Change if necessary. ;6 STA COLUPF ; Put in playfield color register. ;3 LDY #$03 ; ;2 <- added LDA (CurrentObject),Y ; Get background color for this screen. ;5 <- added STA Temp2 JSR ChangeColor ; Change if necessary. ;6 STA COLUBK ; Put it in the background color register. ;3 LDY #$04 ; Set up pointer position for reading the control byte. ;2 <- added LDA (CurrentObject),Y ; Get the room's playfield control. ;5 <- added AND #$04 ; Check if this room is dark. ;2 <- added BEQ SetupRoomPrint2; Branch if it's not. ;2 <- added LDY #$02 ; Set up pointer position to get background color. ;2 <- added LDA (CurrentObject),Y ; Load the background color. ;5 <- added JSR ChangeColor ; Change if necessary. ;6 <- added STA COLUBK ; Set the playfield color register ;3 <- added SetupRoomPrint2: ; <- added ;Playfield Control LDY #$04 ; Set up pointer position for reading the control byte. ;2 LDA (CurrentObject),Y ; Get the playfield control value ;5 TAY ; Save it for later. ;2 <- added AND #$05 ; Keep only mirror and priority bits of the value. ;2 <- added ORA #$20 ; Set ball width = 4 pixels on every screen. ;2 <- added STA CTRLPF ; And put in the playfield control register. ;3 TYA ; Get back original value. ;2 <- added STA ENAM1 ; Enable right wall (bit 1) ;3 LSR ; Move down 2 bits ;2 LSR ;2 STA ENAM0 ; Enable left wall (bit 3 shifted to 1) ;3 ;Get objects to display. JSR CacheObjects ; Get next two objects to display. ;6 ;Sort out their order. LDA CurrentObject+2 ;3 BEQ SwapPrintObjects ; Branch to swap (we want it as player01). ;2 CMP #BridgeNumber ; If the first object is the bridge... ;2 BNE SetupObjectPrint ; Swap the objects (we want it as player01). ;2 LDA CurrentObject+3 ;3 BEQ SetupObjectPrint ;2

I believe the problem lies around SetupRoomPrint since it is the routine that is calling ChangeColor. I can comment out all the non-essential routines (dragons, magnet, bat, portals) and it still gives me the shakes. The screen rumbles also only happen on dark rooms, and tend to occur most aggressively when the yellow dragon is biting. In Stella's debug mode, as I stepped through each frame, I was getting 280 scanlines every several frames or so. It probably just states the obvious, but I thought I should tell you about that observation. My DoVSYNC routine seems to already have the WSYNC's removed. I had some difficulty way back when Haunted Adventure was in development. I used the same DoVSYNC routine that atwwong did because I was getting rumbles with the fourth dragon I added. But here it is nonetheless: DoVSYNC: LDX INTIM ; Get timer output. ;4 BNE DoVSYNC ; Wait for time-Out. ;2 LDA #$02 ;2 STA WSYNC ; Wait for horizontal blank. ;3 STA VBLANK ; Start vertical blank. ;3 STA WSYNC ; Wait for horizonal blank. ;3 STA VSYNC ; Start vertical sync. ;3 STA WSYNC ; Wait for horizontal blank. ;3 LDA #$2F ; Set clock interval. ;2 STA TIM64T ; Countdown next frame. ;4 STX VSYNC ; End vertical sync. ;3 RTS ;6 Also, here is my current main loop in case you want to see it as well: MainGameLoop_2: LDY #$00 ;Allow joystick read - all movement. ;2 JSR BallMovement ;Check ball collisions and move ball. ;6 JSR MoveCarriedObject ;Move the Carried Object ;6 JSR DoVSYNC ;Wait for VSYNC ;6 JSR SetupRoomPrint ;Setup the room and objects for display. ;6 JSR PrintDisplay ;Display the room and objects. ;6 JSR PickupPutdown ;Deal with object pickup and putdown. ;6 LDY #$01 ;Disallow joystick read, move vertically only. ;2 JSR BallMovement ;Check ball collisions and move ball. ;6 JSR Surround ;Deal With Invisible Surround Moving. ;6 JSR DoVSYNC ;Wait for VSYNC ;6 JSR MoveBat ;Move and deal with bat. ;6 JSR MoveWhiteDragon;Move and deal with white dragon. ;6 <- added LDY #Portcullis ;For Each Portcullis. ;2 JSR Portals ;Move and deal with portcullises. ;6 JSR PrintDisplay ;Display the room and objects. ;6 JSR MoveGreenDragon;Move and deal with the green dragon. ;6 JSR MoveYellowDragon ;Move and deal with the yellow dragon. ;6 JSR DoVSYNC ;Wait for VSYNC. ;6 LDY #$02 ;Disallow stick read, move horizontal only. ;2 JSR BallMovement ;Check ball collisions and move ball. ;6 JSR Mag_1 ;Deal with the magnet. ;6 JSR MoveRedDragon ;Move and deal with red dragon. ;6 JSR MoveBlackDragon;Move and deal with black dragon. ;6 <- added JSR PrintDisplay ;Display the room and objects. ;6 BNE MainGameLoop ;always branch ;2 I tried breaking up the portcullis routines, but I didn't notice anything different. As I said above, I can comment most of the routines out and it still rumbles under the same exact conditions. I'll try moving the SetupRoomPrint around some more, but I don't think it will fix the problem without introducing any unwanted side effects. Oh, and CacheObjects? Heh?

I get a very minor screen rumble using the new ChangeColor routine. I didn't notice this until after I readded the 2 gates and keys. From what I can gather though, the new ChangeColor routine is making the program run short on cycles (oh dear). From the main loop, I've been trying every possible combination of relocating the sub routine calls, but so far the only thing that fixes the rumbles is moving the SetupRoomPrint call. However this has the side effect of giving framerate boosts or messing with the ability to pickup and move objects. Is there something else I can try short of removing a portcullis/key? How are things supposed to be positioned in the main game loop? I know there are DoVSYNC's and PrintDisplay's in there, but how should everything be structured between those?

I'm not sure why, but Y was getting altered somewhere in the below code in SetupRoomPrint. I was using INY to increment Y because I thought it was still $02 at that point, but just loading the specific offset corrected the crashes. INY ;2 LDA (CurrentObject),Y; Get room color. ;5 JSR ChangeColor; Change if necessary. ;6 STA COLUPF ; Put in playfield color register. ;3 LDY #$03 ; INY crashes here. ;2 LDA (CurrentObject),Y; Get background color for this screen. ;5 STA Temp2 JSR ChangeColor; Change if necessary. ;6 STA COLUBK ; Put it in the background color register. ;3 And I don't know how Temp was getting corrupted. But it doesn't matter (unless it's going to byte me in the ass later).

Eek! I'm running into crashes again! I'm not sure if it was something I did or if it's the new routines you wrote. This only crept up on me after I uncommented the MoveXXXXDragon calls from the main loop. Uh, these routines wouldn't have anything to do with the dragons, other than recoloring them, would they? I've tried reverting some changes, but no luck so far. I'll try using the new routine in my last revision and see what happens. EDIT: Musta been me. I get no problems after adding it to revision 16. All I did from 16 onward was reorganize data tables and add 7 static items (which worked fine). I guess I'll just have to keep an eye and watch for anything that might cause the crashes. EDIT 2: Found the error. Life is great.

I'm printing a picture of your avatar and hanging it above where my fireplace ought to be. Actually, shortly after my last post, I decided to do the same thing regarding the RoomNumToAddress routine: saving the background color to RAM so I could access it later without having the call the routine inside the ChangeColor routines. I had to use another RAM location for storing the color using your code, however. The surround was picking up the wrong value from somewhere, probably because Temp is used in a million different places, and was probably getting changed before it reached ChangeColor. So I fixed that. Plus, I actually still have quite a few bytes of RAM unused, contrary to what I thought before (memory locations $F8 to FF are still unused). But great God, the results are beautiful! I've learned so much in one day, especially after learning specifically what most of the opcodes do. And you've taught me more than I ever thought I'd learn about assembly. You've finally laid this to rest for me, and I can finally sleep tonight (it's already 5 AM ). It's really funny though, because this is usually what happens in these little episodes: 1. I decide I want to do something. 2. I get stumped, ask some general questions. 3. You give general answers. 4. I go back to the drawing board. 5. I get something that almost/sorta works and show it off. 6. You point out something is wrong. 7. I go back to the drawing board. 8. I get stumped, and attempt suicide. 9. You churn out perfectly-working, deity-approved, plug-and-play source code. 10. I get happy and learn that suicide was not the answer.

Sorry, I'm just getting frustrated. I spent 2 and half days on getting this code to work correctly. I shouldn't be dumping my problems and incapability of understanding all the forces of nature that are working here. Once again, thanks for your patience.