Does a larger const pfres mean less time for other things?

[+Random Terrain]

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.

[RevEng]

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

[+Random Terrain]

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

[+Random Terrain]

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.

[RevEng]

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)

[RevEng]

Also worth mentioning that if you're scrolling, then a large pfres CAN cause a scanline issue, since scrolling involves copying the playfield memory.

[+Random Terrain]

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?

[RevEng]

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.

[+Random Terrain]

Thanks. Hopefully batari will have time to figure out what needs to be fixed.

[+Random Terrain]

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?

[RevEng]

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.

[+Random Terrain]

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.