Jump to content
IGNORED

Next version of bB


batari

Recommended Posts

Each missile must share its color with its player on every scanline. This is a hardware limitation. If a missile is on a scanline where its player is not present, it should be possible to control the color. You won't be able to use COLUPx but a special function should work. Also, you will need to run the function on every frame or leftover player colors will accumulate.

Link to comment
Share on other sites

One other issue - if any of the virtual sprites get a Y coordinate that's large and offscreen, it corrupts player0's graphics.

I wrapped the values in a 256-byte window so this no longer happens. I also had to modify the sprite multiplexer to allow for sprites that have a y-value less than zero but wrap into the visible area.

 

The bug Scumsoft encountered also came back, and I think I fixed it right this time.

I'm playing around with the missiles now and there's no way to control the missile color.

I've added COLUM0 and COLUM1 variables to (sort of) control missile color. The colors won't work while the missile is on the same scanline as a player but it should work fine otherwise.

 

This patch has three files: DPCstartup.asm, DPCplusbB.h and custom/bin/custom2.bin. Unzip into the includes folder.

 

Some of this isn't tested very well so let me know if there are any issues.

bB11cPatch.zip

  • Like 2
Link to comment
Share on other sites

Thanks batari - the y coordinate wrapping is working great!

 

I was looking at the stack code some more. If I do the following...

 

dim sc0=score
dim sc1=score+1
dim sc2=score+2

sc0=$01 : sc1=$23 : sc2=$45
push sc0-sc2
pull sc0-sc2

 

...the score is displayed as $012345, which I'd expect from the documentation in your blog entry. But if I do the following...

 

dim sc0=score
dim sc1=score+1
dim sc2=score+2

sc0=$01 : sc1=$23 : sc2=$45
push sc0 sc1 sc2
pull sc0 sc1 sc2

 

...then the score is displayed as $452301.

 

Truth be told I prefer this behavior, as it's the expected LIFO behavior, and would rather see the first case work like...

 

push sc0-sc2
pull sc2-sc0

 

Since we're not abstracting the stack away, I think we may as well treat it like a stack all around.

 

Otherwise we wind up with an odd situation where the multivariable versions of push/pull look FIFO, and the individual variable versions are LIFO...

 

push f-h
pull f-h
rem restores the right value to each variable

push f
push g
push h
pull f
pull g
pull h
rem doesn't restore the right value to each variable

 

Thoughts?

Link to comment
Share on other sites

push sc0-sc2
pull sc0-sc2

 

 push sc0 sc1 sc2
pull sc0 sc1 sc2

 

Thoughts?

I think what I should do is match ARM assembly. For example, the analogous operations would be:

 STMFD SP!, {R0-R2}
 LDMFD SP!, {R0-R2}

This is exactly the same as this:

  STMFD SP!, {R0, R1, R2}
 LDMFD SP!, {R0, R1, R2}

You can't reorder the registers in a single STMFD/LDMFD operation - some assemblers don't allow it, and some do but the order the registers are specified doesn't change how they are pushed/pulled.

 

If you wish to pull individual values, ARM code would work like this:

  STMFD SP!, {R0-R2}
 LDMFD SP!, {R2}
 LDMFD SP!, {R1}
 LDMFD SP!, {R0}

It may be confusing, but if we're going to be consistent, it's best to match an existing standard.

 

I think this might mean that this is not working right:

 push sc0 sc1 sc2
pull sc0 sc1 sc2

Link to comment
Share on other sites

I've added COLUM0 and COLUM1 variables to (sort of) control missile color. The colors won't work while the missile is on the same scanline as a player but it should work fine otherwise.

 

This patch has three files: DPCstartup.asm, DPCplusbB.h and custom/bin/custom2.bin. Unzip into the includes folder.

 

Some of this isn't tested very well so let me know if there are any issues.

 

Missile1 works as you described, but missile0 seems to take on all sorts of different colors even if player0 is offscreen.

Link to comment
Share on other sites

It seems player(1-9) will flicker even if there aren't any conflicting sprites on the same scanline. They only have to be close by but not overlapping.

It takes a few scanlines to reposition a sprite. I forget how many but I think it's two or three.

 

Another flicker issue is triggered when you have two or more sprites on the same scanline, and then disable the extra sprites by setting their player(1-9) to $00.

The enabled sprite will then flicker as if the extra sprites were still being drawn since the coordinates for the extra sprites are still set to the same scanline area.

 

Workaround this by setting the position of player(1-9) off screen, but then you run into the X position issue as mentioned in RevEng's post, where the other sprites position themselves to the offscreen sprites X position.

 

Also (a stella issue) using player3 causes an ARM crash in stella, but works fine on the Harmony cart.

 

[edit]Comment out player3's graphic setup to avoid the stella ARM crash.

To recreate the flicker issue change the graphics on one of the numbers to $00 and then move one of the other numbers over the same region the now disabled number would reside at, the shown number will flicker even though the other number should be disabled. Press fire to cycle through the numbers.

 

Is there a separate method to disable the extra player units completely so that the multiplexer doesn't try and order them?

If you want to disable a sprite, do not set its Y to zero, but around 200, so it is off-screen. Zero will probably never work right since it is on-screen.

 

I'll look into the Stella issue.

Link to comment
Share on other sites

I don't get the Stella crash. Are you using Stella 3.4 or the beta version?

 

Also, I think it takes 5 scanlines to reposition a player. The reasons for this are a bit complicated but it has to do with the tight timing of the asymmetric playfield and the fact that this is a 2LK even though it has single-line resolution players.

Link to comment
Share on other sites

I am using Stella 3.4 X64 on Win7 X64 Ultimate, building with the latest DPC+ kernel fixes on a fresh install of Visual bB.

 

So setting the graphics for virtual sprites to $00 merely hide them and not disable? Makes sense then, So once they are used there is no way to shut them off besides hiding them off screen?

Link to comment
Share on other sites

So setting the graphics for virtual sprites to $00 merely hide them and not disable? Makes sense then, So once they are used there is no way to shut them off besides hiding them off screen?

 

No other way that I can see... This is where the stack function comes in handy - you can push the player#y value to the stack once it's offscreen, set the player#y value to 200, then pull the player#y value when it's back on screen. That way you don't have to assign one of your precious 26 variables to player#y.

Link to comment
Share on other sites

I am using Stella 3.4 X64 on Win7 X64 Ultimate, building with the latest DPC+ kernel fixes on a fresh install of Visual bB.

 

So setting the graphics for virtual sprites to $00 merely hide them and not disable? Makes sense then, So once they are used there is no way to shut them off besides hiding them off screen?

Yes, you have to move them off-screen.

 

Can you post the binary that gives you crashes? There may be some difference between your bB files and mine.

Link to comment
Share on other sites

Quite honestly, somehow its managed to fix itself. I've simply hibernated my PC for the night and upon resuming it today the code compiles and works fine.

 

Thankfully it's not something that needs corrected on your ends.

 

Sorry! False alarm everyone.

Nothing to see here, move along!

Link to comment
Share on other sites

I've noticed that fixed-point operation seem to be natively supported in the kernel, but that sub-pixeling for sprite updates isn't (i.e. incrementing a sprite's position in fractional amounts produces a "jerky" movement, rather than a smooth one). Is this something that might be included in the final version?

Link to comment
Share on other sites

I've noticed that fixed-point operation seem to be natively supported in the kernel, but that sub-pixeling for sprite updates isn't (i.e. incrementing a sprite's position in fractional amounts produces a "jerky" movement, rather than a smooth one). Is this something that might be included in the final version?

 

I realized this probably wasn't the best explanation. Basically, it seems like fixed-point addition and subtraction works fine, but sprites update only at whole number intervals. So if I incremented a sprite's x position by 0.125 every drawscreen, it would only update visually on drawscreens where the value is equal to a whole number (i.e. 1.0, 2.0, 3.0...)

 

Basically, I was trying to see if I could port my work on Charge to the DPC+ kernel, which requires smooth acceleration of sprite objects.

 

Thanks!

J

Link to comment
Share on other sites

I realized this probably wasn't the best explanation. Basically, it seems like fixed-point addition and subtraction works fine, but sprites update only at whole number intervals. So if I incremented a sprite's x position by 0.125 every drawscreen, it would only update visually on drawscreens where the value is equal to a whole number (i.e. 1.0, 2.0, 3.0...)

 

Basically, I was trying to see if I could port my work on Charge to the DPC+ kernel, which requires smooth acceleration of sprite objects.

 

Thanks!

J

 

Hey jrok,

 

That's great that you're still working on your game.

 

Thanks for the info about the fixed-point addition and subtraction - I've been turning a bit on and off every other frame to make enemies slow down in the game I'm working on. So, more variables saved!

Link to comment
Share on other sites

  • 2 weeks later...

Because BKcolors is controlled by the fractional pointers, there is no way to change just the scorecolor without having wasteful tables such as:

 

setting DF6FRACINC to 64

GreenScore
bkcolors:
$00	;01
$00	;02
$00	;03
$00	;04
$00	;05
$00	;06
$00	;07
$00	;08
$00	;09
$00	;10
$00	;11
$00	;12
$00	;13
$00	;14
$00	;15
$00	;16
$00	;17
$00	;18
$00	;19
$00	;20
$00	;21
$00	;22
$C0 ;Score region
end
return

BlueScore
bkcolors:
$00	;01
$00	;02
$00	;03
$00	;04
$00	;05
$00	;06
$00	;07
$00	;08
$00	;09
$00	;10
$00	;11
$00	;12
$00	;13
$00	;14
$00	;15
$00	;16
$00	;17
$00	;18
$00	;19
$00	;20
$00	;21
$00	;22
$70 ;Score region
end

 

Isn't their an easier method to do this? This also causes a small bkcolor strip of the last set bkcolor to show in the top right of the screen and I can't get rid of it.

Edited by ScumSoft
Link to comment
Share on other sites

  • 2 weeks later...

While developing EggVenture I've built a small wish list on features I would have found most useful.

 

  • I'd say 75% of the code I've written in my game pertains to decided what collided with what for the virtual sprites. Things would be much nicer and spacier in my code if I were able to use "if collision(player0,player2) then yada yada yada" instead of checking positions all the time. I don't know how we might manage this, that's why this is a wish list.
  • I find that having to specify player data (per) player is costly, say for instance I wanted to use my EGG graphics for player2 and player3 in the same playfield, I can't find a method to reference a single EGG definition for both sprites, instead you must specify it individually for each player.
    player2:
    (insert egg gfx data)
    end
    player3:
    (insert egg gfx data)
    end
    This is a double definition to single sprite data. It greatly limits how many of the same objects I want to use in a single playfield.
    If instead I were able to say player2 = EGG :player3 = EGG and have the pointers set appropriately this would alleviate this issue and free up rom space.
  • I know the language is BASIC(pun intended), but I would LOVE to clean up the code a bit with incremental operators such as player0y += 1 or player0y++
    and the decremental counters -= and --, any plans to incorporate them?

Once again I'm not sure how cumbersome this may be to implement on your end, but it would greatly simplify certain conditions that I've encountered which made me wish for such things.

Edited by ScumSoft
Link to comment
Share on other sites

  • I find that having to specify player data (per) player is costly...

One of my on-again-off-again projects is a shooter, with lots of enemies sharing different image data. I wrote the following subroutine for copying the current player0 pointers to any of the other players.

 

It's 90 bytes, so it may not pay off for your egg example. In my case I also have enemy animations, so it's a big win. And even if you don't gain much, you do trade away regular rom for graphics bank rom, where you're likely to have less space.

 

copyp0
rem ** copies the player0 graphic and colors to player1+temp1
asm
; *** copy the graphic...
ldy temp1
lda pdhi,y
sta DF0HI
lda pdlo,y
sta DF0LOW

lda player0pointerlo
sta DF0WRITE
lda player0pointerhi
sta DF0WRITE

; *** copy the height...
lda player0height
sta player1height,y

; *** copy the colors...
lda pclo,y
sta DF0LOW
lda pchi,y
sta DF0HI

lda player0color
sta DF0WRITE
lda player0color+1
sta DF0WRITE

RETURN

pdlo
BYTE #<(playerpointers+0),#<(playerpointers+2),#<(playerpointers+4)
BYTE #<(playerpointers+6),#<(playerpointers+,#<(playerpointers+10)
BYTE #<(playerpointers+12),#<(playerpointers+14),#<(playerpointers+16)
pdhi
BYTE #(>(playerpointers+0))&$0F,#(>(playerpointers+2))&$0F
BYTE #(>(playerpointers+4))&$0F,#(>(playerpointers+6))&$0F
BYTE #(>(playerpointers+&$0F,#(>(playerpointers+10))&$0F
BYTE #(>(playerpointers+12))&$0F,#(>(playerpointers+14))&$0F
BYTE #(>(playerpointers+16))&$0F
pclo
BYTE #<(playerpointers+18),#<(playerpointers+20),#<(playerpointers+22)
BYTE #<(playerpointers+24),#<(playerpointers+26),#<(playerpointers+28)
BYTE #<(playerpointers+30),#<(playerpointers+32),#<(playerpointers+34)
pchi
BYTE #(>(playerpointers+18))&$0F,#(>(playerpointers+20))&$0F
BYTE #(>(playerpointers+22))&$0F,#(>(playerpointers+24))&$0F
BYTE #(>(playerpointers+26))&$0F,#(>(playerpointers+28))&$0F
BYTE #(>(playerpointers+30))&$0F,#(>(playerpointers+32))&$0F
BYTE #(>(playerpointers+34))&$0F
end

This is the first quick-and-dirty implementation - please post back any improvements!

  • Like 1
Link to comment
Share on other sites

  • I find that having to specify player data (per) player is costly...

One of my on-again-off-again projects is a shooter, with lots of enemies sharing different images. I wrote the following subroutine for copying the current player0 pointers to any of the other players.

 

It's 90 bytes, so it may not pay off for your egg example. In my case I also have enemy animations, so it's a big win. And even if you don't gain much, you do trade away regular rom for graphics bank rom, where you're likely to have less space.

 

copyp0
rem ** copies the player0 graphic and colors to player1+temp1
asm
; *** copy the graphic...
ldy temp1
lda pdhi,y
sta DF0HI
lda pdlo,y
sta DF0LOW

lda player0pointerlo
sta DF0WRITE
lda player0pointerhi
sta DF0WRITE

; *** copy the height...
lda player0height
sta player1height,y

; *** copy the colors...
lda pclo,y
sta DF0LOW
lda pchi,y
sta DF0HI

lda player0color
sta DF0WRITE
lda player0color+1
sta DF0WRITE

RETURN

pdlo
BYTE #<(playerpointers+0),#<(playerpointers+2),#<(playerpointers+4)
BYTE #<(playerpointers+6),#<(playerpointers+,#<(playerpointers+10)
BYTE #<(playerpointers+12),#<(playerpointers+14),#<(playerpointers+16)
pdhi
BYTE #(>(playerpointers+0))&$0F,#(>(playerpointers+2))&$0F
BYTE #(>(playerpointers+4))&$0F,#(>(playerpointers+6))&$0F
BYTE #(>(playerpointers+)&$0F,#(>(playerpointers+10))&$0F
BYTE #(>(playerpointers+12))&$0F,#(>(playerpointers+14))&$0F
BYTE #(>(playerpointers+6))&$0F
pclo
BYTE #<(playerpointers+18),#<(playerpointers+20),#<(playerpointers+22)
BYTE #<(playerpointers+24),#<(playerpointers+26),#<(playerpointers+28)
BYTE #<(playerpointers+30),#<(playerpointers+32),#<(playerpointers+34)
pchi
BYTE #(>(playerpointers+18))&$0F,#(>(playerpointers+20))&$0F
BYTE #(>(playerpointers+22))&$0F,#(>(playerpointers+24))&$0F
BYTE #(>(playerpointers+26))&$0F,#(>(playerpointers+28))&$0F
BYTE #(>(playerpointers+30))&$0F,#(>(playerpointers+32))&$0F
BYTE #(>(playerpointers+34))&$0F
end

 

This is the first quick-and-dirty implementation - please post back any improvements! :)

The ability to assign multiple players to a single set of sprite data is another feature I neglected to mention. It is incomplete at the moment but so far, to assign the same data to players 1-4, use player1-4: for the declaration.

 

It apparently only assigns player#height for the first player. Also, it does not yet work for assigning the same colors to multiple players (I will use player1-4color: for that). Since this is a feature you guys probably want, I'll look into getting it going properly.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...