Next version of bB

[Master_Programmer]

okay, the background is completely screwed up.

 

the playfield is white lines, with a yellow background.

 

even when i set it otherwise.

 

 

Hello?

i can't do a THING until i can fix this.....

[RevEng]

Hard to say with just the description. Why not post a .bas?

[Master_Programmer]

Hard to say with just the description. Why not post a .bas?

PSYCHO.BAS

[RevEng]

Ok, the yellow background is a variation on the bug I reported in this post.

 

In your case it happens to the background instead of the playfield because you're using "set kernel_option pfcolors".

 

[edit - Looks like it's a non-bug... nice catch ScumSoft!]

 

BTW, if you want the different playfield lines to show up you need to set DF0FRACINC, DF1FRACINC, DF2FRACINC, and DF3FRACINC to approximately how many scanlines each playfield line should take.

[ScumSoft]

batari DPC+ release blog

 

He mentioned setting the DataFetchers to control color changes.

[edit]Since this has been answered I'm removing the code example, to keep this area tidy and less scrolling required.

Edited June 15, 2011 by ScumSoft

[RevEng]

The stack command doesn't appear to change the stack pointer, unless I'm missing something.

 

Here's a test program...

 

set kernel DPC+

dim val1=a
dim val2=b

DF0FRACINC=1 : DF1FRACINC=1 : DF2FRACINC=1 : DF3FRACINC=1 : DF4FRACINC=1

bkcolors:
$00
end


rem ** push 0 onto stack position 200...
stack 200
val1=0
push val1


main

rem ** push "1" onto stack position 100...
stack 100
val2=1
push val2

rem ** pull stack position 200, which should be 0...
stack 200
pull val1

rem ** if the stack command works, the score shouldn't increase...
score=score+val1
drawscreen
goto main

 

...the score increases. (both in Stella and Harmony.)

[+batari]

The stack command doesn't appear to change the stack pointer, unless I'm missing something.

 

Here's a test program...

 

set kernel DPC+

dim val1=a
dim val2=a

DF0FRACINC=1 : DF1FRACINC=1 : DF2FRACINC=1 : DF3FRACINC=1 : DF4FRACINC=1

bkcolors:
$00
end


rem ** push 0 onto stack position 200...
stack 200
val1=0
push val1


main

rem ** push "1" onto stack position 100...
stack 100
val2=1
push val2

rem ** pull stack position 200, which should be 0...
stack 200
pull val1

rem ** if the stack command works, the score shouldn't increase...
score=score+val1
drawscreen
goto main

 

...the score increases. (both in Stella and Harmony.)

Yep, you are correct. I changed the fetcher used for the stack at some point but only updated the push and pull commands and not the stack command. I've just fixed it on my end.

[RevEng]

Thanks batari. One more for the day... it looks like the sprite multiplexer sometimes gets confused.

 

In the first example, the multiplexer deals with player1 and player2 as expected.

In the second example, the multiplexer gets mixed up with player1 and player2 at certain screen positions.

 

The only difference between the two examples is what happens when player2 hits the top of the screen - in the first example the sprite starts to move down. In the second example, it's immediately positioned at the bottom of the screen and starts moving up again.

 

multiplex1.bas

multiplex1.bas.bin

 

multiplex2.bas

multiplex2.bas.bin

[Byte Knight]

I suppose another way to get more variables would be to use some of the extra player#x and player#y variables and just not define the sprites...

 

Scratch this idea - I've been playing around with it and it doesn't work (completely). If there is value in player#y without a defined sprite you'll still flicker when another onscreen sprite's y value approaches the player#y value. However, you can use player#x as an extra variable without any flicker problems.

[+Random Terrain]

The latest version of Stella has been released, so now we won't have to use a special beta version just to run DPC+ programs:

 

http://www.atariage.com/forums/topic/182591-stella-34-released/

[RevEng]

Thanks batari. One more for the day... it looks like the sprite multiplexer sometimes gets confused.

Another bug, in addition to the multiplexer one...

 

It looks like Harmony doesn't like the last released bB beta. The playfield jumps and jitters more or less depending on the DF#FRACINC values. Using Stella the screen is completely stable.

 

This behavior wasn't present in the first beta.

 

A binary and basic that slowly steps through all of the DF#FRACINC values is attached.

 

Credit for finding this bug goes to ScumSoft.

 

UnstableWithHarmony.bas

UnstableWithHarmony.bas.bin

[ScumSoft]

It looks like the DFxFRACINC pointers get overwritten during the kernal setup, so it loses the values we specify for the playfield.

So a workaround is to rewrite the DFxFRACINC pointers every frame.

 

No more bouncing.

[+batari]

Here is the latest build. It includes bugfixes that I've noted as "fixed" in posts above. I've also added a few features, and I can't remember all of them, but among them are font support. To set a custom font, use const font= where is .21stcentury, alarmclock, handwritten, interrupted, retroputer, or whimsey.

 

Look in score_graphics.asm for a hint as to how to add your own font files and use them (and if you do, let me know.)

bb11c.zip

[ScumSoft]

My code compiled and runs just fine with the updates.

The playfield is looking correct now, although there is still a scanline offset present in the score region that affects the left health meter.

Tis but a minor issue

 

much obliged kind sir!

 

[edit]The issue crops up when pfscore2 has bit 1 set, then it shows a block that is one scanline taller than those to the left of it.

Edited June 15, 2011 by ScumSoft

[Byte Knight]

Thanks batari - nice to see the playfield ripple gone...

 

Any progress with the sprite multiplexer problems as mentioned in RevEng's post? If I get more than two sprites onscreen at once the multiplexer seems to lose track of which sprite is which and will often reset. I can send you my game code if you wish.

[+batari]

Thanks batari - nice to see the playfield ripple gone...

 

Any progress with the sprite multiplexer problems as mentioned in RevEng's post? If I get more than two sprites onscreen at once the multiplexer seems to lose track of which sprite is which and will often reset. I can send you my game code if you wish.

It only seems to happen if you attempt to move a sprite off-screen. I'm sure I can fix it when I get some time, but what would help me is if someone figured out the conditions that make it happen (such as a particular Y coordinate and sprite height.)

[ScumSoft]

Here is an example of a few current bugs I've come across while working on my game:

Control each with the joysticks

 

* No collisions work in an if...endif statement, stella shows we get stuck in a bmi inf loop

* Player0 horizontal screen wrap doesn't work by default, but it works fine for Player1

* If Player1 reaches the score Y offset = 168 then the harmony system crashes, stella just jumps a few frames and recovers. (Sprite height doesn't seem to matter)

 

[edit] forgot to attach the files

DPC+debug.bas

DPC+debug2011_06_03_165049.zip

Edited June 3, 2011 by ScumSoft

[+batari]

Here is an example of a few current bugs I've come across while working on my game:

Control each with the joysticks

 

* No collisions work in an if...endif statement, stella shows we get stuck in a bmi inf loop

This isn't a bug, you're using incorrect syntax. There is no endif statement.

* Player0 horizontal screen wrap doesn't work by default, but it works fine for Player1

Not a bug - player1 only wraps because values larger than 165 cannot be supported, so to prevent crashes, DPC+ wraps automatically. It is up to the programmer to wrap player0, and the missiles and ball.

* If Player1 reaches the score Y offset = 168 then the harmony system crashes, stella just jumps a few frames and recovers. (Sprite height doesn't seem to matter)

I'm still investigating the cause of this.

EDIT: Found the cause - fixing.

Edited June 4, 2011 by batari

[RevEng]

It only seems to happen if you attempt to move a sprite off-screen. I'm sure I can fix it when I get some time, but what would help me is if someone figured out the conditions that make it happen (such as a particular Y coordinate and sprite height.)

Triggering it seems to rely on a bunch of things...

 

First, one of the virtual sprites must reach *near* the top of the screen - near enough so it starts blinking because its close enough to the unused virtual sprites that are at Y=0 but aren't defined. The exact sprite height and the exact Y aren't critical, the blinking is.

 

Second, the virtual sprite needs to directly move to a Y coordinate greater than 128. While it's greater than 128 it takes on the virtual registers of another virtual sprite.

 

Third, if it doesn't move directly to a Y coordinate greater than 128, the bug disappears, even if the first and second circumstances happen again.

 

I'm sure this all sounds crazy, so I'm attaching a binary that cyclically triggers the first and second conditions. You can then move the joystick up to change the Y coordinate and avoid the Second condition. Once you've broken it, you can't make it reappear, even if you move the Y coordinate back to the previous value. Very strange.

 

multiplex3.bas

multiplex3.bas.bin

[+batari]

Second, the virtual sprite needs to directly move to a Y coordinate greater than 128. While it's greater than 128 it takes on the virtual registers of another virtual sprite.

This suggested to me something to do with signed arithmetic, and it was. I think it's fixed now.

 

Interestingly, the bug Scumsoft found at Y=168 also disappeared when this was fixed. I have no idea why.

 

Instead of creating a new version for this one, I'm just posting the file that changed: custom2.bin. This file goes in includes/custom/bin in the bB folder.

custom2.bin

[ScumSoft]

I read about the endif statement from RT's reference site, I understood it wrong

 

Thanks for the update

Edited June 4, 2011 by ScumSoft

[RevEng]

This suggested to me something to do with signed arithmetic, and it was. I think it's fixed now.

Looks fixed to me too!

 

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

 

Admittedly this can be avoided with some extra code on the bB side, but ideally it wouldn't happen at all.

 

As usual, basic and binary demonstrating the issue are attached.

 

player1corrupt0.bas

player1corrupt0.bas.bin

[+batari]

This suggested to me something to do with signed arithmetic, and it was. I think it's fixed now.

Looks fixed to me too!

 

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

 

Admittedly this can be avoided with some extra code on the bB side, but ideally it wouldn't happen at all.

 

As usual, basic and binary demonstrating the issue are attached.

 

player1corrupt0.bas

player1corrupt0.bas.bin

I thought that might happen. Each graphics buffer is 256 bytes, so if the Y position plus the height exceeds that, this will happen. Ideally, the graphics should wrap in each 256-byte area instead of spilling over to the next area. I'll look into doing that.

[+Random Terrain]

I'm glad you guys are quickly finding bugs and batari is quickly fixing them. The new version of bB will be ready in record time.

[Byte Knight]

This suggested to me something to do with signed arithmetic, and it was. I think it's fixed now.

 

Nice job - the multiplexer works great now!

 

I'm playing around with the missiles now and there's no way to control the missile color. Missile0 changes color depending on its y position and with a missileheight of 2 the two pixels are sometimes different colors. This occurs even when you make player0 one solid color. Missile1 has some issues too and will be the color of any multisprite at a similar y position. Any way to bring COLUP0 and COLUP1 variables back to control the color of the missiles?

 

Also, when you define missile0height it displays a missile of that size in the upper right corner of the screen. That missile will change colors as you change the player0 sprite's y position. Very strange...

 

Thanks!

Edited June 5, 2011 by Byte Knight