MSX Info Update 2010 - Lieves!Tuore compo entries

Tunezzzzzzz!!!!

Both of the tunes were made with Arkos Tracker: http://www.julien-nevo.com/arkos/

I enjoyed watching slideshow with my son and I liked Ebykti too. At the beginning, it partly sounds like there are sampled music. Is there? Maybe not.

By the way, that border effect on lower border was really fantastic!!! How long it took to make such thing possible? This was the second time ever someone uses borders. First one was found from dvik&joyrex demo´s end some years ago. (light synthesizer on the upper border) This time whole lower border was used.

Yep. I am sorry if my words got bit misunderstood. I saw that your border thingy was not light synthesizer stuff, like in dvik´s & joyrex´s demo. But it made me stare at it for a long while... just something spectacular I have never seen on MSX!

Maybe it is now the time to get the first MSX game which has SCORE in the border! Or lives left... something which doesn´t have to be updated all the time (to save cpu time for the game itself). Sorry, of course it must be updated all the time to make visible in the border, I guess, but I meant that you don´t have to change numbers to other numbers (=your score) all the time.... if that matters at all....? I was referring to something SIMPLE, just few ASCII characters for SCORE (or SC) and numbers or JUST ASCII NUMBERS.

Yes, that´s really amazing, what one can do with PSG, one skilled enough like you there. It reminded me of some 80´s Tim Follin multichannel Spectrum 48Kb stuff....

That another tune was well done too, of course, but ebykti fitted to my musical taste. That´s it.

FINLAND RULES!!

We also have these border things in our Infinite games during development, to check on CPU usage.

A standalone viewer for the .LT2 images can be found on the productions page now. Complete with source and file format spec.

changing colors in the border is trivial and costs almost no cpu but
showing something else (scores or anything else) on msx1 is impossible

Also timing the border color changes is a bit of a hassle.

But changing the border color is a good way to show that the player or a boss has been hit.

If you want colors in the borders, run this program

10 I=(I+1) AND 15:COLOR 15,I:GOTO 10

Do I understand correctly that sprites in the bottom border could be possible on MSX2, but not MSX1?
Was this ever used on MSX2 system then? What's the trick, changing screen height back from 212 to 192 between raster 192 and 212?

Certain Radarsoft games already use rows of enlarged sprites to mask smooth scroller wobbly borders in the normal display area, but this could be done starting from row 211 also?

So, IF those border effects are that COMMON thing, why not use it in some games then?

I am not programming expert, so I can just guess that it may slow down game a lot (?). Or does it?

If it costs just very little cpu time, then I see NO reason why not using it?

I think most of the game/demo programmers use this "effect" during development to see how much CPU time there is left. It is not used in final products as it is generally considered as uggly and gives impression that the product is not ready. I think it was left in this time just to show how light weight this player actually is.

The whole idea is that the effect does not take CPU time, but visualizes the CPU time used by some other task.

During game/demo development the main loop usually goes like this:
- wait for interrupt
- Change backround color
- execute code
- change backround color
- loop

... when code is ready the "change backround color" things are removed. Here is example in X-BASIC:

10 SCREEN 1
20 CALL TURBO ON
30 SPRITE$(0)="??????"
40 TIME=0:FORI=0TO1:I=TIME:NEXTI
50 COLOR ,,8
60 X=(X+1)AND255:PUT SPRITE0,(X,100),4,0
70 COLOR ,,0
80 GOTO 40

It's an amazing way to show graphics on MSX1.
Using blueMSX, the 'interlaced' (?) images, like, 'shock' with a pulse.
I'll look at it on real hardware shortly.

Didn't see no border color effect by the way but I've seen border colors flicker before in my life - the pics are more interesting.

There's gonna be some flickering, of course, since the colors are changed every frame. Depends a lot on the display device. With MSX2 there's a lot more contrast and saturation.

On emulators IMHO they look a bit too much flickering.
I have to test on real HW to tell how they are.

What kind of algorithm di you use in the coder?
What are main differences with the coder used by Daniel Vick?
Actually they look very good on bluemsx (not a surprise ;-)

Aaarghh!! I forgot add here 5 SCREEN 1 from my "fixed" version.

You cannot change border colours in SCREEN 0. (using BASIC, I mean)

Hey, I was the very first who said "I enjoyed watching slideshow with my son". See the very beginning of all these reactions.

They looked really good!

So, if border effect is stealing the show from SCREEN 2 pictures, it means people are demanding more border effects!! If you don´t believe me, then I hope that you will never get a work in marketing department!

Nice drums in Ebykti, yzi
(don't be mad if I ever steal them for my own songs )

hap: feel free to rip the sounds, I tend to create new ones from scratch for every song, so there'll be more stuff to rip in the future. It's so easy to create drum sounds in Arkos Tracker.

manuel: It's not really targeted for Turbo-R... But if you can post some screenshots of the broken pictures, maybe we can guess what goes wrong. Did you test in Z80 mode? We don't have a Turbo-R machine to be able to test anything, but many different MSX1's and a couple of MSX2 machines.

What is the swapping frequancy?
They flicker a lot

The program pushes data into the VDP as fast as possible, so if the instruction timings are even slightly too fast, the VDP can't handle the incoming data, and you'll get garbage on the screen. VDP1 and VDP2 produce different garbage, because (IIRC) VDP1 inserts seemingly random data into the VRAM, but VDP2 simply rejects the data. The "speed limit" is not even constant, but gets slower as the retrace goes down. Marq's code has many different copying speeds, and it uses the fastest one suitable for that position in the retrace. I can easily imagine that if the R800's emulation isn't perfect, you'll get garbage. I think this VDP behaviour isn't completely accurately emulated by any MSX emulator.

@manuel I think that adnukes can not be fixed to work on R800... I'm pretty sure the problem is that you can't output fast enough to VDP on R800 mode because of S1990.

Very nice pictures. I ran the demo on a TR in blueMSX (Z80 mode i believe) and i saw some corruption on some pictures. I think this can be related to timing. On an MSX1 or MSX2 machine they look good, but on MSX2+ and TR there is some issues. The latter systems have one more wait state on writes to the VDP, so an out takes one cycle more than on MSX1 and MSX2, so probably not all data is sent to the VDP in time for correct display.

In our demos that uses synchronized code, I had to do two versions, one for MSX1 and MSX2 and one for MSX2+ and TR, because of the difference in timing.

A side note: For anyone that is interested in the algorithm we used, I made a PPT at one point: www.bluemsx.com/dev_download/105Colors.ppt
Some things have been improved since this was written, but the improvements are not related to the color calculations, and we haven't really released anything with our improved version so I guess this document describes what you've seen so far from us.

Dvik: nice powerpoint, thanks. Looking at that powerpoint, I think the most important things that our conversion/encoding algorithm adds compared to yours, are
- Dithering: in addition to "threshold" color reduction, you can select various ditherers like ordered ditherers or Floyd-Steinberg (with non-textbook variations). The dithering is tested for all 4-color combinations
- Windowing: the color evaluator (=how good would these colors be) takes into account some of the surrounding pixels, for example in a 3x1 window. I would have thought that error diffusion had taken care of this, but windowing seems to further improve the smoothness of color transitions across blocks. Maybe the same thing could have been achieved by other means as well (for example combining many weighted values from different color spaces in the same evaluation criterion)
- Post-processing: the "A" and "B" frames of every 8x1 block are flipped (A/B -> B/A), if it increases the perceived difference between two consecutive blocks. This gets rid of practically all nasty flashing/flickering block areas.

The overall algorithm could be summed like this
for each 8x1 block:
- do a preliminary color reduction (using the selected reducer) to all allowed 4-color combinations, and calculate an "evaluation number" for it (using e.g. total difference in RGB color space).
- select the set of colors evaluated to be the best, and finalise the block.

A very important factor was of course Marq's selecting and hand-tuning the images and parameters, and even post processing the encoded data. Sometimes a picture just doesn't work, and sometimes you need to move or scale things, to avoid nasty color blocks.

Unfortunately, we don't have MSX2+ or Turbo-R machines for testing. Do you think emulators are accurate enough? I think at least the VDP1's random garbage generation isn't emulated by any emulator.

LOL yes yes, and on an emulator, I can have all the sprites on the same line without flickering.

I suspect that the overall preceived quality of picture depends a lot by the picture itself.
To make a fair comparison between dvik and yzi approach one should convert 10 different images and compare each version...

I also suspect that difference between the two methods is small.

@Marq.:
unfortunately i've only a msx1 without disk drive.
so i need to get .ROM image (i will use loadrom from wav) with one image for every .ROM
or something similar.