Recent posts

#1
Gopher 2600 / Re: v0.40.0-preview
Last post by Andrew Davie - 05 Feb 2025, 11:41 AM
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
#2
Gopher 2600 / Re: v0.40.0-preview
Last post by Thomas Jentzsch - 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"?
#3
Gopher 2600 / Re: v0.40.0-preview
Last post by Andrew Davie - 05 Feb 2025, 01:41 AM
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.
#4
Gopher 2600 / Re: v0.40.0-preview
Last post by JetSetIlly - 03 Feb 2025, 10:22 PM
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.
#5
Gopher 2600 / Re: v0.40.0-preview
Last post by JetSetIlly - 29 Jan 2025, 04:03 AM
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.
#6
Gopher 2600 / Re: v0.40.0-preview
Last post by Thomas Jentzsch - 29 Jan 2025, 03:42 AM
Yes, because no TV adapts to such settings automatically.
#7
Gopher 2600 / Re: v0.40.0-preview
Last post by JetSetIlly - 29 Jan 2025, 03:25 AM
?? Which bit is not realistic? Saving the hue setting per game as per the user wishes, is faking reality?
#8
Gopher 2600 / Re: v0.40.0-preview
Last post by Thomas Jentzsch - 29 Jan 2025, 02:28 AM
Sorry, I am not convinced. Looks a bit like faking reality to me.
#9
Gopher 2600 / Re: v0.40.0-preview
Last post by JetSetIlly - 29 Jan 2025, 01:18 AM
Quote from: Thomas Jentzsch on 29 Jan 2025, 01:10 AMI don't know. There is a risk that this could be abused and a game would only look OK in an emulator.

Yes. I agree that is a concern for new games. It's open to abuse for sure.

I think a compromise is for the emulator to optionally save hue settings for each ROM. So it's something the user consciously does for any game that needs it. But once it's set for the ROM it doesn't have to be done again.

Quote from: Thomas Jentzsch on 29 Jan 2025, 01:10 AMAlso PAL conversions would become problematic, since the mappings would become very random.

That would depend on how the conversion is done I think.
#10
Gopher 2600 / Re: v0.40.0-preview
Last post by Thomas Jentzsch - 29 Jan 2025, 01:10 AM
I don't know. There is a risk that this could be abused and a game would only look OK in an emulator. Also PAL conversions would become problematic, since the mappings would become very random.