horizontal scrolling on ST

[calimero]

That is an STE game so not so special with scrolling there

I did not know that! are you sure?

http://www.atarimania.com/game-atari-st ... 24613.html say it is ST, STe...

and Petari also does not mention this game on STe list:

http://atari.8bitchip.info/steandg.html !

and here nobody mention this game as STe:

http://www.atari-forum.com/viewtopic.php?p=48635

[BoNuS]

Maybe it detects if it is either an ST or STE and uses the right scroll routine.

[calimero]

Maybe it detects if it is either an ST or STE and uses the right scroll routine.

Maybe, but somebody should check and confirm this since there are few place on internet that are talking/writing about STe Enhanced game and non of them list Son Shu Shi!

[Steven Seagal]

Son Shu-Shi is STF.
It uses overscan (lower border) and palette tricks.
It scrolls on its own.
It's a remarkable game.

[ljbk]

Son Shu-Shi is STF.
It uses overscan (lower border) and palette tricks.
It scrolls on its own.
It's a remarkable game.

I don't know if that game is STF or STE.
But if it is STF, we can guess from the video that it uses simple sync scrolling like Enchanted Land since the scroll speed is quite high: probably 4 pixels at a time. So you use 4 screen buffers: one for each shift and the sprites (quite few) must save and restore their background.

Not all the horizontal scrolls or better, games with horizontal scroll, offer the same challenge to the STF programmer.
Let's take the Amiga versions of some very well known games for reference and forget for a while the parallax stuff taking only into account the main plane and remembering that the STFs only have normally up to 1MB:
- Shadow Of the Beast (1, 2 and 3) scrolls at 2 pixels per frame (100 pixels per second) : this could be done with sync scrolling and 8 screen buffers => 256KB for video saving the CPU time for the sprites;
- Blood Money scrolls 1/3 of a pixel per frame or better 1 pixel every 3 frames (17 pixels per second) and uses a lot of sprites: sync scrolling would need at least 16 screen buffers(512 KB) and requires background saving so probably it would not be the best option;
- RType, Apidya and a lot of others scroll 1/2 of a pixel per frame or better 1 pixel every 2 frames (25 pixels per second) and use a lot of sprites: sync scrolling would need at least 16 screen buffers(512 KB) and requires background saving so probably it would not be the best option;
- Menace and Agony scroll 1 pixel per frame (50 pixels per second) with also a considerable amount of sprites: again sync scrolling would need at least 16 screen buffers(512 KB) and requires background saving so probably it would not be the best option;

As long as the number of drawn frames is equal to 50 per second or equal to the scroll speed, the game will look good.
The problem starts if you scroll more than one pixel at a time and draw less than 50 frames per second. But sometimes for STF and especially with 512KB, there is no other solution even with sync scrolling available.
Blood Money STF version added to that to allow the user to move its ship at a bigger frame rate than the ennemies giving a sensation of a more fluid game.
Out of all the Shoot Them Ups listed above it is the closer to the Amiga version because it has a continuous very slow scroll.
Menace and Agony (just the main plane) would be the most dificult ones to convert, especially with 512 KB, because you need a 50 fps scroll and sync scroll would require 512 KB just for the video memory ...

Where does the screen sync shift help ?
It allows you to reduce by 4 the amount of video memory required by the sync scrolling but costs a bit of CPU time to hide the real shifting of the screen. So a 1 pixel (up to 50fps) horizontal scroll is possible with 128KB of video memory. So the programmer can now evaluate more seriously the use of sync scrolling as long as the number of sprites does not cost too much in background saving.
Assuming 30% of a VBL for 1 pixel horizontal scroll using the sync shift (i have not done it yet so i can not tell exactly how much it is), if you want to do a R-Type clone at 25fps, then you have 0.3 VBL for scroll and 1.7 VBLs for the sprites including background saving and restoring. That allows already a good number of sprites and is a much better solution than a ROXL type of scroll especially if your background is very diverse (not mainly black).

I hope to produce some more really visible examples in the near future.

Paulo.

[Zamuel_a]

I just checked quickly that it sayd running on an STE in the youtube video, but never checked if the game was an STE game or not

But if it is STF, we can guess from the video that it uses simple sync scrolling like Enchanted Land since the scroll speed is quite high: probably 4 pixels at a time. So you use 4 screen buffers: one for each shift and the sprites (quite few) must save and restore their background.

Is there a reason to use "hardware scrolling" in a game like this? It doesn't looks like 50fps and using ordinary preshifted tiles are much easier. If they scroll 4 pixels at a time, the amount of data for the tiles won't be that high either. It is also much better for sprites to redraw the background every frame. You don't need to save, restore the sprite background so you can draw almost 3 times the amount of sprites in the same time as on a hardware scrolled background. Also animated tiles are possible without any extra cost.

This game looks like it has rather smooth scrolling and big sprites
http://www.youtube.com/watch?v=6bBhe5AnfJs

[Steven Seagal]

But our goal here is to leave the Shifter with predefined number of words in the pocket when it starts to display the screen:
- 3 (screen shifted by 12 pixels because only 1 word will be read before the 4 are available to draw the bitmap);
- 2 (screen shifted by 8 pixels because only 2 words will be read before the 4 are available to draw the bitmap);
- 1 (screen shifted by 4 pixels because only 3 words will be read before the 4 are available to draw the bitmap);
- 0 (screen shifted by 0 pixels because the 4 words will be read to draw the bitmap);
In order to have always the same unstabilizer code (MED/LOW switch), you need the situation to be stable before: so you need the stabilizer.
Guess what, the stabilizer only really works you get to that time stamp in the line drawing and the Shifter is reading data. The only way to have that for sure AND to avoid that the previous unstable situation will become stable with the 1st line of the next frame is to have no right border.
The unstabilizer code will work at any place during the drawing of the 2nd line. The code provided in the 1st program is the first possible position for my machine. You can delay the "jsr (a4)" by 1 nop, 2 nops, ... 5 nops (like in V05) ... 20 nops up to around 7x nops.
There will be visual impact but we can BLANK the lines with the respective 60/50 switch.
The first words used for the first 16 pixels of the screen will come from the top of the video memory !!!
Another problem with this is that there is no easy way for the SW to guess if the Shifter is in that situation or not but it might be possible.

I hope this was not too boring.

Enjoy,
Paulo.

Boring? I don't think so.
What would be interesting for emulation is to know which switches shift by how many pixels (to the left, I guess), and by how many bytes the shifter counter is "shifted" (lol).
I have your bees shifting in a test version of Steem but they're more like hopping.
The switches are (in emulation scanline cycles):
080:R0001 100:R0000
088:R0001 100:R0000
092:R0001 100:R0000

[Steven Seagal]

I don't know if that game is STF or STE.
But if it is STF, we can guess from the video that it uses simple sync scrolling like Enchanted Land since the scroll speed is quite high: probably 4 pixels at a time. So you use 4 screen buffers: one for each shift and the sprites (quite few) must save and restore their background.

I reported what I saw in Steem debug, no other tricks like sync scrolling.

[npomarede]

Son Shu-Shi is STF.
It uses overscan (lower border) and palette tricks.
It scrolls on its own.
It's a remarkable game.

I don't know if that game is STF or STE.
But if it is STF, we can guess from the video that it uses simple sync scrolling like Enchanted Land since the scroll speed is quite high: probably 4 pixels at a time. So you use 4 screen buffers: one for each shift and the sprites (quite few) must save and restore their background.

Hello
both STF and STE versions are looking the same code wise, no use of STE specific scrolling registers. Screen is updated every 2 VBLs (25 Hz).
As for the result being smooth despite not using hardware scrolling, I guess the guys at Expose Software knew their stuff as former demo coders.

Niclas

[npomarede]

I just checked quickly that it sayd running on an STE in the youtube video, but never checked if the game was an STE game or not

But if it is STF, we can guess from the video that it uses simple sync scrolling like Enchanted Land since the scroll speed is quite high: probably 4 pixels at a time. So you use 4 screen buffers: one for each shift and the sprites (quite few) must save and restore their background.

Is there a reason to use "hardware scrolling" in a game like this? It doesn't looks like 50fps and using ordinary preshifted tiles are much easier. If they scroll 4 pixels at a time, the amount of data for the tiles won't be that high either. It is also much better for sprites to redraw the background every frame. You don't need to save, restore the sprite background so you can draw almost 3 times the amount of sprites in the same time as on a hardware scrolled background. Also animated tiles are possible without any extra cost.

Enchanted Land runs in 50 Hz, both game and intro (as one of the best ST demo coders, Nick / TCB couldn't certainly admit to have a lower refresh rate ). It does cost more to restore the background for sprites than when redrawing the whole screen, but by using hardware scroll, you only need to "refresh" a 16 pixels colum on left or right, or line up or down (depending on scrolling direction). So the gain is huge and is the reason allowing to reach 50 Hz in Enchanted Land.
Hardware scrolling won't allow you to have animated background at 0 cost, but considering you get the visual result of a 50 Hz multidirectional scrolling at less than 10 % CPU usage per VBL, you can use the 90% remaining to do lots of fancy stuff (even if you need to restore bg for sprites)

This game looks like it has rather smooth scrolling and big sprites
http://www.youtube.com/watch?v=6bBhe5AnfJs

From my memory on my STF, capcom arcade conversions by US Gold were anything but smooth, don't base your appreciation on the youtube video with bad replay rate. Forgotten Worlds didn't really look great (even if the game could be fun to play, but that's another debate)

Nicolas

[ljbk]

I don't know if that game is STF or STE.
But if it is STF, we can guess from the video that it uses simple sync scrolling like Enchanted Land since the scroll speed is quite high: probably 4 pixels at a time. So you use 4 screen buffers: one for each shift and the sprites (quite few) must save and restore their background.

I reported what I saw in Steem debug, no other tricks like sync scrolling.

Well, i am sorry i made a mistake but it is quite dificult to guess only from a Youtube video especially when you don't have a constant scroll but only scroll from time to time.
This is also important for the user perception. If your screen scrolls constantly even at 25fps more than 1 pixel at a time you will think it looks bad. If you just scroll from time to time it will look ok.
On the chapter how it is done, there are several tricks possible like limiting the colors of tiles/blocks. You can have blocks of 2 bitplanes and you can have several groups of them with 16 colors and have the other logical color bits fixed with $0000 or $FFFF so you don't need to shift/scroll them.
That is exactly how it looks for the Forgotten Worlds case but i might be wrong.

[ljbk]

Is there a reason to use "hardware scrolling" in a game like this? It doesn't looks like 50fps and using ordinary preshifted tiles are much easier. If they scroll 4 pixels at a time, the amount of data for the tiles won't be that high either. It is also much better for sprites to redraw the background every frame. You don't need to save, restore the sprite background so you can draw almost 3 times the amount of sprites in the same time as on a hardware scrolled background. Also animated tiles are possible without any extra cost.

The use of sync scrolling is a possibility that has to be evaluated for each individual project. It might be worth it or not.
You can have preshifted tiles and no sync scrolling.
You can have sync scrolling and no preshifted tiles.
You can have 1 screen buffer for each shift position and no sync scrolling.
Shifted tiles cost memory.
1 screen buffer per shift position costs memory.
50 fps whole screen constant horizontal scroll with 1 pixel (or plus) speed + 4 bitplane tiles/images is hardly achieved on STF without sync scrolling + preshifted tiles + 1 screen buffer per screen shift.

You can use classic sync scrolling with 25fps constant scroll as long as you use more than 1 screen buffer for the same shift position.

[ljbk]

But our goal here is to leave the Shifter with predefined number of words in the pocket when it starts to display the screen:
- 3 (screen shifted by 12 pixels because only 1 word will be read before the 4 are available to draw the bitmap);
- 2 (screen shifted by 8 pixels because only 2 words will be read before the 4 are available to draw the bitmap);
- 1 (screen shifted by 4 pixels because only 3 words will be read before the 4 are available to draw the bitmap);
- 0 (screen shifted by 0 pixels because the 4 words will be read to draw the bitmap);
In order to have always the same unstabilizer code (MED/LOW switch), you need the situation to be stable before: so you need the stabilizer.
Guess what, the stabilizer only really works you get to that time stamp in the line drawing and the Shifter is reading data. The only way to have that for sure AND to avoid that the previous unstable situation will become stable with the 1st line of the next frame is to have no right border.
The unstabilizer code will work at any place during the drawing of the 2nd line. The code provided in the 1st program is the first possible position for my machine. You can delay the "jsr (a4)" by 1 nop, 2 nops, ... 5 nops (like in V05) ... 20 nops up to around 7x nops.
There will be visual impact but we can BLANK the lines with the respective 60/50 switch.
The first words used for the first 16 pixels of the screen will come from the top of the video memory !!!
Another problem with this is that there is no easy way for the SW to guess if the Shifter is in that situation or not but it might be possible.

I hope this was not too boring.

Enjoy,
Paulo.

Boring? I don't think so.
What would be interesting for emulation is to know which switches shift by how many pixels (to the left, I guess), and by how many bytes the shifter counter is "shifted" (lol).
I have your bees shifting in a test version of Steem but they're more like hopping.
The switches are (in emulation scanline cycles):
080:R0001 100:R0000
088:R0001 100:R0000
092:R0001 100:R0000

Hello !

As for the bees example, you must be patient as i need some time to recover from my surgery to be able to program something better.
I will be happy to give you the same information and files i will provide to Nicolas.
Please send me your email via PM.
"Steem will not be left behind" !

Paulo.

[calimero]

The use of sync scrolling is a possibility that has to be evaluated for each individual project. It might be worth it or not.
You can have preshifted tiles and no sync scrolling.
You can have sync scrolling and no preshifted tiles.
You can have 1 screen buffer for each shift position and no sync scrolling.
Shifted tiles cost memory.
1 screen buffer per shift position costs memory.
50 fps whole screen constant horizontal scroll with 1 pixel (or plus) speed + 4 bitplane tiles/images is hardly achieved on STF without sync scrolling + preshifted tiles + 1 screen buffer per screen shift.

You can use classic sync scrolling with 25fps constant scroll as long as you use more than 1 screen buffer for the same shift position.

sorry for lame question, but can somebody explain on what technical stuff "sync scrolling" is referred to?
what does it include?

[ljbk]

sorry for lame question, but can somebody explain on what technical stuff "sync scrolling" is referred to?
what does it include?

The STF can only set the screen address on a muliple of 256 bytes address. There is no byte register like the $FFFF820D one present on STE.
Sync scrolling is the hability to emulate a byte address on word boundary (128 combinations) using the top lines of the video screen with different sizes: 0, 54, 56, 80, 158, 160, 162, 184, 186, 204, 206 and 230 bytes.
With 5 lines (line 0 to line 4) and combining the several available sizes you can emulate a byte address register for the screen starting on line 5.
As the different line sizes are obtained via quick changes on the $FFFF820A and $FFFF8260 registers to force the GLUE chip to provide a Display Enable signal to the MMU the way we want it was called the "sync" scrolling despite it is also called "hardware" scrolling.
It was aparently invented by the swedish group Omega at the end of 1988 or beginning of 1989 but first used in a demo by TCB in the spring of 1989 in the Cuddly Demos: main menu + fullscreen.
The "sync" shift scrolling, i have refered lately, provides, on top of that, the possibility to emulate partially the STE register at $FFFF8265 but with only 4 values: 0, 4, 8, 12 again using some switches at $FFFF820A and $FFFF8260 registers and some extra code to hide the real screen shifting that occurs.
This last one is also called the "4bit" sync scroller and up to now was only possible with fullscreen: "Let's do the Twist" from ST Connexion in Punish Your Machine Demo from 1991. The "new" thing is to have this possibility for non fullscreen cases, not having to do the "sync" switches for every scan line, leaving a lot of free CPU to the programmer.

So all this only helps the STF users and brings nothing new to the STE.
And still there is no way to emulate the STE $FFFF820E Line Offset for STF users.

Hope i have been clear.

Paulo.

[AtariZoll]

Does some game use extra STE features is very easy to judge: run it in Steem Debugger (best with TOS 1.62 ) and set detections of STE specific HW register access - like DMA audio, Hscroll ... There are some very rare cases when game detects incorrectly HW, but most of it is fixed in latest Steem SSE version. Son Shu Shi is not STE enhanced.

Regarding detection of wake-up state : I tested Ijor's SW and it detects it not correctly on STE. Here talking only about state which affects colors by Spectrum 512 like fast palette change, used in some demos too. I tried something similar earlier, and it worked not on STE too. Still, it may be possible. Don't know about such code.

[Zamuel_a]

One thing I never understod about syncscrolling is how to scroll horizontaly? Vertical is ofcourse no problem. It would be the same as setting the screen address on an STE, but to scroll horizonaly you need to extend the screen size but how do you do that on an ST?

[npomarede]

One thing I never understod about syncscrolling is how to scroll horizontaly? Vertical is ofcourse no problem. It would be the same as setting the screen address on an STE, but to scroll horizonaly you need to extend the screen size but how do you do that on an ST?

On STE, you would use the "line width" register to create a virtually larger line that what is displayed (imagine a 1000 pixel line where you move the starting point of a 320 pixel window).
But even with that, if you have a game with the equivalent of 50 horizontal screens, you can't have a virtual line of 50*320 pixels, it would take too much ram.
So, what you need is to use hardware scroll to change video address 16 pixels left or right + fine scroll reg (ff8265) to have a <16 pixel precision + at one point you should loop in your screen buffers (else, for a left scroll the start address of your screen will increase all the time on each VBL and you will end up filling all your ram)
On STF, you can't extend the screen, so moving to the let is done by adding 8 bytes as Paulo described with "sync scroll" and then you need to "repaint" 16 pixel on the left column and 16 pixel on the right.
Not easy to describe, a picture would be better

EDIT : "On STF, you can't extend", not "you can extend"

[ljbk]

How to "sync" scroll horizontally ?

Completing the answer above here is a "picture" :

Each normal line is made of 320 pixels or 160 bytes. Each group of 16 pixels are 8 bytes or more precisely 4 words one for each bitplane. Let's call each group of 16 pixels Wxx.

So you start with:
W00 W01 W02 W03 W04 W05 W06 W07 W08 W09 W10 W11 W12 W13 W14 W15 W16 W17 W18 W19
W20 W21 W22 ...

If you add 8 bytes to the screen offset, you will get:
W01 W02 W03 W04 W05 W06 W07 W08 W09 W10 W11 W12 W13 W14 W15 W16 W17 W18 W19 W20
W21 W22 W23 ...
If you then correct the column of W20/W40/W60 ... with the new group of 16 pixels that comes from the right you will get an horizontal scroll of 16 pixels to the left.

If you substract 8 bytes to the original screen offset, you will get:
W99 W00 W01 W02 W03 W04 W05 W06 W07 W08 W09 W10 W11 W12 W13 W14 W15 W16 W17 W18
W19 W20 W21 W22 ...
If you then correct the column of W99/W19/W39 ... with the new group of 16 pixels that comes from the left you will get an horizontal scroll of 16 pixels to the right.

Now, how to do a 8 pixels scroll ?
Simple, you use 2 screen buffers that you show once every 2 frames.
The first screen buffer is used like above.
The second screen buffer uses other sets of 16 pixels where each one contains 8 pixels of one Wxx and 8 pixels of the adjacent Wxx.

Now, how to do a 4 pixel scroll like in most main menus of well know demos ?
Again, you increase the number of screen buffers to 4:
Wxx like 1st case
Xxx with 4 pixels of Wxx and 12 pixels of the adjacent Wxx
Yxx with 8 pixels of Wxx and 8 pixels of the adjacent Wxx
Zxx with 12 pixels of Wxx and 4 pixels of the adjacent Wxx

2 pixel scroll => 8 screen buffers

1 pixel scroll => 16 screen buffers

Beware that if your screen does not move horizontally you are working on the same screen that is displayed to the user so you can only modify the screen in line with the place where the electron is to avoid flickering effects when clearing and drawing sprites. That is one of the main credits to Nick in Enchanted Land because we are talking about a game and not a demo.

1 screen buffer for 200 lines = 32KB minimum + the memory space required to scroll horizontally to the extremes left, right, top and bottom.
16 screen buffers for 200 lines = 512 KB minimum so many of the STFs are out ...


I hope this helped in explaining this "sync" scroll and turned clear some of my previous statements.

Paulo.

[Zamuel_a]

Ah ok Clever and not to difficult. Tobad there aren't to many games on the ST that use this technic. Giana sisters on ST had been a good game to use syncscroller in. As it is now, it's total crap. There aren't to many sprites on screen at the same time, so not to much to draw, and only horizontal scroll.

[simonsunnyboy]

Ah ok Clever and not to difficult. Tobad there aren't to many games on the ST that use this technic. Giana sisters on ST had been a good game to use syncscroller in. As it is now, it's total crap. There aren't to many sprites on screen at the same time, so not to much to draw, and only horizontal scroll.

I totally disagree. Just beause Giana Sisters doesn't scroll it is not also a bad game. It is very very playable even without hte scroll, IMHo even more playable than the scrolling versions in some levels.

[Zamuel_a]

I totally disagree. Just beause Giana Sisters doesn't scroll it is not also a bad game.

It looks very cheap with the no scroll. It's much more fun to play on an Amiga or a c64 than on Atari. They didn't even try and make some kind of scroller. The amount of tiles are not that big, so preshifted tiles wouldn't take to much memory so possible without any big effort on an ST.

(If someone could dissamble it, it would had been fun to convert it to STE EDIT: I found a copy of the game that I could dissamble, so maybe I will take a look at adding real scrolling to it )

[Zamuel_a]

I'm using Easyrider to dissamble the code and did it like I have done before, but all addresses for variables and stuff are fixed and not dynamic. I'm not sure if it's the game itself that does this or not?

So instead of:

move.w #123,L0001
L0001 dc.w 0

I get

move.w #123,$xyz

This makes it abit tricky to do anything since if I just put in a NOP somethere, everything crash.

[AtariZoll]

Not unusual for games not using TOS - code is in most cases not relocatible, assembled and written for fixed RAM location. So, variables are on absolute adresses in many cases - may be in lowest 32KB - then can use short addressing.

You need to replace all absolutes with labels - if their location will change (they are in middle of code) - then reassembling will be OK.
Adding just l before address should be enough.

And I'm not sure that adding scrolling without some level redesign will be good in all cases .

[Zamuel_a]

There isn't a way to make Easyrider fix it so that all fixed addresses become dynamic?

it looks like the variables are on addresses < $FFFF so if the game code was above this it should be ok. I'm not sure where Devpac usually put the code, but had been good if it was possible to force the location here to to be somethere > $FFFF

EDIT:
I found the ORG statement in Devpac so I could move the code, but it didn't help. As soon as I add anything extra into the code, it crash. There are also alot's of TRAP commands in the game. Not normal TOS calls, but TRAP 0,7,8...11,12