/tech/ - Technology★

Can't you just oscillate the vertical scale using a plain sin function / some other function which bounces between 1 and -1?

You would also need to make sure that the text is always vertically centered too.

I'll explain this FPP routine. FPP itself is a fucking clever trick, but all the magic is still in these tables.

On C64 you have 8 sprites and they have their registers like X/Y position, double width, double height, the color etc. Sprites are 24x21 pixels. There's a bug in the VIC that allows you to stretch the sprites. It's done be just turning on and off the double width register for the sprite you want to stretch, it will display the same line again, not incrementing the pointer that points to the new line of graphics. Why exactly it works like this you can read in the VIC article (among other things about the VIC)

http://www.zimmers.net/cbmpics/cbm/c64/vic-ii.txt

So what do you do with that ? You can line up 8 sprites and stretch them for however you want (set / unset double width register on every line) but that will just display the same line of graphics on the same screen. But... you can change the pointer to the sprite graphics on every line too. So you stretch (like I do for 120 lines) and on every line you change the sprite pointer to one of 21 sprites. Each of these 21 sprites has it's first line filled with graphics, the rest is blank. (C64 effects fragment your memory like motherfucker !) So now by selecting on of the 21 sprites you can pick any line of graphics on any line on the screen. But that's for one sprite, we want more, preferably all of them. How ?

You place 8 sprites next to each other, each 1 pixel higher. and you start doing the FPP routine at the line where sprite 1 begins.

Now you are stretching the 1st line of sprite 1, second line of sprite 2, third line of sprite 3 etc... Now you can prepare 21 sprites where the first 8 lines are the lines of graphics for your 8 sprites and you can do a 8 pixel wide graphic that way ! For this effect I have to read the font and create such sprites on the fly.

>>922861

Why do you post 3 times ? Keep in mind I am on a 8 bit CPU without any multiplification or division. I also have about 10-15% of the CPU time to calculate this table, the rest is spent on the basic effect and updating the font.

>>922862

>Why do you post 3 times ?

I edited my post twice to be more specific. Refresh the page and the other two will disappear.

If you want to rotate along the X axis, you need to be able to stretch vertically. Figure out yourself how to accomplish that; drawing a subset of lines that is centered vertically.

>Keep in mind I am on a 8 bit CPU

Not my problem you chose weak hardware to make this on even though better hardware is available for low prices.

>>922867

So are you looking for a rotation that is in perspective or orthogonal?

>What were you thinking

It sounded like you were complaining about it being to heard to do since the hardware you are running is limited. If you are making a demo for it, you set this difficulty upon yourself so you shouldn't complain.

>>922867

>I want to calculate it real time so I can control the speed and direction.

It's been forever, but on PC for effects like that we'd calculate (on startup) a fixed 256 entry table that was a shitty approximation of sin() which got used for everything involving rotations. Pulling out a value was via adding to a counter per frame that would be shifted to use as an 8 bit index into the table, allowing for it to go slow enough to reuse the same value across multiple frames. And for oscillating rotations the value added to the counter would be chosen this way too. Then to add the extra twisting you'll see on a lot of these it would also add an additional increment per scan line.

>>922885

I'm using precalculated sin tables too, I just don't know what to do with these values to calculate the rotation.

By using the sinus values as the line numbers themselfs (especially 2 added sinuses with different increment values) gives cool results, but not this.

The blinds or stretching in the video I posted in OP uses such tables of course, for the blinds the value read is how many lines of screen to skip and for stretch how many times should the same line be displayed (or to be more precise, it is used as jmp address into unrolled constant graphics setting routine, so if you jump further you draw less lines and you can also draw lines "upside down")

>>922884

I'm not complaining, I'm saying your proposition won't work in this computer.

Here's a snippet of code that calculates the "blinds" effect

FppCalcSub:	
// the graphics start from 128 and go up to 149, 128 is the first line. 128+22 is blank line
	ldx #128
// index to the sinus table
	ldy FPP_TABLE_INDEX_1
	clc
-:
// loading the skip value (0-5) and adding it to the FPP_TAB pointer. FPP_TAB is this 120 bytes table
// that decides what graphics are displayed on which line
.tablePtr = *+2
	lda fppSkip_good, y
// if zero skip addition (too little raster time to do this for all the lines)
	beq +
	adc .FppStore
	sta .FppStore
+:
.FppStore=*+1
	stx FPP_TAB
	
	iny
	inx
	inc .FppStore
// if still not 21th line of graphics, go back and keep on drawing
	cpx #128+22
	bne -
// restore the pointer to FPP_TAB (#< means the low byte of the 16bit addr)
	lda #<FPP_TAB
	sta .FppStore
	inc FPP_TABLE_INDEX_1
	bne ++
// switch the inc to dec and vice versa if the counter wraps to zero to spice up
// the movement paterns
.incPtrTable=*
	inc .tablePtr
	ldx #$ee ; inc $xxxx opcode
	lda .incPtrTable
	cmp #$ee
	bne +
	ldx #$ce ; dec $xxxx opcode
+:
	stx .incPtrTable
++:
	
	rts

>>922891

>I'm using precalculated sin tables too, I just don't know what to do with these values to calculate the rotation.

When I last did it I was too young to understand trig so I just winged it. But today it should be easy to understand. Just look up how to do rotations and projections, I'd recommend looking into doing it with a linear algebra rotation matrix since matrix math comes into play in a bunch of things (e.g. convolution kernels for the classic PC bouncing lens effect). Do the math in something convenient like python, then translate what you find works to your code. Everything can be written in terms of sin/cos and then those can be replaced with lookups into your approximation.