MSX Info Update 2010 - Lieves!Tuore compo entries

by NYYRIKKI on 22-08-2010, 12:05
Topic: MRC
Tags: Challenges
Languages:

At the moment, the MSX Info Update party takes place in Helsinki. Among other activities, there are competitions going on. Here's news fresh from the party floor: the entries by Lieves!Tuore!

  • Adnukes, a slideshow for MSX1 using rapidly alternating tiles, like you may have seen earlier in dvik&joyrex demos
  • Ebykti, a catchy and highly detailed PSG song by Yzi
  • Silence of the Pigs, a PSG song, equally detailed, by Roz

More news will without doubt follow within the next few days. Until then, enjoy these fresh entries!

Relevant link: Lieves!Tuore

Comments (49)

By Latok

msx guru (3694)

Latok's picture

22-08-2010, 23:23

Tunezzzzzzz!!!!

By ARTRAG

Enlighted (6280)

ARTRAG's picture

23-08-2010, 00:57

Nice replayer
is there a tracker too?

By Marq

Champion (386)

Marq's picture

23-08-2010, 08:03

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

By yzi

Champion (441)

yzi's picture

23-08-2010, 08:52

We converted the Arkos Tracker replayer source to as-z80 syntax and added C headers for SDCC, and a couple of features to allow e.g. muting individual channels in the MSX-DOS player. We'll release the sources at some point, preferably sooner than later. The Arkos Tracker distribution package already has an MSX player with example code and everything, but it's used from BASIC.

I must say, using a music editor is just so much more productive than writing everything as data in an asm source with a text editor... I already had a half-finished compo song with my old system, but I abandoned it after trying out Arkos Tracker two weeks before the party. Wink There have been other PSG trackers around, but Arkos Tracker is the first one that finally made me ditch "asm composing".

By MäSäXi

Paragon (1884)

MäSäXi's picture

23-08-2010, 09:03

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

By the way, that border effect on lower border was really fantastic!!! Smile How long it took to make such thing possible? Smile 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. Smile

By yzi

Champion (441)

yzi's picture

23-08-2010, 09:37

Thanks! Do you mean the raster time meter perhaps? Smile It's not really an effect, I'm just changing the background color between some subroutine calls to see how much time is spent in different parts of the interrupt player.

There are no sampled sounds, it's all just normal PSG stuff. It's surprising what you can do with the PSG's simple square wave tone and noise in such a short time. The bass sound uses the PSG's hardware envelope, which my old player didn't use at all.

By MäSäXi

Paragon (1884)

MäSäXi's picture

23-08-2010, 19:28

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... Smile just something spectacular I have never seen on MSX! Smile

Maybe it is now the time to get the first MSX game which has SCORE in the border! Smile 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. Smile

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

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

FINLAND RULES!! Big smile

By PingPong

Prophet (3460)

PingPong's picture

23-08-2010, 20:26


just something spectacular I have never seen on MSX!

@masaxi: it's quite common to use the border to count how much time is taken from a cpu to execute a time critical job.
It's a common tech used on almost all computer of that era: ZX Spectrum, C64, MSX, ......
Strange you never seen this before.

By wolf_

Ambassador_ (9774)

wolf_'s picture

23-08-2010, 21:20

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

By Huey

Prophet (2644)

Huey's picture

23-08-2010, 22:23

Yes quite common while developing but almost never used in final products.
So not too strange MäSäXi never saw them before.

By Marq

Champion (386)

Marq's picture

24-08-2010, 08:27

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

By MäSäXi

Paragon (1884)

MäSäXi's picture

24-08-2010, 08:27

Yep, not too strange as I haven´t seen many not finished MSX products Smile with exception of certain MSX-DEV games. Wink (and none of them had any border effect mentioned here)

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?

At least for the curiousity´s and never-seen-before-in-MSX-game´s sake! Smile

I have seen borders in good use on Commodore 64 since 1980s.

Until dvik&joyrex demo some years ago, I always though it is just IMPOSSIBLE to do on MSX. Because, if it is not impossible, why haven´t anyone done it?!?!? That´s very strange, I think!

Yeah, now I understand that you coders may think it as common thing and so you may think it´s dull thing. But others (ordinary MSX´ers) have never seen it! So not everybody think it´s stupid effect or something like that.

If it is that easy to do, then put score and hi-score and lives into border and voilá! You get one or more rows more space for game design!! On MSX-1 it´s then no more those 192 pixels on Y-coordinate minus all those pixels needed for score board, but whole 192 pixels just for the GAME!! Smile

Why MSX coders must be different than coders on other old computers? Why you can´t use something special effect you CAN do to amaze people?!?!? I can´t understand that. Question

In the old days, on every possible old computer and video game, if some coder invented nice little or bigger effect, it usually got used in that game (if memory allowed that) and in certain cases many other coders started to copy/imitate such effect, just to make their games to look more special. Smile Special effects were used to make player more happy about her/his game (and to give coder a way to show off his skills) and software house got again one more way to show "Our games always have something SPECIAL in them!". Smile

If someone makes simple border score/whatever effect for game, then someone else may do something more special, and after that, someone else again may do... etc. It may result domino effect and we can get many games making good use of borders.

You can give some special touch to game that way! Smile

Okay, I don´t know if it flickers or wobbles how much if you make some sort of score board into border(s)?

You coders tell me. Or then experiment with it and then tell me. Smile

Some small wobblying may not harm your eyes too badly. Everyone who has played many Commodore 64 games in the past, surely will remember, that there were many games which had wobbly edges between two different graphical areas, like on the edge of scrolling game screen and score/speed/lives board. Those wobble things never bothered me. They belonged to those games, and actually I liked that little wobble. Big smile But as I said, I don´t know how much wobble or flicker some border score table whatever may give. Please tell me. Smile

By ARTRAG

Enlighted (6280)

ARTRAG's picture

24-08-2010, 08:44

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

By yzi

Champion (441)

yzi's picture

24-08-2010, 09:24

No, you can't do much with the borders. It's not worth the trouble.

At some point we'll release a converter for creating LT2 files. Our current utility, written in Lazarus (free Delphi clone), was made for prototyping different algorithms, and it's quite slow and messy, so I'd much rather make a streamlined C version.

By Huey

Prophet (2644)

Huey's picture

24-08-2010, 09:33

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.

By MäSäXi

Paragon (1884)

MäSäXi's picture

24-08-2010, 10:31

shame... Crying

but anyway, dvik&joyrex demo had some sort of little light synthesizer in the upper border, right? What was the demo´s name? I don´t remember it anymore.

About colours in the border, I was thinking about few ideas:

1) If upper border can have different still colour than lower border, then we could have more realistic pictures. Like dark blue upper border to make sky even higher and red bottom border to make red desert to continue downwards. Just don´t allow player step on lower border so effect won´t be spoiled by the fact that player´s feet are disappearing in the air. Wink

2) In two player fighting game, both players could have their own border to show when they are hit. Like yellow upper border for player 1 and red lower border for player 2.

3) Or imagine some fight against big boss monster. Monster is on the upper part of the screen (Knightmare style game on example) and that border flashes when boss is hit and when boss hits the player, lower border flashes.

4) But anyway, I would like to see borders somehow used in game´s title screen at least. To give some old-skool colour cycle effect at least.

Something like this: Smile

http://www.youtube.com/watch?v=HklIf_hll_Y

By yzi

Champion (441)

yzi's picture

24-08-2010, 10:42

If you want colors in the borders, run this program Wink

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

By Huey

Prophet (2644)

Huey's picture

24-08-2010, 10:45

Timing will be a real problem in a game.
In a demo you can balance the load as you know what the CPU load will be (constant).
But in a game it is very hard to predict the correct time to display the border.

By Hrothgar

Champion (479)

Hrothgar's picture

24-08-2010, 11:05

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?

By MäSäXi

Paragon (1884)

MäSäXi's picture

24-08-2010, 12:50

I did similar programs in the eighties already. Tongue

I am sorry to say that your program doesn´t work the way you intended to.

Here´s fixed version: Wink

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

By NYYRIKKI

Enlighted (5399)

NYYRIKKI's picture

24-08-2010, 13:41


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

By yzi

Champion (441)

yzi's picture

24-08-2010, 18:01

The BASIC program does work in screen 0, I actually tested it.

But isn't anybody interested in our screen 2 graphics... Wink It's hilarious that we did an incredible amount of work on getting those graphics out of a regular 1983 MSX1, but changing border colors steal the show. LOL!

What comes to Dvik&Joyrex's dual-frame screens, they're really only watchable on an emulator, on real machines you get a headache and/or an epileptic seizure. Wink

By JohnHassink

Ambassador (5417)

JohnHassink's picture

24-08-2010, 18:56

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 Question but I've seen border colors flicker before in my life - the pics are more interesting. Wink

By Manuel

Ascended (15825)

Manuel's picture

24-08-2010, 19:04

yzi - so what technique did you use then? (I haven't seen anything of it yet, of course, so I can't guess...)

By Marq

Champion (386)

Marq's picture

24-08-2010, 19:05

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.

By NYYRIKKI

Enlighted (5399)

NYYRIKKI's picture

24-08-2010, 20:43

I definately want to see those pictures on real MSX, but I think it will take still few days untill I have enough energy to put up my MSX table at home. Now everything is in boxes. Tongue

By ARTRAG

Enlighted (6280)

ARTRAG's picture

24-08-2010, 21:11

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 ;-)

By yzi

Champion (441)

yzi's picture

24-08-2010, 23:11

I don't know what exactly Dvik's program does, but looking at the end results, there must be many differences. I started by making a normal 15-color screen 2 converter, and in the following thread I've listed some of the improvements that were made to it along the way.
http://www.msx.org/forumtopic10138.html

Marq has also done lots of manual pre-processing and post-processing work, adjusting the source images' colors in many ways, and even fixing a few "offending" pieces from some pictures even after encoding. Getting good-looking pictures is far from an automatic process, so you can't just throw random jpegs at it and expect good results every time.

By MäSäXi

Paragon (1884)

MäSäXi's picture

25-08-2010, 12:35

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

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. Smile

They looked really good! Smile

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

By NYYRIKKI

Enlighted (5399)

NYYRIKKI's picture

25-08-2010, 13:31

@MäSäXi Maybe you should try this SC5 picture viewer for "MSX1". It has both... neat pictures and border effects. :P

By hap

Paragon (2021)

hap's picture

25-08-2010, 16:59

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

By Manuel

Ascended (15825)

Manuel's picture

25-08-2010, 21:52

Great stuff! I discovered that on R800 there are some glitches in adnukes Tongue

By yzi

Champion (441)

yzi's picture

25-08-2010, 22:28

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... Wink 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.

By Marq

Champion (386)

Marq's picture

26-08-2010, 15:56

I converted some lt2 pics to gif animations just so that you get an idea of how they look like. Firefox seems to be the only browser where the flicker works close to real framerates.

http://www2.uiah.fi/~mreunane/bladerun.gif
http://www2.uiah.fi/~mreunane/puppy.gif
http://www2.uiah.fi/~mreunane/fruit.gif
http://www2.uiah.fi/~mreunane/cadillac.gif

Pixel by pixel faithful to the MSX versions, but of course the contrast and color balance is different on modern hardware.

By ARTRAG

Enlighted (6280)

ARTRAG's picture

26-08-2010, 18:24

What is the swapping frequancy?
They flicker a lot

By Manuel

Ascended (15825)

Manuel's picture

26-08-2010, 19:08

yzi - well, there were some weird horizontal stripes or so... and yes, that was on R800. I was trying on Z80 mode, but ran into a problem with Nowind... I can't really take screenshots from my MSX monitor I think...? Take a photograph? Smile

By yzi

Champion (441)

yzi's picture

26-08-2010, 20:49

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.

By Marq

Champion (386)

Marq's picture

26-08-2010, 21:11

Artrag: it's 50 Hz, as supposed to. Like I said, most browsers can't cope with that. Firefox (and surprisingly, N900's own browser) seems to do a pretty good job except a few hiccups. Anyway, these gifs shouldn't be taken as anything else but mere curiosities, Adnukes and LT2S on MSX are the real thing.

By NYYRIKKI

Enlighted (5399)

NYYRIKKI's picture

27-08-2010, 10:32

@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.

By Manuel

Ascended (15825)

Manuel's picture

27-08-2010, 20:10

yzi: I was running it all on a real turboR Tongue The output looked fine in openMSX, IIRC (only tested MSX2).

By dvik

Prophet (2200)

dvik's picture

28-08-2010, 00:44

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.

By poke-1,170

Paragon (1757)

poke-1,170's picture

28-08-2010, 02:57

ah great tune !

By yzi

Champion (441)

yzi's picture

28-08-2010, 11:47

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.

By ARTRAG

Enlighted (6280)

ARTRAG's picture

29-08-2010, 22:21

neverthe less, at least on emulators, dvick's pictures look with less fickering

By yzi

Champion (441)

yzi's picture

29-08-2010, 22:43

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

By Manuel

Ascended (15825)

Manuel's picture

30-08-2010, 19:12

I don't recognize ARTRAG's remark...

By PingPong

Prophet (3460)

PingPong's picture

31-08-2010, 08:30

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.

By Marq

Champion (386)

Marq's picture

03-09-2010, 16:02

PingPong: Feel free to doubt it all, but wouldn't it be better to just check out the existing pics first on a real MSX1? To me the difference doesn't seem small by any means Smile We've also provided the well-known parrot and Lenna pics in LT2 format as points of reference.

By PingPong

Prophet (3460)

PingPong's picture

03-09-2010, 20:25

@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.