MSX1 entry 5th in Assembly 2009 extreme graphics compo

Page 1/2
| 2

By yzi

Champion (444)

yzi's picture

09-08-2009, 22:49

Lieves!Tuore contributed an MSX1/VDP1 entry in the Assembly '09 extreme graphics compo. The entry is called "Lievestuoreen Liisa Ihmemaassa" and it placed 5th in the competition. The full results are here.

http://www.kameli.net/lt/prod.htm

Credits:

Man: image
Yzi: converter
Marq: MSX viewer

The picture uses our new screen 2 graphics converter/viewer system, which we'll certainly use in more productions in the future. It's worth checking out on a real MSX, especially MSX1, because at least in my own biassed opinion, the graphics are among the best seen on MSX1. The best thing is, there are still many areas to improve in the converter. :D If you look at the VRAM data on an emulator, you'll perhaps notice some things. ;)

Login or register to post comments

By NYYRIKKI

Enlighted (5900)

NYYRIKKI's picture

09-08-2009, 23:14

So you really update the VRAM all the time. Smile Unfortunately this does not work on 60Hz MSX computers, but it is a really neat picture.

If I'm correct the black parts are using only one character and the not used characters hide part of the second picture. Rest of the second picture is "streamed" from RAM... It looks like this is more advanced method than what dvik used. Wink

By yzi

Champion (444)

yzi's picture

09-08-2009, 23:45

Yeah, the picture is made for PAL/50Hz machines, that's something we should have mentioned. The CPU usage limit can be freely configured in the converter, so we could have made it to work in 60Hz machines, but then we would have had to change the picture (once again).

Actually the black parts (as well as a few other non-interlaced 8x8 blocks) are using _two_ characters, even though that doesn't make any sense. Wink Well, I'll most definitely improve the converter so that it uses all available CPU and VRAM resources. No character should go to waste. Crying Marq's viewer routines probably squeeze every last drop out of an MSX1, so the improvements must be done in the converter.

By Vampier

Prophet (2386)

Vampier's picture

10-08-2009, 03:09

isn't this already done by dvik&joyrex? nice pic though

By dvik

Prophet (2200)

dvik's picture

10-08-2009, 05:45

The most advanced interlaced image viewer for MSX1 we made is the one we use for the cyborg and south park images in Utopia and the result is imo pretty good. Every second frame is screen 2 and every second is two screen 3 images (to get 4x2 pixel blocks instead of 4x4). The total VRAM need for that viewer is about 17 kB for a true full screen image.

The L!T viewer is pretty neat though and does a bit better job with the interlace to avoid large blocks of same color switching at the same time. The result is much smoother than for example the MSX unleashed pictures.

Anyways, its nice to see some progress on the interlace technique. Its pretty useful, especially if the monitor used for showing it has some afterglow.

By NYYRIKKI

Enlighted (5900)

NYYRIKKI's picture

10-08-2009, 08:03

Actually the black parts (as well as a few other non-interlaced 8x8 blocks) are using _two_ characters, even though that doesn't make any sense. Wink

Does this mean two characters/position or two characters/"all of the black" ?

By yzi

Champion (444)

yzi's picture

10-08-2009, 08:29

isn't this already done by dvik&joyrex?

Their screen2/3 combination technique was quite different.

Does this mean two characters/position or two characters/"all of the black" ?

The latter, two characters total for all the black areas. But it should have been just one, of course. And the black character isn't the only one, there are other ones that have identical bitmaps for both frames, which is pretty stupid. I haven't counted them, but I guess we could have used something like 10-20 character positions more. This will be fixed in the next version.

Our system does a lot of new things compared to other screen 2 converters that I've seen. I'll explain more when I have time. We'll also eventually release the source code, so other people can improve it. There are probably things we didn't think of.

By Marq

Champion (387)

Marq's picture

10-08-2009, 08:41

Definitely it doesn't squeeze every drop yet: pure outi during blank and outi+nop+nop during screen refresh. No use optimizing the latter but the precious blank time could statistically be used better if there's reoccurring bytes in the data (out (c),register is 12 cycles instead of outi's 16). That approach would require more memory and a bit more sophisticated compiler for the viewer, though.

By MäSäXi

Paragon (1884)

MäSäXi's picture

10-08-2009, 11:53

Nice looking picture!! Smile

How many screens did you use? 2 or 3?

I am glad I am not living at Lievestuore, because of such scary looking flowers there... Tongue

By dvik

Prophet (2200)

dvik's picture

10-08-2009, 16:09

Their screen2/3 combination technique was quite different.

The image viewer in MSX Unleashed (and Technicolormania) is screen 2 only. Yesterday I updated it to swap every second scan line and the result is better. Still on the todo list is to add dither support, as wolf_ suggested at one time.

By yzi

Champion (444)

yzi's picture

10-08-2009, 18:02

Swapping every second scan line mechanically for all odd or even lines isn't enough, as you'll soon discover. Smile It solves 90% of the problem, but still leaves a few nasty chunks all over. You only want to swap, if swapping increases the perceived difference between consecutive lines (inside the same character column) compared to the non-swapped alternative.

A few other things that we've discovered:
- You really need to disable a large part of the color combinations (105 is quite optimistic, to say the least), because only a subset of the theoretically possible combinations are actually usable in practice. For example, you don't get a good gray color by combining black and white. This of course depends on how high you raise the bar, or personal taste, or whatever Wink
- Adjusting the RGB values of the 15 basic colors makes a difference. Since different MSX1 and MSX2 models have different colors, it's a compromise.
- Dithering adds a whole new set of interesting problems. Dithering the whole picture first without considering the 8-pixel color limitations and then reducing the colors with simple thresholding works, but it isn't always the best solution. Our converter dithers each 8x1 block to all possible 4-color combinations with brute force and chooses the combination which "looks the best" according to some aesthetic criteria. Then the color choice is "finalised" and the algorithm proceeds to the next 8x1 pixel block. By using error propagation, this process also takes into account the choices that were made previously.
- You don't want to use standard textbook Floyd-Steinberg, because it propagates the errors way too far. Tone it down some.
- The aesthetic criteria is a tricky and quite subjective thing. What is a "good" choice of colors? Especially since you're dithering stuff as you go. The question is not as trivial as it might first seem, and it depends on the image. Adding the errors of individual pixels doesn't work for most pictures. But for example, if you're converting an image that's already 100% in MSX1 screen 2, it's the only correct choice. Generally, I've found it best to use a windowing function, which takes some of the surrounding pixels into account. This lets Floyd and Steinberg do their job properly, and because of the error propagation, usually there's surprisingly little blockiness. In most pictures you don't see the screen 2's 8-pixel column boundaries at all.

I wrote the converter with Lazarus/Free Pascal (the free open-source Delphi clone), which enables me to easily compile a Windows version for those who need one - like our graphics artist Man, for example. Wink I and Marq normally work on the Mac. I tried to build it into some kind of an object-oriented framework, where the user can try different combinations of algorithms and settings, and it's possible to add more by adding new classes. It's a quite esoteric piece of software, but maybe someone in the MSX scene finds some use for it. Hey, don't you have to be a bit nuts if you want to develop software for MSX in this day and age. Wink

Page 1/2
| 2