How do stretch and tilt relate to perspective transforms?

[tschak909]

Stating off the bat, I may be in way over my head. That's ok, wouldn't be the first time.

 

Have been trying to use Suzy to blit a checkered playfield as a ground plane using stretch and tilt, and I'm scratching my head trying to figure out how those two additional parameters, along with the scaling and position, affect potential perspective transforms (e.g. making "floors")

 

This is the image I am working with.

img_playfield.bmp

 

Is there a concise description of the relationship of these parameters buried deep in the developer docs, or...?

 

-Thom

 

[laoo]

Are you aware of https://atarilynxdeveloper.wordpress.com/2012/10/14/programming-tutorial-part-8changing-appearances/ and https://atarilynxdeveloper.wordpress.com/2012/10/31/programming-tutorial-part-9advanced-sprites/

 

?

 

Edited June 11, 2022 by laoo

[tschak909]

2 minutes ago, laoo said:

Are you aware of https://atarilynxdeveloper.wordpress.com/2012/10/14/programming-tutorial-part-8changing-appearances/ and https://atarilynxdeveloper.wordpress.com/2012/10/31/programming-tutorial-part-9advanced-sprites/

 

?

 

yes

[laoo]

If reading it again does not help you can always read the source code of the emulation.

[42bs]

Quote

Horizontal Stretch

The horizontal size of a sprite can be modified every time a destination scan line of that sprite is processed. This includes scan line processing while the actual sprite is off screen. The modification consists of adding the 16 bit stretch value ('STRETCH') to the 16 bit size value ('HSIZE') at the end of the processing of a scan line. If the stretch value was 0, no effective modification occurs. This modification only takes place if enabled by the reload bits in SPRCTL1. Since the STRETCH 16 bit value consists of 8 bits of size and 8 bits of fraction, the stretch increment can be as small as 1/256 of a unit size and as large as 128 unit sizes. A STRETCH value of >128 unit sizes will cause a wrap in the ALU and result in a size reduction.

Vertical Stretch

The vertical size of a sprite can be modified every time a destination scan line of that sprite is processed. The specifics are the same as those for horizontal stretching. The value used is also the same as that used for horizontal stretching. Vertical stretch can be independently enabled or disabled. Even though the stretch factor is added at each destination line processing, the new vertical size only takes effect at the next source line fetch.

T i I t

The horizontal position of a sprite will be modified every time a scan line of that sprite is processed. This includes scan line processing while the actual sprite is off screen. The modification consists of 2 steps. The first is to get the 8 bit integer tilt value by adding the 16 bit tilt value ('TILT') to the tilt accumulator ('TILTACUM') at the end of the processing of a scan line, and shifting the answer to put the upper 8 bits in the lower position. The second is to add that integer to the horizontal position of the sprite ('HPOSSTRT'). This modification only takes place if enabled by the reload bits in SPRCTL1. The increments and negativeness are the same as for the stretch bit. Positive values of tilt will cause a tilt to the right. If the sprite is painting to the left (either due to flip or quadrant), then the software will have to set a negative tilt value if left tilt is desired.

 

[42bs]

Also

https://github.com/42Bastian/lynx_hacking/tree/master/248b/lovebyte21/LyLoBy

 

[42bs]

33 minutes ago, laoo said:

Are you aware of https://atarilynxdeveloper.wordpress.com/2012/10/14/programming-tutorial-part-8changing-appearances/ and https://atarilynxdeveloper.wordpress.com/2012/10/31/programming-tutorial-part-9advanced-sprites

'Tilting like a pinball machine'

The description is wrong!

Stretch affects the size. So a sprite of size $100 with six pixel will be 12 pixels wide in the next line if stretch is $100.

[Positron5]

OK  I'll bite.

If you are after the Ballblazer playfield effect then a method like the one
I used on the atari 8bit would do..

Take a sprite like this one for a space harrier background:

harr_playf_1.pcx

 

With the tilt capability of the lynx you could tilt this image through 2 "segments" then switchback to original image.

That takes care of horizontal parallax.

To simulate forward and backward movement you would need to use line interrupts to animate bands of colour down the screen.?

[LX.NET]

21 hours ago, 42bs said:

'Tilting like a pinball machine'

The description is wrong!

Stretch affects the size. So a sprite of size $100 with six pixel will be 12 pixels wide in the next line if stretch is $100.

I see that I did not explain the stretch correctly and clearly enough. I will update it at some point and make sure that the examples illustrate how stretch is added to size on each scanline. 

Thanks for pointing it out, Bastian. 

[IronWorks]

Just had a go at the Space Harrier type playfield. Using a large bitmap sprite.

I was surprised how quick it was to do.

This version uses one sprite. But probably better to cut it in half and mirror it.

Also needs a line interrupt for the vertical moving colour change.

Written using Bll assembler

chex.o

Chex.asm chex.bmp chex2.bmp

Edited June 19, 2022 by IronWorks
Clarity

[IronWorks]

More checkerboard stuff. Thought I`d try the triangle route to see how easy that was.

Using 2 single pixels of different colours stretched and tilted.

The main problem I see with it is the large amount of 2 byte adds and stores for every triangle (chex2)

The next attempt was to use 2 sixteen pixel bitmaps of alternating colours. This causes a slight visual bump. I think this is because the triangles

don`t start from the same origin.

So I reduced it to 8 pixels and this gives a better affect. You can also get away with a single byte add for tilt or use a table.

And only 2 sprites to update (chex3)

As before written using Bll, oh and `D` pad does minor stuff ☺️

 

 

 

 

 

chex2.o Chex2.asm chex3.o Chex3.asm greendots1.bmp greendots2.bmp

[42bs]

Hint: Link SCBs. So you need only one call to DrawSprite

Player_SCB   			dc.b $C0,$30,$02
						dc.w 0
Player					dc.w Player_sprite0 

=>

Player_SCB   			dc.b $C0,$30,$02
						dc.w Player2_SCB
Player					dc.w Player_sprite0 

 

No need to "cpx #$ff" after "dex"-

 

 

readstk:
    ldy tilt
	lda Cursor
	bit	#$20
	beq	joyrt
    clc
    tya
	adc #8
	tay
	bra .cont
joyrt:
	sec
	tya
	sbc	#8
	tay
.cont
    cpy #-8
	bne	.no_wrap1
	ldy	#248
.no_wrap1
	cpy #224
    bne .no_wrap2
    ldy #0
.no_wrap2
	sty tilt
	sty tilt2
    

 

Edited June 28, 2022 by 42bs

[IronWorks]

Thanks for the tips, I`ll put them in. ?

[Songbird]

Nice looking demos!

[+Stephen]

Sorry for the dumb question.  To view these, do I just use the .o file in a Lynx emulator?

[tschak909]

1 hour ago, Stephen said:

Sorry for the dumb question.  To view these, do I just use the .o file in a Lynx emulator?

yes, that works for me, in Mednafen, for example.