Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Can we have the option Color (Standard) back? #357
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. :)
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.
In the thread "AppleWin 1.26.0 (pre-release)", Steve Nickolas on cea2 posted:
19 Sep 2016:
10 Oct 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.
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.
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.
There are 2 issues being conflated here:
WRT to the Lode Runner image and the second issue:
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.
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:
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.
Regarding the first point:
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 ...
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.
@Michaelangel007, good point. I think this issue's title speaks to the desire to have at least one of the old modes from 220.127.116.11.
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.
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:
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
Edit: Removed incorrect
changed the title
Not an issue (per se) .. Can we have the option Color (TV Emulation) back?
Feb 11, 2017
Has there been any more discussion on this? I'm using 18.104.22.168 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.
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.
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.
(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).
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...
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!
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.
Thanks everyone for testing & feeding back.
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.
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).
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!
referenced this issue
Jan 6, 2019
My standard "goto quality" are these two litmus tests:
Let's take a look at Archon first.
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.
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.
Next message I'll summarize my 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?
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!
Thanks for doing this extensive analysis... and it's actually shaken out a subtle bug:
This wasn't what I intended!
My intent was the 2nd of these.
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! : - )
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:
Actually I used Version 22.214.171.124. That's what the
I don't believe there are any visual differences between 1.24 and 1.25 but I should probably double check instead of assuming.
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
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.