Wabbit Killscreen

[glurk]

This is a HELP NEEDED post, if anyone wants a challenge...

 

OK, so over in the '2600 hacks' section I posted my hack of Apollo's "Wabbit", because I wanted to eliminate the black HMOVE bars and change some visual issues.  And I did that, but then the high score record holder pointed out that the game has a max score / killscreen.  I've found the culprit code, but it's a bit complex to fix.  Especially for me, since I'm not really a 2600 programmer anyways, I mostly do 8-bit ports...

 

SO... Here's the source code, mostly completed, search it for the word "fix" to find my initial try at fixing the issue.  I know it's not a real fix, but the calculation is too complex for me to figure out.

 

Also, many of the labels in the source may be wrong, I just made-up labels for some things....

 

wabbit.asm

 

Edited July 22, 2022 by glurk
EDIT: Add new upload, old one had VSYNC issue.

[glurk]

Bumping my own thread...  It's a darn shame that no one wants to even take a look at this.  I put an awful lot of work into this one, disassembling and labeling the whole source, fixing the HMOVE bars, fixing the carrot placement and 'wiggling' and a bunch of other visual improvements.

 

It's a really pretty game with a lot of potential, marred mostly by the difficulty ramp speedup / killscreen /scoring bug stuff.  I rarely ask for help, but if someone else (another set of eyes) could take a look at this, maybe it could get ironed out and we'd all have a really nice game...  One can hope, I guess.

[JetSetIlly]

On 7/21/2022 at 9:58 PM, glurk said:

This is a HELP NEEDED post, if anyone wants a challenge...

 

OK, so over in the '2600 hacks' section I posted my hack of Apollo's "Wabbit", because I wanted to eliminate the black HMOVE bars and change some visual issues.  And I did that, but then the high score record holder pointed out that the game has a max score / killscreen.  I've found the culprit code, but it's a bit complex to fix.  Especially for me, since I'm not really a 2600 programmer anyways, I mostly do 8-bit ports...

 

SO... Here's the source code, mostly completed, search it for the word "fix" to find my initial try at fixing the issue.  I know it's not a real fix, but the calculation is too complex for me to figure out.

 

Also, many of the labels in the source may be wrong, I just made-up labels for some things....

 

wabbit.asm 84.64 kB · 5 downloads

 

 

I'd like to take a closer look at this but I can't build it because of a missing "tia_constant.h" file. Is that something you've created yourself? I've not seen it before. It looks like it contains definitions for NO_REFLECT and similar values.

[glurk]

Hmm, it comes with DASM I think (?)  But here it is:

 

tia_constants.h

 

I have a preliminary "fix" in there, but from the testing I've been able to do, I've just made the "killscreen" come later, sigh....

[Tempest]

What is the actual cause of the kill screen?

[glurk]

1 hour ago, Tempest said:

What is the actual cause of the kill screen?

That's the question....  I can see that a calculation is made such that the rabbit-speed is a function of the hundreds value of the player's score.

 

It looks like 7 + (ScoreH x 3), then if greater than 8, subtract 8 and repeat.  Meanwhile, increasing some other value I assume is the speed value.  I modified it to do (Score x 2) instead of 3, but it only seems to delay the killscreen.

 

Some bug in the original due to inadequate testing I suppose.  It was probably simple to write, but it's difficult to figure out.  Hence why I'm asking for help.  It would probably be best to remove the calculation and use a table of values such that the difficulty increases, but never becomes unplayable or dies...  It's all a bit above my pay grade, LOL.  I was hoping someone else might be more familiar with what's going on...

 

 

[Tempest]

9 hours ago, glurk said:

That's the question....  I can see that a calculation is made such that the rabbit-speed is a function of the hundreds value of the player's score.

 

It looks like 7 + (ScoreH x 3), then if greater than 8, subtract 8 and repeat.  Meanwhile, increasing some other value I assume is the speed value.  I modified it to do (Score x 2) instead of 3, but it only seems to delay the killscreen.

Ah so it's something to do with the score and a bad calculation.  Thank you, that answers my question.

 

I'm not much of a programmer, but I've always had an interest in kill screens and what causes them.

[4ever2600]

Maybe, rename your title to "Need help with programming cause of wabbit killscreen".  Title is everything when it comes to people clicking or not. 

Edited July 25, 2022 by 4ever2600

[atarifan88]

2 hours ago, 4ever2600 said:

Maybe, rename your title to "Need help with programming cause of wabbit killscreen".  Title is everything when it comes to people clicking or not. 

I was thinking Wabbit Kiwlscween has a nice sound to it! ?

[4ever2600]

Killsqween... lol

[Fort Apocalypse]

@glurk tried reaching out to anyone listed here? They may not be following the group closely but might have a few minutes to help, possibly.

 

It also wouldn't hurt to tag the post with "disassembly", "disassemble", "wabbit", and/or whatever else might attract folks. Tags look annoying, but it seems like I've gotten more views on pages after adding them, as long as you add appropriate ones, and not too many.

Edited July 25, 2022 by Fort Apocalypse

[Thomas Jentzsch]

Can you describe the bug in a bit more detail? When does ist happen (e.g. score related) and what exactly does happen?

 

If the info has already been posted, a link would help too.

 

Just from looking at the code, I think there will be an overflow at around ~5200 points (depends on game selection).

 

BTW: The calculation here is quite odd, because it adds up a BCD value without the decimal flag enabled. Also, instead of subtracting 8, the result could be shifted right 3x and then simply decreased. 

Edited July 25, 2022 by Thomas Jentzsch

[glurk]

Ok, first off, games 7 & 8 are supposed to be the "Kid's games" at half speed.

 

The bug description I read (seems accurate) is:

 

• BUG: Kill screen – At 1,100, the rabbits start moving so erratically that they aren’t able to clear all the rows. At 1,300 points, the rabbits disappear, making it impossible to continue.

 

Here's a video:

 

https://www.youtube.com/watch?v=BJqGkpBIRq4

 

Also, I think it's generally agreed by most people that the game gets TOO hard, TOO fast...  It becomes impossible, so even if the bug in the code worked correctly, the game would still not ramp up in difficulty the way it should....

 

I bet you are onto something with the decimal flag, I didn't think of that one.  My goal is just to improve the game, make it play better, etc...

[Omegamatrix]

I think the best solution would be a look up table to make the ramp up better and cap it off. However I took a look and think this should prevent the kill screen. Note, I have not tested it though!

 

Replace this code:

L3184
    clc            
    adc     scoreH 
    adc     scoreH 
;   adc     scoreH ; ************************************* Commenting this out SEEMS to fix the score bug / killscreen.  Further investigation needed!!

 

With this code:

L3184
    LDY    scoreH
    CPY    #$10+1  ; 
    BCC    .normal
    ADC    #$30-1  ; correction routine, cap score high at $10*3 = $30, and have -1 because carry is set
    BNE    .done   ; always branch
    
.normal:           ; carry is clear
    ADC    scoreH
    ADC    scoreH
    ADC    scoreH
.done:

 

 

Again, smooth ramp up is not handled. I would also check for unintended negative consequences if the player wraps the score as the bug prevents them from doing so.

[Omegamatrix]

@glurk I just took another look and with a few changes it should be easy to slow the ramp up speed and have a lower top speed limit. Here is what I did, still untested but looks reasonable to me. Alternatively you could just re-write it to use a look up table.

 

WabbitHmoves
    lda     #HMOVE_L1    
    ldy     wabbitReflect1,x
    bne     .skipRight   
    lda     #HMOVE_R1    
.skipRight
    sta     wabbitHMD  
    
    
    
;new code
    LDA     scoreH          
    LSR                      ; half the ramp up speed! Add another LSR to quarter it.
    STA     wabbitHMDO       ; store temp value here. wabbitHMDO gets updated right after we use it so no harm 
    
    lda     #7    
    ldy     gameSelection
    cpy     #6  
    bcc     L3184
    lsr
L3184
;     clc            
;     adc     scoreH 
;     adc     scoreH 
; ;   adc     scoreH ; ************************************* Commenting this out SEEMS to fix the score bug / killscreen.  Further investigation needed!!


TOP_SPEED = $07              ; Speed Control. Valid range is $01 to $10, no $0A to $0F (BCD only)


    LDY    wabbitHMDO        ; scoreH / 2
    CPY    #TOP_SPEED+1      ; 
    BCC    .normal
    ADC    #(TOP_SPEED*3)-1  ; correction routine, cap score high at $10*3 = $30, and have -1 because carry is set
    BNE    .done             ; always branch
    
.normal:                     ; carry is clear
    ADC    wabbitHMDO        ; scoreH / 2
    ADC    wabbitHMDO
    ADC    wabbitHMDO
.done:




;code resumes
    ldy     #0   
    sty     wabbitHMDO 
L318f

[glurk]

@Omegamatrix  Hey thanks for coming out of "semi-retirement" to look at this, LOL.  I have applied your fix (as-is) from the above post and it seems to work out nicely, I tested it over a wide range of scores and it seems to ramp-up "just right."

 

So I'm going to clean up the code and post it and the binary over in the original hacks section post and call this one "case-closed!"  So thanks!!!

[Thomas Jentzsch]

For the game to become fair, not only the rabbits should become faster, but also the player. Currently, after a few rounds, you only defend the last carrot. Which is boring and tedious. 

Edited July 28, 2022 by Thomas Jentzsch