What exactly does scrolling speed have to do with cpu power?

[Multijointed Monster Maker]

What does the speed of a moving sprite or the scroll speed of a background have to do with cpu power?

Edited January 29, 2010 by Multijointed Monster Maker

[roland p]

Depends on how good the VDP can scroll. Anyway, the faster you scroll, the more amount of new data you have to supply to the VDP.

[retrozoneorg]

What does the speed of a moving sprite or the scroll speed of a background have to do with cpu power?

My Thoughts - I'm no expert though...

Most early computers did not include a Hardware Scrolling capability.

Some relied on the CPU for all graphical output.

 

Plus scrolling means moving data in and out of memory which would use a lot of the CPU cycles in a system without DMA.

[Multijointed Monster Maker]

What about for sprites? I've been programming a multijointed sprite boss on the Super Nintendo (hence my username Multijointed Monster Maker), and I don't get it why people think there is a limit on how fast sprites can move around the screen due to the cpu being clocked at 3.58Mhz. You can render a sprite on one side of the screen one frame, and render the same sprite on the opposite side of the screen the next.

[analmux]

Well, in case of the videochip of the SNES, it is as easy as changing the registers of X and Y positions of a sprite. Even the shape is directly programmable.

 

This is not the case in general for any computer.

 

For example changing x-coordinate of a 'sprite' on Atari 8bit home computer is just a matter of changing one 8bit reg. But, changing y-coordinate of an object you'd need to manually (with CPU) move data around. So, sprites on A8 are really a mixture of software-sprites and hardware-sprites. Also, if you want to change the shape, you must manually change the sprite-gfx-data.

 

But, also in the world of softwaresprites many subtleties could arise. The x-coordinate of a SWSprite on a monochrome background could be bound to integer multiples of 8. Then you won't need to do bitshifts (ROL / ROR commands) when moving a sprite. It's up to the coder what to do now. He can hold all preshifted stuff in memory, or do a big CPU-grunt when any non-integer*8 type of x-co is needed.

 

It is also up to the coder how to do this SWSprite-rendering. He could make some 'smartcode', first looking whether so-called AND-masking is needed, or just LOAD - STORE actions instead of brute-force LOAD - AND - ORA - STORE actions ... or maybe even LOAD - XOR - STORE actions.

 

 

It's really the same in case of scrolling, on f.e. the 8bit NES. Just scrolling 1 pixel to the right might not need any new data being written to the screen-memory, but scrolling half a screen to the right IMMEDIATELY needs a lot of new screen-data updates (when not using buffering). OK, a smart coder could prepare for these buffers outside the screen-area, but there are cases when you don't have this possibility (see Super Mario Bros 3 on NES 8bit): It already uses the NES's scroll buffers for vertical scrolling, so it is not possible to do horizontal buffering; that's why you see the weird scrolling artefacts in the sideborders. So, if SMB3 wants to scroll right half a screen it won't be possible. That would be nearly 400 bytes to be updated, which is not really possible during the VBlank time (remember, screenbuffers on NES must be updated during VBlank).

 

...so, reasons enough to assume it's not always that trivial to obtain 'unlimited' scrolling speed. However, if I'm correct, the SNES is a lot more flexible in this case. I'm not sure about the size of the screen/scroll-buffers of the SNES, but when you prepare it correctly, there's not a real hardware-limit to the scrolling speed.

 

On A8 it's also a lot more flexible. It's (again) up to the coder to choose a screen/scroll buffer layout. The A8's video-chip can be programmed to any desired scroll buffer layout. For example, it could use (nearly) all memory as a screen buffer, and just scroll through it without doing anything more than just change a 16-bit pointer and a finescroll register.

 

But, let's look at the older computers, which do not have a hardware-scroll feature. If you want to scroll the whole screen to the right, you need to replace all old data with new data, except in case you have a smart scrolling handler, ignoring 'empty' parts of the screen, but let's not assume this. So, data must be moved anyway. The desired scrolling speed might be far less of any influence on the actual CPU-time needed. It's a matter of LOAD data at one place of the screen, STORE it at another place, and LOAD new data, and STORE at the place which needs new screen content. So, only the altered code-logic needed for this is of any influence. The idea: Many CPU-time is wasted anyway, so the desired scrolling speed has less influence. The NES really seems to be one of the least optimal systems for scrolling at any arbitrary desired speed.

[Multijointed Monster Maker]

Background maps on the Snes are set up like this:

 

(1,1)

(1,1)

 

(1,2)

(1,2)

 

(1,1)

(2,2)

 

or

 

(1,2)

(3,4)

 

V-ram address of bg maps can be moved around. The Snes also has a DMA that runs at 2.68Mbps.