ZX Recoloring project

[rg_software]

Thanks to @geecab for pointing me to this thread! Sorry for a somewhat long reply, but my project rarely gets much attention, so let me use it as an excuse for stating my point of view

1) Motivation. I think the idea of "easy remastering" is still relevant today, and I am happy that some people share my view. What's different now. First, a few major titles got "official" remasterings and re-releases, and some companies started fighting with fan-made remakes, which doesn't increase our motivation to do this work. This concerns Speccy scene to a lesser degree, but fun remakes competitions (like organized by remakes.org) are long gone, and I miss those times. Nowadays a decent remake (especially with a blessing of a copyright holder) can be turned into a commercial mobile game, which can be a preferable path for many.

2) Tech stuff. It turns out that only certain types of games would benefit from the approach I proposed in "ZX Recoloring Project", and not all of them are equally easy to convert. Well, this is to be expected, but in practice it just means that one needs love a certain game, have a motivation to do a remake (in spite of my point (1)), be satisfied with my project's capabilities, and be happy that only the graphics gets upgraded. I wanted scrolling and better sound in Joe Blade 3, so I had to write my remake from scratch. I think it is good. Since modern emulators support advanced graphic filters, I bet many people are just happy with them.

3) On good recolorings. In my strictly personal view, a good remake (I imagined when designing ZX Recoloring Proj) should feature double-resolution sprites and updated colors. I like, for example, Deflektor, Exolon and Head over Heels remakes from Retrospec. I tried to play with triple resolution, but it looks weird -- like a huge screen populated with few huge blocky objects and vast empty spaces in between (we upgrade the screen resolution, but the game resolution stays the same). I am not a fan of keeping the initial resolution intact -- yes, I understand that such a game looks "more faithful", but... Even a double resolution is "pixelated enough" nowadays to look retro, and if a game has a version for Amiga or Atari, it would be exactly what you want -- the same game, (nearly) the same resolution, better colors. We've seen a lot of HD remasters today, and now I think we know they can look good if made properly. Say, I really like HD remasterings of Grim Fandango, Full Throttle and Monkey Island. They are good. I don't like Leisure Suit Larry, though, and I completely dislike modern Dizzy made for Android. So it is possible, but it takes time and skill.

4) On the state of "ZX Recoloring Project". I don't consider it "effectively abandoned" -- it is just being postponed every year due to other exciting things I have to do, like my daily job and other semi-hobby projects Though in practice the biggest hindrance was graphics. I wanted to create a nice showcase for the project, so I tried to recolor I, Ball 2. Unfortunately, I was never satisfied with the results. I am a reasonably decent coder, but drawing sprites is completely outside my expertise. Yes, I could so something semi-decent, but that's not the purpose of a showcase, right?

Technically the project is in a permanent alpha stage. There are a lot of things (in coding) that must be done there, but it makes sense to invest my effort only if someone really wants and is able to recolor some nice game. I don't think I can do it, but I can help and improve the project if there are any interested people around. Can't promise to do it fast, but I am still alive and capable of doing various stuff.

[Ralf]

Well and honestly said, Rg_Software.

I believe it was some kind of vicious circle here. Nobody used the tool, because they weren't any nice examples of recoloured
games with it showing what would be possible.

Maybe you actually should have finished this I Ball 2 game, it would give an impression that actually it's possible to complete
something with the tool. On the other hand if it was done with "programmer graphics" then it wouldn't be very encouraging too.

So nobody used the tool because nobody used the tool

And I'll be honest here too, people are afraid of using new, unchecked tools because they are untested and probably buggy.
So working with them may be frustrating and there is a risk that you'll do some work but eventually it'll turn out that
obtaining your goal isn't possible and you have to trash what you've done.

Double resolution was also a thing that put some people away. It should be an option, not a must. And no, working in higher
resolution and using 2x2 pixels just doesn't feel right.

That's what I feel, hope you didn't get offended by it.

[hikoki]

4) On the state of "ZX Recoloring Project". I don't consider it "effectively abandoned" -- it is just being postponed every year due to other exciting things I have to do, like my daily job and other semi-hobby projects Though in practice the biggest hindrance was graphics. I wanted to create a nice showcase for the project, so I tried to recolor I, Ball 2. Unfortunately, I was never satisfied with the results. I am a reasonably decent coder, but drawing sprites is completely outside my expertise. Yes, I could so something semi-decent, but that's not the purpose of a showcase, right?

Technically the project is in a permanent alpha stage. There are a lot of things (in coding) that must be done there, but it makes sense to invest my effort only if someone really wants and is able to recolor some nice game. I don't think I can do it, but I can help and improve the project if there are any interested people around. Chan't promise to do it fast, but I am still alive and capable of doing various stuff.

Cool project! Thanks for coming by and telling us you are still alive and kicking.

Would it be possible to use these graphics for a showcase? http://www.smspower.org/Homebrew/BruceLee-SMS
We could ask the authors for permission.
Sprites from other Spectrum games would have a big impact on me, say using Scuba Dive graphics on some other Spectrum game which is not underwater.

[rg_software]

That's what I feel, hope you didn't get offended by it.

No offense, of course. There is no ideological reason for me to restrict the resolution to double size or impose any additional restrictions. When you look at my webpage and see "2009" there, it might give an impression of a long project in a state of stagnation. In reality, it is just an early prototype I dared to put online just in case someone is interested.

However, you are right -- I should find some time and make something workable out of it. I just feel constant lack of time, though.

As suggested below, I can indeed reuse sprites of some other existing port just as a proof of concept. Bruce Lee is one possibility; another one can be to take Dizzy sprites from Amiga and recolor Dizzy 3.5, AFAIK it is Spectrum-only.

[geecab]

Thanks so much for joining the thread rg_software! Hopefully this thread will ignite enthusiasm back into the project and encourage more people to give it a try

I'm going to waffle on about the ZX Relcoloring Project now (I'm going to refer to it as 'ZXRP' in this post as I mention it a few times. Hope that's ok). Nothing is in any particular order, just stuff I have in my head after reading all the posts:-

I really like the fact how quickly with ZXRP you can add a splash of color to a much loved speccy game in a very short amount of time. For me, I'd just be happy seeing a few of my old favorites 'tweaked' a little. Perhaps just adding a dash of color to the hero & enemies so that they no longer blend into the landscape. The games that I'd like to see get the ZXRP treatment, are the games that existed on the Speccy, that didn't get a decent Amiga/AtariST port. Amaroute, Fairlight, TargetRenegade, Marauder to name a few.

I also think ZXRP will be really handy for developers when prototyping game graphics. Say you are working on the graphics for a fighting/platform type game where the hero is an Alien, the enemies are Colonial Marines. You could 'pick' a game from an vast number of Speccy titles (Lets say you pick Renegade), and use ZXRP to change the sprites of the hero/enemies. You could be really imaginative, the original 'Forward-Punch' sprite could be replaced with a 'Alien-Spraying-Acid-From-Mouth' sprite sort of thing. Very quickly you can put together a few sprites in any paint editor, and soon you'll be able to try out your own ideas (The fun part), getting the graphics looking great before progressing.

I do think the spec256 emuzwin 'way' of doing things is very good. I used it quite a lot now and have decent results (Although this varies depending on the game). The problem I've found is, emuzwin is no longer being developed and the 256 color options are a bit buggy (I spent ages recently working on Amaurote, but there are game speed issues with emuzwin running in 256 color mode. Also, with Amaurote, the screen slowly becomes corrupt with random colors and there doesn't seem to be any setting in emuzwin that can help). You also have to rely on emuzwin's sprite editor to add your colors which can be very time consuming, especially when its a case of coloring one pixel at a time. There is also the fact that you will need to know the memory locations of all the graphics you see in the game. The sprites maybe stored in memory in a confusing separated/split/reversed manor (Certainly the case for Amaurote), so that adding your artistic flair, one pixel at a time can be very tricky. Sure, some graphics are easy to find when viewing a memory dump of the game, but some sprites can not be found no matter how much you arrange the memory view/width, and you'll end up getting dirty in a load of machine code looking for them. Whereas, with ZXRP, you can just take a few screen caps of the game when that sprite is showing, bang it into an editor and off you go.

I was also thinking that perhaps one day, ZXRP could be modified as a post processing video add-on for Mame. When Mame has rendered a frame of a game, it gives it to ZXRP for some sprite replacement, before being given back to Mame so that it can be displayed on screen. Kind of like a filter. It could be used for any game platform too, not just the Speccy. Just a thought anyways

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!

Latest screenshot...
Stormbringer2

[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).