Horizontal interrupts to stretch image?

[matteus]

Recently watched the how too on the travellers tales sonic 3d fmv intro. Jon notes that they used a 256 X 80 resolution and then used horizontal interrupts to stretch the image by 2 and half times it's size.

Question how the heck do I do this with an image in the SGDK? Can I even do this?

[cero]

I guess you mean stretch vertically? Add a horizontal interrupt callback that sets the line scroll accordingly, and you can double every scanline, or do other such things.

[matteus]

Sounds complicated I don't suppose there is any example code around here?

[cero]

It is an advanced technique, there can't really be an example for every such thing, especially with the small community.

[Miquel]

If I remember correctly there is a function pointer to be used for those reasons, just change the vertical scroll then, but you need a new scroll value for each call, better having it pre-calculated.

Depending on your situation, perhaps it's wiser to simply enlarge your image accomplishing better resolution.

Having hblank interruptions for every line takes about 50% of the cpu, in your case you will need every two, so about 25% of the cpu will be gone this way.

[Manveru]

I think that trick is something like the "axelay effect" in some games like Jurassic park, Vectorman or Pier solar.
For Sonic 3D example, it is all about setting the vscroll offset at current + 1 in the even scanlines, so it will draw again the last odd scanline.

[Sik]

If I remember correctly there is a function pointer to be used for those reasons, just change the vertical scroll then, but you need a new scroll value for each call, better having it pre-calculated.

Or calculating it outside hblank where timing is not an issue (i.e. in the main "thread", or during vblank) and storing the results in RAM. Although in his he just needs to stretch an image so probably the values remain fixed and can be stored in ROM.

Depending on your situation, perhaps it's wiser to simply enlarge your image accomplishing better resolution.

He's short in memory.

Having hblank interruptions for every line takes about 50% of the cpu, in your case you will need every two, so about 25% of the cpu will be gone this way.

It definitely takes a lot of CPU time (just jumping into the handler eats up about 10% of the scanline) but I doubt it needs that much. Then again maybe SGDK makes it take longer through overhead =P

[Miquel]

I don't use SGDK, but tried several minimalistic techniques for the H exception.

What I did is test how many Actors can I put running together without frame loses and was about half of the original value. Not a deterministic calculation but.

For example Outrun (arcade) has two 68K, and one basically all it does is wait for H exceptions and change horizontal scroll accordingly whit a pre-computed table, while the other does the game mechanics.

Back on MD, it's really a disgrace that Z80 can't access the VDP, much better car game can be produced then.

[Stef]

SGDK will cause an important overhead for sure as it uses an internal callback then call the "user" callback from it (use SYS_setHIntCallback method for that)... If you really need to have fast hint callback, just place code inside the _HINT method of sega.s file. If you cleverly optimize your H-int code (basically you need a single 32 bit RAM read / VDP write operation) you can probably end up without more than 30% of CPU time used.

[Sik]

Maybe a better method would be to reserve a small amount of RAM (say 128 bytes) and then copy the hblank handler directly into it, then point the hblank vector there. Sure, somebody could pass a handler that's larger than that, but it's probably safe to assume such a handler is doing something that runs across several line and hence a jump doesn't harm (in that case just put a trampoline as the handler). The big advantage is that you can swap handlers at will to use different effects across the game.

The big issue would be how to handle that from C. You need to get the size of the function somehow (even if just to check if it'll fit), and also make sure GCC actually compiles it as an interrupt handler (i.e. don't clobber registers and return with RTE). This is likely more feasible with handlers written in asm, which you probably want for timing reasons anyway.


Also tsk, SGDK maybe should include some premade handlers for common effects and have functions that just set them up :v (blasting a table to vscroll like in this case could be one, maybe also one that swaps all palettes mid-screen like in Sonic games, etc.).

[Miquel]

Sik what you say is more or less what I did:
Exception vector points to an u16 array on RAM. There are several functions that fill that array, for example:
- Simply call a procedure from a function pointer, so a C function can be used. Excellent for testing new things.
- Modify a value of vertical scroll for both planes, in two pieces. The first one is simply a group of three MOVE's with an immediate value to modify scroll, the second part is a self modifying code to change the mentioned immediate values for next exception.

I tested several other configurations, but this two are the ones I fond most useful. Unfortunately, currently I don't use any of them for my actual project.