+Random Terrain Posted June 2, 2012 Share Posted June 2, 2012 Seems like it would, but I'm asking just to make sure. Does const pfres=31 take up more time than const pfres=23? I moved up to const pfres=31 to see what would happen and now my program is going over 262. Seems like the larger resolution is stealing time from my bB code. If it's true that larger resolutions take more time, can anything worth playing be done using const pfres=31? Looks like I'm stuck with const pfres=23 or smaller. Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 4, 2012 Share Posted June 4, 2012 It shouldn't mean less time for other things. If it's going over 262 than its a bug, either in your code or in bB. Are you using playfield: to set things up? I'm getting some glitches with a test program that suggests it's overwriting memory elsewhere, but I don't think I updated to the last beta so it may alread be fixed. Does this display the usual score=000000 for you? const pfres=16 scorecolor=$0f playfield: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX end mainloop COLUPF=$18 drawscreen goto mainloop Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted June 4, 2012 Author Share Posted June 4, 2012 Here's what it looks like: I was using the beta version of bB, but it wasn't acting right, so I switched back to an older version of bB. I'm not sure what version it is or what has been fixed. I think it is the one that is in the 64-bit folder in the VbB thread. In case you want to know what was messing up, check out the following program. Move the joystick up and see what happens. That's how it's supposed to work: ex_scrolling_2012y_05m_21d_1655t.bin Now do the same with this one and notice the odd changes that are happening on the screen: ex_scrolling_2012y_06m_04d_0152t.bin Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted June 4, 2012 Author Share Posted June 4, 2012 Thanks. Here's what it looks like: I was using the beta version of bB, but it wasn't acting right, so I switched back to an older version of bB. I'm not sure what version it is or what has been fixed. I think it is the one that is in the 64-bit folder in the VbB thread. (I switched back to the beta version just to try your test program, but I got the same result.) In case you want to know what was messing up, check out the following program. Move the joystick up and see what happens. That's how it's supposed to work: ex_scrolling_2012y_05m_21d_1655t.bin Now do the same with this one and notice the odd changes that are happening on the screen: ex_scrolling_2012y_06m_04d_0152t.bin The second one, compiled with the beta version, seems to randomly add and delete playfield pixels as the screen scrolls up. Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 4, 2012 Share Posted June 4, 2012 I get the same result as you, so I think its likely a bB bug. It seems the address used for the playfield is wrong if pfres is used - I think having some of your variables overwritten caused your scanline count problems. I expect this happened when batari added "mirror playfield" capability to the standard kernel. I'll report it in the bug thread later. (Posting from a cell right now) 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 4, 2012 Share Posted June 4, 2012 Also worth mentioning that if you're scrolling, then a large pfres CAN cause a scanline issue, since scrolling involves copying the playfield memory. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted June 4, 2012 Author Share Posted June 4, 2012 I get the same result as you, so I think its likely a bB bug. It seems the address used for the playfield is wrong if pfres is used - I think having some of your variables overwritten caused your scanline count problems. I expect this happened when batari added "mirror playfield" capability to the standard kernel. I'll report it in the bug thread later. (Posting from a cell right now) Thanks. Also worth mentioning that if you're scrolling, then a large pfres CAN cause a scanline issue, since scrolling involves copying the playfield memory. In the version of the program I'm working on now, I scroll the screen up one notch so the platforms touch the feet of the little guy. Would scrolling only once cause a problem? Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 4, 2012 Share Posted June 4, 2012 Thanks. Not a problem. The bug report has been submitted. In the version of the program I'm working on now, I scroll the screen up one notch so the platforms touch the feet of the little guy. Would scrolling only once cause a problem? Nope. If you see scanline issues as a result of scrolling, you'd only see them when then scroll position is updated, and even then only when a coarse-scroll eventually happens. 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted June 4, 2012 Author Share Posted June 4, 2012 Thanks. Hopefully batari will have time to figure out what needs to be fixed. 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted June 5, 2012 Author Share Posted June 5, 2012 Since the code above was missing set romsize 8kSC, does that mean something else is wrong that is making a resolution of 31 steal time away from the code? Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 5, 2012 Share Posted June 5, 2012 Yep. At this point I'd say we'd have to see the code in question to see why it's using too many scanlines. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted June 5, 2012 Author Share Posted June 5, 2012 Yep. At this point I'd say we'd have to see the code in question to see why it's using too many scanlines. Thanks. I'll be posting bB code in the platformer thread once I figure out what the enemy or target will look like. 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.