Yes, because no TV adapts to such settings automatically.

Quote from: Thomas Jentzsch on 29 Jan 2025, 03:42 AMYes, because no TV adapts to such settings automatically.

Fair.

But there's lots we do with emulators already that improve ease of use but aren't realistic. No console allows us to unplug a joystick and to plug in a paddle automatically but we set up emulators to effectively do that.

All that's happening with a hue adjustment is the automation of getting out of the armchair and moving the knob. If the user chooses to do that every time they launch a specific game then I don't see the harm in allowing the user to choose to automate that.

But I agree that it's a bad idea to allow this to happen without the user explicitly making the choice. I called it "palette abuse" in my post and it's likely to happen over time.

Quote from: Thomas Jentzsch on 28 Jan 2025, 09:13 PMYour findings about the different hues are interesting. I suppose the developers had configured their TVs quite badly. Without noticing!

I've been thinking about this and trying to understand the circumstances which resulted in the Krull we see today.

First off, I would imagine that developing in the 80s is very different to today. As far as I can tell, the development cycle would have been very slow by comparison. Today we can change the program, assemble it and boot it in an emulator very quickly. In the 80s, the time between a changing the program to seeing the results on screen would have been much longer.

So, when selecting the values to use for colour, surely the developers would use the reference table in the Stella Programmer's Guide (or equivalent). They wouldn't just blindly try different values until they got the result they wanted (which we might do today because the feedback is immediate).

But when the hue is shifted so that Krull more closely matches the images on the game box, the colour table in the guide is completely wrong. How could they have missed that?

I'm not ready to believe it was intentional but if it isn't, I'm struggling to understand how the development process allowed that to happen.

The other possibility, is that the person who prepared the box art had their TV hue aligned differently and which just so happened to be a setting that results in a better looking Krull (to my eyes at least).

For that we would have to accept that quality control when producing the final product was poor. We would also have to accept that the developers wanted the castle walls to be green.

I'd love to quiz the person who made the game.

The other possibility is that my colour calculations are wrong but I would need somebody else to check that because I can't see where the problem would be.

Quote from: JetSetIlly on 03 Feb 2025, 10:22 PMFirst off, I would imagine that developing in the 80s is very different to today. As far as I can tell, the development cycle would have been very slow by comparison. Today we can change the program, assemble it and boot it in an emulator very quickly. In the 80s, the time between a changing the program to seeing the results on screen would have been much longer.

When we were burning EPROMs to check, was about 15 minutes.
Eventually we got IBM plug-in boards which emulated the ROMs, and at that point we could build/test in about 20 seconds.

Quote from: Andrew Davie on 05 Feb 2025, 01:41 AMEventually we got IBM plug-in boards which emulated the ROMs, and at that point we could build/test in about 20 seconds.

When was "eventually"?

Quote from: Thomas Jentzsch on 05 Feb 2025, 03:31 AM

Quote from: Andrew Davie on 05 Feb 2025, 01:41 AMEventually we got IBM plug-in boards which emulated the ROMs, and at that point we could build/test in about 20 seconds.

When was "eventually"?

Best guess 1987

I've written a new blog article describing the process of "phase adjusting" a fixed RGB palette. I incorrectly believed that it wasn't possible to adjust the phase of a fixed palette but I show here how it can be done. It's an easy additional step that I missed.

https://jetsetilly.github.io/Gopher2600-Blog/posts/improving-the-ntsc-colour-model/

As I say in the conclusion, this method has the advantage of using a "standard" palette that modern people expect while also emulating the colour delay pot. Of course, there are still massive questions about what the correct calibration is but I think this is a nice compromise.

I'm happy with this and will finalise v0.40.0 of Gopher2600 later today (at long last).

https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.40.0