Can we have the option Color (Standard) back?

[mediaguy]

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]

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]

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]

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

[tomcw]

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]

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]

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]

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

[sicklittlemonkey]

Just to be clear, "Color (TV Emulation)" had blending of adjacent _vertical_ lines, for those who aren't aware of this. So alternating lines of red and green would become solid yellow. No-one above has mentioned that feature - just the ability to turn off the "blur" of NSTC emulation - so possibly it's a separate issue. EDIT (by Tom): Yes, see #344. If so, perhaps this issue should be renamed to RGB video emulation etc. Cheers, Nick.

[Michaelangel007]

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]

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.

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

... so we end up with this:

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

... we end up with this:

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]

Lode Runner Demo Level:

1.25 Color TV

1.26 Default

1.26 Tweaked

1.26 Solid 16 Colors

Raw .HGR (zipped)

demo.zip

[Michaelangel007]

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

• 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]

@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]

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]

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

[Michaelangel007]

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]

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]

@waltervn - thanks for sharing your opinion.

[mikezila]

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]

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]

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]

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]

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

[tomcw]

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)

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

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

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

[Michaelangel007]

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]

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]

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]

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]

NB. Release of AppleWin 1.28.0 is here.

[NoxFfred]

I have a request to add a video mode simular in effect to the "Color (Text Optimized)" mode which was present in AppleWin v1.25. Michael P. suggested this as a good place to post it.

The reason is because we get a significant number of requests from Nox Archaist players to remove the color bleed from the text so it is easier to read.

Here is a screenshot of Nox Archaist text in v1.2.5.04. I realize this is now an unsupported version, I am just providing it as an illustration.

Thanks for considering!

[Michaelangel007]

Here are 6 screenshots (Normally 3 but I've included both half and 50% scanlines)

• v1.25 full scanlines
  

• v1.25 half scanlines
  

• v1.31 idealized full scanlines
  

• v1.31 idealized half scanlines
  

• v1.31 NTSC full scanlines
  

• v1.31 NTSC halfscanlines
  

[Michaelangel007]

2x3 Mega Image. Look at the word Import in the 3rd menu option:

[Michaelangel007]

@tomcw Do we want to create a new issue? i.e. Bring back Text Optimized mode?

[Michaelangel007]

I just realized I never uploaded the "Tweaked_Palette.bmp" that showcases how tweaking the NTSC palette can make the image worse (or better.)

Tweaked_Palette.zip

[Michaelangel007]

The tweaked image is just manually setting all 4 phases to the same 16 colors for all 256 permutations.

[hasseily]

For Text Optimized mode, duplicate the RGB Card mode, and set the pixel to black that is in the middle of 11011.
I can submit a pull if you want.

[Michaelangel007]

Proof of concept when the NTSC palette is hand tweaked to remove color fringing. I call this "NTSC Text Optimized"

I spent about 4 hours manually touching up colors one by one. The process was:

1. Load the HGR image in AppleWin
2. Alt-PrintScreen the main menu of Nox Archaist
3. Paste the NTSC screenshot into GIMP
4. Isolate a color that should be either black or white
5. Switch to the NTSC palette in GIMP
6. Select > By Color to find the EXACT color in the palette
7. Use the pencil tool to the color to either black or white on a new layer
8. Export the BMP
9. NTSC LOAD in the debugger
10. Rinse and repeat 2-9.

Things that were cleaned up:

• removing chroma from the inside of letters
• removing black ghosting

Things that weren't:

• color fringing on the edges of glyphs

Here is the Select Color options for GIMP:

The Pencil options are (size is 1 px):

Here is the WIP NTSC "Text Optimized" palette:

It isn't obvious what colors were hand-tweaked so here is the background set to gray to make them stand out:

[NoxFfred]

@Michaelangel007 the text on this looks great!

[Michaelangel007]

@Michaelangel007 the text on this looks great!

Thanks! Still have more work to do but it looks promising.

Here are my raw notes about the colors touched up.

Dull brown "E" left side
133, 115, 48
..................RRR..GGG..BBB...XXX YYY NTSC Palette BMP location
"p" hole left 2 : 255, 255, 200    45  60  White
"p" hole left s : 165, 134, 131    60  60  Black
"p" hole center :  43,  34,  67     9 120  Black
"p" hole right  : 144,  60, 146    19 240  Black
"p" hole right 2: 240, 188, 255    39 225  White

About, "b" inside hole
"b" hole left 2 : 244, 243, 255    14  30  White
"b" hole left   : 121, 152, 155    28  60  Black
"b" hole center :  38,  47,  14    41 120  Black
"b" hole right  :  46, 130,  44    51 240  Black
"b" hole right 2: 195, 247, 123     7 225  White

"b" hole left2b : 128, 138, 209    28 252  Black

"n" hole left  : 110, 150, 192     28 124 Black
"n" hole center:  28,  46,  46     41 248 Black
"n" hole right :  46, 130,  44     51 240 Black ... already done
"n" hole right :  64, 118,  61     51 112 Black
"n" hole left  : 148, 134, 178     28  28 Black

"a" top hat
"a" left       :  13,  13,  40      1 127 Black
"a" mid        : 149,  87, 149     19 255 Black
"a" hole
"a" left       : 139, 152, 108     60  28 Black
"a" mid        :  23,  48,  48      9  56 Black
"a" right      : 126,  73, 129     19 112 Black

"a" top
"a" left       :  10,  18,  24     33 255 Black
"a" mid        :  77, 139,  76     51 255 Black
"a" right      : 213, 251, 157      7 255 White

"a" middle vertical
"a" right      : 165, 137,  99     60 192 Black
"a" right      :  53,  11,  27      8 128 Black
"a" right      :  29,  33,   0      8  24 Black

About "o" inside hole
"o" hole left 2 :
"o" left       : 158, 148, 77      60 252 Black
"o" mid        :  53,  36, 35       9 248 Black
"o" right      : 144,  60, 146 ... already done "p"


Bottom "n" inside hole
"n" left       : 153, 156, 56      60 12 Black
"n" mid        :  36,  51,  1       9 24 Black
"n" right      : 137,  75, 92      19 48 Black

"S" bottom loop
"S" left       :  46,  17,   1     8 248 Black
"S" mid        :   6,   0,  35    33 225 Black
"S" right side :  84, 128,  98    51 195 Black

Black Fringing
"N" right side
   11,  32,  15    40 120 Black
  135, 131, 231    28  12 Black
   19,  16,  81    40  24 Black
  110, 159, 129    28   0 Black
    7,  41,   0    40   0 Black
   96, 180,  53    28  48 Black
    0,  57,   0    56 201 Black False Postive #1 Black
                   49 136       False Positive#2 Green
                   40  96       Match
   22,  15,   8     1 255 Black
   37,  16,  33     8 120 Black
    2,  31,  47    40 248 Black
   20,  19,   1    33 127 Black
   16,  27,   0    33   7 Black
   72, 146,  55    51  15 Black
   59,  33,  33    41  56 Black
    6,  26,   1    33 135 Black
  117, 145, 184    28 192 Black
    0,  39,  23    40 128 Black
  172, 123, 153    60   0 Black
   43,   9,  59     8   0 Black
  185, 101, 228    60  48 Black
   50,   0, 125     8  96 Black

At some point I want to figure out the pattern for why certain transition colors should be forced black or white. i.e. Reverse mapping. Given a RGB color figure out what bit-pattern produced it.

Another option would be to add NTSC EDIT and show a cursor on the HGR screen and have it dump the array index that was accessed for that pixel.

Lastly, another option is to hack up the RGB Mode to add a text optimized version as mentioned by hasseily.

[Michaelangel007]

Some more NTSC Text Optimized WIP images:

• Archon
  

• Swashbuckler
  

[tomcw]

@Michaelangel007 - yeah, probably best to create a new issue, since this one is closed (and was for a different old Color video mode). Done as #1210.

[Michaelangel007]

Done as #1210.

Thanks!