Jump to content

Multicolor mode - the mode everybody wants


Recommended Posts

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.

Link to comment
Share on other sites

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 :D I saw another MSX game called Zanac which looks like it would make a really good TI port.

  • Like 1
Link to comment
Share on other sites


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 by artrag
Link to comment
Share on other sites

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




  • Like 1
Link to comment
Share on other sites

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 by artrag
  • Like 2
Link to comment
Share on other sites

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:
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

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.





  • Like 2
Link to comment
Share on other sites

  • The title was changed to Multicolor mode - the mode everybody wants

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...