# Idea for math experts...

Page 1/9
| 2 | 3 | 4 | 5 | 6

I've seen that many people around here have liked very much these 105 color picture tricks for MSX1. Makes me wonder how about MSX2... Maybe people would like to see beautiful pictures on this platform as well?

So here we go... My idea of cute picture is not interlaced SCREEN 7 picture with 512 colors. How ever because I'm not too familiar with color reduction algorithms, dithering etc. stuff I'll leave this side open to anyone who is interested, I'll just show my idea of the way how to do it. So here we go...

When thinking about source format I suggest reading 24 bit BMP picture, because it is ideal for this kind of stuff. Just throw away header and you have RAW data that has one byte for each R,G & B value. For this purpose it is enough to take just 3 most high bits of each byte. Remember anyway that in BMP file the picture is upside down, so last line is actually first.

Here are the steps how I think conversion should be implemented: (Not 100% accurate, but I'm sure you'll get the idea)

- Select 16 colors that are best for representing the last line in picture (512 dots)
- Select 12 colors from generated pallette that are best for representing second last line in picture
- Select 4 colors that would be best with the existing 12 colors to form the second last line
- Check that these new selected colors are not same as the colors you did not select. If the colors are same, make sure they end up with same color number they were previously using. Mark these colors also with "no change" flag or something similar.
- Repeat last 3 steps untill you are in top of picture.
- Save the pallette you ended up (first 16 * %0RRR0BBB, %00000GGG of data in example display routine)
- Convert the first line of picture without using the colors that are going to be changed for next line. Only if these colors are marked with "no change" flag you can use them.
- For example display routine save pallette changes in following format after the exisiting pallette data: %0000CCCC (C=color number), %0RRR0BBB, %00000GGG
- Repeat 2 last steps untill you are in last line. In last line you can freely use all 16 colors.

What we end up is a picture where each line contains 12-16 unique colors. The total number of colors depends of the picture. Basic idea is, that the pallette is newer visually changed on color that the VDP is displaying.

If you want to improve this idea even further I think that you can define even 5 colors / line, but I think you'll end up just having more "no change" flags.

I think better idea is to split the picture in right and left side and think only 2 different changeing colors. This way you can define a color for example in left side of screen and use it on right side. You can go even further... In theory it should be possible to have even more than 16 colors in one line still without flickering!

BTW even that I've been talking about 16 colors all the time, you may want to keep one color solid in order to have one color backround.

If you like interlaced pictures then you can run this algorithm for odd and even lines separately. You can check wich pallette set should be used by reading VDP status register 2 bit 1.

You may also want to generate more colors using similar trick that was used in those MSX1 demos. Feel free, if you are skillfull enough...

Anyway... I'll leave future development for you... Here is the very simple example display routine for these kind of pictures:

```
DEFW BEGIN
DEFW END
DEFW START

ORG #D000
; 16 * %0RRR0BBB, %00000GGG (32 bytes of first line pallette)
; lines * 4 * %0000CCCC, %0RRR0BBB, %00000GGG (12 bytes / line)

BEGIN:
START:

LD A,(#2D)
CP 3
LD A,#80
CALL Z,#180 ; Change to Z80 if MSX tR

DI
IN A,(#AA)
AND #f0
or 8
OUT (#AA),A

LD A,#90	 ; PALETTE register
OUT (#99),A
LD A,#91
OUT (#99),A
AGAIN:
XOR A
OUT (#9B),A
LD HL,DATA
LD BC,#209A
OTIR	; First palette

LD A,0
OUT (#99),A
LD A,#8F
OUT (#99),A

WAITLINE0:
IN A,(#99)
RRA
JP NC,WAITLINE0

LD A,2
OUT (#99),A
LD A,#8F
OUT (#99),A

LD D,212	; Number of lines

WAIT:
IN A,(#99)
AND 32
JP Z,WAIT

INC C
OUTI
DEC C
OUTI
OUTI

INC C
OUTI
DEC C
OUTI
OUTI

INC C
OUTI
DEC C
OUTI
OUTI

INC C
OUTI
DEC C
OUTI
OUTI

DEC D
JP NZ,WAIT

NEXT:
IN A,(#A9)
AND 1
JP NZ,WAITLINE0 ; SPACE pressed?

EXIT:
XOR A
OUT (#99),A
LD A,#8F
OUT (#99),A
EI
RET

END:
```

There is a program that does this already, for Amiga at least. It's called HamLab. It will take any image and break it down into 16 colors with a certain number of colors allowed to change on each line. The result can be saved as an .IFF file.

Ah, good!

Amiga has 4096 color pallette, so the result is not optimal, but I think this could give a nice result anyway! Definately worth of trying. Now all we need is some Amiga owner that would convert us some PCHG-pictures and we can start enjoying new level of graphics quality.

I had a drawing program for Atari ST that did the same thing. Actually if I remember correctly the Atari ST version mixed two images, so it did sortof the same thing as the 105 color images and also switched palette on the two images every scanline. Can't remember what the program was called but the result was quite good.

how unfortunate the palette is stored in registers and not in vram. anyway, someone know if you can change the screen mode on vblank without the screen flickering?

what you could do is interlace screen 8 and screen 7. making it many colors and high resolution at the same time. where screen 7 is used to change the color of the left and right side of a screen 8 pixel.

it's just a thought... probably doesn't add too much quality to a screen 8 image anyway, lol

I have an amiga what would you want me to convert?Something specific?

HAM6 display mode in Amiga has a very complex structure, and is bitplane based, so I don't think will be easy to use it for this. And, in fact, it is not adequate, as this Wikipedia article about HAM screen modes clarifies.

By the way, as it is usual for MSX1 users to complain about the screen 2 color clash, Amiga users complain about the bitplane structure of graphics in Amiga (requiring to update 8 bytes when plotting a single pixel in 256 color mode).

Well, there're several ways to avoid the drawbacks of Amiga's bitplane structure, in fact thanks to the blitter is an advantage. You can freely define your own screen structure and how the 5 bitplanes (for the typical 32 colors mode) are ordered to let the blitter manage a full software sprite (or "bob" as they're called in Amiga) in only one operation. The copper+blitter combo is the most powerful video managing system I've ever seen!.
Side note: There's no 256 color mode on Amiga. The higher modes are extra halfbrite (64 colors) and HAM (4096 colors)

I was refering to AGA modes, in this case. And the "incompatiblility" of HAM6 for this is still valid, isnt it?

Nice idea but the problem is that the VDP and Z80 are not exactly fast. From what I remember of the old demos days, I think you could only do so many "out" during one scan line and it was possible to change a maximum of 5 colors per line (4 on a Turbo R due to the extra wait states). I am not really sure about the numbers but anyway, there is no way you'll be able to change all of the 16 colors at every scanline

what you could do is interlace screen 8 and screen 7. making it many colors and high resolution at the same time. where screen 7 is used to change the color of the left and right side of a screen 8 pixel.

I think this would look quite good even with a fixed screen 7 palette. Not sure if Prodatron reads this but the palette used in the Symbos images are probably a good one to choose.

The images in Utopia uses a similar technique. Its mixing screen 2 and screen 3 images to get big images with decent resolution.

Page 1/9
| 2 | 3 | 4 | 5 | 6