ZX Recoloring project

Share graphical tips, notes and queries related to our favourite screen layout and its editors.
geecab
Berk
Posts: 18
Joined: Sun Jun 23, 2019 11:44 am

Re: ZX Recoloring project

Post by geecab » Thu Jul 11, 2019 11:35 am

ZXDunny wrote:
Thu Jul 11, 2019 7:29 am
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 :)
0 x

User avatar
ZXDunny
Microbot
Posts: 167
Joined: Tue Nov 14, 2017 3:45 pm

Re: ZX Recoloring project

Post by ZXDunny » Thu Jul 11, 2019 2:12 pm

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.
0 x

User avatar
4thRock
Dizzy
Posts: 89
Joined: Thu Nov 09, 2017 9:35 am
Location: Portugal
Contact:

Re: ZX Recoloring project

Post by 4thRock » Thu Jul 11, 2019 2:30 pm

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.
0 x

User avatar
ZXDunny
Microbot
Posts: 167
Joined: Tue Nov 14, 2017 3:45 pm

Re: ZX Recoloring project

Post by ZXDunny » Thu Jul 11, 2019 3:25 pm

4thRock wrote:
Thu Jul 11, 2019 2:30 pm
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?
0 x

User avatar
4thRock
Dizzy
Posts: 89
Joined: Thu Nov 09, 2017 9:35 am
Location: Portugal
Contact:

Re: ZX Recoloring project

Post by 4thRock » Thu Jul 11, 2019 4:40 pm

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).
0 x

Joefish
Manic Miner
Posts: 476
Joined: Tue Nov 14, 2017 10:26 am

Re: ZX Recoloring project

Post by Joefish » Thu Jul 11, 2019 6:52 pm

ZXDunny wrote:
Sat Jul 06, 2019 9:59 pm
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.
0 x

geecab
Berk
Posts: 18
Joined: Sun Jun 23, 2019 11:44 am

Re: ZX Recoloring project

Post by geecab » Fri Jul 12, 2019 12:39 pm

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.

:)
0 x

User avatar
ZXDunny
Microbot
Posts: 167
Joined: Tue Nov 14, 2017 3:45 pm

Re: ZX Recoloring project

Post by ZXDunny » Fri Jul 12, 2019 1:14 pm

geecab wrote:
Fri Jul 12, 2019 12:39 pm
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.
1 x

Ralf
Dynamite Dan
Posts: 1161
Joined: Mon Nov 13, 2017 11:59 am
Location: Poland

Re: ZX Recoloring project

Post by Ralf » Fri Jul 12, 2019 2:39 pm

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.
0 x

geecab
Berk
Posts: 18
Joined: Sun Jun 23, 2019 11:44 am

Re: ZX Recoloring project

Post by geecab » Fri Jul 12, 2019 3:57 pm

ZXDunny wrote:
Fri Jul 12, 2019 1:14 pm
<splutter>
Sorry, honest mistake :)
0 x

Post Reply