Genesis raster skew/scale demo + source code

Months ago, I made a program for the genesis showing a picture of a gnome getting stretched and skewed. I don't think I ever formally "released" it, and I even had someone tell me it was fake. I guess now is as good a time as ever. I'm sure someone will have fun playing it with, and maybe someone can incorporate the effect into their own homebrew.

Here is the old video clip that I've shown off in the past:
http://gfycat.com/ScentedIncomparableGosling

Here is a new improved version:
http://gfycat.com/GoldenFineAustraliankestrel

It runs at 60FPS (50 for PAL), and only uses 7 bytes of RAM not including the stack. It uses somewhere around 60%-75% of the genesis's CPU cycles.

But ComradeOj, how could you warp those high res images like rubber at 60FPS, using only 7 bytes of RAM? Raster trickery! My program takes advantage of the Genesis's natural scrolling abilities. It continuously scrolls farther and farther as the TV draws the image (from top to bottom). It then resets the scrolling when the TV draws the entire thing. The result is a natural looking skewing and scaling. This is also why it can only scale vertically, and not horizontally.

I'm including a version with the gnome, and a version with the SEGA-16 logo. The source code is also included. The source is super easy to alter, even if your not much of a programmer. Just make tiny changes, build a new copy of the program, and try it! Just have fun with it, I was able to get all sorts of neat effects by inserting random instructions into the skew routines.

Controls

Use the D-pad to warp the image, and use A, B, C to toggle slow, medium, or fast movement speed.
You can press START to reset the image.

Download link:
https://drive.google.com/file/d/0B-u...ew?usp=sharing

Building the source

To build the program from the source, simply double click the "make.bat".
It will output a ROM called "Genesis raster FX test.bin"
It's as easy as that.

How it works:

Here is the meat of the source code. Hblanks, skewamount, vertskewamount, and speed are all just labelled locations in RAM. VDP control is loaded into A3, and VDP data is loaded into A4.

Here is the routine for horizontal skewing. It gets called once per Hblank along with an almost identical routine for vertical scaling. "speed" is 7, 5, or 3 depending on what the player sets it to. In addition the "hblanks" variable gets counted up by one every hblank.

Code:

---

skew_H:
          move.l #$40000003,(a3) ;set VRAM write at $C000 (scroll data)
          move.w hblanks,d0      ;increase skew the farther down
          muls.w skewamount,d0  ;Calculate scroll distance
          move.b speed,d1        ;add controllable speed factor
          sub.b #$01,d1          ;make H speed more closely match V speed
          lsr d1,d0              ;speed adjustment
          move.w d0,(a4)            ;write scroll data
          move.w d0,(a4)
          rts

---

On the Vblank, we have:

Code:

---

          move.w #$0000,hblanks

---

...and the controller input reading routine. That's pretty much it.

Cool work, but what means raster anyway?

Quote:

---

Originally Posted by EPSYLON EAGLE

Cool work, but what means raster anyway?

---

An image made out of pixels basically. The opposite would be vector graphics, which are drawn point-to-point. Think the asteroids arcade game, or the vectrex.
"Raster effect" is kind of a broad term. I think "line scrolling" might have been a better word for me to use. Have you ever played road rash on genesis? The road is a type raster effect.

Can't imagine where in gameplay such effect might be useful. But for a logo-joke it's super cool. :D

Quote:

---

Originally Posted by Nitroman

Can't imagine where in gameplay such effect might be useful. But for a logo-joke it's super cool. :D

---

It's admittedly not a super practical effect. Neat looking though! I actually use it for the title screen of a game I'm working on. The effect can also be applied to sprites though, not just backgrounds. I was thinking about starting a simple 2 player space combat game, and using the effect to stretch the player into infinity when they die.

Quote:

---

Originally Posted by ComradeOj

It's admittedly not a super practical effect. Neat looking though! I actually use it for the title screen of a game I'm working on. The effect can also be applied to sprites though, not just backgrounds. I was thinking about starting a simple 2 player space combat game, and using the effect to stretch the player into infinity when they die.

---

Ah, that game about guy and his refrigerator?
2-player space combat game? So much variations comes to mind (always wanted to design one), from Ship demo(Spacewar! clone for Genesis by Technopop) to co-op schmup where 2 players can transform their ships into whole one monstrosity.

Quote:

---

Originally Posted by Nitroman

Ah, that game about guy and his refrigerator?
2-player space combat game? So much variations comes to mind, from Ship demo(Spacewar! clone for Genesis by Technopop) to co-op schmup where 2 players can transform their ships into whole one monstrosity.

---

Yep the refrigerator one! There's more to it than that now though :)

I was thinking something like the Atari 2600 game called "combat". Something super simple, but enjoyable for a few rounds. I figured it would be easy to program, unlike that that time sink of a project with the refrigerator.

Quote:

---

Originally Posted by ComradeOj

Yep the refrigerator one! There's more to it than that now though :)

I was thinking something like the Atari 2600 game called "combat". Something super simple, but enjoyable for a few rounds. I figured it would be easy to program, unlike that that time sink of a project with the refrigerator.

---

I guess, you like simple and plain code. Yeah... For a simple game such effects will indeed be useful. Hope you'll start programming it, 2-player (or even 4p TDM :)) homebrew game for genesis is still a rare gem. Maybe even draw a small ship sprite for it.

This is naiss !

Quote:

---

Originally Posted by Nitroman

Can't imagine where in gameplay such effect might be useful. But for a logo-joke it's super cool. :D

---

Doesn't the SNES's color window also require updates each line? That was used in games. Though it did tend to cause slowdown when scaled up to big sizes, which is why it tended to be used for game elements where slowdown wasn't so bad, like when you used a bomb. This could be used the same way.

The limitation of this, of course, is that you have so few BG layers to use for such a superfluous effect. But you could just use it as an effect with the normal BG layers you're already drawing, the way some games "shake" the screen when something hits the ground really hard. You could slightly distort the BG layers (maybe scale one up and one down, and keep the bottom of the screen where it is), while flashing the palette, etc, at the climax of a bomb's explosion.

Cool demo.

Quote:

---

Originally Posted by roundwars

Doesn't the SNES's color window also require updates each line? That was used in games. Though it did tend to cause slowdown when scaled up to big sizes, which is why it tended to be used for game elements where slowdown wasn't so bad, like when you used a bomb. This could be used the same way.

---

The SNES doesn't use hblank interrupts though, so you have less overhead than an interrupt every line. You build tables, and the HDMA write data to whatever reg you specified (up to 8 channels). I always thought the color effects were slowed down for dramatic effect (Contra 3?).

Quote:

---

It uses somewhere around 60%-75% of the genesis's CPU cycles.

---

That's quite a bit. I just noticed the multiply instructions in the hblank routine :o You could definitely tight up that routine and save some cycles.

Quote:

---

Originally Posted by tomaitheous

The SNES doesn't use hblank interrupts though, so you have less overhead than an interrupt every line. You build tables, and the HDMA write data to whatever reg you specified (up to 8 channels). I always thought the color effects were slowed down for dramatic effect (Contra 3?).

---

Interesting, so there's no impact on CPU at all if you're just DMAing a static table? That'd explain why Contra's shield doesn't seem nearly as resource-intensive as the bomb effects -- all you're doing is moving it around on the X and Y axes. But with the expanding bomb type of effect, you have to scale it up every frame, which probably involves doing some math. And suddenly slapping all that math on top of all the stuff the game is already doing each frame seems like it'd cause actual slowdown, which I doubt is an intentional effect, though it does look kind of cool. If it were essential to not have slowdown, they could use more tables and less calculations to draw the expanding window, making it a bit choppier if necessary, so I guess in that sense it's "intentional".

From what you're saying, it sounds like the SNES could use HDMA to do heavier raster-skipping effects than the Genesis without as much resource hit. Is that how this scene in R-Type III is done?

Quote:

---

Originally Posted by roundwars

Interesting, so there's no impact on CPU at all if you're just DMAing a static table? That'd explain why Contra's shield doesn't seem nearly as resource-intensive as the bomb effects -- all you're doing is moving it around on the X and Y axes. But with the expanding bomb type of effect, you have to scale it up every frame, which probably involves doing some math. And suddenly slapping all that math on top of all the stuff the game is already doing each frame seems like it'd cause actual slowdown, which I doubt is an intentional effect, though it does look kind of cool. If it were essential to not have slowdown, they could use more tables and less calculations to draw the expanding window, making it a bit choppier if necessary, so I guess in that sense it's "intentional".

From what you're saying, it sounds like the SNES could use HDMA to do heavier raster-skipping effects than the Genesis without as much resource hit. Is that how this scene in R-Type III is done?

---

Well, to give an idea it can read and write (tranfer) 1 byte in 8 master clock cycles. For the cpu in slow mode, that's 1 clock cycle. So it's pretty fast. There are 8 channels and each channel can write two bytes to any PPU per scanline, or one if it doesn't need a WORD update. The cpu is stalled while this happens, but halt time is pretty tiny. Each HDMA channel has its own scanline counter as well, and has full access to the 24bit address range to read from. It also has indirect mode, which is interesting (you can use tables in rom, with values in ram.. type of setup).

The 68k isn't really great at interrupts. Just for the call and return, the minimum is 68 cycles. If the call is in the middle of an instruction, that overheard will me greater than 68 cycles. The same as on other cpus, but the instruction times tend to be longer on the 68k. So a good case scenario is usually 68+8=72cycles in average, but can be higher. To put that into context, if you did that every scanline (224 NTSC) then that's 12.6% cpu resource just for the call (no other instructions). Pushing and popping isn't that fast, so if you reserve a few regs just for h-int routines to speed them up - then you lessen the range of optimization else where in local code. It's give or take.

For comparison, on the PCE it's 15 cycles overhead for the interrupt call (call and return). The average instruction is 3-4 cycles. I'll go with 3, since I went low on the 68k (according to emulation a couple of authors that did some compares, the average for 68k was 10 cycles an instruction and 3 cycles for 6280). So (15+3)*224 scanline is 3.3% cpu resource.

But yeah, that's why the Genesis has scroll tables. But I guess they didn't have enough silicon to do the same for vscroll tables (it only has hscroll tables and a column scroll table).

By comparison for the snes, it's something like 1 cpu cycle (disregarding the initial load at the start of the display) just for the call. And it can move data waaaay faster than the cpu can, doesn't have to push/pop registers, doesn't have to do adding/etc operations. Though, you still have to put data in those hdma tables to update regs with, so there's still that. But were talking just the calling overhead.

Quote:

---

Originally Posted by tomaitheous

Cool demo.

That's quite a bit. I just noticed the multiply instructions in the hblank routine :o You could definitely tight up that routine and save some cycles.

---

Thanks!

Yeah, it probably has room for improvement. A big part of the 60-75% is because the demo does horizontals and verticals independently, therefore has to to everything twice. If it only did the effect only on 1 axis or just did the both directions with the same calculations, it would run faster. I could also have the hblank routine called every other line, instead of every line. That would save a lot of cycles, and only look a little bit worse. I might also try experimenting with replacing the multiply instructions with left shift instructions, since they are a lot faster.

I actually have implemented the effect into two different games I'm working on with pretty good results.

Quote:

---

Originally Posted by tomaitheous

The 68k isn't really great at interrupts. Just for the call and return, the minimum is 68 cycles. If the call is in the middle of an instruction, that overheard will me greater than 68 cycles. The same as on other cpus, but the instruction times tend to be longer on the 68k. So a good case scenario is usually 68+8=72cycles in average, but can be higher. To put that into context, if you did that every scanline (224 NTSC) then that's 12.6% cpu resource just for the call (no other instructions).

---

I think you're mixing interrupt latency and interrupt cycle... The 68000 auto vector interrupt takes up to 44 cycles to process.
That is counting the SR & PC saving operations as well as the BUS interrupt cycle to determine the vector interrupt address. Actually this period is variable and 44 cycles is the maximum. So an interrupt usually takes between 26 and 44 cycles with a mean of 32 cycles but that is without the latency of currently executed instruction:
- If we were executing a NOP instruction then you can add a maximum of 4 cycles latency between the interruption time and the first executed instruction in the interrupt handler.
- If we were executing a DIV instruction then latency can be much higher...
In every case that does not add any cycles to the interrupt processing itself, it is just the previous instruction was still executing when interruption happened...

So here you are over estimating the 68000 interrupt cycle... We usually say 44 cycles but it's actually between 26 and 44 cycles with an average 32 cycles. Of course you have to add the 20 cycles for the RTE instruction so you still end up to a *maximum* of 64 cycles without any operation yet ;)
But so, i think a better estimation is about 10% of CPU time (just to take the interrupt) if we interrupt on each scanline instead of 13%. But anyway to get back to the HDMA stuff, i think that is probably the best feature the SNES bring =) A really good, efficient and elegant way to provide powerful and fast raster effects (among others possible stuff)

COPPER > HDMA :p. Shame there isn't a single Amiga game that uses it to the fullest (not even Brian the Lion, though probably the best example).

Quote:

---

Originally Posted by Stef

I think you're mixing interrupt latency and interrupt cycle... The 68000 auto vector interrupt takes up to 44 cycles to process.
That is counting the SR & PC saving operations as well as the BUS interrupt cycle to determine the vector interrupt address. Actually this period is variable and 44 cycles is the maximum

---

The official 68k manual says nothing about min/max values, or up to, etc. It says specifically 44cycles. Why would the process itself be variable? I mean, what could possibly be variable about a fixed process such as that?

Quote:

---

In every case that does not add any cycles to the interrupt processing itself, it is just the previous instruction was still executing when interruption happened...

---

Opps, you're right. I'm mixing two perspectives here. Call overheard and the time from the call - to when you need to write the reg or whatever (time sensitive updating); latency. I've written so many time sensitive interrupt routines, that the two ideas have fused in my brain :P

Well actually if you read the official documentation : http://tict.ticalc.org/docs/68kUM.pdf (page 8-11)
You can read "The interrupt acknowledge cycle is assumed to take four clock periods." which is a lot... actually it all depends from the connected external device (here the VDP).

I assume the interrupt processing being close to this :

4 = interrupt pre compute (SR copy, set supervisor mode, remove trace and update interrupt mask)
8+4 = save PC+SR
X = request interrupt vector (with interrupt acknowledge)
8 = fetch address from vector
4 = fetch first instruction

which is 28 cycles + X
where X can be 4 to 16 cycles i guess. In which case the minimum would be 32 cycles and not 26 cycles as i read somewhere.
But honestly i am not very confident in my description... I just know some people reported measuring different timings for interruption so the bus acknowledgment is probably the reason. Need more tests !

Quote:

---

Originally Posted by ComradeOj

Thanks!

Yeah, it probably has room for improvement. A big part of the 60-75% is because the demo does horizontals and verticals independently, therefore has to to everything twice. If it only did the effect only on 1 axis or just did the both directions with the same calculations, it would run faster. I could also have the hblank routine called every other line, instead of every line. That would save a lot of cycles, and only look a little bit worse. I might also try experimenting with replacing the multiply instructions with left shift instructions, since they are a lot faster.

I actually have implemented the effect into two different games I'm working on with pretty good results.

---

If you don't mind, how about a discussion to speedup your routine? Optimizations are always fun (and 65-75% is a heafty chunk of cpu time) :)


There's two ways to attack this; low level and high level. What I mean by that is, low level is clock cycle counting and ways to reduce it on an instruction level (finding the best or fastest instructions for the job), and high level is re-approaching your idea that translates into less work.



I'll start with the immediate low level stuff you can apply:

For a nice speed up, use the WORD address mode to cut down on 1 extra bus cycle (which usually translates into 4 cycles).

Stuff like move.w hblanks,d0 can be optimized to move.w (hblanks).w,d0 . Your assembler might automatically do this, but it's best to force it (I hate when assemblers pick opcodes it thinks are best!). This type of addressing is signed, mean 0-32767 value is rom (the start of rom, nice for fast table rom access too), and negative values are ram (the upper 32k of ram, because of how it wraps on the address range). Just make sure your variables are declared/defined in this range of ram. Hopefully the assembler is smart enough to realize when a variable isn't defined inside this addressing range, and throws a warning for you (just in case, you never know).

You have quite a few instances of loading variables, so this address mode would save about 4 cycles per instance.

Second, bsr/rts are rather slow to begin with (IMO), and in your code they aren't necessary at all for this routine. You're wasting 68 cycles every scanline (18*2 + 16*2). You'll save 12% cpu resource per frame just right there. Get ride of the bsr/rts and move both sections of code right after "add.w #$01,hblanks".

Let's see. add.w #$01,hblanks is 24 cycles. You can cut that down to add.q #$01,(hblanks).w , which is 16 cycles.
move.b speed,d1 is done twice. It only needs to be loaded once since D1 isn't modified. It's subtracted by #$01 in the next routine, but have that be the second routine in the listing (not the first). So that removes one redundant load, and you can optimize the second as move.b (speed).w,d1 for more savings.




For high level stuff, I would move the hscroll update routine out of the h-int routine. The Genesis has scroll ram for this, so you're just wasting cycles this. With using the tables, you don't have a move.l #$40000003,(a3) every scanline (which is 20 cycles) or every write.



For an even higher level optimization, re-think the multiplication:

If you think about it, multiplication is a function of reiterating accumulation; it's adding X <n> number of times. In this context, the multiplication is a scalar effect. Well, since you are drawing out something sequentially, you can adapt this same idea to the concept of what multiplication is; you can exploit the nature of the linear/sequential operations. Think of it like scaling a waveform along the time axis. You can do this with a fixed point counter. Umm.. you probably should look up Phase Accumulator. How can I explain this... you have a pointer and you have an accumulator. Both are fixed-point variables. For each iteration, you added the accumulator value to the pointer. The pointer is either an index into an array of data, or a direct value for something. In this case, the value is directly be applied to the scroll value for X or Y. If the accumulator is fractional (a<1, a=/=0), you're expanding the range. If the accumulator is a whole number + fractional (a>1), then you're compressing the range. This means you don't need a MUL every access, nor do you need any shifts either. That's a decent savings. You build the accumulator value only when the scale factor changes. Of course, you'll need two accumulators (since you're correcting X for the scale state of V). I mean, you're doing a linear scale. But if you wanted, you can still use a phase accumulator for non linear scaling as well (think about it; linear means the accumulator never changes. Non linear means the accumulator is changing as it's accumulating; the accumulator itself is accumulating!).

I probably suck as explaining this stuff adequately. But once you understand it, you'll realize how simple the concept is.

Anyway, that's my take on it. Anyone else want to chime in?