Jump to content

Photo

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


11 replies to this topic

#1 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

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

Posted Sat Jun 2, 2012 1:15 AM

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.

#2 RevEng OFFLINE  

RevEng

    River Patroller

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

Posted Sun Jun 3, 2012 9:57 PM

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


#3 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

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

Posted Mon Jun 4, 2012 12:00 AM

Here's what it looks like:

test.png


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:

Attached File  ex_scrolling_2012y_05m_21d_1655t.bin   4KB   64 downloads


Now do the same with this one and notice the odd changes that are happening on the screen:

Attached File  ex_scrolling_2012y_06m_04d_0152t.bin   4KB   68 downloads

#4 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

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

Posted Mon Jun 4, 2012 12:01 AM

Thanks. Here's what it looks like:

test.png


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:

Attached File  ex_scrolling_2012y_05m_21d_1655t.bin   4KB   64 downloads


Now do the same with this one and notice the odd changes that are happening on the screen:

Attached File  ex_scrolling_2012y_06m_04d_0152t.bin   4KB   68 downloads

The second one, compiled with the beta version, seems to randomly add and delete playfield pixels as the screen scrolls up.

#5 RevEng OFFLINE  

RevEng

    River Patroller

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

Posted Mon Jun 4, 2012 6:12 AM

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)

#6 RevEng OFFLINE  

RevEng

    River Patroller

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

Posted Mon Jun 4, 2012 6:39 AM

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

#7 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

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

Posted Mon Jun 4, 2012 7:53 AM

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?

#8 RevEng OFFLINE  

RevEng

    River Patroller

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

Posted Mon Jun 4, 2012 8:55 AM

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.

#9 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

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

Posted Mon Jun 4, 2012 8:58 AM

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

#10 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

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

Posted Tue Jun 5, 2012 4:39 AM

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?

#11 RevEng OFFLINE  

RevEng

    River Patroller

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

Posted Tue Jun 5, 2012 5:44 AM

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.

#12 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

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

Posted Tue Jun 5, 2012 8:40 AM

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.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users