ZX Recoloring project

[rg_software]

Once again, really glad you have joined the thread rg_software! Right, sorry for waffling on. Going to get back on do a bit more work with Stormbringer!

Thank you Well, meanwhile, if you need me to tweak something in the toolset -- just let me know.
Let's see how life goes, but I will try to find some time to update the project with new capabilities. Of course, if you finish something, please share with me so I can use your work as one of possible showcases.

BTW, one reasonable scenario for using original sprites is just fighting with color clashes. Say, many DizzyAge ports simply use the original images, but they still look much better, since in the real Speccy Dizzy games color clash it is a big problem. (It might be much less relevant for many other games, such as Myth).

[geecab]

Great stuff rg_software!

Things have been going well with Stormbringer and I've colored in a load of sprites in now. I think, however, there might be a small problem with the emulator failing to recolor sprites at certain positions when I believe it should be able to handle it.

Its a bit difficult to describe, so here is a picture that hopefully shows one example of what I am seeing:-
walk_in_front_of_tree_pic

Here, the Knight walks in front of a tree trunk, and after he reaches a certain point, he stops being recolored. My first thought is that I've drawn my 'search' bitmaps incorrect somehow, but I've double checked them and they look ok to me?

I've zipped up everything I've done with Stormbringer so far. If you have a spare moment and fancy giving it a try sometime, then I'd really appreciate it. It might be easier for you to see it in action to get any idea of what is happening (and where I've messed up :p). When you run the emulator, I've saved the game state so that you standing next to the tree trunk in the picture.
Stormbringer recolor project

Many thanks

[rg_software]

Things have been going well with Stormbringer and I've colored in a load of sprites in now. I think, however, there might be a small problem with the emulator failing to recolor sprites at certain positions when I believe it should be able to handle it.

I see. OK, please give me a few days -- I am having a particularly tough week, but I promise to get back to this project as soon as I can.

[geecab]

Cool! Absolutely no rush, just thought I'd mention it, thanks again

[geecab]

Hi Hikoki!

Just been looking back over the thread an noticed your post.

Do you think it'd be possible to take the Jet Pac Advance Mod and put Scuba Dive's sprites instead? Using Horace everywhere could also be fun. I'd like to see a different Bruce Lee sprite. Another kind of game to mod could be those with 3d graphics like Ant Attack to use baddies from other Spectrum games giving them a 3d look. What about Double Dragon? there were graphics out there for a remake that never was finished. One could also think of using Renegade graphics for Double Dragon, or take one of these beatemups and give them a Christmas theme like making the Three Wise Kings fight with burglars disguised like Santa Claus.

Yes, I definitely think all that should be possible. You have put the idea of recoloring Scuba Dive in my head now Excellent game, and there shouldn't be many sprites to recolor either...

You also mention the 128k edition of the Hobbit in a previous post and I've given that some thought. You could really put your own spin on lots of graphic adventures with this technique, changing 'stationary' images with something new. I was thinking about Micronaut One, I know its a vector game but that could be given a make-over, recolor the dashboard/cockpit panel, might look pretty cool. There is also an 'about' option in Micronaut One where you can view images of the insects you are fighting against. Those images could be tweaked to look a little more scary.

One other thing that crossed my mind, you could replace dull looking "Menu", "Game Over" and "Congratulations, You have completed the game!" screens (That are perhaps just text on a black background) with an impressive picture. Some people (Myself included) enjoy getting spectrum games running on their arcade machines and this has got me thinking, when I load a spectrum game on my arcade machine and are confronted with the menu (Something like, "S to start, R to Redefine Key, K for Kempston Joystick") it would be cool to replace all that with "Insert coin to start!" sort of thing.

Lots of possibilities

[4thRock]

That Stormbringer recolor project is interesting.
Only gave it a quick look but having the graphics as .bmp is a great idea.

I'd limit myself to a simple graphic replacement with Spectrum "compatible" graphics (original resolution, only one colour per 8x8 or at most 8x1).
That's something that could have happened back in the day if the Spectrum had some sprite support.

Must find some time to try it with Bomb Jack and Golden Axe.

[geecab]

I'd limit myself to a simple graphic replacement with Spectrum "compatible" graphics (original resolution, only one colour per 8x8 or at most 8x1).
That's something that could have happened back in the day if the Spectrum had some sprite support.

The good things is that as the replacement sprites are bitmaps, you can mod someones else's bitmaps pretty easily in any paint editor and get the look you are after

>>Must find some time to try it with Bomb Jack and Golden Axe
Sounds good!

[geecab]

Hi rg_software!

I've been adding the remaining graphics to Aquaplane (Thought I'd try and get one game completely finished). Unfortunately, I think I've reached the maximum number of sprite recognition jobs that my PC can handle (Which seems to be about 20 'pixel' recognition jobs in total).

I've had a few thoughts on how to overcome this. Please don't think I expect any of it to be implemented (Its sounds like a scary load of work to me now I've wrote it all down :p). I'm just suggesting stuff really and parts of it might be worth considering as and when you are in the code again

- In settings.txt, the "SearchArea=Y:n|X:n|H:n|W:n" parameter. Searches for a sprite in a specified area (Where n is pixels. Height (H) and Width (W) sets the size of the search area. The top left of the search area is positioned at Y and X). If omitted, the entire screen is searched.

- In settings.txt, the "MaxInstances=n" parameter. Stops searching for a sprite after 'n' instances of that sprite have been recognized. If omitted, search for as many instances of the sprite as possible.

- In settings.txt, the "Group=n" parameter. Specifies a group of sprites that depict the same object/character (For example, a sequence of sprites depicting a person running). When one of these sprites is recognized, no need to search for any of the other sprites in that group.

- Use multiple CPU cores to perform recognition jobs simultaneously.


Example of how settings.txt might look:-

; Search for the Sun, there'll only be one and it'll be located at the top right of the screen...
0 pixel zx_sun.bmp pc_sun.bmp SearchArea=Y:0|X:200|H:50|W:56 MaxInstances=1

; Below the Sun are some clouds that move horizontally across the screen, there are only ever 3 clouds shown at once...
0 pixel zx_cloud.bmp pc_cloud.bmp SearchArea=Y:50|X:0|H:50|W:256 MaxInstances=3

; Search for the game's hero. There'll only be one of him, but he's depicted by a number of sprites...
0 pixel zx_myhero1.bmp pc_myhero1.bmp SearchArea=Y:100|X:0|H:92|W:256 MaxInstances=1 Group=1
0 pixel zx_myhero2.bmp pc_myhero2.bmp Group=1
0 pixel zx_myhero3.bmp pc_myhero3.bmp Group=1
0 pixel zx_myhero4.bmp pc_myhero4.bmp Group=1


Something else I was thinking about was a dependency setting. For instance, the recognition of sprite A, B & C to occur only while sprite D is recognized. Or perhaps recognition of sprite A, B & C to start only when Sprite E is recognized, and to finish only when Sprite F is recognized. Just trying to think of ways to stop searching for everything all of the time. To search for certain set of sprites that only get displayed when the player reaches a particular level/stage/screen in the game.

Sorry for waffling on. Hope this helps

[ZXDunny]

Holy crap dude, you're doing this by image recognition? While that's an impressive task, there really are much, much easier ways to do this

Are you monitoring an emulator screen display, or do you have your own emulator that this engine is tacked onto?

[4thRock]

BombJack didn't work, it just replaced the entire background.

So I tried Xevious and it works


The new ship sprite only has added colour. This allows it to downgrade nicely to the original when over a background:

[geecab]

Nice job 4thRock! That looks great

[4thRock]

Thanks! Recoloured an enemy sprite and it's the same thing.
Mostly works but sometimes it defaults to the the original. It doesn't affect gameplay much but it's a bit strange

[geecab]

Holy crap dude, you're doing this by image recognition? While that's an impressive task, there really are much, much easier ways to do this
Are you monitoring an emulator screen display, or do you have your own emulator that this engine is tacked onto?

Yes that's right, it uses image recognition. Have a read though the thread posts to find out more, but to summarize, rg_software has modified the UnrealSpeccy emulator to do this. Its still at a early stage of development, but I really like the idea

[geecab]

Thanks! Recoloured an enemy sprite and it's the same thing.
Mostly works but sometimes it defaults to the the original. It doesn't affect gameplay much but it's a bit strange

Nice! Its difficult to say why its defaulting to the original without seeing it running for myself (Maybe upload the project and I can take a look?). My guess is that it might the same issue as described in This post

[ZXDunny]

Holy crap dude, you're doing this by image recognition? While that's an impressive task, there really are much, much easier ways to do this
Are you monitoring an emulator screen display, or do you have your own emulator that this engine is tacked onto?

Yes that's right, it uses image recognition. Have a read though the thread posts to find out more, but to summarize, rg_software has modified the UnrealSpeccy emulator to do this. Its still at a early stage of development, but I really like the idea

Yeah, that's why I'm amazed. He's hit his limit at 20 sprites - or his PC grinds to a crawl presumably. Unless this is being run on a 486, then a much better strategy is needed. And oh my, there are so many.

[geecab]

Yeah, that's why I'm amazed. He's hit his limit at 20 sprites - or his PC grinds to a crawl presumably. Unless this is being run on a 486, then a much better strategy is needed. And oh my, there are so many.

Remember that this is an Alpha build of software, still very much a work in progress / proof of concept. The recognition code is not optimized in any way, it searches for everything, everywhere, for every frame, so its expected to be processor hungry. A few posts ago I mentioned several obvious ways I could think of to boost performance, no doubt the developer has his own ideas too so I am not too concerned about high CPU usage at this stage

[ZXDunny]

As has been pointed out, the problem is that nobody uses the tool, so... nobody is inclined to use the tool.

Graphics detection is pretty easy to do, especially as you have (in the worst case) only 6kb of image data to search. And if it's written well, you only have to search it once per frame. As the emulator builds the frame byte by byte, that portion (the screen rendering) is the perfect place to either directly replace the graphics or to buffer a list of changes that need to be made once frame generation is complete. Honestly, if I can detect 50 sprites per frame (of 16x16 pixels) in interpreted PC BASIC then a compiled solution should be able to detect thousands per frame.

As you're testing screen bytes for bit patterns (which is blisteringly fast on any PC hardware) you can then check the attribute at the end of the frame to catch those "same sprite, different colour" issues that apparently plagued Spec256 (only they didn't, really).

To be perfectly honest, I think that the best method would be a blend of Spec256's implementation alongside this sprite-detection - would solve all the issues, both the shortcomings of this and that of Spec256. Generic sprites and background items could be immediately drawn as 256 colour items, and anything procedurally generated or colour-changing could be flagged as such as part of the detection algorithm.

One thing though - don't increase resolution - Spectrum games very rarely look better in higher res, as the i-ball example plainly shows, and with a lot of games using pixel-perfect collision detection you're going to muck that up as smoothed curves generally use more pixels.

[4thRock]

The problem with recognition on a running game screen is sprite overlap and false positives.

I think a better solution would be to use pattern recognition trick to find/replace the sprites in memory or even better, on a tape file.
That would give you two options:
» Change the original pixel data. Only original resolution and no color. No overlap issues and total compatibility. You'd get a new TAP/SNA.
» Watching the original sprite memory positions and feeding extra graphic data when accessed (like Spec256 I think). Needs a special emulator but has no limitations.

[ZXDunny]

The problem with recognition on a running game screen is sprite overlap and false positives.

I think a better solution would be to use pattern recognition trick to find/replace the sprites in memory or even better, on a tape file.
That would give you two options:
» Change the original pixel data. Only original resolution and no color. No overlap issues and total compatibility. You'd get a new TAP/SNA.
» Watching the original sprite memory positions and feeding extra graphic data when accessed (like Spec256 I think). Needs a special emulator but has no limitations.

The second one has legs, IMO. Sprite overlap won't be a problem for a Spec256 implementation, as you're reading/writing 256 colour byte strips directly to the 256 colour screen. As for detection instead, you could take it one step further - hook the z80 code that draws the sprite. It's that simple - you just hijack it and draw your own sprite to the display instead.

"But that would mean we need to be able to detect the game!" You all cry. Well yes, but your current implementation of auto-identifying screen graphics already does that - your replacement graphics won't work for any other game, will they?

Just insert an $ED00 instruction at the sprite draw routine and have your emulator pause emulation while you inspect what's being drawn, render your own sprite and then issue a RET to go back to the emulation.

DId I mention that there were many solutions to this that are superior to image recognition?

[4thRock]

Image recognition solves the problem of matching sprites with memory content.
That makes it a "universal" solution. In theory all we need is a sprite sheet, and then the software would map the original memory positions for all the graphics.
This would allow for the Spec256 approach on a user friendly way
User friendly is important (that's why previous efforts have failed, too hard to work with).

[Joefish]

You need an emulator that reads and writes memory using shadow RAM images.

When a memory read is performed, you read from three extra copies of the 64k that's paged in - and store them in shadow registers. When writing, you either write just the 8 bits you read from main memory (in the case of a general memory write), unless you're writing to the screen in which case you extract 8 bits for PAPER and 8 bits for INK and combine those to a screen that can handle 256 colours. If you have 7 extra banks of RAM, you can easily make graphics that are 256 colours per pixel.

Of course, you can't load games from tape this way, but snapshots are really useful. All you need then is an editor that allows you to identify graphical objects in memory and pre-load those regions with 256 colour representations of their 1s and 0s.

This has already been done, btw, many years ago. But it never gained any traction at all, despite being very simple for the average user to mess around with. You don't need to do image recognition, no need to trap screen display routines.

I quite liked the 256 colour project, but I think there were a few flaws that needed to be overcome. It didn't get updated much. And I've probably forgotten or got most of this wrong...

The added-in backgrounds just looked awful and should have been dropped.

The SNA editor wasn't very sophisticated, and I can't exactly remember but most 256 colour palettes I see are a mess. It may have been better to pick a smaller pallette, or do something like 16 shades of 16 common colours, rather than try and use some 'web-safe' jumble where it's impossible to find the colour you want.

It would also be much more interesting if part of the palette was set aside for e.g. 8 shades of the PAPER colour of a character cell and 8 shades of the INK colour, maybe hue-shifted or tinted by the BRIGHT bit. Then when you used the INK-related colours in a sprite, they would change depending on the colour that sprite was drawn in. So in Manic Miner you could draw a penquin in cyan with an orange beak and a white belly, but the main sprite colour would swap from cyan to yellow automatically for the other penguin.

The sprite editor would also need some sort of intermediate file format where you can designate the sprites and how they're stored in memory. Once that was defined for a game, more people could then get into editing its graphics.

[geecab]

I have used Emuzwin in spec256 mode a lot quite recently. It is very good, though it doesn't work for every game you throw at it, there are also some general bugs/usability/stability issues with it too (Which I mention in this post). I really like the sound of ZXDummy's solution, and the tool that 4thRock mentions (Software that would map the original memory positions for all the graphics from a tape image). Unfortunately, these things don't exist yet, would be nice though as I'd happily use them

Its been interesting listening to opinions regarding the best way to add color to Spectrum games and what does and doesn't look correct (Amount of colors and resolution). It sounds like that would make a good debate thread on its own (I.e. "What colors and resolution should spectrum remakes have?" thread). They way I see it though, there is no right or wrong, Sinclair never released a Spectrum 48K/128K with improved graphics, so with everyone 'imagining what might have been' you are likely to get a difference of opinion. Purists can make a remake that might have been achievable in the 80ties given the hardware available if that's what they desire, but that doesn't mean everyone else must be constrained to do the same. Some people might want to make a completely modern looking remake. I was thinking that I might digitize a few of my friends, and use the tool to replace the graphics on WayOfTheExplodingFist. I thought that'll be quite a fun project, I don't need perfect results, and would be very quick & easy to achieve with the sprite recognition tool.


With all the talk of the correct/theoretical ways of doing things, its easy to loose sight of the benefits this tool (a pure sprite recognition solution) has:-

- Easy to understand and you can get something working quickly

- No Z80 machine code literacy required

- Use any paint editor you like

- Could be developed into a general solution for all platforms (Not just the Speccy)


Sure, it has its limitations, but lots can be over come and we haven't scratched the surface:-

- Sprites hiding behind sprites issues
There is always the danger of so little of one sprite showing, that recognition algorithm won't find focus. However, who is to say the recognition algorithm can't be modified one day to make intelligent guesses as to what a partially hidden sprite is based on its historical position in previous frames. Your eye does this, then recognition algorithm could be trained to, maybe .

- Performance issues
Already mentioned a few ways the tool could be optimized, and with PCs getting faster and faster I don't see this as a long term issue.

[ZXDunny]

II really like the sound of ZXDummy's solution

<splutter>

- Sprites hiding behind sprites issues
There is always the danger of so little of one sprite showing, that recognition algorithm won't find focus. However, who is to say the recognition algorithm can't be modified one day to make intelligent guesses as to what a partially hidden sprite is based on its historical position in previous frames. Your eye does this, then recognition algorithm could be trained to, maybe .

Yeah, we could have an online connection to Google's deepmind.

[Ralf]

I believe a sprite recognition is generally a wrong approach. In Spectrum games, graphics often overlap and when they overlap often things like XOR are used which alter pixels even more. And even without any XOR - when a player stands in front of a tree then only a part of a tree is visible so how it's going to get recognized? It will mostly fail and not work instead of a few very special cases where nothing touches nothing.

I would say the proper approach was used in EmuZWin - paint directly over bytes in memory. Yes, it often failed too and would need quite a lot of work to make it work better and become more user friendly but that's the way it should be.

[geecab]

<splutter>

Sorry, honest mistake