Rotating map demo

[Asmusr]

Yet another demo - I don't think we have seen anything quite like this on the TI before.

 

 

The speed is quite good at 20 FPS, but could it be used for a game?

ROTATE.dsk

[mantadoc]

Wow wild stuff very nice

[+Schmitzi]

uiiih rollercoaster

[ti99iuc]

Very nice ! i never seen something like this for sure on the TI-99/4A ... great...

 

the latest little Demos you done Rasmus, seems like an hope that a good real FIRST demoscene for the TI-99 is coming

Edited March 18, 2021 by ti99iuc

[Tursi]

Very nice.

 

Thinking of game aspects... I wonder if you could adapt it slightly for a "mode7"-like projection and get a pseudo 3D road map up there. I haven't /done/ it, so I'm not quite sure, but just changing the scale each line seems like it'd work... and you only have to draw half the screen in that case.

[+save2600]

Wow! Never thought I'd see Mode 7 graphics on the TI! Immediately thought of the sky dive sequence in Pilot Wings and could totally see this being used to create a TI Kart's racing game.

[Willsy]

Great demo. Didn't someone do a plasma style demo on the ti a while back?

[ralphb]

Great demo!

 

Is plain scrolling faster then zooming or rotating i.e., could you go faster than 20 fps when scrolling? And if you used high color mode, would the result be 5 fps, or actually faster?

[Asmusr]

Great demo. Didn't someone do a plasma style demo on the ti a while back?

 

I did a plasma demo, but that was using the F18A.

[Asmusr]

Great demo!

 

Is plain scrolling faster then zooming or rotating i.e., could you go faster than 20 fps when scrolling? And if you used high color mode, would the result be 5 fps, or actually faster?

 

Plain scrolling of the name table could easily be done at 60 FPS. I have had an idea of doing a very fast character scrolling game for a while.

 

Multicolor mode is 1536 bytes (as opposed to the 768 bytes of the name table) and requires 2 pixels to be packed into one byte, so it would be slower. See:

http://atariage.com/forums/topic/228454-multicolor-mode-the-mode-nobody-wanted

[Asmusr]

Very nice.

 

Thinking of game aspects... I wonder if you could adapt it slightly for a "mode7"-like projection and get a pseudo 3D road map up there. I haven't /done/ it, so I'm not quite sure, but just changing the scale each line seems like it'd work... and you only have to draw half the screen in that case.

 

I never heard of mode 7 before, so I had to look it up. Yes that might be possible. The cost of re-scaling each row should be more than compensated for by not updating the entire screen.

[Asmusr]

I have attached the source code.

 

This is the central loop that draws the screen:

       LI   R15,24                     ; Row counter
FRAME1 LI   R14,32                     ; Column counter
       MOV  R12,@X                     ; Save X
       MOV  R13,@Y                     ; Save Y
*      Upload byte
FRAME2 MOV  R13,R1                     ; Y
       MOVB R12,@R1LB                  ; YX
       ANDI R1,>3FFF                   ; Wrap Y to 64
       MOVB @MAP(R1),*R0               ; Send to VDP (R0 is VDPWD)
*      Next position
       A    R3,R12                     ; X += cos(a) * scale
       A    R2,R13                     ; Y += sin(a) * scale
*      Column loop
       DEC  R14                        ; Column counter
       JNE  FRAME2
*      Row loop
       MOV  @X,R12                     ; Restore X
       MOV  @Y,R13                     ; Restore Y
       S    R2,R12                     ; X -= sin(a) * scale
       A    R3,R13                     ; Y += cos(a) * scale
       DEC  R15                        ; Row counter
       JNE  FRAME1
       B    *R11

(looking at the code now I see I could save a little bit of time by saving X and Y in registers)

 

X and Y are stored as 8.8 fixed point values, so the integer part is simply the MSB. And because the map is 256 bytes/characters wide, all the takes to generate an offset is to use integer Y as MSB and integer X as LSB. The ANDI R1,>3FFF is required to wrap the vertical edges of the map, but could be left out if the map had boundaries. To move (X,Y) to next column you simply add (cos(a) * scale, sin(a) * scale) and to move to the next row you add the orthogonal of this vector (-sin, cos).

 

I have a question about the MPY instruction: From what I can read in the E/A manual page 93 it's supposedly for unsigned values, but I have used it now for several projects on signed values. The only thing is that it overflows more easily on negative values because of the sign bits. Is that what it means that it's for unsigned values?

rotate.a99

map6.a99

[+Lee Stewart]

...

I have a question about the MPY instruction: From what I can read in the E/A manual page 93 it's supposedly for unsigned values, but I have used it now for several projects on signed values. ...

 

The TMS9900 Data Manual says this, as well.

...

The only thing is that it overflows more easily on negative values because of the sign bits. Is that what it means that it's for unsigned values?

 

How are you getting the MPY instruction to overflow when no status bits are affected by it? It is impossible for the MPY instruction to overflow. That is why status is unaffected. The largest unsigned, 16-bit number, FFFFh, when multiplied by same, is FFFE0001h (the unsigned, 32-bit result), which can neither carry nor overflow. The fact that the leftmost bit is set is the only reason we might consider the number negative.

 

...lee

[+mizapf]

I have a question about the MPY instruction: From what I can read in the E/A manual page 93 it's supposedly for unsigned values, but I have used it now for several projects on signed values. The only thing is that it overflows more easily on negative values because of the sign bits. Is that what it means that it's for unsigned values?

 

MPY is clearly for unsigned values only. The TMS9995 offers a separate MPYS (and DIVS).

 

You can only work with signed values when they are positive. For instance, multiplying -1 by -1 (FFFF * FFFF) will deliver FFFE0001 with MPY, but 00000001 with MPYS.

Edited March 27, 2016 by mizapf

[Asmusr]

 

 

The TMS9900 Data Manual says this, as well.

 

How are you getting the MPY instruction to overflow when no status bits are affected by it? It is impossible for the MPY instruction to overflow. That is why status is unaffected. The largest unsigned, 16-bit number, FFFFh, when multiplied by same, is FFFE0001h (the unsigned, 32-bit result), which can neither carry nor overflow. The fact that the leftmost bit is set is the only reason we might consider the number negative.

 

...lee

 

 

You're right, of course, that MPY cannot overflow. What I mean is overflowing into the most significant word. What I'm usually doing is to multiply two signed words, then use only the least significant word of the result. In the case of >FFFF (-1) * >FFFF (-1) the result as you say is >FFFE0001 and the least significant word is >0001, which is correct. Another example: >FFFE (-2) * >0003 (3) = >0002 FFFA, where >FFFA = -6. What I think I have found is that there is a limit to how big numbers this works for, but I'm not sure. Edit: I mean a more restrictive limit than the obvious of not being able to store the result in a single word.

[+mizapf]

This is an interesting observation. In fact, when you consider negative numbers in their 2s complement format to be subtracted from the maximum unsigned number +1, you can find:

 

0xFFFE * 0xFFFD = (0x10000 - 0x0002) * (0x10000 - 0x0003) = 0x10000^2 - 0x10000 * 0x0003 - 0x10000 * 0x0002 + 0x0002 * 0x0003

 

The first term (0x10000^2) is 0 mod 2^32, then there is (0x10000 * (- 0x0003 - 0x0002)) = (0x10000 * (-0x0005)) = 0xFFFB0000, and finally 0x0006.

[+Lee Stewart]

 

You're right, of course, that MPY cannot overflow. What I mean is overflowing into the most significant word. What I'm usually doing is to multiply two signed words, then use only the least significant word of the result. In the case of >FFFF (-1) * >FFFF (-1) the result as you say is >FFFE0001 and the least significant word is >0001, which is correct. Another example: >FFFE (-2) * >0003 (3) = >0002 FFFA, where >FFFA = -6. What I think I have found is that there is a limit to how big numbers this works for, but I'm not sure. Edit: I mean a more restrictive limit than the obvious of not being able to store the result in a single word.

 

Yes—I think the product result must be from -32768 to 32767 for your scenario to work.

 

...lee

[+Lee Stewart]

As @mizapf said, the only way to do signed multiplication is with positive numbers, which would mean the extra steps of converting to positive numbers and tracking the sign. Then, any non-zero value in the MSW of the product would indicate overflow.

 

Of course, -32768 would need to be handled as a special case because you cannot negate it in 16 bits and 32768 would be a legitimate intermediate result if the result sign were negative.

 

...lee

Edited March 27, 2016 by Lee Stewart

[Asmusr]

Of course, -32768 would need to be handled as a special case because you cannot negate it in 16 bits and 32768 would be a legitimate intermediate result if the result sign were negative.

 

I don't think you need a special case. Negating >8000 (-32768) gives >8000 (32768), which is what you want for the multiplication.

 

Anyway, it looks like I can continue to use MPY directly as long as the numbers are small enough, e.g. if both numbers are -128 < 0 < 128.

[+Lee Stewart]

I don't think you need a special case. Negating >8000 (-32768) gives >8000 (32768), which is what you want for the multiplication.

It is still a negative number; but, the effect with MPY is moot as you imply. However, I should have gone further with what determines overflow. Overflow is indicated not only by a non-zero MSW, but by a 1 in the MSb of the LSW. The special case is when the result is exactly >8000 and the result sign is negative.

Anyway, it looks like I can continue to use MPY directly as long as the numbers are small enough, e.g. if both numbers are -128 < 0 < 128.

 

Indeed.

 

...lee

[globeron]

Hope that save2600 with TI-Kart is referring to Mario Kart ?

* (the one on the RetroPie Nintendo64 (64 version) - Mario Kart, is quite fun with rotating platforms)

 

* new version of a TI-Super Asteroids ? (I got a bit the feeling like that)

 

* 3D Tetris ?

 

* or a kind of Escher game ?

[Asmusr]

Very nice.

 

Thinking of game aspects... I wonder if you could adapt it slightly for a "mode7"-like projection and get a pseudo 3D road map up there. I haven't /done/ it, so I'm not quite sure, but just changing the scale each line seems like it'd work... and you only have to draw half the screen in that case.

 

It does look a bit like a racing game, but even Pole Position looks like Full HD in comparison.

 

 

I think the best game for this technique would be a top view racing game where sprites could be used to provide some high res details.

[Tursi]

It does look a bit like a racing game, but even Pole Position looks like Full HD in comparison.

Ah, hehe!! Thanks for trying though, I got a kick out of seeing it!

[Asmusr]

This is the map you see transformed on the last video.

 

[sometimes99er]

       MOVB @MAP(R1),*R0               ; Send to VDP (R0 is VDPWD)

       A    R3,R12                     ; X += cos(a) * scale

 

The first one above is a nice one. Somehow I've never used it much and probably never in an inner loop, but it seems just fine.

 

The second one looks kickass. The comment threw me off a bit. cos(a) * scale is of course not calculated here.

 

Overall impressive framerates.

 

 

Edited April 2, 2016 by sometimes99er