Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can we have the option Color (Standard) back? #357

Closed
mediaguy opened this issue Oct 9, 2016 · 58 comments

Comments

Projects
None yet
@mediaguy
Copy link

commented Oct 9, 2016

NOOB post here ... Not sure where to post a wish to this forum. I love this emulator. It's the BEST! However, I have one (personal) issue which is really a wish/complaint...

I know the latest releases attempt to better emulate the visual experience on the color TVs or monitors some of us used with our beloved Apple II. However, I'm one of the minority, I'm sure, that doesn't love the blurred or hashed/alt scanlined emulated effects in the 1.26.xx releases.

How can I request, humbly, that the video option Color (TV Emulation) last used in v1.25.04 be added back or perhaps an option to turn off the added visual "effects" which blurs or hashes the video graphics. MAME provides for this to accommodate the visual preferences of its users. I'd simply like the option to turn this off/on ... until that is added then I may have to stick with 1.25.04, but don't want to ...

So, help a NOOB out and tell me how to post a "feature wish" for future releases if this is the wrong area and if my request is crazy. :)

Thanks all.

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Oct 10, 2016

Thanks for your positive feedback!
... and this is the right place to post this kind of thing.

Just to check: Does the new 1.26 "Color Monitor" video mode not meet your needs?

@mediaguy

This comment has been minimized.

Copy link
Author

commented Oct 10, 2016

applewin_screenshots compare v1 25 04 v 1 26 xx

No, it's not really. I know I will be in the minority, I suspect, but the graphics rendering has shifted a lot in v1.26.xx and I get why but I'd like the prior setting still available for folks like me. I've attached a screenshot of comparisons to show what I'm seeing in case it's unique or not as you expected.

The top portion (across) shows 3 snaps out of v1.25.04 from Lode Runner (text, title, and game snap) and the bottom (across) shows 3 snaps out of v1.26.05 from same dsk file.

Hope it helps.

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Oct 11, 2016

Thanks for the extra detail & screenshots. I'll discuss this further with the other AppleWin devs.

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Oct 11, 2016

In the thread "AppleWin 1.26.0 (pre-release)", Steve Nickolas on cea2 posted:

19 Sep 2016:

If I miss something, it's a "normal-ish" mode that blends color in
graphics modes, but still shows clear text in text modes.

With the current version, I either get blended color and blurry,
headache-inducing text (even in text mode), or sharp text and unblended
color.

10 Oct 2016:

"Blended color and blurry headache-inducing text" is "Color TV".

"Sharp text and unblended color" is "Color Monitor".

I believe I generally used to use Color (Text Optimized).

If I had the option, I'd have it so that graphics modes appeared as
"Color TV", but text modes appeared as "Color Monitor" (i.e., just
plain, clean, unfiltered, unblurred, black and white). (And I'd be OK
with the text in graphics modes still being fringed and blurry. I used
ApplePC for years, and it emulates that quirk faithfully.)

@puzzud

This comment has been minimized.

Copy link

commented Oct 12, 2016

I want to bump this enhancement.

I often see display artifact emulation as a novelty--something I rarely actually use though. I recognize that typically I am using C64 and NES emulators and that with systems like Apple II and Atari 2600 the way these display artifacts manifested were part of how shades of colors and quasi-transparency were achieved.

When developing Apple II programs and games, it's nice to run in a crisp mode where one can count pixels and such.

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Oct 13, 2016

I'll discuss this further with the other AppleWin devs.

There's some general agreement (within the team) that reinstating a "Color (TV Emu)" or straight RGB (solid crisp colour and text) would be good.

Is there a preference for either "Color (TV Emu)" or straight RGB?

NB. There won't be any reinstatement for the imminent 1.26.0 release, as I want to get that out in a few days.

@Keatah

This comment has been minimized.

Copy link

commented Oct 13, 2016

Why not do it both ways? Have an option (like most emulators) to enable artifacting or not.

@sicklittlemonkey

This comment has been minimized.

Copy link
Contributor

commented Oct 13, 2016

@Michaelangel007

This comment has been minimized.

Copy link
Contributor

commented Oct 14, 2016

Enclosed is a .zip file of the lode_runner logo .hgr and .dsk that auto-loads the logo.
lode_logo.zip

I'm currently in the process of allowing a 16x1.bmp file to be imported as the palette.

@Michaelangel007

This comment has been minimized.

Copy link
Contributor

commented Oct 14, 2016

There are 2 issues being conflated here:

  • The vertical "mixing" of two adjacent scan lines (even and odd) to artificially produce colors (such as grey)
  • The screen shots show that what people are really asking for is "solid, crisp" pixels.

WRT to the Lode Runner image and the second issue:

  • AppleWin v1.25 does NOT generate an authentic image. It artificially "sharpens" the 140x192 resolution so colors appear "solid".
  • AppleWin 1.26 properly emulates what a real monitor shows -- this means we lose the fake "solid" colors of 1.25. The trade-off is that pixels are no longer sharp but blurry as on a real monitor. :-/ On the positive side we get accurate colors.

For 1.26 authenticity was chosen over non-authenticity.

1 26_default_palette

It is possible to "clean" up the some of the pixels by extending a 64-color palette to fill in the remaining values ...

1 26_manual_64x1_palette

... so we end up with this:

1 26_tweaked_palette

I know some people prefer the crisp, but blocky look of 1.25 and I hear your lament. (Personally, I hate the "blurry" look but I prefer accurate colors. :-/ I take (some) consolement in that fact that a real monitor is worse.) Unfortunately, this not possible unless one manually tweaks all 16,384 colors in the palette. Why? Because the chromatic value of a single pixel depends on adjacent bits. i.e. This is what causes the color fringes when the monitor transitions from black to white.

I've added support (commit 515e66c) so that the debugger can now import 16x1 and 64x1 BMP files for the NTSC palette which will help, but not entirely solve the problem.

  • ntsc load 64x1.bmp
  • ntsc load 16x1.bmp

Note: Bitmaps must be in 32-bit format.

As you can see while sharpness is better it ends up creating more problems then it solving. ("Text" on the graphics screen is how horrible.)

Using the first 16 colors (phase 0 of the 64 colors) ...

16x1

... we end up with this:

1 26_manual_16x1_palette

e.g. When we make the colors solid the fringes become more pronounced.

Note: The 16 colors could definitely be optimized. I just used the first 16 colors of phase 0 -- but ideally for each color we should pick the most accurate (brightest?) colors across all 4 phases.

There is no good solution that gives everyone what they want due to the goals being mutually exclusive:

  • Solid Colors
  • Sharp Pixels
  • Accurate Colors

They may be compromises but that will take some R&D to figure out how to "best" meet all these conflicting goals.

Hope this gives some info. so people can better understand the issues and trade-offs.

@Michaelangel007

This comment has been minimized.

Copy link
Contributor

commented Oct 14, 2016

Lode Runner Demo Level:

1.25 Color TV

1 25_demo

1.26 Default

demo_default

1.26 Tweaked

demo_tweaked

1.26 Solid 16 Colors

demo_16x1

Raw .HGR (zipped)

demo.zip

@Michaelangel007

This comment has been minimized.

Copy link
Contributor

commented Oct 14, 2016

Regarding the first point:

  • The vertical "mixing" of two adjacent scan lines (even and odd) to artificially produce colors (such as grey)

In the 1.25 screenshot of the demo level -- we can see the enemy Bungling head is a grey pixel.

Using my HGR Byte Inspector ... these 2 bytes are ...

hgrbyte

  • X=14 Y=42: $283C: 90
  • X=14 Y=43: $2C3C: A8

In a future 1.27+ one way to achieve this grey would be to add another (frame) buffer where we save the raw 12-bit values per pixel (in a 16-bit framebuffer). Obviously a 12-bit even + 12-bit odd = 24-bit "mix" lookup table is impractical but there might be a way to lose precision without a general loss of quality.

@puzzud

This comment has been minimized.

Copy link

commented Oct 14, 2016

@Michaelangel007, good point. I think this issue's title speaks to the desire to have at least one of the old modes from 1.25.0.3.

The issue author's main point it seems is to have a mode which does not blur to the effect of making my fancy monitor feel like an old CRT.

Personally, I miss "Color (Standard)". I probably should file such separately, but I think it's a related sentiment. I'm not a fan of the vertical lines--it makes the next version almost unusable for me.

@Michaelangel007

This comment has been minimized.

Copy link
Contributor

commented Oct 14, 2016

I_do_ believe it is possible to tweak the 4,096 colors * 4 phases = 16,384 colors to get the sharpness of v1.25 without degrading the color accuracy of v1.26 too much.

The bottleneck is figuring out how the 4,096 colors map to the 65,536 permutations of 2 consecutive HGR bytes.

What is involved is inspecting the bit patterns and prioritizing one color.

For example, Lode Runner's ladder has these bytes:

2C80: 86
3080: 86
3480: FE

One idea might be to inspect the NTSC palette and force any color "near" white to be "white", and any color "near" black to be black. This would improve the sharpness albeit at the cost of losing the color fringes.

Technically we don't need to map the full 16,384 colors as Colors 0, 5, 10, and 15 are pure colors. (0x000000, 0x838383, 0x787878, 0xFFFF respectively.)

Palette Entries to Fix
= 16,384 - (Black 256 colors * 4 phases) - (Gray1 256 colors * 4 phases) - (Gray2 256 colors * 4 phases) - (White 256 colors * 4 phases)
= 163,84 - 1,024 - 1,024 - 1,024
= 13,312 palette entries still need fixing.

Edit: Removed incorrect color == 1, color == 14

Note: Also see #253 and #254

@sicklittlemonkey

This comment has been minimized.

Copy link
Contributor

commented Oct 15, 2016

Perhaps we PAL //e users had the best of both worlds.

titlemixedtrimmed

@Michaelangel007

This comment has been minimized.

Copy link
Contributor

commented Oct 16, 2016

Nice Nick !

I guess at some point we probably should add an option to kill the color burst in mixed mode -- even though it isn't accurate it is practical. :-)

@waltervn

This comment has been minimized.

Copy link

commented Dec 4, 2016

While I really appreciate having these new display modes to play around with, I'd also like to request a return of the "Color (Standard)" mode. I personally use an RGB SCART cable with my IIc and it looks very similar to that mode.

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Dec 5, 2016

@waltervn - thanks for sharing your opinion.

@tomcw tomcw changed the title Not an issue (per se) .. Can we have the option Color (TV Emulation) back? Can we have the option Color (TV Emulation) back? Feb 11, 2017

@mikezila

This comment has been minimized.

Copy link

commented May 29, 2017

Has there been any more discussion on this? I'm using 1.26.1.1 and it's still missing any mode with non-blurry graphics modes. I can appreciate that the behavior is more correct/accurate than perfectly crisp colors, but I would really love the option to just have crisp colors in graphics modes instead. I consider highly accurate (crt effect, color blending, scanlines) graphics a nice novelty, but not one I'd use often.

@tomcw

This comment has been minimized.

Copy link
Contributor

commented May 29, 2017

Nothing much has been discussed recently, but I'm still interested in taking this forward. Privately I have made a few notes about how I might approach this, and I've been familiarising myself with the NTSC code as I've been fixing a few edge-case rendering bugs. So currently just small steps, and nothing in the very immediate pipe.

@6502-workshop

This comment has been minimized.

Copy link

commented Jun 25, 2017

Hi guys! First of all, I’d like to say AppleWIN is great. It is my emulator use the vast majority of the time.

Additionally, I’d like to add my voice to the OP requesting an option to turn on a video mode equivalent to Color (TV Emulation) in v1.25.04.

I have a number of reasons but I think the most compelling is it’s usefulness for quickly visually inspecting pixels during development, as another poster mentioned.

For that reason I’m currently running both 1.25.04 and 1.26.02, which isn’t ideal. For example, needing to make sure to promptly test my software in 1.26 that might be affected by a bug fix, such as bank switching write-mode.

I’m sure there are a lot of priorities, and understand if this one doesn’t make the cut. I just wanted to add my perspective to the mix.

Thanks.

Mark

@Keatah

This comment has been minimized.

Copy link

commented Jun 26, 2017

I also run two versions, 1.25.0.4 and 1.26.2.4 for those very same reasons. So bringing back the color tv option, without effects, is important to me.

@Michaelangel007

This comment has been minimized.

Copy link
Contributor

commented Sep 19, 2017

(Thread from #408 asking about the next major release.)

This is a HUGE undertaking -- especially W.R.T. all the video modes.

I don't have any plans to address it until next year (due to Games Disassembly Projects, DOS 3.3 disasm, Debugger and Saturn support). Is anyone else working on this? Tom you've mentioned you have a few notes -- is it a bit pre-emptive to share those?

To minimize the amount of work one option might be to add a new F9 mode that works ONLY with HGR (and supports mixed TEXT mode).

@peterfarted

This comment has been minimized.

Copy link

commented Dec 29, 2018

Nice! I am also seeing good results so far (playing my favorite horse racing game), will report back if I run into any issues. Thank you very much!!

@Keatah

This comment has been minimized.

Copy link

commented Dec 29, 2018

Looking good so far.

@ShadowMan44

This comment has been minimized.

Copy link

commented Dec 29, 2018

Works great, sprite ripping should be doable for me now.

@sicklittlemonkey

This comment has been minimized.

Copy link
Contributor

commented Dec 29, 2018

@inexorabletash

This comment has been minimized.

Copy link

commented Dec 29, 2018

Comparison screenshots, for posterity? (And for those following along vicariously.)

@mediaguy

This comment has been minimized.

Copy link
Author

commented Dec 30, 2018

Wow ... all I can say is hallelujah!! This experimental version works pretty darn great so far. Only tested a handful of titles and it's great. I love it!!!!

@peterfarted

This comment has been minimized.

Copy link

commented Dec 30, 2018

Sorry for spamming everyone's notification boxes, I take cookbook templates a little too literally, which is why I could never figure out Linux or Unix...

Before
After

I am sure many emulation purists will prefer the first style and that is totally valid. My darn-near bifocal-needing eyes prefer the second. Again, thanks for the fix!

@6502-workshop

This comment has been minimized.

Copy link

commented Dec 30, 2018

Tom,

Thanks, looks great! It looks to me like 1.27.14 renders Color (Standard) just as 1.25.04 did.

Any plan to also include an option for Color (TV Emulation)? I read back through the issue comments and didn't see a conclusion, sorry for the redundant question if this was decided and I missed it.

Mark

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Dec 30, 2018

Thanks everyone for testing & feeding back.

Hi Nick,

holding down F9 cycles through the modes, but occasionally a line will flicker with garbage

Yes, I've seen this too, and in older versions (1.26 / 1.27) so this isn't a regression. I'll raise a new issue for this.

Hi Mark,

Any plan to also include an option for Color (TV Emulation)?

NB. Better vertical blending for the NTSC video modes is covered by #344.

The problem with AppleWin 1.25's "Color (TV Emulation)" is that is doesn't support the HGR half-dot-shift like 1.25's "Color (Standard)" (eg. Archon's title screen's "A" has smooth diagonals). Which was one reason for choosing this "Color (Standard)" 1.25 video mode (the other reason being that most in this issue-thread just wanted the solid colour/sharp text, and didn't mention the vertical blending).

My current preference is not to just reinstate the old 1.25 "Color (TV Emulation)"... although admittedly just adding it is the easiest option. Let me think about it. But if I can unpick the logic for "Color (TV Emulation)" then perhaps adding this as an option to modify this "Color Simplified" video mode is best (eg. like CTRL+SHIFT+F9 modifies the video mode to toggle 50% / 100% scan lines).

@6502-workshop

This comment has been minimized.

Copy link

commented Dec 30, 2018

Hi Tom,

My current preference is not to just reinstate the old 1.25 "Color (TV Emulation)"... although admittedly just adding it is the easiest option. Let me think about it.

Thanks for considering it! Currently there is no Apple II emulator I'm aware of which does vertical blending in a way where colors like yellow and dark blue are visible (other than AppleWIN 1.25.04 of course), it would be really great to have Color (TV Emulation) as a workaround until a better solution is implemented, such as #344.

But, I totally understand if you decide not to do it. I'm sure there are factors like technical debt, prioritization, and other things to consider.

Again, thanks for even considering it!

Mark

@Michaelangel007

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2019

There ARE minor differences with the chroma. I'll be uploading a whole set of images. Here is the first batch of comparison screenshots

Lode Runner

  • Logo

    • 1.24
      1.24 Lode Runner Logo

    • 1.27
      1.27 Lode Runner Logo

  • Level 1

    • 1.24
      1.24 Lode Runner Level 1

    • 1.27
      1.27 Lode Runner Level 1

Lambda

  • 1.24 Lambda

  • 1.27 Lambda

@Michaelangel007

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2019

Next batch ...

Swashbuckler

  • 1.24

1 24_swashbuckler_logo

  • 1.27

1 27_swashbuckler_logo

Ultima 4 Logo

  • 1.24

1 24_ultima4_logo

  • 1.27

1 27_u4_logo

@Michaelangel007

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2019

The GR Color accuracy of 1.24 is pretty bad. 1.27 is definitely better. Even the 2 grays match. :-)

  • 1.24

1 24_gr_colors

  • 1.27

1 27_gr_colors

@Michaelangel007

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2019

Aztec

No real change in the Aztec since it isn't using fine detail.

  • 1.24

1 24_aztec_logo

  • 1.27

1 27_aztec_logo

Gumball

The bottom text is a little more readable now since there is less chroma fringing.

  • 1.24

1 24_gumball_logo

  • 1.27

1 27_gumball_logo

@Michaelangel007

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2019

My standard "goto quality" are these two litmus tests:

  • Archon 1 Logo,and
  • my HGR Byte Permutations.

Let's take a look at Archon first.

Archon

  • 1.24

The diagonals of the cubes have noticeable color fringing in 1.24 and almost none in 1.27. I like this trade-off.

Also, text is more readable such as the last part of "Nitchals". Again, this looks good.

1 24_archon_logo

  • 1.27

1 27_archon_logo

HGR Bytes

Moving on, let's examine all the permutations of the HGR bytes or pixels.

As I mentioned at the start of this comparison there are minor differences between 1.24 and 1.27. Now that we've seen a few comparison screenshots and the difference we can summarize the differences from 1.24 and 1.27:

If we take a look at the visual difference we can see which specific patterns have less chroma fringing. That is, when we have a span of white pixels with a 1 px gap and another white span 1.24 will colorize the gap. In 1.27 this doesn't happen. This is a reasonable trade-off. For "HGR text" this is worth doing. For graphics we usually want that black gap. Are there any images where 1.27 this looks worse? I haven't seen any (yet).

There is also a faint / ghosting of blue due to 1.27 using more accurate colors. We can ignore this.

  • 1.24

1 24_hgr_bytes

  • 1.27

1 27_hgr_bytes

  • Here is the visual difference between 1.24 and 1.27 so we can specifically see which pixels are different.

hgr_bytes_diff

Next message I'll summarize my conclusions.

@Michaelangel007

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2019

Conclusions

I hope that is a large enough sample size.

First impressions -- I really like what you've done Tom!

First, the 1.24 Standard 1.27 Color Simplified rendering is a HACK. They were designed as a "fast good enough" solution back in the day on slower computers. And as such there are various trade-offs that I've mentioned back near the start of this thread.

Hacks are perfectly fine -- when we are aware of them. As I say "One man's noise is another man's music."

Accurate colors on the Apple will always be a "blur" due to the "wave" peak to trough brightness of adjacent pixels. Remember, on the Apple 2 EVERY HGR color image is basically a monochrome image with hue hacked in. How do we handle these even/odd transitions? Fill them in with a color? Which color? Extend the previous color or use the proper "wave phase" color?
Due to the way the Apple does Color = "Monochrome Just Add Hue" TM design decisions influence the quality because we are forced to pick one or the other: Color Accuracy or Sharpness.

The "solid colors" is a preference thing. Due to faking solid colors the color accuracy will never be good in this mode. And for some that's OK. For those that want the correct wave phase color we have Color Monitor mode.

Second, as we get older many of us want "sharper" edges. That's the advantage of Standard / Color Simplified.

I think we've taken this mode as far as we can (for now.) There is still the topic of vertical blending to better support perceived perceptual color but that is a whole different topic.

Given the limitations of this mode I really like the way 1.27 Color Simplified looks all things considered. I'm glad we again support both options.

Thanks Tom for adding this back in! Looks good!

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2019

Hi Michael,

Thanks for doing this extensive analysis... and it's actually shaken out a subtle bug:

Also, text is more readable such as the last part of "Nitchals". Again, this looks good.

This wasn't what I intended!

  • If you quit AppleWin in any video mode that's not "Color Simplified", then restart this experimental 1.27.14 AppleWin then you'll get this "text optimized" effect (when you switch to "Color Simplified). This is a bug AFAIAC!
  • If you quit AppleWin in "Color Simplified", then restart this experimental 1.27.14 AppleWin then you'll get the regular 1.25 "Color (Standard)" mode.

My intent was the 2nd of these.
I see "text optimized" similar to "vertical blending", ie. as a style or post-effect.

Your 1.25 screenshot:
1 24_archon_logo

My intended 1.27:
archon-1 27 14

btw. (minor typo) in all your comments above you reference 1.24, when really this is 1.25 - 2x windowed mode was added at 1.25, so these screenshots must be from 1.25! : - )

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2019

A couple more screenshots that can't be compared with 1.25 (which didn't support cycle accurate video mode switching), which show sharp TEXT40/TEXT80 when mixed with graphics modes:

Mixed (horizontal) DGR & TEXT80: (FT's Ansi Story)
as-side1

Mixed (vertical) DGR & TEXT80: (FT's Ansi Story)
as-side2

Double height GR (96x40), interlacing GR1 & GR2: (Deater's Cycle Counting Megademo)
megademo-gr96

Mixed (horizontal) TEXT40 & GR: (Deater's Cycle Counting Megademo)
megademo-mixed

@Michaelangel007

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2019

btw. (minor typo) in all your comments above you reference 1.24, when really this is 1.25

Actually I used Version 1.24.0.0. That's what the .exe properties say along with version from the debugger. =P

I don't believe there are any visual differences between 1.24 and 1.25 but I should probably double check instead of assuming.

@Michaelangel007

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2019

If you quit AppleWin in any video mode that's not "Color Simplified", then restart this experimental 1.27.14 AppleWin then you'll get this "text optimized" effect (when you switch to "Color Simplified). This is a bug AFAIAC!

That definitely is.

I guess that raises a question -- are we going to bring back Text Optimized mode for 1.27 ?

i.e. 1.25 / 1.27

  • Color Standard -> Color RGB Simplified
  • Color Text Optimized -> Color RGB Text Simplified
@tomcw

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2019

I guess that raises a question -- are we going to bring back Text Optimized mode for 1.27 ?

I've no plans to at the moment. I'd rather limit the feature set to those that there's strong demand for (initially). Mark (above) nails it with "factors like technical debt, prioritization", and also increased testing matrix.

tomcw added a commit that referenced this issue Jan 9, 2019

Reinstate support for old AppleWin 1.25 "Color (Standard)" video mode (
…#357) (PR #614)

Renamed this video mode to: "Color (RGB Monitor)"
Also renamed "Color (Monitor)" to "Color (NTSC Monitor)".

As for the colours: I've changed them from the original 1.25 colours. Instead I runtime-generate the colours from the NTSC code. See NTSC.cpp's GenerateBaseColors(). This shifts the same 4-bit pattern in, combining with NTSC color phase, until the colour stabilises. Then I average the next 4 RGB values to get the final colour. The reason for this is that we now have consistent colours between NTSC and this simplified rendering mode.

NB. The 2 greys (in GR,DGR,DHGR) are now the same RGB value.

@tomcw tomcw added this to the 1.28 milestone Jan 12, 2019

@tomcw tomcw changed the title Can we have the option Color (TV Emulation) back? Can we have the option Color (Standard) back? Jan 12, 2019

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Jan 12, 2019

I've changed the title so this bug is just for bringing back "Color (Standard)", which will be done at 1.28.0.
Closing this bug.

@tomcw tomcw closed this Jan 12, 2019

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Jan 12, 2019

NB. Release of AppleWin 1.28.0 is here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.