Modifying Score Display?

[+Random Terrain]

set kernel DPC+

set tv ntsc

set kernel_options collision(playfield,player1)

 

Cybearg,

The set kernel_options collision...

is no longer needed as RevEng repaired the problem for that work-around, no?

 

If we find out that is true, I'll need to update the bB page.

[RevEng]

There was a bug in one of the official versions whereby it would mess up the screen if it wasn't used. That was fixed.

 

But if you want the first Y coordinate of a specific collision, you still use that kernel option.

[Omegamatrix]

Here is Version 3:

 

DPCplus_kernel_V3.zip

 

To do a split score you will need to use splitscore_2_4 as an option, dim splitKernelVar (this holds the bit you check to do the split score kernel), and set a const SPLIT_KERN_BIT to the bit you want to check. I made some bit definitions (BIT_0 to BIT_7).

 

 

There should be enough bytes now with another 8 or so to spare. One of the things that is not supported is pfscore with the splitscore_2_4 option. If you don't use splitscore_2_4 then pfscore is still available. I made warnings for all these things in the code.

 

 

Lets see if it will even compile now. If it doesn't please try commenting this out at the top:

;spit out some error messages and break the compile if the user hasn't set up the split score kernel.
;do this only on the second pass...
  if DASM_2ND_PASS
    ifconst splitscore_2_4
      ifconst pfscore
        ECHO "Error: pfscore can not be used with the splitscore_2_4 option"
        err
      endif
      ifnconst splitKernelVar
        ECHO "Error: Please Dim splitKernelVar = my_Var_Name to use the split score kernel"
        err
      endif
      ifnconst SPLIT_KERN_BIT
        ECHO "Error: Please const SPLIT_KERN_BIT = BIT_x to use the split score kernel"
        ECHO "       You can use 'BIT_0' to 'BIT_7'. for the bit."
        err
      endif
    endif
  endif
DASM_2ND_PASS = 1

And then uncomment this right below:

;splitKernelVar = $D1         ; This is the zp ram location you keep the flag for changing kernels.
;SPLIT_KERN_BIT = BIT_7       ; If this bit is set in "splitKernelVar" then the split score is drawn.

Then we will see where we are at.

[Cybearg]

Works perfectly, Omega! No tweaks required! Thanks so much!

 

What's great is that it offers a number of options. One could flicker the score and essentially display a 12-digit HUD if one wanted (probably not how I'll use it, but still!)

 

If I wanted to tweak the locations of the split variables such that, rather than being flush with the left and right of the screen, the digits were instead flush with the edge of the playfield space (i.e. left moves right 16 pixels and the right moves left 16 pixels), how would I make that adjustment? If it's really difficult to do then don't worry about it.

Edited October 21, 2014 by Cybearg

[Omegamatrix]

If I wanted to tweak the locations of the split variables such that, rather than being flush with the left and right of the screen, the digits were instead flush with the edge of the playfield space (i.e. left moves right 16 pixels and the right moves left 16 pixels), how would I make that adjustment?

You can't make that adjustment as the routine lies on the last two copies being wrapped around to the left side. However, I'm not saying this is impossible... just that with the limited space in BB it is not likely this could be imported while supporting the original kernel too. At the very minimum have to give up supporting both score kernels and just focus on this new one. Even then it would have to be written to see how much room it takes up.

 

Without space restrictions you would use some combination of RESPx and NUSIZx while the score is being drawn to make this work.

[Omegamatrix]

Here is an example of the shifted score that you mentioned. I simply used writes to NUSIZx to create the two digits on the far left (going to two copies wide, and wrapping the copies around the screen).

 

 

SplitScore_2_4_(ver2).zip

 

 

 

Incorporating it into BB wouldn't be too bad, but having this and the other kernel both supported might be tricky because of rom available. I would have to check but not tonight.

Edited October 21, 2014 by Omegamatrix

[Omegamatrix]

Also FYI, here is an example of a completely centred 3 digit split score. I wrote it originally for CAA. I'm doing some other things in the rom to get two colors.

 

 

wideScore.zip

[Cybearg]

Also FYI, here is an example of a completely centred 3 digit split score. I wrote it originally for CAA. I'm doing some other things in the rom to get two colors.

 

wideScore.png

 

wideScore.zip

Does this one also have the issue of not working as a flip between split and normal scoring?

 

For the time being, having the ability to flip between the normal score and the split score is more important to me than having the score lined up how I might prefer, but thanks for looking into it!

Edited October 21, 2014 by Cybearg

[Cybearg]

Eegh... I don't suppose another 12 bytes could be shaved off somewhere, Omega? There are 2 additional score definitions that I need to make the HUD work, but adding them in puts me just a few bytes short on bank 1.

 

Cutting goto __Bank_2 bank2 (the only line I have in bank 1) saves 18 bytes. Could that be simplified using direct ASM? __Bank_2 is the first definition of bank2, so I just need the game to make a bank switch to bank 2 after it has loaded the kernel. The default code generated from that line is:

 sta temp7
 lda #>(.__Bank_2-1)
 pha
 lda #<(.__Bank_2-1)
 pha
 lda temp7
 pha
 txa
 pha
 ldx #2
 jmp BS_jsr

Edited October 21, 2014 by Cybearg

[+Gemintronic]

Eegh... I don't suppose another 8 bytes could be shaved off somewhere, Omega? There are 2 additional score definitions that I need to make the HUD work, but adding them in puts me just 6 bytes short on bank 1.

 

Could you just remove some unneeded functions in std_kernel.asm to make up the difference, man?

Edited October 21, 2014 by theloon

[Cybearg]

 

Could you just remove some unneeded functions in std_kernel.asm to make up the difference, man?

I'm not using the standard kernel. Also, can you just start chopping stuff out of a kernel and have it still work?

[Cybearg]

Also, what do I need to do to allow for more than 10 digits in the score? Apparently just adding them to the end of the 0-9 definitions isn't enough. I've tried chopping out kernel11 of DPC+ (which I assume draws the 10th sprite) and it still seems to work, right up until I put in the extra two score values. Although it doesn't put me over for bytes, I just get a black screen when checking out the ROM.

 

EDIT: And yes, I have followed these instructions, but it doesn't seem to work.

 

EDIT AGAIN: Well, it DOES work if I copy exactly what that thread specifies and use the full 16 definitions. It doesn't seem to like only 12, though. Only 10 or 16 seem to work, even if I adjust the ORGs appropriately. Any idea what's up there?

Edited October 21, 2014 by Cybearg

[Omegamatrix]

I won't look at the more than 10 digits in the score just yet... First lets see if this works. This is version 4. I cut out a bunch of bytes of the kernel, but I am worried about page alignment for the data tables.

 

DPCplus_kernel_Ver4.zip

 

In this version you will hopefully have enough bytes to do most options, and the split score should now be shifted. pfscore is now available when you use the centred score.

 

 

This version is just a total shot in the dark. I would be surprised if it worked "as is" as I'm making many changes at once. But lets see where we are at. Can you please post a list file if it works? I would like to see the table alignments.

[Cybearg]

It seems you changed things up on me a little, Omega. Now it won't accept my kernel_option of splitscore_2_4 and kept saying it was unresolved, so I took it out of the kernel options and added const splitscore_2_4 = 1 instead.

 

Now I'm getting a different problem:

 

--- Unresolved Symbol List

LEFT74_11 0000 ???? (R )

LEFT74_12 0000 ???? (R )

free ram: 0

DPC free RAM= 603

37 bytes of ROM space left in bank 1

2584 bytes of ROM space left in bank 2

3665 bytes of ROM space left in bank 3

3919 bytes of ROM space left in bank 4

3919 bytes of ROM space left in bank 5

3919 bytes of ROM space left in bank 6

3367 bytes of ROM space left in graphics bank

Fatal assembly error: Source is not resolvable.

Errors were encountered during assembly.

Looking at your kernel, you do mention LEFT74_11 and LEFT74_12 in one place (below) but don't seem to assign them values. I have no idea what they do.

  IF splitscore_2_4
    lda    splitKernelVar    ; Omega - new code
    and    #SPLIT_KERN_BIT
    cmp    #SPLIT_KERN_BIT   ; carry now set/cleared for branching later

    ldx    #LEFT74_12
    stx    HMP1
    ldx    #LEFT74_11
    stx    HMP0

If I give LEFT74_11 and LEFT74_12 const values like so:

   const LEFT74_11 = 0
   const LEFT74_12 = 0

It compiles and seems to mostly work! There is a bit of weirdness when the split score bit is set, on the left side of the screen (a little red line):

And the numbers look a little wonky in their relation to one another when it's not set (as if their spacing is staggered):

Other than that, it seems to work. I've attached what you want in a .zip. (don't worry about the weird colors--that's my doing)

Split.zip

[Omegamatrix]

I know what's wrong. You are correct, it can't find those constants. I pasted them into the top of the file now. Here's V5:

 

 

DPCplus_kernel_Ver5.zip

 

 

Edit:

Fixed my post. I also found the problem with the centred score and fixed it.

Edited October 22, 2014 by Omegamatrix

[Cybearg]

Almost there! There's a problem with the second digit on the left. Otherwise, things look solid!

 

Splitv5.zip

[Omegamatrix]

Doh! Version 6... I used 'IF' instead of 'ifconst' for splitscore_2_4.

 

 

DPCplus_kernel_Ver6.zip

 

 

 

Should be good now.

 

 

 

Edit:

Okay seeing your last post not okay. Looks like the routine is working on the wrong cycle. Standby.

Edited October 22, 2014 by Omegamatrix

[Cybearg]

Doh! Version 6... I used 'IF' instead of 'ifconst' for splitscore_2_4.

 

 

DPCplus_kernel_Ver6.zip

 

 

 

Should be good now.

 

 

I don't actually see any difference... The bug with that one number is still there.

Splitv6.zip

[Omegamatrix]

V7:

 

DPCplus_kernel_Ver7.zip

 

 

This really needs to be checked on real hardware...

[Omegamatrix]

Also, splitscore_2_4 should be fixed. I mean you shouldn't have to define it as this anymore:

 

const splitscore_2_4 = 1

 

Just set it as a normal option.

[Cybearg]

Just tried it out in Stella and on my Harmony. Seems to work great! I don't see any issues in either, though granted I only have the playfield and sprite 0 on screen, but that shouldn't matter, should it?

 

Now, assuming it actually works as well as it appears to, what would I need to do to get only two extra score sprites in there (only need the extra two, not a whole six more)?

Splitv7.zip

[Omegamatrix]

Just tried it out in Stella and on my Harmony. Seems to work great! I don't see any issues in either, though granted I only have the playfield and sprite 0 on screen, but that shouldn't matter, should it?

 

Now, assuming it actually works as well as it appears to, what would I need to do to get only two extra score sprites in there (only need the extra two, not a whole six more)?

I took a quick look, and I think you only need to add the graphics in score_graphics.asm.

 

 

It looks like you don't have to mess with the ORG and RORG statements, probably because DPC+ is already hardcoded in size. Now accessing those I'm not sure. What I mean is if you might not be able to do math on the score if you are holding a value of A,B,C,D,E,F. That would screw the score up as BB is likely using BCD mode. So it depends on how you are manipulating the score data.

[Cybearg]

It looks like you don't have to mess with the ORG and RORG statements...

Ahh... That's probably why nothing seemed to happen when I modified the ORG and RORG statements and why it would only accept 10 or 16 values (probably an if statement in the kernel that only handles for 10 or 16).

 

What I mean is if you might not be able to do math on the score if you are holding a value of A,B,C,D,E,F. That would screw the score up as BB is likely using BCD mode. So it depends on how you are manipulating the score data.

Don't worry. I'll be putting aside 6 bytes, three for the actual score and three for the other stuff. I'll just switch between them so different data is shown. Handling the score should be easy, as should the value on the left since I only need to worry about one digit.

 

Is there a way to manipulate digits in BCD mode? For instance, let's say I have the right value at $b1 and $90 between the two lower bytes. I want to subtract 1 from 190 per cycle until it's just $b0 and $00. I'm sure I could do a little logic to check if $b1 & $0F is > 0 or not when $90 reaches $00 and then add $99 to the second score, but how do I do -1 in BCD in a way that will actually count down in BCD and not in hex?

[Omegamatrix]

In BB BCD mode (for 1 byte) you can only count down from $99 (99 in BCD) to 0, before it wraps back to $99.

 

 

So you should count down and exit using a BEQ, not BMI, because $99 already has bit 7 set (the negative bit).

 

 

Edit:

Corrected BB for BCD.

Edited October 22, 2014 by Omegamatrix

[Cybearg]

So you should count down and exit using a BEQ, not BMI, because $99 already has bit 7 set (the negative bit).

So I just have to subtract in BCD mode, such as:

dec variable = variable - 1
temp1 = variable2 & $0F
temp2 = variable2 & $F0
if !variable && temp1 then dec variable2 = temp1 - 1 + temp2
if !variable && !temp1 then variable = 0

... And so on?