Cybearg Posted March 6, 2013 Share Posted March 6, 2013 (edited) By "overscans" I assume you mean taking too many scanlines. I looked at your barebones demo and it is fine. The reason the first frame takes too long is that the timer hasn't been initialized yet. Sometimes when I write a game I initialize the timer once after the clear loop and before the first VSYNC to avoid a long delay. It wastes a few bytes, but gives a little better feel. I don't think you can do that in BB unless you hack the startup file. Anyhow, your barebones .bin ran, except everything was colored black. If you hit ALT and comma in Stella you can see the screen through the fixed color debugging. Apparently it's just me, then, because no one else mentioned anything about needing to initialize any timer. Even if it runs fine after that first bit, that first bit would ruin any game made with it, so how can I deal with that initial excess of scanlines? EDIT: The Space Rocks demo does work for me. it's an extremely impressive 2600 version of Asteroids, but I can't say I understood why I would randomly die all the time when nothing visibly hit me. Edited March 6, 2013 by Cybearg Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted March 6, 2013 Share Posted March 6, 2013 Apparently it's just me, then, because no one else mentioned anything about needing to initialize any timer. Even if it runs fine after that first bit, that first bit would ruin any game made with it, so how can I deal with that initial excess of scanlines? Nope, you misunderstood. You don't need to initialize it. It doesn't wreck the game. The game is running fine after the timer runs out the first time. This all happens well under a second, and probably less then a half second worse case (without doing any calculations). Quote Link to comment Share on other sites More sharing options...
iesposta Posted March 6, 2013 Share Posted March 6, 2013 I don't know what the heck is going on, but I can't compile/run your code. I just get a blank screen and Stella flickers the scanlines, thinking it's trying to render PAL (even if I enable your rem'd-out "set tv ntsc" code). I'm thinking that my batariBasic version is broken. ... I know it is frustrating. I went into this knowing this is alpha software. The 1.0 basic kernel didn't interest me due to the limitations. The ideas I was thinking up just were beyond the 1.0 kernel. Great things can be done with 1.0, but I wasn't clever enough to come up with "Princess Rescue (Super Mario 2600)," "L.E.M.," "Blue 21," "Seaweed Rescue." I have messed up my compile environment royally. Can't tell you for sure how I got it back, but I did. Sometimes using Visual Batari Basic and you have space in bank one and you add just one variable, it errors FOR NO EXPLAINABLE REASON, it compiles and runs fine, but it errors, so I save many copies and save after each change in case I need to go back. I currently have problems with the titlescreen editor and you haven't even got that far. I hate Windows OS. Only use it for this and Future Pinball. I did all of Satan's Hollow on my iPad connected VNC to my iMac running VMWare with Windows 7. Even copy binaries back to the iMac, then to my iPad, and run and test in Stella running on said iPad. I don't know why you have scan line problems. Many games have changing scan lines. Jr. PAC Man 2600 changes scan lines start of each maze. Throws my projector off synch and you lose a life. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 6, 2013 Share Posted March 6, 2013 Nope, you misunderstood. You don't need to initialize it. It doesn't wreck the game. The game is running fine after the timer runs out the first time. This all happens well under a second, and probably less then a half second worse case (without doing any calculations). But I've done a test game in DPC+ (still in early stages) and it has solid 262 scanlines except for the first frame, where it gets up to 270, yet the game (on the Harmony, not in Stella) has the playfield continuously bouncing. Since there is no flicker in the scanlines for any other time in the game, it must come from that first 270 scanlines in the very first frame, which does ruin the game because it's annoying and very distracting. Quote Link to comment Share on other sites More sharing options...
iesposta Posted March 6, 2013 Share Posted March 6, 2013 But I've done a test game in DPC+ (still in early stages) and it has solid 262 scanlines except for the first frame, where it gets up to 270, yet the game (on the Harmony, not in Stella) has the playfield continuously bouncing. Since there is no flicker in the scanlines for any other time in the game, it must come from that first 270 scanlines in the very first frame, which does ruin the game because it's annoying and very distracting. I've seen this bouncing too. Started happening in my Food Fight example. Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 6, 2013 Share Posted March 6, 2013 But I've done a test game in DPC+ (still in early stages) and it has solid 262 scanlines except for the first frame, where it gets up to 270, yet the game (on the Harmony, not in Stella) has the playfield continuously bouncing. Since there is no flicker in the scanlines for any other time in the game, it must come from that first 270 scanlines in the very first frame, which does ruin the game because it's annoying and very distracting. It doesn't come from the first excess of scanlines. A TV can receive utter gibberish, short frames, long frames, but the minute you start sending it full proper frames it will lock on to the sync signals and display the frames solidly. Try updating your harmony firmware to ensure an early version isn't the cause. (the firmware files located whereever the updater was unpacked) Stella doesn't emulate the cycles spent in ARM mode, so it's entirely possible that bouncing on real hardware is because you're using too many cycles in your game. Try disabling expensive chunks of code and see if things are more stable on real hardware. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 6, 2013 Share Posted March 6, 2013 (edited) It doesn't come from the first excess of scanlines. A TV can receive utter gibberish, short frames, long frames, but the minute you start sending it full proper frames it will lock on to the sync signals and display the frames solidly. Try updating your harmony firmware to ensure an early version isn't the cause. (the firmware files located whereever the updater was unpacked) Yeah, I updated the firmware and the problem is the same. Stella doesn't emulate the cycles spent in ARM mode, so it's entirely possible that bouncing on real hardware is because you're using too many cycles in your game. Try disabling expensive chunks of code and see if things are more stable on real hardware. Oh... So Stella's scanline count can't be trusted? :/ I'll try chopping things down and see. The reason I suspect the kernel is because, if I remove the DPC+ guts (that is, swap the DPC+ specific stuff for standard kernel stuff, such as for the colors), it works perfectly. The problem only comes when I use the DPC+ kernel. Were you playing the demo or release candidate? Yeah, the RC 7 or whichever. It was linked to from the top of the first page. Edited March 6, 2013 by Cybearg Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted March 6, 2013 Share Posted March 6, 2013 But I've done a test game in DPC+ (still in early stages) and it has solid 262 scanlines except for the first frame, where it gets up to 270, yet the game (on the Harmony, not in Stella) has the playfield continuously bouncing. Since there is no flicker in the scanlines for any other time in the game, it must come from that first 270 scanlines in the very first frame, which does ruin the game because it's annoying and very distracting. Nope, if it's bouncing then it's not from the first frame. You're on the wrong track there. If you continually have 270 scanlines and some bouncing then your code is spending too much time. I know you will say but I'm not even doing nothing yet, but that is what is really happening. So you got to track down why it is spending all that extra time and try to solve it. But these are not first frame issues, and more likely how you are trying to implement your code. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted March 6, 2013 Share Posted March 6, 2013 EDIT: The Space Rocks demo does work for me. it's an extremely impressive 2600 version of Asteroids, but I can't say I understood why I would randomly die all the time when nothing visibly hit me. Were you playing the demo or release candidate? Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 6, 2013 Share Posted March 6, 2013 Oh... So Stella's scanline count can't be trusted? :/ I'll try chopping things down and see. The reason I suspect the kernel is because, if I remove the DPC+ guts (that is, swap the DPC+ specific stuff for standard kernel stuff, such as for the colors), it works perfectly. The problem only comes when I use the DPC+ kernel. It can't be trusted with regard to DPC+ code timing. Stella is Awesome with a capital A, but the DPC+ stuff is pretty new and cycle accuracy isn't in there yet. The bB DPC+ kernel actually shares some of the overscan time with your own code, so there's less to go around than with previous kernels. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted March 6, 2013 Share Posted March 6, 2013 Oh... So Stella's scanline count can't be trusted? :/ When it comes to ARM code, then no. That's why you have to test DPC+ all the time on real hardware. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 6, 2013 Share Posted March 6, 2013 Nope, if it's bouncing then it's not from the first frame. You're on the wrong track there. If you continually have 270 scanlines and some bouncing then your code is spending too much time. I know you will say but I'm not even doing nothing yet, but that is what is really happening. So you got to track down why it is spending all that extra time and try to solve it. But these are not first frame issues, and more likely how you are trying to implement your code. No, only the first frame has 270 scanlines. It's 262 after that. I'll go back and fiddle to see if I can chop some stuff out to simplify it, though how am I to test whether or not it legitimately goes over scanlines if Stella's scanline readout isn't accurate? Well, I guess the answer to that is obvious--I'll have to test it in the Harmony each time. Drat. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted March 6, 2013 Share Posted March 6, 2013 Well, I guess the answer to that is obvious--I'll have to test it in the Harmony each time. Drat. I don't think Stella will be kilometers off here. You don't need to test every single change on real hardware. You can get buy with more occasional testing on real hardware. Some people (like RT) keep their Harmony connected to their computer and 2600 with a TV close by, and download the rom everytime the build. We're talking just a single image on the Harmony here. I prefer to just test now and then. I mean if it rolls now or rolls later than all you can do is try to optimize your code for speed (providing that it simply is taking too many cycles). If you can, see if you can still stick some of your code in VBLANK. I don't know if that is possible with the DPC+ kernel, but it would be some free time for you. Other methods could also involve using the little bit of VSYNC time that is available. Again, I don't know if the BB DPC+ kernel is doing anything fancy there. Just to give you an idea of this, the driving controller code I wrote for Heartbreak takes place in VSYNC. The BB kernel wasn't doing anything in there, so I stuck it there mainly because it wouldn't take away from you coding cycles. I don't recommend doing any updates to the TIA registers during VSYNC, but anything between the 6507 and RIOT should be fair game. VSYNC is still just a small time space though. The real underutilized time slot in BB is VBLANK. That's the bread and butter, or meat and potatoes. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted March 6, 2013 Share Posted March 6, 2013 Remember: gosubs are naughty no nos. Also, wouldn't a playfield with less resolution elevate issues going over cycle? Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 6, 2013 Share Posted March 6, 2013 (edited) Well, I cut basically everything out except for the background. It still bounces. I'm pretty sure that I shouldn't be over-cycling from just drawing a playfield. rem batari Basic Program rem created 2/27/2013 2:26:04 PM by Visual bB Version 1.0.0.565 rem ***************************************************** bank 1 rem ***************************************************** temp1 = temp1 include div_mul.asm set tv ntsc set kernel DPC+ set smartbranching on set optimization inlinerand set optimization speed set kernel_options collision(playfield,player1) rem DEFINE VARS HERE dim level = a goto levelinit bank2 rem ***************************************************** bank 2 rem ***************************************************** temp1 = temp1 levelinit gosub setlevel MAIN rem INSERT GAMEPLAY LOGIC maindraw gosub godraw if !switchreset then goto MAIN reboot godraw drawscreen : return thisbank setlevel on level goto level0 level0 DF0FRACINC = 32 DF1FRACINC = 32 DF2FRACINC = 32 DF3FRACINC = 32 DF4FRACINC = 64 DF6FRACINC = 64 bkcolors: $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $02 end pfcolors: $84 $94 $76 $66 $56 $48 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 end playfield: XXXX.XXXXXXXXXX..XXXXXXXXXXXXX.X XXX...XXXXXXXXX..XXXXXXX..XXXX.X XXX...XXXXXXXXX..XX...XX..XXX..X XX.....XXX...X...XX...XX..XXX... .X........................X.X... .X........................X..... ..........XXXXX................. ..........X.XXX................. ..........XXXXX...............X. ..........XXXXX...............X. ..........XX.XX...............X. ..........XXXXX..........XXX..X. ..........XXXXX..........X.X..X. ..........X.XXX.........XXXXXXXX ..........XXXXX....XXXX.XXXXXXXX XXXXXXXX..XXX.X....XX.X.XXXXXX.X X.XXXXXX..XXXXX....XXXX.XXXXXXXX XXXXXXXX..XXXXX..XXXXXX.XX.XXXXX XXXXXX.X..XXXXX..XXX.XX.XXXXXXXX XXXXXXXX..X.XXX..XXXXXX.XX...XXX XX.X.XXX..XXXXX..X.X..X.XX...X.X XXXX.XXX..XXXXX..X.XXXX.XX...XXX end scorecolors: $0C $0A $08 $06 $06 $08 $0A $0C end return thisbank rem ***************************************************** bank 3 rem ***************************************************** temp1 = temp1 rem ***************************************************** bank 4 rem ***************************************************** temp1 = temp1 rem ***************************************************** bank 5 rem ***************************************************** temp1 = temp1 rem ***************************************************** bank 6 rem ***************************************************** temp1 = temp1 rem ***************************************************** bank 7 rem ***************************************************** rem You may be able to place your TitleScreen here with no consequences Edited March 6, 2013 by Cybearg Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted March 6, 2013 Share Posted March 6, 2013 Well, I cut basically everything out except for the background. It still bounces. I'm pretty sure that I shouldn't be over-cycling from just drawing a playfield. Do you have a bin? Quote Link to comment Share on other sites More sharing options...
+Atarius Maximus Posted March 6, 2013 Author Share Posted March 6, 2013 If you can, see if you can still stick some of your code in VBLANK. I don't know if that is possible with the DPC+ kernel, but it would be some free time for you. I posted about this earlier in this thread. According to what I've read in other posts about DPC+ vblank must reside in bank 1 (RevEng I think posted about it). That leaves very little ROM space, only around 100 bytes free in bank 1 I believe. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 6, 2013 Share Posted March 6, 2013 (edited) And in case you want to blame the gosub for that flicker, that's not it, because this version cuts out the gosubs and just puts that code directly in line, and it still jumps in exactly the same way: rem batari Basic Program rem created 2/27/2013 2:26:04 PM by Visual bB Version 1.0.0.565 rem ***************************************************** bank 1 rem ***************************************************** temp1 = temp1 include div_mul.asm set tv ntsc set kernel DPC+ set smartbranching on set optimization inlinerand set optimization speed set kernel_options collision(playfield,player1) rem DEFINE VARS HERE dim level = a goto levelinit bank2 rem ***************************************************** bank 2 rem ***************************************************** temp1 = temp1 levelinit level0 DF0FRACINC = 32 DF1FRACINC = 32 DF2FRACINC = 32 DF3FRACINC = 32 DF4FRACINC = 64 DF6FRACINC = 64 bkcolors: $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $02 end pfcolors: $84 $94 $76 $66 $56 $48 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 end playfield: XXXX.XXXXXXXXXX..XXXXXXXXXXXXX.X XXX...XXXXXXXXX..XXXXXXX..XXXX.X XXX...XXXXXXXXX..XX...XX..XXX..X XX.....XXX...X...XX...XX..XXX... .X........................X.X... .X........................X..... ..........XXXXX................. ..........X.XXX................. ..........XXXXX...............X. ..........XXXXX...............X. ..........XX.XX...............X. ..........XXXXX..........XXX..X. ..........XXXXX..........X.X..X. ..........X.XXX.........XXXXXXXX ..........XXXXX....XXXX.XXXXXXXX XXXXXXXX..XXX.X....XX.X.XXXXXX.X X.XXXXXX..XXXXX....XXXX.XXXXXXXX XXXXXXXX..XXXXX..XXXXXX.XX.XXXXX XXXXXX.X..XXXXX..XXX.XX.XXXXXXXX XXXXXXXX..X.XXX..XXXXXX.XX...XXX XX.X.XXX..XXXXX..X.X..X.XX...X.X XXXX.XXX..XXXXX..X.XXXX.XX...XXX end scorecolors: $0C $0A $08 $06 $06 $08 $0A $0C end MAIN rem INSERT GAMEPLAY LOGIC maindraw drawscreen goto MAIN rem ***************************************************** bank 3 rem ***************************************************** temp1 = temp1 rem ***************************************************** bank 4 rem ***************************************************** temp1 = temp1 rem ***************************************************** bank 5 rem ***************************************************** temp1 = temp1 rem ***************************************************** bank 6 rem ***************************************************** temp1 = temp1 rem ***************************************************** bank 7 rem ***************************************************** rem You may be able to place your TitleScreen here with no consequences There's not much more I can cut out. jumpy.bin Edited March 6, 2013 by Cybearg Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted March 6, 2013 Share Posted March 6, 2013 I posted about this earlier in this thread. According to what I've read in other posts about DPC+ vblank must reside in bank 1 (RevEng I think posted about it). That leaves very little ROM space, only around 100 bytes free in bank 1 I believe. It should be possible to bankswitch at that point, do more code, and bankswitch back. Perhaps you would have to do some fancy things to get this to work in BB, but I really can't see it as being a fundamental limitation. Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 6, 2013 Share Posted March 6, 2013 Out of curiosity, is it any better without the "set kernel_options collision(playfield,player1)"? [edit] And yes, there should be tons of cycles left in your stripped down version. Atarius Maximus, you're right about vblank, but in recent versions of the DPC+ kernel there's no useful time left in vblank. It's a moot point to the bouncing issue, because he's not trying to use vblank time. Quote Link to comment Share on other sites More sharing options...
iesposta Posted March 6, 2013 Share Posted March 6, 2013 You don't need include div_mul.asm Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 6, 2013 Share Posted March 6, 2013 (edited) You don't need include div_mul.asm I had it in there due to calculations I was doing that involved dividing by ten. Cutting it out makes no difference. I tested it without that as well. Same bounce. Out of curiosity, is it any better without the "set kernel_options collision(playfield,player1)"? Let me test. EDIT: If I take it out, the playfield is a garbled mess. Edited March 6, 2013 by Cybearg Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted March 6, 2013 Share Posted March 6, 2013 The jumpy.bin displays 262 lines. Where does it bounce on you? Does it bounce on real hardware? Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted March 6, 2013 Share Posted March 6, 2013 I dun geddit. jumpy.bin runs at a rock solid 262 for me. I forget, is that a bad number? Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted March 6, 2013 Share Posted March 6, 2013 I dun geddit. jumpy.bin runs at a rock solid 262 for me. I forget, is that a bad number? Nope it's good. You want 262 for NTSC games on the 2600. 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.