274 replies to this topic

[Master_Programmer]

Master_Programmer, on Wed Apr 27, 2011 7:25 PM, said:

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]

RevEng, on Fri May 20, 2011 11:51 AM, said:

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

Attached Files

•  PSYCHO.BAS   3.43K   84 downloads

[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 by ScumSoft, Tue Jun 14, 2011 9:31 PM.

[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]

RevEng, on Sun May 22, 2011 1:32 PM, said:

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   890bytes   64 downloads
 multiplex1.bas.bin   32K   86 downloads

 multiplex2.bas   863bytes   60 downloads
 multiplex2.bas.bin   32K   82 downloads

[Byte Knight]

Byte Knight, on Fri May 13, 2011 10:59 PM, said:

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....la-34-released/

[RevEng]

RevEng, on Sun May 22, 2011 5:39 PM, said:

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   1.03K   69 downloads
 UnstableWithHarmony.bas.bin   32K   83 downloads

[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=[font name] where [font name] 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.)

Attached Files

•  bb11c.zip   192.33K   95 downloads

[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 by ScumSoft, Tue Jun 14, 2011 9:35 PM.

[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]

Byte Knight, on Fri Jun 3, 2011 10:39 AM, said:

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

Attached Files

•  DPC+debug.bas   2.92K   70 downloads
•  DPC+debug2011_06_03_165049.zip   4.54K   84 downloads

Edited by ScumSoft, Fri Jun 3, 2011 5:56 PM.

[batari]

ScumSoft, on Fri Jun 3, 2011 5:50 PM, said:

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.

Quote

* 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.

Quote

* 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 by batari, Fri Jun 3, 2011 8:37 PM.

[RevEng]

batari, on Fri Jun 3, 2011 12:30 PM, said:

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   1.06K   70 downloads
 multiplex3.bas.bin   32K   76 downloads

[batari]

RevEng, on Fri Jun 3, 2011 9:33 PM, said:

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.

Attached Files

•  custom2.bin   1.39K   98 downloads

[ScumSoft]

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

Thanks for the update

Edited by ScumSoft, Fri Jun 3, 2011 11:36 PM.

[RevEng]

batari, on Fri Jun 3, 2011 11:09 PM, said:

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   821bytes   69 downloads
 player1corrupt0.bas.bin   32K   71 downloads

[batari]

RevEng, on Sat Jun 4, 2011 4:55 PM, said:

batari, on Fri Jun 3, 2011 11:09 PM, said:

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   821bytes   69 downloads
 player1corrupt0.bas.bin   32K   71 downloads

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]

Quote

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 by Byte Knight, Sat Jun 4, 2011 10:10 PM.