ZX Recoloring project

[hikoki]

I've made a quick search and there seem to be photo editors based on AI like pixelmator for Mac.
Another interesting experiment is this Neural photo editor on github, https://github.com/ajbrock/Neural-Photo-Editor
I guess you would have to fit your custom sprites to the original ones by selecting them manually on a rzx snapshot. Supervised machine learning I think it's called the jargon term. Looks like complicated!

[rg_software]

We've already established that your approach will not work for the vast majority of games.

Well, honestly speaking I think many of these issues still can be resolved with partial matching and other tricks, so I might be able to cover many harder cases, so it isn't done yet.

No, you don't understand. I'M NOT TALKING ABOUT USING AI OR ML AT 50 FRAMES PER SECOND.

Okay, I think I got it this time. Though, I still think it sounds very nice as a theoretical chit-chat, but can be much harder to achieve in practice. Let's say, I am not arguing, but I don't feel capable of taking this amount of work, at least, in near future.

[ZXDunny]

We've already established that your approach will not work for the vast majority of games.

Well, honestly speaking I think many of these issues still can be resolved with partial matching and other tricks, so I might be able to cover many harder cases, so it isn't done yet.

Yes, but even getting the more obvious XOR problems sorted, your algorithm will end up with so many bolted-on edge cases that it might not be fun to maintain. And even then, you're still restricting yourself to a very narrow corridor of the amount of games that people will want to convert.

I do understand that you want a method that presents the user with as easy an experience as you can, for recolouring games. But when the method used restricts people to only a handful of games that can run smoothly (with all the rest exhibiting missing/flickering sprites and holes in the background - and yes that will happen) then at some point you have to sacrifice some of that ease of use for an approach that enables more games to be meddled with.

I'm going to be watching your progress, but I can't promise I won't laugh along the way

No, you don't understand. I'M NOT TALKING ABOUT USING AI OR ML AT 50 FRAMES PER SECOND.

Okay, I think I got it this time. Though, I still think it sounds very nice as a theoretical chit-chat, but can be much harder to achieve in practice. Let's say, I am not arguing, but I don't feel capable of taking this amount of work, at least, in near future.
[/quote]

It's a fair bit of work, yeah, but might be worth it to make the tools that the user engages with much easier to use. Detecting sprites in memory from a snapshot is a perfect example of what an AI/ML model can be used for. It would simplify how the user finds those sprites without them having to worry about sprite size, interleaving etc etc.

And yeah, I presented the idea initially as a joke, but it would actually be very very useful. Not for the game rendering itself, but for the search tool the user would use for making their remake.

And as I said, when I go back to writing ZXSpin again, I'll definitely be looking at Spec256 and code hooking with an API for advanced users - I'm not as restricted by ease of use as you are.

[geecab]

Here's my Xevius test recolour. For some reason it can't replace the bullet, the crosshair or the square scenery block.
I was lazy and didn't rename it, so click on iball2.exe
Feel free to play with this and eventually finish it, for me it was just a test. I included a sprite sheet to make things easier

https://we.tl/t-kZizNQltfI

Looks good, thanks for uploading it, I gave it a go and really like the colour choice

- The bullet isn't showing because you've got the black and whites the wrong way round.
- The crosshair isn't showing because the bitmap dimensions need to be multiples of 8 (The searchBitmap, and the recolouredBitmap). Currently its, 12x8, should be in 16x8. I scratched my head with this problem in the past, the developer does mention it on his website though its easy to miss.
- The scenary block was the wrong dimensions too, I made it 16x16 but still couldn't make it show. This one is a bit odd. I might look into this a bit more later.


>>Mostly works but sometimes it defaults to the the original. It doesn't affect gameplay much but it's a bit strange

I do think you are experiencing the same bug that I've seen (The "Stormbringer Knight walking under a tree" issue I mentioned several posts ago).

In Xevious, when the player's ship flies over a patch of shaded ground, the emulator should still be able to recognise the ship as I've checked your searchBitmap and it looks correct to me.

Its strange, when the ship flies into the shaded area and whilst its completely inside the shaded area, the original bitmap is shown. Then, as the first (top left) pixel of player's ship leaves the shaded area, then the colour bitmap is shown (Correctly layered over the shaded area)...

[geecab]

>>The scenary block was the wrong dimensions too, I made it 16x16 but still couldn't make it show. This one is a bit odd. I might look into this a bit more later

Found it. The scenary blocks are named differently to what is in your settings.txt.

E.g. the lines that read:
0 pixel zx_block_1.bmp pc_block_1.bmp
0 pixel zx_block_2.bmp pc_block_2.bmp
0 pixel zx_block_3.bmp pc_block_3.bmp
should be:
0 pixel zx_block1.bmp pc_block1.bmp
0 pixel zx_block2.bmp pc_block2.bmp
0 pixel zx_block3.bmp pc_block3.bmp

Once renamed (and the bitmaps resized to 16x16 pixels), then the blocks appear

[Joefish]

Why not use the pattern-matching algorithm to search for the sprite data in a memory snapshot and present it for editing, then use a Spectrum-256 like approach to present it in-game?

I am not really familiar the details of with Spec256 approach. I mean, I know that it emulates a sort of "shadow graphics processor", but I neither know the details nor can estimate how hard is to to something similar.

I think it's already been covered, but the Spec256 approach is to run an emulation where each bit of memory is handled as a byte instead. That way, a 1-bit pixel in the emulated screen memory is actually an 8-bit colour index.(REMEMBER you'd need colour #1 to be 'black', as colour #0 is 'transparent' or a zero bit).
When emulating the Z80, you use the zero/non-zero status of a bit as 0/1. But when building the screen display, for each bit of pixel data you ignore the attribute, consider the 'bit' to be its full 8-bit representation, and look up its colour in a 256-entry palette.

Now my suggestion, to improve things, is you have a palette that is partly fixed, and partly dependent on the current attribute.
The fixed part of the palette is the first 224 colours.
Then there's a palette of another 256 colours. Each holds 16 variations on each of the 16 spectrum colours (including BRIGHT / DARK BLACK).
So the palette for a character cell consists of 224 base colours + 16 variations on the INK colour + 16 variations on the PAPER colour from the current attribute.
This allows sprites to be partially recoloured depending on their current attribute, as much or as little as desired. So for Manic Miner, your penguins could still have an attribute-dependent body-colour. But for something like 3 Weeks in Paradise, with its horrendous colour clash, you'd just use the fixed colour palette.

Furthermore, I am not entirely sure that the sprites are stored in the memory in the same format for all games. We know exactly that when a certain picture is displayed on the screen, it has a predefined pixel structure. When it sits in memory, it can be literally anything stored in the way the authors wanted. For some games with large sprites (like Popeye) I guess there are maybe no complete sprites at all, just separate sprite pieces later combined into a character on the fly. So in order to recolor such sprites one would need to guess these pieces and process them separately.

Most sprites are stored in a simple linear fashion, or a slight variant of it. Variations include alternating bytes of sprite / mask, or alternating rows, or alternating frames of sprite / mask; reversal of byte order, reversal of row order, reversal of every second row; sometimes pre-shifted with animation. But this is what the smart routine is for - to recognise the repeating shapes in memory and identify the start and end of individual sprites; which ones are similar enough to be considered animations, etc. And all done from a memory snapshot, so it can take as long as it wants, and accept hints and prompts from a user to guide it.

If sprites are stored as UDGs, with a second table to organise the UDGs into a large object, then you're pretty much stuffed. But a huge number of games could be tackled with only a few simple variations from linear storage.

You wouldn't even have to identify attribute data, as with my suggested approach sprites could be partly re-coloured by their original attributes, or with no respect to their attributes at all, as the designer wishes.

[ZXDunny]

I think that most people saw the Spec256 tool as being way too complex for them - they just want to be presented with graphics for recolouring without actually having to find them first.

Which is a shame, because it's the best "automatic" way to do it we've seen so far.

[4thRock]

Once renamed (and the bitmaps resized to 16x16 pixels), then the blocks appear

Thanks!

[4thRock]

I think that most people saw the Spec256 tool as being way too complex for them - they just want to be presented with graphics for recolouring without actually having to find them first.

That's why pattern matching is a great idea. Sure you still need to create a spritesheet, but that's very intuitive.
Once I tried to find sprites directly on TAPs and memory. Confusing because of different sizes, masks and the variations mentioned by Joefish.
So an automated approach has it's merits I think.

[ZXDunny]

I think that most people saw the Spec256 tool as being way too complex for them - they just want to be presented with graphics for recolouring without actually having to find them first.

That's why pattern matching is a great idea. Sure you still need to create a spritesheet, but that's very intuitive.
Once I tried to find sprites directly on TAPs and memory. Confusing because of different sizes, masks and the variations mentioned by Joefish.
So an automated approach has it's merits I think.

It does, but it certainly limits the games you can recolour and also the circumstances in which they can be recoloured. I'm hoping that I can be proved wrong though.

[rg_software]

Didn't have time for an update yet... However, since several people mentioned that EmuZWin has a potential to do the job "the right way", I tried to investigate the state of that project. It seems that it is effectively abandoned, and the sources are given to Denis Grachev (given that he keeps them locked somewhere). So he is perhaps the only person who can modify the emulator now, and it seems it's far from trivial given its old codebase.

P.S. People suggest using EmuZWin 2.6 instead of 2.7 -- it seems that some bugs @geecab encountered appear on the 2.7 version only.

[ZXDunny]

I would start a new emulator from scratch tbh. They're not terribly hard, just laborious to get right. If all you intend to do is play recoloured games then the accuracy doesn't have to be anything like SpecEMU or its ilk.

[hikoki]

This project might be a good opportunity for the Sam Coupe

[ZXDunny]

This project might be a good opportunity for the Sam Coupe

I'm not sure the Sam Coupe, even with an accelerator, would be able to find and replace the graphics quickly enough.

[Stefan]

This project might be a good opportunity for the Sam Coupe

I'm not sure the Sam Coupe, even with an accelerator, would be able to find and replace the graphics quickly enough.

Even an optimised SAM Coupé port of any title will have trouble since it needs to move four times the amount of graphics data around with only a slightly faster z80.

[geecab]

Rebelstar II is coming on nicely I think. Julian Gollop was clearly influenced by the Aliens film when he programmed this, so I've always wanted to see a full on Aliens version of this game.

The main changes are the Aliens look more like the ones from the film (Black with no eyes). I've also replaced all the members of your squad with the names (and small images) of the film characters.

I replaced about 80 of the sprites (Got about 20 left to do) and as I'm just working with bitmaps in my favored editor it hasn't taken long. I can use the 'block' search feature in my settings.txt, and there hasn't been any performance problems.

[geecab]

Hi all!

The developer of the recoloring tool (rg_software) has been busy fixing bugs, improving performance and adding new features since his first release. The latest version works really well I think

Here is a quick preview of RebelstarII - with new graphics, fonts, music and sound effects. All achieved with the recoloring tool. I'll upload the entire game at some point:

https://www.youtube.com/watch?v=8sTQy8_eQRw&t=1s

New RebelstarII features:

- All game graphics and fonts have been redrawn/recolored.
- The names of the raiders changed to those from the Alien (1979) and Aliens (1986) films.
- Marine and Alien voice samples heard when squad members are selected.
- Menu music and in-game music.
- Motion tracker heard during 'fire mode'.
- Swamp Rat changed to a facehugger.
- Better ending screen.

[ZXDunny]

...do those Aliens have bows and swords?

[hikoki]

Would Super Off Road be a good candidate to be recoloured? Playability could be improved by giving the player a different colur as every car looks the same!

[Stefan]

Would Super Off Road be a good candidate to be recoloured? Playability could be improved by giving the player a different colur as every car looks the same!

I would expect that the same car sprite is used for all cars, so there is only one sprite to colour, resulting in all cars then having that colour.

[geecab]

To be honest hikoki, I would probably recommend that you just play the Arcade/Amiga/ST versions of Super Off Road. That would be the ideal look/sound that I'd be aiming for if I were to improve the Speccy version. That is, unless the Speccy version has something extra that the other versions don't?

This has got me thinking about 3D Stock Car Championship:
https://spectrumcomputing.co.uk/index.p ... 96&id=4904
Used to love that game as a kid. Bit of a rubbish looking game with awful sound, but really fun with your mates (could have up to 4 players). I quite fancy giving that a make over sometime

[geecab]

Hi there!

Just thought I'd upload a shorter version of my RebelstarII video. Just wanted to mix together the interesting sections of gameplay and also include footage of the dropship, hopefully making it a bit more exciting for viewers

ZX Recoloring Project: Rebelstar II "Ripley's Revenge"

[geecab]

Hi there!

Thought I'd upload this video of Stormbringer - with new graphics and fonts. All achieved with the recoloring tool. I'll upload the entire game at some point:


ZX Recoloring Project: Stormbringer

[4thRock]

Looks great! My preference would be a more restrained graphic style (keep one colour per sprite, only use the Spectrum palette), but this really shows the potential for this technique! Looking forward

[geecab]

Cool thanks! I know what you mean about a more restrained graphic style. To be honest, I was going for the look of an ST/Amiga game. Incidentally, there was an Atari ST version of Stormbringer, but it wasn't the best