Jump to content

Photo

Next version of bB


274 replies to this topic

#151 Master_Programmer OFFLINE  

Master_Programmer

    Moonsweeper

  • 280 posts
  • Beep Boop, son, Beep Boop.
  • Location:Appleoosa

Posted Fri May 20, 2011 10:26 AM

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

#152 RevEng ONLINE  

RevEng

    River Patroller

  • 3,275 posts
  • bit player
  • Location:Canada

Posted Fri May 20, 2011 11:51 AM

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

#153 Master_Programmer OFFLINE  

Master_Programmer

    Moonsweeper

  • 280 posts
  • Beep Boop, son, Beep Boop.
  • Location:Appleoosa

Posted Fri May 20, 2011 2:59 PM

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

Attached Files



#154 RevEng ONLINE  

RevEng

    River Patroller

  • 3,275 posts
  • bit player
  • Location:Canada

Posted Fri May 20, 2011 3:55 PM

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.

#155 ScumSoft OFFLINE  

ScumSoft

    Moonsweeper

  • 348 posts
  • Location:Polysorbate 60

Posted Fri May 20, 2011 3:58 PM

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.


#156 RevEng ONLINE  

RevEng

    River Patroller

  • 3,275 posts
  • bit player
  • Location:Canada

Posted Sun May 22, 2011 1:32 PM

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

#157 batari OFFLINE  

batari

    )66]U('=I;B$*

  • Topic Starter
  • 6,464 posts
  • begin 644 contest

Posted Sun May 22, 2011 1:57 PM

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.

#158 RevEng ONLINE  

RevEng

    River Patroller

  • 3,275 posts
  • bit player
  • Location:Canada

Posted Sun May 22, 2011 5:39 PM

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.

Attached File  multiplex1.bas   890bytes   85 downloads
Attached File  multiplex1.bas.bin   32KB   108 downloads

Attached File  multiplex2.bas   863bytes   82 downloads
Attached File  multiplex2.bas.bin   32KB   103 downloads

#159 Byte Knight OFFLINE  

Byte Knight

    Dragonstomper

  • 564 posts
  • Robinett Rules!
  • Location:Waconia, MN

Posted Wed May 25, 2011 6:25 PM

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.

#160 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 24,756 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Mon May 30, 2011 5:43 AM

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/

#161 RevEng ONLINE  

RevEng

    River Patroller

  • 3,275 posts
  • bit player
  • Location:Canada

Posted Wed Jun 1, 2011 4:48 PM

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. :thumbsup:

Attached File  UnstableWithHarmony.bas   1.03KB   93 downloads
Attached File  UnstableWithHarmony.bas.bin   32KB   104 downloads

#162 ScumSoft OFFLINE  

ScumSoft

    Moonsweeper

  • 348 posts
  • Location:Polysorbate 60

Posted Wed Jun 1, 2011 6:00 PM

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.

#163 batari OFFLINE  

batari

    )66]U('=I;B$*

  • Topic Starter
  • 6,464 posts
  • begin 644 contest

Posted Thu Jun 2, 2011 8:34 PM

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



#164 ScumSoft OFFLINE  

ScumSoft

    Moonsweeper

  • 348 posts
  • Location:Polysorbate 60

Posted Thu Jun 2, 2011 9:20 PM

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 :D

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.


#165 Byte Knight OFFLINE  

Byte Knight

    Dragonstomper

  • 564 posts
  • Robinett Rules!
  • Location:Waconia, MN

Posted Fri Jun 3, 2011 10:39 AM

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.

#166 batari OFFLINE  

batari

    )66]U('=I;B$*

  • Topic Starter
  • 6,464 posts
  • begin 644 contest

Posted Fri Jun 3, 2011 12:30 PM

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

#167 ScumSoft OFFLINE  

ScumSoft

    Moonsweeper

  • 348 posts
  • Location:Polysorbate 60

Posted Fri Jun 3, 2011 5:50 PM

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 :P

Attached Files


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


#168 batari OFFLINE  

batari

    )66]U('=I;B$*

  • Topic Starter
  • 6,464 posts
  • begin 644 contest

Posted Fri Jun 3, 2011 8:32 PM

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


#169 RevEng ONLINE  

RevEng

    River Patroller

  • 3,275 posts
  • bit player
  • Location:Canada

Posted Fri Jun 3, 2011 9:33 PM

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.

Attached File  multiplex3.bas   1.06KB   91 downloads
Attached File  multiplex3.bas.bin   32KB   97 downloads

#170 batari OFFLINE  

batari

    )66]U('=I;B$*

  • Topic Starter
  • 6,464 posts
  • begin 644 contest

Posted Fri Jun 3, 2011 11:09 PM

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



#171 ScumSoft OFFLINE  

ScumSoft

    Moonsweeper

  • 348 posts
  • Location:Polysorbate 60

Posted Fri Jun 3, 2011 11:31 PM

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

Thanks for the update

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


#172 RevEng ONLINE  

RevEng

    River Patroller

  • 3,275 posts
  • bit player
  • Location:Canada

Posted Sat Jun 4, 2011 4:55 PM

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

Looks fixed to me too! :thumbsup:

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.

Attached File  player1corrupt0.bas   821bytes   90 downloads
Attached File  player1corrupt0.bas.bin   32KB   92 downloads

#173 batari OFFLINE  

batari

    )66]U('=I;B$*

  • Topic Starter
  • 6,464 posts
  • begin 644 contest

Posted Sat Jun 4, 2011 5:42 PM


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

Looks fixed to me too! :thumbsup:

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.

Attached File  player1corrupt0.bas   821bytes   90 downloads
Attached File  player1corrupt0.bas.bin   32KB   92 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.

#174 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 24,756 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sat Jun 4, 2011 6:53 PM

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.

#175 Byte Knight OFFLINE  

Byte Knight

    Dragonstomper

  • 564 posts
  • Robinett Rules!
  • Location:Waconia, MN

Posted Sat Jun 4, 2011 9:52 PM

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.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users