Examples of the most advanced side scrolling?

[Thomas Jentzsch]

I don't really get how you're measuring the scrolling speed in fps. In the case of 30fps does it mean that 30 of the 60 frames in a given second will have a movement of one pf pixel? Wouldn't it make more sense to measure the scrolling speed in pf pixels per second? That way you could easily have a speed of 42.5 pixels per second, etc.

In this case 30 FPS means, that the playfield moves every 2nd frame. So that's 4 pixel moving at 30Hz = 30 PF pixel = 120 pixel per second.

[ZackAttack]

Now I understand what you mean. A 4 pixel increment at 60fps would have the same scroll speed as a 12 pixel increment at 20fps, but the 4@60 would appear smoother.

 

I bet the difference in smoothness becomes more apparent when you vary the scroll speed. For example if you had a scroll speed of 160 pixels/sec. The 60fps would have a 3 frame pattern of 0,4,4. The 30fps would have a 6 frame pattern of 0,4,0,4,0,8. I wonder how noticeable the difference would be.

[Thomas Jentzsch]

I am pretty sure that a more even speed (0,4,4) would look significantly better. But still more jerky than a completely even speed even at a lower FPS.

 

Moving the PF at 60 FPS results in the smoothest scrolling, but usually the resulting speed is too fast for a game. The Empire Strikes Back gets away only because the fast scrolling bottom is just icing on the cake, the relevant action is the much slower scrolling speed of the AT-ATs.

Edited March 11, 2016 by Thomas Jentzsch

[iesposta]

I found another amazing horizontal scroller.

Lots of tricks and unfortunately it uses P0 P1 and background.

Seems that playfield, ball, M0 & M1 are unused.

 

Another problem using this demo to make a game, is it flips the whole background to white while the P0 & P1 are black, then the players turn white against a black horizontally striped background.

 

Movable Grid Demo (PD).a26

 

EDIT: Well that above is wrong. All it is doing is a black, white repeated background top top bottom, and when you push left or right it is cycling P1 & P0 3 frames (both always white), with a 4th frame of background all white.

[MacrosCode]

Some other scrolling stuff I've done in the past:

 

14 Vertical Bars. This uses JSR with the stack pointer aligned to the color registers to do quick updates.

 

SP pointing to hardware registers!?! THIS is REALLY crazy!!!

 

Very cool!! How did you get this idea??

 

 

This has potential!

Maybe this technique could be used to modify other registers instead of the colors... e.g. PF or NUSIZ0+1 etc.

Edited August 11, 2016 by MacrosCode

[tschak909]

The combat stack trick uses the stack pointer to enable missiles and/or ball in O(1) time. According to Joe Decuir, the hardware was specifically aligned to allow this, and was a result of the hardware and software being developed in tandem.

 

-Thom

[Omegamatrix]

 

SP pointing to hardware registers!?! THIS is REALLY crazy!!!

 

Very cool!! How did you get this idea??

 

 

This has potential!

Maybe this technique could be used to modify other registers instead of the colors... e.g. PF or NUSIZ0+1 etc.

Yes, you can use it for other registers. It is particularly useful for registers that can be strobed (write value doesn't mater) such as the RESxx registers.

 

Other than that it just depends on what address you can JSR or BRK from. Here is another example where I'm using JSR to change the color of the playfield and background. I'm doing this in the six byte display because at the time the update needs to be done I already have A, X, and Y preloaded to update the digit graphics. That kernel is even a little more nuttier as I'm also using the timer as a loop counter and index for the graphics. So there is a lot more than meets the eye going on there.

[MacrosCode]

The combat stack trick uses the stack pointer to enable missiles and/or ball in O(1) time. According to Joe Decuir, the hardware was specifically aligned to allow this, and was a result of the hardware and software being developed in tandem.

 

Oh that's new for me. So designers itself thought of that possibilities... very clever!!

[MacrosCode]

Yes, you can use it for other registers. It is particularly useful for registers that can be strobed (write value doesn't mater) such as the RESxx registers.

 

Other than that it just depends on what address you can JSR or BRK from. Here is another example where I'm using JSR to change the color of the playfield and background. I'm doing this in the six byte display because at the time the update needs to be done I already have A, X, and Y preloaded to update the digit graphics. That kernel is even a little more nuttier as I'm also using the timer as a loop counter and index for the graphics. So there is a lot more than meets the eye going on there.

 

This idea has potetial to do far more. With no other assembly command you can change 2 registers so fast.

 

I looked at your example.. if you did not tell me i would have suggested to do this 2 colors like the one in the star castle title screen.

As you wrote: there is a lot more behind as you could see.

 

Really intersting stuff!

Edited August 12, 2016 by MacrosCode

[Thomas Jentzsch]

Interesting stuff. I thought about this stack pointer trick too, but couldn't come up with any useful code.

 

BTW: With BRK you can even change 3 consecutive registers.

[MacrosCode]

BTW: With BRK you can even change 3 consecutive registers.

 

BRK? Can you give me an example of how to use it?

[Thomas Jentzsch]

Nope.

 

It's the same as with Omega's JSR trick, but you only have the (fixed) break vector (instead of an address). Additionally it pushes the status flags register. So it is even less flexible than the JSR trick, but might be useful for (very) special cases.

[Thomas Jentzsch]

BTW: While doing some research, I found "Retrogame Archeology: Exploring Old Computer Games" by John Aycock.

 

Looks quite interesting (and I got credited! )

[tschak909]

The common thread with these tricks, is that you're using the dedicated circuitry in the 6507 to do a series of writes in quick succession, which otherwise would not be possible. These tricks just happen to be possible because both page 0 and page 1 decode to exactly the same space. (Yay for very partial address decoding!)

 

-Thom

[Omegamatrix]

 

BRK? Can you give me an example of how to use it?

Here is an example of BRK being used to do fast color changes. You have to start reading from about post #7 of that thread to figure out what is going on.

[Omegamatrix]

Nope.

 

It's the same as with Omega's JSR trick, but you only have the (fixed) break vector (instead of an address). Additionally it pushes the status flags register. So it is even less flexible than the JSR trick, but might be useful for (very) special cases.

I have always dreamed of a cartridge where the break vector was ram (for doing these type of tricks).

[Thomas Jentzsch]

That means that the RAM write offset would have to be negative. So that reading from RAM can be at the end of the 4K.

[MacrosCode]

Here is an example of BRK being used to do fast color changes. You have to start reading from about post #7 of that thread to figure out what is going on.

 

TestColors.zip is an amazing demo of what could be done from a technical point of view!

 

If transformed into a real picture with many colors then it would be REALLY impressive.

But I think that needs a very good graphic artist to take care of all limitations.

[MacrosCode]

Nope.

 

It's the same as with Omega's JSR trick, but you only have the (fixed) break vector (instead of an address). Additionally it pushes the status flags register. So it is even less flexible than the JSR trick, but might be useful for (very) special cases.

 

Nope?!

 

Anyway now I understand the difference (BRK vs. JSR). You are right. That has some even more limitations!

For very special circumstances it may be working, but JSR is far more flexible.

Edited August 13, 2016 by MacrosCode

[Thomas Jentzsch]

It think BRK might be most usable for fast RESxy. Then the values are irrelevant.

 

Repeated TXS, JSR can update two registers within 8 cycles (with varying values).

 

[MacrosCode]

It think BRK might be most usable for fast RESxy. Then the values are irrelevant.

 

Thats true! Good point!

[maiki]

Never say never -http://atariage.com/forums/topic/224946-smooth-scrolling-playfield-i-think-ive-done-it/

 

I got burnt out on the back and forth of this with no CRT of my own to test it on, hopefully someone else will pick it up, or I'll get a CRT and have another crack myself...

 

It is perhaps a very well tuned code but on a CRT TV it just flickers... yes it is smooth but it flickers.

[eshu]

 

It is perhaps a very well tuned code but on a CRT TV it just flickers... yes it is smooth but it flickers.

 

Not sure if you read the whole thread etc.. , but I thought my comment made it clear it doesn't work properly/universally - but there's at least a lead as to how a smooth scrolling playfield might be achieved. Difficult to know what you mean by flickering in this context, but the likelihood is your TV doesn't like the various butchered signals being sent out by the VCS.....

[iesposta]

Not sure if you read the whole thread etc.. , but I thought my comment made it clear it doesn't work properly/universally - but there's at least a lead as to how a smooth scrolling playfield might be achieved. Difficult to know what you mean by flickering in this context, but the likelihood is your TV doesn't like the various butchered signals being sent out by the VCS.....

If you do have a display this works on, you appreciate what an amazing machine the Atari 2600 really is and also the amazing creativity of people still making it do new things it was never intended for!

 

Amazingly beautiful:

https://www.dropbox.com/sc/n4g444x2y4qe0fa/AAAzD2aO2N04bSZxlqViY9Cma

[maiki]

Well, it certainly doesn't look that clean on my TV (the text tends to flicker horizontally). Seems like this is something really really picky even when connected to real CRT. OR, and this could be very well true, my Atari 2600 Jr., the Chinese model, has got different TIA timing... proved with good number of games so far.