Video: a curious bug in a game I've been working on

[scotthuggins]

Hello!


I've been working on this game for a few months...and I'm slightly stuck.  A lot of it is working, but the animation sequence I have shown in the attached video makes the display go hay wire.  It corrects itself and then everything is fine, but I've got a lot of sound effects in there that are fine, but why is this so different.


If you watch the attached video, you'll see what I am talking about.  It 100% is because of that crescendo sound I am playing during the animation sequence.  The code is below.  If I comment it out, everything is fine.  I appreciate ANY ideas you guys might have. 

Here's the video of it running in emulator: Cavern Rescue bug

Here's the sound code that is causing everything to go ballistic there in the video.  It's called for about 5 seconds (7 frames) while the animation sequence is happening. 

B500 ; the "crescendo" sound - if we comment this code out, the flicker never happens

        jsr dptoc8 ; DP to RAM

        ldu #sweepsnd ; get some music - all this does is play notes from high pitch down to low and back again to high

        jsr init_music_chk ; and init new notes

        jsr waitrcl ; Vectrex BIOS recalibration

        jsr do_sound ; ROM function that does the sound playing

        jsr dptod0

                

Any ideas would be much appreciated!  Thanks for looking at this.
Scott

[christophertumber]

The problem is with your use of the BIOS text routine. The broken animation is actually the text ("500"). It looks like your height and width values are getting munged. BIOS usually uses $C82A - There may also be a problem with the Scale of the initial positioning vectors given the way the "500" drifts down and left after it comes together unless that's intentional. If you're using variables for the height and width of that string, check that they're not being overwritten somehow (ie; by this sound routine). Or make sure you're actually setting them up/using them properly there.

[scotthuggins]

Awesome advice. But, yea the animation was intended - I'm scaling the text very high and then gradually low - and back to normal. Also the 500 gradually turning sideways. Believe it or not, that was intentional.

>If you're using variables for the height and width of that string, check that they're not being overwritten >somehow (ie; by this sound routine).

That very well could be it!

Thank you for responding.

[mountaingoat]

I have seen this kind of broken drawing with my games as well.

Usually there are some enormous vector lists that the hardware just has trouble drawing. Even though they are all ok one by one, the end of the list is just "too much" off screen.

If you are tweaking the height of the text you may accidentally create a text vector list that cannot be drawn.

I would disable the text scaling part and see if everything is cool.

(Also, I think Wait_Recall already sets DP to D0 so you could just remove that. Not that will cause a problem.)

The game looks pretty cool btw!

[scotthuggins]

>I would disable the text scaling part and see if everything is cool.

Nice suggestion, I got same result after trying that. I really think it's the sound code I am using in there for when you "pick up" the orb. If I comment out the code above, the sound effect is gone, but the screen stays very stable and the animation sequence looks good.

>(Also, I think Wait_Recall already sets DP to D0 so you could just remove that. Not that will cause a problem.)

Yep! commented out the "jsr dptod0" line and, yes, it still works the same way. I don't need it. Thanks. Saves extra cycles. Still, I feel I have tried everything to resolve this. I might try and just live with it while I finish all the other elements of the game play.

I will say this though: it's ABSOLUTELY the "jsr waitrcl" is 100% the problem. I comment that line out and the code runs ell - animation works and everything is fine - EXCEPT, there's no sound when you pick up the "orb" when I comment out the "jsr waitrcl".

Thanks for the reply - and I love this forum. Very helpful - seems like a lot of talent here.

I plan to post a binary of this when I get it close to being done.

[christophertumber]

Why are you calling Wait_Recall there? Usually it's only called once at the start or end of your main loop. Are you calling it multiple times and different places?

[mikiex]

like Chris says, wait_recall..Also double check you are not using an of the ram reserved for Bios sound functions, its right below $c880 where your ram for the game should start at $c880

[scotthuggins]

Hello!

I hopefully am not overstaying my welcome. But I've gotten farther with this, but still a minor glitch. The video hopefully will explain it. I do think I'm close. It's the sweeping sound I put in there with the animation is working well..... the first time I do it.

Video: youtu.be/bTYbf9m3x30

I know I am not clearing something out when player dies and then he tries (again) to pick up the ORB. Video shows and explains it better than me typing.

I triple checked and I really think I am resetting stuff correctly when player dies, but apparently not. I dumped the BIOS sound routine(s) and am using an approach the great Christopher Tumber showed in his awesome sound lecture (http://vectorgaming.proboards.com/thread/312/vectrex-sound-programming?page=2) - which is.... feeding data one byte at a time directly to the SOUND REGISTER.

; when you first pick up ORB (and only first time with the current ship you are playing with) -
; I put 55 into this ram variable - if you die and pick up ORB on second (and successive ships), the sound
; as shown in the video is just random at that point. Remains that way until I RE-LOAD the rom file.
lda #$55
sta SwpSnd ; I am starting at frequency 55 and decrementing this variable by 1 each frame during animation sequence

; here's where I am writing the byte to the sound register
lda SwpSnd ; again this thing starts at 55 and decrements down to 0
cmpa #$00 ; if we are done, stop playing the sweep sound
ble turnoff ; we are done at this point. Stop the sound
lda #$00 ;Modify Register 0
ldb SwpSnd ;Register will start at 55 and then each frame decrement to 0
jsr BYTE2SNDCHIP ;Set sound Register
dec SwpSnd ; again, decrement from 55 to zero is what gives me this sweep sound effect
jmp weHaveSnd

Any suggestions are GREATLY appreciated!

[mikiex]

I'd try as many things as possible to eliminate possible causes.
For instance what happens when you replace the fire sound with the orb pickup sound?

When you totally run out of ideas, I'd load up the DVE emulator in DOSBOX
and use it's debugging features.

(Or get PARAJVD)

[scotthuggins]

ParaJVD... yes. I have that (Franck released a newer version) and I will try that. Thanks for your reply. If I can get past this, I have a lot of ideas for the "actual" game play. Hopefully this will be resolved soon. But, all-in-all, I am learning a ton thru all of this.

Also, I will take just that part of the code and put it in a separate program all by itself - so it's very isolated.  Might make it easier to debug.

Hope your projects are going well.

[christophertumber]

If you eliminate (comment out, jump over) the explosion sound when the player dies, does it have any effect?

Maybe try clearing out all the sound registers after the player's death? ie; throw in a call to the BIOS routine clear_sound_chip $F272

It's either a case of:

- The sound registers are munged (ie; your effect only changes some of the registers and misses one that was changed by the player's death sound so that leftover register value is impacting your sound).

- A variable that controls the sound is wrong/overwritten (or isn't getting reinitialized properly).

I think the best approach is to try to narrow down which problem you have. I tend to think it's the first and you have white noise enabled on the channel that's playing the pick-up sound and/or you're not resetting the high byte of the frequency.

[mountaingoat]

Make sure that you are not overwriting the shadow registers of the sound chip.

Vec_Snd_Shadow equ $C800 ;Shadow of sound chip registers (15 bytes)

This could even happen is you have DP set to $C8 and you meant to set it to $C9 for some RAM access.

The fact that you have to reset to fix the sound also can indicate that SwpSnd is getting overwritten. So you could try to reset it every time before the sound effect - that way you can make sure that it is in fact getting overwritten by some random value.

I had issues like these when the RAM variable just in front of another one was written as a word (not a byte) and it was thrashing the one following it. You could check that.