Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics


A member registered Sep 07, 2016 · View creator page →

Creator of

Recent community posts

Hi all,

I'd like to let you know that I have just released a new Amiga puzzler.

Follix is a puzzle game heavily inspired by Atomix, a game from 1990 where the player had to build chemical molecules by connecting correctly the atoms they were made of. Using similar mechanics, in each of its 30 levels, Follix challenges the player to build a piece of a message by sliding in the correct places the tiles that contain the relevant text characters.

Check it out at and enjoy!

While I did write the game with Amiga in mind, a port can't and won't happen.
I'm really, really sorry to disappoint you. But you deserve a detailed answer...

In particular, a classic Amiga version won't happen because:
* it would be inferior (AGA just doesn't cut it, even if aided by a powerful accelerator board);
* it would require a huge development effort, as no direct port is possible: the code would have to be written from scratch and the data would have to be adapted;
* it would require an additional effort for testing, given the variety of hardware configurations;
* it would require again a big effort in case of updates (if any - and, as you might have noticed, I tend to update my games a lot).

In general, I'm not considering ports for other platforms (the same goes for all my games):
* porting is boring;

* supporting multiple platforms is a huge (insane) undertaking;
* help offers aren't of any help (terrible pun intended) because also collaborating, for several reasons, takes time and energies;
* I have many other projects (for classic Amiga and Commodore 64) waiting to be worked on, and time and energies are limited.

Glad to hear that! Thank you :)

Thank you, my friend!

Follix community · Created a new topic Backstory
(3 edits)

I was 16 when I bought a stock Amiga 1200, in the fall of 1993, finally making the jump from my beloved Commodore 64. Back then, I was isolated in a little town, knew nobody who was into software development, owned no programming books and had no software, apart from a bunch of floppies containing 3 pirated games I got as a bonus from the shop I had bought the Amiga from. However, having heard I was interested in programming, some friends put me in touch with an older guy who had an Amiga 4000 loaded with several original productivity programs - among which AMOS Professional - and sitting on a desk in his shop, doing nothing. The guy (who eventually became a close friend) allowed me to go to his shop and use his Amiga at will (years later, he even let me take it with me to another town!) and provided me with a copy of AMOS (registered in his name).

I started learning AMOS and improving the little programming skills I had built with the Commodore 64 User Manual and some tapes that taught BASIC. I did not consider another language because I was totally unaware of other options and, anyway, AMOS felt like a natural step from Commodore 64's BASIC and gave me the feeling that I could finally satisfy my desire of making a whole, proper game.

Still, my skills and knowledge were limited, my unexpanded Amiga (which was the computer I did most of my programming on anyway) was not exactly a workstation and AMOS had its limits, so most of my ideas were doomed to remain just that - ideas. Yet, I was quite interested in puzzle games, which often have little hardware demands. And so the first game I ever created ended up being a puzzler. It was called Follia NBA¹, and the year was 1994.

The concept was stol... erm... heavily inspired by Thalion's Atomix², which I had seen on an MS-DOS computer of one of the aforementioned friends. It was a bit different from Follix: the tiles of a level were the pieces of a picture depicting the logo of an NBA team³; as a consequence, there was only one correct place for each tile; the player had to guess the area where the reconstucted picture fitted; for every 2 minutes left, the player was awared a bonus that, at his/her command, would automagically put a tile in the correct place.

That first version was really bad: some design choices were completely wrong; most of the graphics were ugly; the code was messy, inefficient and, in places, uselessly complicated; the sound effects were taken from various tracker modules. In all, it mirrored perfectly the fact that the development had been a learning process. Though, it did work (I am somewhat amazed by how the patches to the workarounds to the fixes to the bugs produced, in the end, the correct result); moreover, the puzzles were actually good and the game was indeed fun.

In those days, I could not imagine I was sowing a seed. Through the years, I reworked/remade the game 4 times (plus an additional attempt that brought a prototype to AmigaOS 4 and Windows, as a byproduct of an iOS version which somebody else was supposed to take care of), with Follix being the result of the last effort. The motivation behind it was not only to make the game better, but also to make it technically special through ALS (enhancing Follia NBA using CSS, the ALS predecessor, is something I had been wanting to do for ages), to put ALS to good use and to get rid of the basketball theme (which, at some point, no longer felt appropriate to me and certainly is not everybody's cup of tea). The code and the assets of Follix have been created from scratch, but the puzzles are still the original ones (except for Follix' first 4, which are new and purpose to introduce the player to the mechanics gently, and Follia NBA's last 2, which have been excluded because of their sheer difficulty).

¹ "Follia" is Italian for "madness".

² Follix = Follia NBA + Atomix

³ Such an odd choice is due to the fact that at that time I was a lot into (and  played) basketball.
  By the way, those logos resulted surprisingly good, despite:
   · the wrong technical choices made at the beginning (i.e. HIRES resolution and very saturated palette of just 15 colors - color 0 was not usable for graphics as it was reserved for a background rainbow effect);
   · those were my first real pixelling experiences;
   · since I had no better tool, I was (painstakingly) pixelling the logos (some of which were downright huge), eyeballing them from a magazine, with the AMOS Object Editor, which was not suited at all for such a proposition.

Glad you found the culprit! Thanks for having let me know.
(BTW, never heard of PicBoot before.)

I'm afraid your emulator and/or system must be broken:
 * I have a real A1200 with a 68030 accelerator here, and the game has been developed (mostly) on it,
 * for a while, I developed and tested the game on an A4000 with 68040,
 * I have developed and tested extensively the game also on WinUAE, with a variety of settings,
 * my testers tested the game on a variety of system (the last of which is the 68060 + AmigaOS 3.2 mentioned earlier),
 * I never received a report regarding corrupted graphics,
so it's pretty safe to say that the game works just fine.

The game is coded entirely in assembly. For the graphics, I have used mostly Personal Paint. For the music, I used originally OctaMED SoundStudio and MilkyTracker afterwards.

Just received this test report: "Graphic all crisp and clear and sound issues on real 060 and OS3.2"

It looks like it's an issue with your setup - which means that, unfortunately, I can't help :/

(1 edit)

The grey and black displaced and cut "cards" (for example, the one that appears at 2:07 in the video, after the removal of the Switchblade II cards) are artifacts that simply shouldn't be there.  Also, the title screen is heavily corrupted at 10:54. Those artifacts denote wrong memory writes, so I'm not surprised by the crash on exit (which is another thing that never occured neither was ever reported to me). AmigaOS shouldn't matter as the game turns it off and hits the hardware directly. I guess it's an emulation issue. I'll try to see if I can reproduce it.

EDIT: I've played the game for a while on UAE with 68060 as the emulated CPU, but everything worked fine; I'll ask one of my testers to try the game on his real 68060 + AmigaOS 3.2 machine(s).

Thanks a lot :)

The video shows a lot of corrupted graphics, which never happened on my A1200 (with and without accelerator board), nor in UAE: could you tell me your system specifications, please?

Glad you like them :)
By the way, those for Follix, ArtPazz and SkillGrid will be in the same style.

Glad to hear that and thanks for the report!

It's released now :)
Please let me know if the problem is solved.

You're welcome!

I have just checked the game and the code and found a bug that I introduced with the previous update: the code allowed both players to point the same card at the same time, which is a condition forbidden by the rules. The code assumes that such condition never happens, so maybe the stuck card bug you noticed is a consequence of this unwanted behaviour.

The 0 score is OK in this case: points are awarded only after the completion of a round.

The CPU shouldn't make any difference. Anyway, I'm going to test the game myself on my 68030 machine and, if everything goes well, I'll release a new update shortly thereafter.

Thanks for reporting!
I fired up the game and quickly tried to flip the first card, but it worked just fine.
As for the 0 score, was that after completing at least the first level?
I'll make more tests later today and get back to you.

Hello compfused, I've just released a new update and I seized the chance to add support for joystick in the mouse port (full story here). Thanks for the suggestion and enjoy!


thanks, I'm glad you like the game :)

Regarding the joystick, sorry, but 2 joysticks are not supported - in 2 players mode, player 1 uses the keyboard and player 2 uses the joystick.
The game development is over and there are no plans to resume it (although, if life will allow it, I hope one day to add an AI). At the moment I'm busy with other (Amiga) projects, so unfortunately I can't help.

Kind regards,

(1 edit)

Hi all,

I just wanted to let you that if you have an Amiga (even if emulated), there's a new little game waiting for you to give it a go. It's a little puzzler -  an alternative take on jigsaw puzzles. ArtPazz is puzzle game where the player has to piece together the tiles an image has been split into. It has been designed to be very simple, so learning how to play is a matter of minutes or even just seconds.

it's free, so just go get it from its page at ;)

ArtPazz community · Created a new topic Backstory
(6 edits)

In 1995 I made Puzzly, my third little game for Amiga (while, instead, I should have studied for the high school exit exam). It did not look good (although my eyes could not see that back then) and it had a very annoying feature that was even totally superfluous, but it was fun enough and I actually enjoyed it with some friends in a few of occasions. The game was written with AMOS Professional.

11 years later (2006), I worked on a project for the local department of the Ministry of Heritage. I had a technical role and I was surrounded by art experts. The project was called ART-PAST. It was so badly planned, the resources were so scarce, the salaries were so low and the demands on my colleagues were so huge that we soon ended up calling the project ART-PAZZ ("pazzo" means "mad"/"crazy" in Italian, and "pazz'" is the way it is spoken in our dialect), as those people were being driven mad and the overall atmosphere was totally crazy.

Now, 15 additional years later (2021), during a break from the writing of a novel, I found the perfect time for a small project like this. I rewrote the game from scratch using ALS, a graphics engine for AMOS Professional I released in October 2020 (rewriting the game using CSS, the ALS predecessor, is something I had been wanting to do for ages), keeping it as simple as I could.

I chose the name ArtPazz because the game might actually drive crazy, because "Pazz" (in Italian) sounds similar to "puzz" in "Puzzly"/"puzzle", because I threw some paintings in the mix and because it gave me one more reason to have a good laugh with some of the old friends involved in the ART-PAZZ... erm... ART-PAST project.

(1 edit)

THE CURE earned its author a nomination in the New Talent category of The Meteoriks 2021 (that's the demoscene equivalent of the Oscars)!

Here's the official nominees list (it does not mention "RETREAM" but "saimo", i.e. the author's scene handle):

To debug some unrelated code, I printed it on recycled paper, and one of the sheets turned out to be the one I used back in June/July 2020 to design the demo - it made me smile, and I thought it might bring a smile to your faces, too.

(1 edit)

Back in December, I was contacted by Ghandy, a scener involved in the making of issue #18 of the diskmag Jurassic Pack (12 years after the previous issue). He asked whether I felt like answering a few questions for the diskmag: that was a nice and unexpected surprise, so here's the interview that followed...

Q: How comes that someone from a bunch of people being involved into producing games for the Amiga began to code a demo?

A: I hope you don't mind if I first correct a common misconception: RETREAM is not a bunch of people, it's just me.

Also, I hope you don't mind if, to answer your question, I paste here a part of the README that comes with the demo: the reason is that there is no shorter explanation, and I wouldn't be able to put it in better words anyway - and yes, that helps saving some energies (to produce other Amiga stuff, of course)!
At the end of 2017 I derived the graphics engine at the core of the demo from another engine of mine. Since then, I have been occasionally tinkering with it while trying to come up with a game that would make use of it, but I failed: the engine was too stressful for the eyes and unsuitable for small/medium-sized graphical elements; it was clearly more suited for a demo (in fact, some people proposed to make a production of that kind with it), but I kept on ruling that out because I prefer making games.
Until, one day, what was happening around the world changed my mind: I just had to say something - and that could be rather effectively and relatively quickly done with a demo. In the past, I had already tried through a book, but since I'm Mr. Nobody my message reached only very few people. With a demo I could reach somebody else - very few people again, but still some more people.
Therefore, although part of my motivation was to make use of the engine, to have fun doing so, and to give the Amigans a little something to enjoy, the demo's main purpose is to say something.

Q: What's the connection between these two scenes? Is there any? Are retro gamers interested into the demo scene at all?

A: Regarding the first question, honestly I can't really say, as I'm not really connected to them (sometimes I post in Amiga forums, but that happens mostly when I present a production of mine - basically that's all there is to it). So, I'll just go for some theorethical thoughts: I'd say that there's a connection if/when demo coders make games and/or techniques used in demos are used in games and/or demos influence games - and everything vice versa, of course. But maybe there are other kinds of connections that I can't even think of.
As for the second question, from what I see in the forums, for sure there are people interested in both games and demos.

Q: Why did you choose Solskogen as the place to release "The Cure"? Are you all or Saimo coming from Norway? Or what was the reason?

A: After the demo was done, I checked out the upcoming parties and looked at those which had had a decent number of productions in the last years. I would have liked to participate to the major ones like Evoke or Assembly and/or to a live party, but they were too far in the future (which clashed with the urge of spreading the message carried by the demo) and the COVID was forcing all parties to go online. Eventually, Solskogen looked like the best candidate, so I went for it - and hey, there were even some attendees at the party place, which was quite nice.
By the way, I'm from Italy.

Q: Did the party people treat you with open arms?

A: I wasn't physically at the party, so all my interactions boiled down to the few and short messages I exchanged with the organizers to join the compo. Nevertheless, I have a nice little story that allows me to give a positive answer to your question: initially I asked the organizers if I could submit the demo as an out-of-compo entry because, a few months earlier, I had put on SoundCloud a different version of the music as a standalone track (which was mostly listened to by a few friends), but they told me that it wasn't an issue rule-wise and welcomed the demo with arms wide open.

Q: The comments at YouTube are quite positive, but some people at Pouet complained about the political statements of "The cure". What's the story behind this demo? It it a sort of sequel of Ozones "Smoke Bomb" from 1999?

A: My apologies to Ozone: I had never heard of Smoke Bomb before - but now I've watched it, and I've found it utterly cool!
Regarding the background story, well, you already know the answer now.

Q: Do you think demos should contain a message?

A: If they do, it's a plus. It's an additional element which has an own value and also increases the overall production value because it requires more planning, more design, more effort also for the other aspects of the demo. I guess that holds true for all forms of art. For example, let's think of a poem written according to strict metrics: one thing is to come up with random or loosely connected words that comply with the metrics, and quite another is choosing words that comply with the metrics and, at the same time, express a coherent and possibly complex message.

Q: I'm no coder, but what sort of effects did you use? How are they called, how do they work?

A: A proper answer would require an overly long paper, so please excuse me if I'll try to keep it short. Regarding the names of the effects, I'll use quite generic definitions (mostly as found in the code), as I don't know if there are established names out there (or even if/how those effects are done by others).

It's the core of the graphics engine. It's an almost-native chunky engine, in the sense the that dots are chunky (i.e. each dot corresponds to a byte in a matrix of dots), but no chunky-to-planar conversion is needed. It allows 4 colors + background color.

The engine takes the source dots wherever they are (each source dot can be anywhere in memory) and puts them in the right destination place according to a freely-definable map.

Like the solid ones, but they also allow transparent dots, which optionally can also go through solid dot-maps.
The distortion, tunnel, scrolltext and sun corona effects (and maybe others I can't think of now) are all based on the dot-maps.

The images are stored as dots coordinates instead of bitmaps. The engine handles each dot separately, so it can perform the morphing, scaling, explosion and bouncing effects. The images until the tube effect are made of 4130 dots each (the following ones are made of slightly less dots).

They come in a few custom formats, chosen according to the context (for example, in some places textures need to be encoded in a particular way to allow transparent dots).

I guess the name says it all already. Used for the rolling vertical stripes, the tube and the wobbling of the finale.

They do what the name says: they rotate and zoom textures. They are adaptions of a more general routine I wrote originally at the beginning of 2000.

Although there are only 4 non-background colors, the dots are faded in/out in 8-bit precision (this is particularly visibile when the Death picture fades out). They are based on an alternative use of the solid dot-maps: basically, to perform a fade step, it's enough to shift just 256 bytes.

Simple sequences of run-length-encoded 2-bit-packed chunky images.

The engine is an adaption of the one I made for SkillGrid.
Technical details:
* the music lasts 5 minutes and 23.2 seconds, and uses 12 tracks (clean rhythm guitar, overdrive rhythm guitar, clean arpeggio guitar, solo guitar, keyboards, bass guitar and drums taking all the remaining tracks);
* the original data is 48 kHz, 16 bit, stereo;
* the data is downsampled to 28867 Hz, 8-bit;
* the raw data amounts to (5*60 + 23.2) * 28867 * 2 = 18659628 bytes;
* the data is compressed with a custom lossless method (delta-based, Huffman-like - no rocket science) that brings it to 10902907 bytes (5429340 left + 5473567 right);
* the data is decompressed in real time;
* on my 68030-equipped Amiga, decompressing takes about 42 rasterlines, i.e. about 14% of a frame time.

The waveform shown at the bottom of the screen when speech plays, the sun corona and the wobbling of the finale graphics are all based on the reading of the values in the audio buffers being played.

The effects are driven by a script that consists in a structured mix of code and data.

Given that the music is not a tracker module, everything is synchronized manually: I manually pinpointed (with sample-level precision, although the demo runs at 50 fps, so the final precision is in 50ths of second) the spots in the waveform where the music does something particular (a snare beat, a guitar bend, and so on) and then I wrote the timings in the script that drives all the effects; each and every visual change is synchronized with the music, so there are tens of timings.

Q: Saimo, only one person, did it all? Music, code and design? Really? How comes?

A: Because I love that. Because I want to control each and every aspect of my creations. Because my perfectionism (which doesn't mean that what I do is perfect - actually, it's quite the opposite) makes me extremely demanding, probably more than others would be willing to accept. Because I'm a solitary person. Because, maybe, I'm simply a terrible person.
However, I must admit I've given some thoughts to having somebody else handle the graphics (and perhaps the audio department) of my next game(s): with somebody better than me, it's possible to produce better stuff, not to mention that I'd be able to focus more on design and code, and that getting the game done should take less time (although I dread the thought of the time and energies taken by managing the team). Hmm... oh, well, it's not something for the near future anyway.

Q: I hope this is the start but not the end of your demoscene career.

A: I'll be honest: I don't plan to make other demos - my heart is into making games, and I have way too many projects for the Amiga and the Commodore 64 already. But who knows what the future will bring...
Thanks for the opportunity you gave me and bye!

Thank you so much, my dear friend!

If you are - or were - an Amiga user or, even better, an AMOS Professional developer, then this should bring you a smile ;)
ALS is a library that allows to easily overlay multiple screens with complete control of order, colors and opaqueness, while keeping them renderable as usual. This opens up infinite possibilities for  new Amiga games with never-seen-before graphics and mechanics.

No, sorry: my games are like children to me, so I can't accept that there are unsupported/lesser/different versions around; in addition to that, also letting others do the port requires collaboration and verification from me, and, as already said, that's another no-go.
(Mind you, all I'm saying in this thread holds true for any game and any platform.)

THE CURE community · Created a new topic About the music
(1 edit)

A few times I've been asked questions about the music, so here's some detailed technical information:

  • it lasts 5 minutes and 23.2 seconds;
  • the original data is 48000 Hz, 16 bit, 12 real stereo channels;
  • for the demo, the data has been downsampled to 28867 Hz (the Amiga maximum in 15 kHz screen modes, for who isn't familiar with the machine's capabilities) 8 bit stereo;
  • therefore, the raw data amounts to (5*60 + 23.2) * 28867 * 2 = 18659628 bytes;
  • I compressed the data with a custom lossless method (Huffman-based) that brings it to 10902907 bytes (5429340 left + 5473567 right);
  • the data is decompressed in real time by an algorithm I wrote specifically for an unexpanded A1200, as I needed it for SkillGrid;
  • every frame, the algorithm decompresses just slightly more than the amount of data strictly needed (so, after a bunch of frames, the internal buffers are full and the decompression stops for a frame);
  • on my 68030-equipped Amiga, decompressing takes about 42 rasterlines, i.e. about 14% of a frame time.

The close-to-the-original version can be listened to from SoundCloud:

Hi all,

last saturday I released an Amiga demo (i.e. a demoscene production, not a preview of a game) at the oldskool demo compo of the Solskogen 2020 demoparty, and it ended up ranking 1st!

For technical reasons, the best way to enjoy it is to run it on a real Amiga, but if you don't have a suitable computer you can also watch it at decent quality in this video:

For plenty of information and the download, just have a look at the demo's page here on

Enjoy the deep audiovisual journey!

I'm absolutely happy to hear you welcomed my thoughts and appreciated my effort. Thanks from the bottom of my heart!

I'm sorry, this version is not available to the public.

Thanks a lot :)

Yep, I'm trying to stay safe... I'm staying home! That's what I wholeheartedly suggest to everybody, even if their country is not enforcing that by law (yet). The coronavirus threat must not be underestimated.

Take care!

(1 edit)

Thank you for buying the game and the nice words!

The currently available levels are rather hard indeed.  The CLIFFS level is the only level available in the IIm version (because that has to fit in 16 kB), so it couldn't be easy, otherwise the game would have been too short. Since it's difficult, it has been placed as the next-to-the-last level in the IIo version - this means that it will be preceded by easier levels. Suggestion: try also the FORTRESS level: although it's supposed to be the last one, currently it is incomplete and, for that reason, at the moment it's a little bit easier than the CLIFFS levels.
For further information, if you haven't already, please check out the notice (which, among other things, says a bit more about the levels) and the manual (which, among other things, gives a few precious tips away) included in the preview itself.

Sorry, there are no keyboard controls.

(1 edit)

No, it's available only as an EasyFlash cartridge image (.crt).

After some months, the deluxe edition is back in stock on the RGCD store!

BTW, never said or even thought that MorphOS users are bad ;)

(1 edit)

Hi papiosaur,

I'm glad that you find Blastaway fun. Thanks.
Your offer is incredibly kind and I can't thank you enough for that. However, I have to turn it down for some of the reasons explained in the previous post. Thanks in advance for your understanding.

Great to hear you've found a solution! Thanks for having shared it!

Have fun!

For everybody's convenience, I'm posting the result of a little investigation.
itchtoplay kindly ran a test program I gave him to check how the joysticks were reported to Blastaway. The resulting report was this:

number of devices found: 3
device: 0
 analogue axes: 2
 digital hats: 0
 balls: 0
 buttons: 3
 not suitable
device: 1
 analogue axes: 2
 digital hats: 0
 balls: 0
 buttons: 8
 not suitable
device: 2
 analogue axes: 2
 digital hats: 0
 balls: 0
 buttons: 10
 not suitable

Basically, SDL reports that the shaft of the joysticks is analog, not digital, which explains why they aren't suitable to Blastaway. As discussed in the previous post, the problem originates somewhere between the joysticks and the OS (given that they are treated as analog in the system settings).

Should anyone experience the same problem, I can only suggest to check if the joysticks or the OS offer a way to switch from analog to digital.

Glad you like the game and thanks for the feedback!

No, sorry, there won't be a 2 player version. The game is finished and I'll be working on other projects in the future.

Email received, thanks. I'll answer as soon as possible. In the meanwhile, my guess is...

The chain is like this:

joystick -> OS <-> SDL ->Blastaway

The problem probably lies in the fact that something in the joystick -> OS part (I'd say the default OS drivers) make the joysticks look as if they were analogue. As a consequence, SDL and then Blastaway are told that the joystick are analogue.

(5 edits)

Hi uigiflip,

you're absolutely right :D

To be honest, I would have loved to make Blastaway only for AGA Amigas, but I had to go a different route. I'm sorry to say that Blastaway won't land on classic Amigas for several reasons.

In general, other platforms won't be considered because:
 * I can't take the burden of adapting the game and then of offering (future) support (two platforms are already demanding, and with BOH I've learned that increasing the number of supported systems beyond two is insane);
 * porting is boring;
 * help offers aren't of any help (terrible pun intended) because also collaborating, for several reasons, takes time and energies;
 * I don't own all the machines I'm being / I will be asked to port the game to, and for money and logistical reasons I can't get more;
 * I have many other projects (for classic Amiga and Commodore 64) waiting to be resumed, and time and energies are limited.

In particular, a classic Amiga version won't happen because:
 * it couldn't be identical;
 * it would require a huge development effort, as no direct port is possible: the code would have to be written from scratch and the data would have to be adapted;
 * it would require an additional effort for testing, given the variety of hardware configurations;
 * it would require again a big effort in case of updates (if any).