Multicolor mode - the mode everybody wants

[artrag]

Pre-loading up to 8 frames in VRAM could allow ANY frame rate.

[+hloberg]

Anyone ever play Atari 'the Eidolon' with it's crude 3-d cavern. I would think the caverns would be good fit for the multi-color mode.

http://youtu.be/E9cTvuwYi3w

[RXB]

Looks like Wolfenstiene in a way.

[artrag]

If I understand correctly tiles up to 191 are used to show a single picture

 

Just a question: would it be possible to use tiles from 192 to 255 to show other pictures instead of changing r4 ?

Edited August 13, 2014 by artrag

[Asmusr]

If I understand correctly tiles up to 191 are used to show a single picture

 

Just a question: would it be possible to use tiles from 192 to 255 to show other pictures instead of changing r4 ?

 

Yes, but the 64 tiles you have left are only enough for 1/3 picture.

[artrag]

In this case it is probably simpler to store the frames in different "pages", it would allow to have 8 frames. The spare room has to be used for sprites and for PNT

[+nanochess]

I went crazy searching for this MSX game. The name is not easy to remember

 

Iligks episode IV, also known as Illegus. It uses the multicolor mode.

 

https://www.youtube.com/watch?v=ZCeaUfUJvbw

[Willsy]

Very good frame rate.

[+hloberg]

Very good frame rate.

think you get same frame rate using on the TI. also, does the MSX access the video memory via some DMA or like the TI99 does.

[Tursi]

The MSX has port-mapped access to the VDP just like we do, but the Z80 has a much higher effective processing and memory copy speed than the 9900. They can push the VDP to the edge, we have trouble even generating an overrun.

[+OLD CS1]

The MSX has port-mapped access to the VDP just like we do, but the Z80 has a much higher effective processing and memory copy speed than the 9900. They can push the VDP to the edge, we have trouble even generating an overrun.

 

We can still try I saw another MSX game called Zanac which looks like it would make a really good TI port.

[artrag]

Zanac this ?

 

https://www.youtube.com/watch?v=lRR7N363wPc

[artrag]

 

Yes, but the 64 tiles you have left are only enough for 1/3 picture.

Just an idea: why not spending this extra room to render and store a frame larger than 64x48 ? This could allow a limited scrolling whne the ship moves across the screen

Possible sizes could be:

- 64x64 => only y scrolling

- 84x48 => only x scrolling (it uses 2016 bytes instead of 2048)

- 72x56 => limited x/y scrolling (it uses 2016 bytes instead of 2048)

 

It could be shown by changing the PNT only, allowing to have a x/y movement while the tunnel scrolls

Edited August 13, 2014 by artrag

[RXB]

Zanac this ?

 

https://www.youtube.com/watch?v=lRR7N363wPc

This looks like the game Quintion wrote called War Zone 2

[+OLD CS1]

Zanac this ?

 

Yup.

 

Edit: Though I am not certain we can keep up with all the sprite action on the screen.

[artrag]

First attempts in multi-color mode, 7 frames pre-loaded in vram

Edited August 16, 2014 by artrag

[artrag]

Humm... how do you attach gif pictures in atariage ?

It seems that linking them from google sites does not make them visible to all users

[+nanochess]

Humm... how do you attach gif pictures in atariage ?

It seems that linking them from google sites does not make them visible to all users

 

Use the "More reply options" button and annex the GIF as a file. Don't forget to click in Attach File.

[+OLD CS1]

It does not animate for me. When I save it, it is just a single frame.

[Omega-TI]

Zanac this ?

 

https://www.youtube.com/watch?v=lRR7N363wPc

 

This reminds me a little bit of an early concept of a PC game that came out later called Raptor: Call of the Shadows.

It would be an AWESOME port to the TI without a doubt. I bet if done correctly it would even give TI-Scramble or Road Hunter some competition.

[Asmusr]

It does not animate for me. When I save it, it is just a single frame.

 

Same for my now, but earlier today I could see a tiny little animation.

[artrag]

I could have fixed, anyway here the gif should be attached to the post.

 

Edited August 17, 2014 by artrag

[artrag]

Maybe in this way it could work:

 

 

What I need is to find an efficient way to store scaled version of the spinning asteroid in rom and compose 2x2 sprites 16x16 when its size passes the 16x16 limit.

The main ship takes 20 sprite positions out of 64 (two layers).

 

The I/O can be totally devoted to update the sprite definition of the asteroids and the SAT.

A single asteroid can need up to 4x2 = 8 sprites to be updated (256 bytes) so I think in the end the max number of asteroid on msx will be about 3 (msx can move more than 768bytes per frame, but in the end there will be bullets explosions etc etc...)

With 3 asteroids 3x8 = 24 positions of the SPT have to be taken (44 out of 64 in total)

 

On the screen we would have 2 main ship + 24 for asteroids = 26 SAT positions used

There would be room for 6 extra sprites to be spent with bullets and explosions... doable, maybe with flickering (for the 5th sprite limit) but doable

[artrag]

About distance and scaling, this should be the table for asteroids:

Z Scale = fix(32/(1+z))

0 32

1 16

2 10

3 8

4 6

5 5

6 4

7 4

8 3

9 3

10 2

11 2

12 2

13 2

14 2

15 2

16 1

17 1

18 1

19 1

20 1

21 1

22 1

23 1

24 1

25 1

26 1

27 1

28 1

29 1

30 1

31 1

There are only 10 different sizes:

1 2 3 4 5 6 8 10 16 32

that reduce to 9 as asteroids of 1x1 pixels and of 2x2 pixels are a single point and where only the last size would need 2x2 sprites, all the others fit in a single 16x16 sprite (except for the second color layer).

The table becomes:

Z= 0 1 2 3 4 5 6 7 8 9 10

Scale= 32 16 10 8 6 5 4 4 3 3 2

assuming scale = 1 for Z>10

Some problems could come from occlusion: a possible solution could be to sort sprites on Z and place them in descending order in the SAT, some clever algorithms exist when you have to update an already sorted array instead of sorting it all the time, so also this issue could be solved.

About perspective, all items should have their x and y scaled according to their z with these formulas

x_screen = fix (x/(1+z));

y_screen = fix (y/(1+z));

If we restrict to items that fall in a box of [ -127,128] x [ -127,128] around the center of the screen (those that will actually hit the screen) the formula can be

x_screen = x * s/128;

y_screen = y * s/128;

where s= fix (128/(1+z)) can be precomputed: only 64 values are actually meaningful, where if z>=64 we can assume s=0

Edited August 18, 2014 by artrag

[artrag]

Demo disk with the sole tunnel (use bluemsx or openmsx do see it). The code is few lines of basic:

10 SCREEN 3,2: COLOR 15,0,0
20 BLOAD "data0.bin",S,&H800
30 BLOAD "data1.bin",S,&H1000
40 BLOAD "data2.bin",S,&H1800
50 BLOAD "data3.bin",S,&H2000
60 BLOAD "data4.bin",S,&H2800
70 BLOAD "data5.bin",S,&H3000
80 BLOAD "data6.bin",S,&H3800
90 VDP(2)=0:VDP(6)=0
100 N=0:M=0:' initialize the PNT
110 FOR K=0 TO 5:
120 FOR I=0 TO 3:FOR J=0 TO 31:VPOKE N,M+J:N=N+1:NEXT:NEXT
130 M=M+32:NEXT
140 VPOKE &H1B00,&HD0:' remove sprites
150 ' actual main
160 FOR I=1 TO 7
170 GOSUB 210
180 VDP(4)=I
190 NEXT
200 GOTO 160
210 ' delay: wait for two vblank
220 TIME=0
230 IF TIME <2 GOTO 230 ELSE RETURN

I had to overlap the PNT with the SPT at 0x0000.

This means that the first 768 bytes of the sprite definition table are wasted and that only 40 positions are really usable.

On the other hand meteors use 2x2 = 4 sprites (8 due to the black layer) only at Z=0 (i.e. at their max dimension) where they fit in a single sprite (2, due to the second color) at the other scales, so things should stay manageable if also the main ship is updated on fly.

In average we should update about (2+3*2)*32 = 256 bytes per frame except when an asteroid reach Z=0 when you need extra 3*2*32=192 bytes.

The other option would be to use just 6 frames of animation instead of 7, and store the main ship steadily in VRAM, and probably this could the best option for the TI 99/4A that has less bandwidth.

 

 

 

tunnel.dsk