Master_Programmer Posted May 20, 2011 Share Posted May 20, 2011 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..... Quote Link to comment Share on other sites More sharing options...
RevEng Posted May 20, 2011 Share Posted May 20, 2011 Hard to say with just the description. Why not post a .bas? Quote Link to comment Share on other sites More sharing options...
Master_Programmer Posted May 20, 2011 Share Posted May 20, 2011 Hard to say with just the description. Why not post a .bas? PSYCHO.BAS Quote Link to comment Share on other sites More sharing options...
RevEng Posted May 20, 2011 Share Posted May 20, 2011 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. Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted May 20, 2011 Share Posted May 20, 2011 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted May 22, 2011 Share Posted May 22, 2011 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.) Quote Link to comment Share on other sites More sharing options...
+batari Posted May 22, 2011 Author Share Posted May 22, 2011 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. 2 Quote Link to comment Share on other sites More sharing options...
RevEng Posted May 22, 2011 Share Posted May 22, 2011 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 1 Quote Link to comment Share on other sites More sharing options...
Byte Knight Posted May 26, 2011 Share Posted May 26, 2011 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted May 30, 2011 Share Posted May 30, 2011 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/ 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 1, 2011 Share Posted June 1, 2011 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 1 Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted June 2, 2011 Share Posted June 2, 2011 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. 1 Quote Link to comment Share on other sites More sharing options...
+batari Posted June 3, 2011 Author Share Posted June 3, 2011 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 Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted June 3, 2011 Share Posted June 3, 2011 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Byte Knight Posted June 3, 2011 Share Posted June 3, 2011 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. Quote Link to comment Share on other sites More sharing options...
+batari Posted June 3, 2011 Author Share Posted June 3, 2011 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.) Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted June 3, 2011 Share Posted June 3, 2011 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
+batari Posted June 4, 2011 Author Share Posted June 4, 2011 (edited) 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 Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 4, 2011 Share Posted June 4, 2011 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 1 Quote Link to comment Share on other sites More sharing options...
+batari Posted June 4, 2011 Author Share Posted June 4, 2011 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 1 Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted June 4, 2011 Share Posted June 4, 2011 (edited) 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 Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 4, 2011 Share Posted June 4, 2011 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 1 Quote Link to comment Share on other sites More sharing options...
+batari Posted June 4, 2011 Author Share Posted June 4, 2011 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted June 5, 2011 Share Posted June 5, 2011 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. 1 Quote Link to comment Share on other sites More sharing options...
Byte Knight Posted June 5, 2011 Share Posted June 5, 2011 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.