Jump to content

Photo

Smooth Vertical Scrolling from DATA (Want 4-way)


31 replies to this topic

#26 bogax OFFLINE  

bogax

    Dragonstomper

  • 715 posts

Posted Sat Nov 4, 2017 6:05 AM

If you want to see how I did horizontal scrolling in Princess Rescue, just go to Random Terrain's Batari site, and he has my source code for it there, along with added documentation.  You can find how I did my scrolling in there with the ScrollLeft and ScrollRight routines.  I did use pfhscroll, but with some added code.  When new data needed to show up, it would look at the new data I had in the level data table, using a pointer, to pick up the 2 new bytes, and then it would compare bit by bit with what the var screen variables had on the edge of the screen.  If it didn't match up, it would flip the bit, saving time so it didn't redraw every bit on the edge of the screen.

 

(I haven't looked at your code) (yet)

 

hmm.

 

I wonder if it would be useful to store the data as sort of a table of difs or deltas (or whatever you'ld call them)

then just flip a bit if necessary, depending on what's in the table



#27 Sprybug OFFLINE  

Sprybug

    Dragonstomper

  • 551 posts

Posted Sun Nov 5, 2017 5:21 AM

 

(I haven't looked at your code) (yet)

 

hmm.

 

I wonder if it would be useful to store the data as sort of a table of difs or deltas (or whatever you'ld call them)

then just flip a bit if necessary, depending on what's in the table

 

I'm not sure what you mean by that exactly.  The level data is simply like this.  Every 2 bytes represent the playfield from the top to the bottom vertically.  Since Batari's resolution is 11 rows (12 if you count the invisible one, that I don't use).  This leaves 5 extra bits that I use for enemy/object spawn in information.  So the first byte is row 0 to row 7.  So if one of this bits is on, on the screen (held in the varxx variable), that playfield block will be on, and if that new data shows that one bit in that one row is off, then it'll flip it or vice versa (it's off on the screen and will be flipped to be on). If it's the same then don't do anything.  There's no need to.  The first 3 bits of the second byte represent rows 8-10 and you repeat the same checks.



#28 bogax OFFLINE  

bogax

    Dragonstomper

  • 715 posts

Posted Sun Nov 5, 2017 9:07 AM

 

I'm not sure what you mean by that exactly.

 

I'm not sure exactly what I mean either (and, again, I haven't had a chance to look at your code)

 

And I'm just sorta thinking out loud.

 

from your description:

 


When new data needed to show up, it would look at the new data I had in the level data table, using a pointer, to pick up the 2 new bytes, and then it would compare bit by bit with what the var screen variables had on the edge of the screen.

 

What I'm thinking is rather than doing a comparison just have the level data table indicate if a bit needs flipping (build the results of the comparison into the table)

I wouldn't bet that that would save you anything I'm just wondering if it could.



#29 Sprybug OFFLINE  

Sprybug

    Dragonstomper

  • 551 posts

Posted Mon Nov 6, 2017 5:25 AM

 

I'm not sure exactly what I mean either (and, again, I haven't had a chance to look at your code)

 

And I'm just sorta thinking out loud.

 

from your description:

 

 

 

What I'm thinking is rather than doing a comparison just have the level data table indicate if a bit needs flipping (build the results of the comparison into the table)

I wouldn't bet that that would save you anything I'm just wondering if it could.

 

I think I see where you are going with this, and it might work well if it scrolled in one direction and didn't go back, but with my games they scroll in both directions, which would mean when the data going the other way would have to be different to compensate, which would probably add to the size of the tables, sacrificing ROM space to gain a few CPU cycles.  I know this is a constant game you play with programming on the Atari 2600.  Sometimes you need more CPU cycles, and since you got the ROM space, do some pre-calculations so the CPU doesn't have to.  And sometimes you need more ROM space, so you let the CPU do a little more work to produce the data you need.  I tend to do one or the other depending on what's on my plate.  It's a very delicate balancing act, that's for sure!



#30 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • Topic Starter
  • 8,851 posts

Posted Mon Nov 6, 2017 10:34 AM

Since this topic is still active I may as well post a demonstration video.  Mr SQL reported that the engine is going over cycle, though.

 



#31 Sprybug OFFLINE  

Sprybug

    Dragonstomper

  • 551 posts

Posted Mon Nov 6, 2017 4:24 PM

Since this topic is still active I may as well post a demonstration video.  Mr SQL reported that the engine is going over cycle, though.

 

 

Impressive!

I'd love to see the code on how you did it.  4 way scroll would be great for games I'd like to make!



#32 Mr SQL OFFLINE  

Mr SQL

    Stargunner

  • 1,748 posts

Posted Mon Nov 6, 2017 5:58 PM

Macky Man is awesome! :)  If there were a hack to bB to allow access to the other vertical blank there's probably enough time left over there to split the scroll routines up to fit.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users