Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #3515 > unrolled thread

Articles on Apple II High-Res mode + tips/tricks/hacks

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Articles on Apple II High-Res mode + tips/tricks/hacks anthonypaulo@gmail.com - 2017-06-08 16:30 -0700
    Re: Articles on Apple II High-Res mode + tips/tricks/hacks James Davis <JPD.Enterprises@outlook.com> - 2017-06-08 18:58 -0700
      Re: Articles on Apple II High-Res mode + tips/tricks/hacks Antoine Vignau <antoine.vignau@laposte.net> - 2017-06-09 03:18 -0700
        Re: Articles on Apple II High-Res mode + tips/tricks/hacks anthonypaulo@gmail.com - 2017-06-09 07:16 -0700
          Re: Articles on Apple II High-Res mode + tips/tricks/hacks Antoine Vignau <antoine.vignau@laposte.net> - 2017-06-09 08:29 -0700
      Re: Articles on Apple II High-Res mode + tips/tricks/hacks anthonypaulo@gmail.com - 2017-06-09 07:14 -0700
        Re: Articles on Apple II High-Res mode + tips/tricks/hacks James Davis <JPD.Enterprises@outlook.com> - 2017-06-09 18:17 -0700
        Re: Articles on Apple II High-Res mode + tips/tricks/hacks James Davis <JPD.Enterprises@outlook.com> - 2017-06-09 18:26 -0700
          Re: Articles on Apple II High-Res mode + tips/tricks/hacks anthonypaulo@gmail.com - 2017-06-09 18:54 -0700
            Re: Articles on Apple II High-Res mode + tips/tricks/hacks James Davis <JPD.Enterprises@outlook.com> - 2017-06-09 19:34 -0700
              Re: Articles on Apple II High-Res mode + tips/tricks/hacks anthonypaulo@gmail.com - 2017-06-09 21:28 -0700
    Articles on Apple II High-Res mode + tips/tricks/hacks Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-06-09 07:24 -0700
      Re: Articles on Apple II High-Res mode + tips/tricks/hacks anthonypaulo@gmail.com - 2017-06-09 13:25 -0700
        Re: Articles on Apple II High-Res mode + tips/tricks/hacks Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-06-09 17:52 -0700
          Re: Articles on Apple II High-Res mode + tips/tricks/hacks Michael J. Mahon <mjmahon@aol.com> - 2017-06-10 00:30 -0500
          Re: Articles on Apple II High-Res mode + tips/tricks/hacks anthonypaulo@gmail.com - 2017-06-11 10:56 -0700
            Re: Articles on Apple II High-Res mode + tips/tricks/hacks Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-06-11 18:22 -0700
              Re: Articles on Apple II High-Res mode + tips/tricks/hacks anthonypaulo@gmail.com - 2017-06-11 19:11 -0700
                Re: Articles on Apple II High-Res mode + tips/tricks/hacks Michael J. Mahon <mjmahon@aol.com> - 2017-06-12 09:32 -0500
                  Re: Articles on Apple II High-Res mode + tips/tricks/hacks James Davis <JPD.Enterprises@outlook.com> - 2017-06-12 17:54 -0700
                    Re: Articles on Apple II High-Res mode + tips/tricks/hacks Michael J. Mahon <mjmahon@aol.com> - 2017-06-13 00:34 -0500
                      Re: Articles on Apple II High-Res mode + tips/tricks/hacks John Brooks <jbrooks@blueshiftinc.com> - 2017-06-13 05:56 -0700
                        Re: Articles on Apple II High-Res mode + tips/tricks/hacks Brian Patrie <bpatrie@bellsouth.spamisicky.net> - 2017-06-13 17:43 -0500
              Re: Articles on Apple II High-Res mode + tips/tricks/hacks Mark Lemmert <mark.lemmert@gmail.com> - 2017-06-15 15:15 -0700
                Re: Articles on Apple II High-Res mode + tips/tricks/hacks Nick Westgate <nick.westgate@gmail.com> - 2017-06-15 20:37 -0700
                Re: Articles on Apple II High-Res mode + tips/tricks/hacks Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-06-16 16:49 -0700
                  Re: Articles on Apple II High-Res mode + tips/tricks/hacks Mark Lemmert <mark.lemmert@gmail.com> - 2017-06-21 17:33 -0700
                    Re: Articles on Apple II High-Res mode + tips/tricks/hacks Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-06-22 09:17 -0700
                      Re: Articles on Apple II High-Res mode + tips/tricks/hacks Mark Lemmert <mark.lemmert@gmail.com> - 2017-06-22 16:49 -0700
                        Re: Articles on Apple II High-Res mode + tips/tricks/hacks James Davis <JPD.Enterprises@outlook.com> - 2017-06-23 08:59 -0700
                          Re: Articles on Apple II High-Res mode + tips/tricks/hacks Mark Lemmert <mark.lemmert@gmail.com> - 2017-06-23 10:52 -0700
                        Re: Articles on Apple II High-Res mode + tips/tricks/hacks Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-06-25 06:10 -0700
                          Re: Articles on Apple II High-Res mode + tips/tricks/hacks Mark Lemmert <mark.lemmert@gmail.com> - 2017-06-25 15:49 -0700
    Re: Articles on Apple II High-Res mode + tips/tricks/hacks Jean-Michel Paris <paris.jean.michel@gmail.com> - 2017-06-09 15:31 -0700
    Re: Articles on Apple II High-Res mode + tips/tricks/hacks Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-06-13 11:31 -0700
      Re: Articles on Apple II High-Res mode + tips/tricks/hacks anthonypaulo@gmail.com - 2017-06-13 16:25 -0700
        Re: Articles on Apple II High-Res mode + tips/tricks/hacks James Davis <JPD.Enterprises@outlook.com> - 2017-06-13 16:56 -0700
        Re: Articles on Apple II High-Res mode + tips/tricks/hacks Michael J. Mahon <mjmahon@aol.com> - 2017-06-13 23:10 -0500
          Re: Articles on Apple II High-Res mode + tips/tricks/hacks anthonypaulo@gmail.com - 2017-06-14 18:31 -0700
            Re: Articles on Apple II High-Res mode + tips/tricks/hacks Michael J. Mahon <mjmahon@aol.com> - 2017-06-15 00:31 -0500
              Re: Articles on Apple II High-Res mode + tips/tricks/hacks anthonypaulo@gmail.com - 2017-06-15 14:54 -0700
                Re: Articles on Apple II High-Res mode + tips/tricks/hacks Nick Westgate <nick.westgate@gmail.com> - 2017-06-15 20:35 -0700
                  Re: Articles on Apple II High-Res mode + tips/tricks/hacks anthonypaulo@gmail.com - 2017-06-16 05:31 -0700
                    Re: Articles on Apple II High-Res mode + tips/tricks/hacks Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-06-16 16:54 -0700
                    Re: Articles on Apple II High-Res mode + tips/tricks/hacks James Davis <JPD.Enterprises@outlook.com> - 2017-06-16 18:27 -0700
                      Re: Articles on Apple II High-Res mode + tips/tricks/hacks anthonypaulo@gmail.com - 2017-06-16 18:33 -0700
    Re: Articles on Apple II High-Res mode + tips/tricks/hacks Nick Westgate <nick.westgate@gmail.com> - 2017-06-15 20:52 -0700
    Articles on Apple II High-Res mode + tips/tricks/hacks Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-06-17 10:32 -0700
      Re: Articles on Apple II High-Res mode + tips/tricks/hacks anthonypaulo@gmail.com - 2017-06-17 17:57 -0700
        Re: Articles on Apple II High-Res mode + tips/tricks/hacks Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-06-17 22:01 -0700
      Articles on Apple II High-Res mode + tips/tricks/hacks Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-06-18 14:04 -0700
      Articles on Apple II High-Res mode + tips/tricks/hacks Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-06-18 14:18 -0700
        Re: Articles on Apple II High-Res mode + tips/tricks/hacks anthonypaulo@gmail.com - 2017-06-18 15:23 -0700
          Re: Articles on Apple II High-Res mode + tips/tricks/hacks Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-06-18 15:57 -0700
    Re: Articles on Apple II High-Res mode + tips/tricks/hacks anthonypaulo@gmail.com - 2017-06-19 09:57 -0700
      Re: Articles on Apple II High-Res mode + tips/tricks/hacks Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-06-25 06:11 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#3544

James Davis <JPD.Enterprises@outlook.com> wrote:
> On Monday, June 12, 2017 at 7:32:20 AM UTC-7, mjm...@aol.com wrote:
>> <anthon...@gmail.com> wrote:
>>> On Sunday, June 11, 2017 at 9:23:00 PM UTC-4, Michael Pohoreski wrote:
>>>> Most of the screenshots are:
>>>> 
>>>> - in monochrome mode, and
>>>> - before AppleWin 1.25 which has proper NTSC emulation (Sheldon's work
>>>> was integrated into the video rendering).  
>>>> 
>>>> Pre AppleWin 1.25 is "sharper" due to NOT emulating the NTSC color
>>>> fringe artifacts AT ALL.  This is why pictures of a real monitor is
>>>> necessary to compare what an actual CRT monitor is doing -- which
>>>> AppleWin 1.25+ does. The trade off is that text becomes blurry. You can
>>>> have proper color fringe accuracy with bluriness or inaccurate color
>>>> fringes with sharpness. Pick one.
>>>> 
>>>> The only good way to get sharp text on a CRT is disable all chroma.
>>> 
>>> Jees... makes me wonder why we don't come up with a video card that kills
>>> two birds with one stone : 1) finally rid ourselves of the NTSC artifacts
>>> and 2) SVGA mode. I'm guessing "Second Sight" did just that.
>>> 
>> 
>> A simple mod to provide a switch to disable color in graphics modes would
>> be pretty easy. 
>> 
>> -- 
>> -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com
> 
> My monitor has such a switch to toggle between color and monochrome (black & white).
> 

Yes, the AppleColor Composite makes this easy.  

The lock to monochrome can be done either in the monitor or the computer. 

In some ways, it's unfortunate that the color burst wasn't controlled by a
softswitch (but you could always hijack an annunciator). ;-)

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#3545

On Monday, June 12, 2017 at 10:34:48 PM UTC-7, mjm...@aol.com wrote:
> James Davis wrote:
> > On Monday, June 12, 2017 at 7:32:20 AM UTC-7, mjm...@aol.com wrote:
> >> <anthon...@gmail.com> wrote:
> >>> On Sunday, June 11, 2017 at 9:23:00 PM UTC-4, Michael Pohoreski wrote:
> >>>> Most of the screenshots are:
> >>>> 
> >>>> - in monochrome mode, and
> >>>> - before AppleWin 1.25 which has proper NTSC emulation (Sheldon's work
> >>>> was integrated into the video rendering).  
> >>>> 
> >>>> Pre AppleWin 1.25 is "sharper" due to NOT emulating the NTSC color
> >>>> fringe artifacts AT ALL.  This is why pictures of a real monitor is
> >>>> necessary to compare what an actual CRT monitor is doing -- which
> >>>> AppleWin 1.25+ does. The trade off is that text becomes blurry. You can
> >>>> have proper color fringe accuracy with bluriness or inaccurate color
> >>>> fringes with sharpness. Pick one.
> >>>> 
> >>>> The only good way to get sharp text on a CRT is disable all chroma.
> >>> 
> >>> Jees... makes me wonder why we don't come up with a video card that kills
> >>> two birds with one stone : 1) finally rid ourselves of the NTSC artifacts
> >>> and 2) SVGA mode. I'm guessing "Second Sight" did just that.
> >>> 
> >> 
> >> A simple mod to provide a switch to disable color in graphics modes would
> >> be pretty easy. 
> >> 
> >> -- 
> >> -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com
> > 
> > My monitor has such a switch to toggle between color and monochrome (black & white).
> > 
> 
> Yes, the AppleColor Composite makes this easy.  
> 
> The lock to monochrome can be done either in the monitor or the computer. 
> 
> In some ways, it's unfortunate that the color burst wasn't controlled by a
> softswitch (but you could always hijack an annunciator). ;-)
> 
> -- 
> -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

BTW: The Apple IIGS has a soft switch to force monochrome output for double hires: bit 5 of $C029.

-JB
@JBrooksBSI

[toc] | [prev] | [next] | [standalone]

#3547

On 2017-06-13 07:56, John Brooks wrote:
 > BTW: The Apple IIGS has a soft switch to force monochrome output for
 > double hires: bit 5 of $C029.

Which is what the Type setting in the Display control panel controls. 
(It also affects single-hi-res, of course.)

(Remember to check that you're running on a IIgs before playing with 
this register.  (e.g. the IIc+ uses locations in this area for other 
things.)  (See 
http://umich.edu/~archive/apple2/technotes/tn/misc/TN.MISC.007))

[toc] | [prev] | [next] | [standalone]

#3554

On Sunday, June 11, 2017 at 8:23:00 PM UTC-5, Michael Pohoreski wrote:
> Most of the screenshots are:
> 
> - in monochrome mode, and
> - before AppleWin 1.25 which has proper NTSC emulation (Sheldon's work was integrated into the video rendering).  
> 
> Pre AppleWin 1.25 is "sharper" due to NOT emulating the NTSC color fringe artifacts AT ALL.  This is why pictures of a real monitor is necessary to compare what an actual CRT monitor is doing -- which AppleWin 1.25+ does. The trade off is that text becomes blurry. You can have proper color fringe accuracy with bluriness or inaccurate color fringes with sharpness. Pick one.
> 
> The only good way to get sharp text on a CRT is disable all chroma.


Hi Michael,

I had been using AppleWIN 1.25.04 for a long time and recently started using AppleWIN 1.26.2.2.  I noticed that 1.25.04 hi-res screens looks a lot "sharper" than 1.26.2.2 hi-res screens. Do you know if that is due to further NTSC adjustments?

Thanks.

Mark
 

[toc] | [prev] | [next] | [standalone]

#3556

On Friday, 16 June 2017 10:15:24 UTC+12, Mark Lemmert  wrote:
> I noticed that 1.25.04 hi-res screens looks a lot "sharper" than 1.26.2.2 hi-res screens. Do you know if that is due to further NTSC adjustments?

Yes, the 1.26 versions have NTSC emulation. The old VGA-style emulation has been removed. There's a feature request for it.

Cheers,
Nick.

[toc] | [prev] | [next] | [standalone]

#3559

I haven't noticed that.

Do you have screenshots so we can compare please?

Thanks

[toc] | [prev] | [next] | [standalone]

#3571

On Friday, June 16, 2017 at 6:49:05 PM UTC-5, Michael Pohoreski wrote:
> I haven't noticed that.
> 
> Do you have screenshots so we can compare please?
> 
> Thanks


HI Michael,

Was your screenshot request in reference to my post below about AppleWIN versions? Sorry for the late reply. 


>I had been using AppleWIN 1.25.04 for a long time and recently started using AppleWIN 1.26.2.2.  I >noticed that 1.25.04 hi-res screens looks a lot "sharper" than 1.26.2.2 hi-res screens. Do you know if that >is due to further NTSC adjustments? 

  

[toc] | [prev] | [next] | [standalone]

#3572

> Was your screenshot request in reference to my post below about AppleWIN versions? Sorry for the late reply. 

Yes.

>I had been using AppleWIN 1.25.04 for a long time and recently started using AppleWIN 1.26.2.2.  I
> noticed that 1.25.04 hi-res screens looks a lot "sharper" than 1.26.2.2 hi-res screens. Do you know if that >is due to further NTSC adjustments? 

I'll take a look at 1.25.0.4 and and 1.26.2.2 screenshots next week.

Was there a specific application / game you noticed these differences?

TIA.

[toc] | [prev] | [next] | [standalone]

#3573

On Thursday, June 22, 2017 at 11:17:55 AM UTC-5, Michael Pohoreski wrote:
> >I had been using AppleWIN 1.25.04 for a long time and recently started using AppleWIN 1.26.2.2.  I
> > noticed that 1.25.04 hi-res screens looks a lot "sharper" than 1.26.2.2 hi-res screens. Do you know if that >is due to further NTSC adjustments? 
> 
> I'll take a look at 1.25.0.4 and and 1.26.2.2 screenshots next week.

Thanks, I look forward to your thoughts after you have a chance to take a look. 
 
> Was there a specific application / game you noticed these differences?
> 
> TIA.

I originally noticed it during Nox Archaist development and I just tried Ultima 5 and see simular results. 

Here are screen shots of both:

AppleWIN 1.25.04: Ultima 5
https://www.dropbox.com/s/ylu29orvezkgfef/U5.AppleWIN1.25.04.png?dl=0

AppleWIN 1.26.22: Ultima 5
https://www.dropbox.com/s/bmxqulk6x740pzr/U5.AppleWIN1.26.22.png?dl=0


AppleWIN 1.25.04: Nox Archaist
https://www.dropbox.com/s/6o4jn11nujkthsv/NA.AppleWIN1.25.04.png?dl=0

AppleWIN 1.26.22: Nox Archaist
https://www.dropbox.com/s/mc9vyf0vam39q3j/NA.AppleWIN1.26.22.png?dl=0


Using 1.26.22 the horizontal gaps between the pixels look larger to me than in 1.25.04. 

In any event, I'm not complaining. AppleWIN is awesome. I'm just curious. 


Thanks.

Mark

[toc] | [prev] | [next] | [standalone]

#3578

Hi Mark,

Looking at your screen shots, I actually like the latter AppleWin ones better.  The latter screen shots appear to have less color bleeding than the former ones.

James Davis

[toc] | [prev] | [next] | [standalone]

#3579

On Friday, June 23, 2017 at 10:59:34 AM UTC-5, James Davis wrote:
> Hi Mark,
> 
> Looking at your screen shots, I actually like the latter AppleWin ones better.  The latter screen shots appear to have less color bleeding than the former ones.
> 
> James Davis


Hi James,

Fair point. I was thinking the color bleed was a positive as it results in fairly solid horizontal color lines, but I agree in some circumstances it's not desirable. In particular with text characters where the space is tight. 


Mark

 

[toc] | [prev] | [next] | [standalone]

#3582

> I originally noticed it during Nox Archaist development and I just tried Ultima 5 and see simular results. 
> Do you know if that >is due to further NTSC adjustments? 

At first I thought we changed the rendering mode in ver 1.24 -> ver 1.25 so when you mentioned 1.26 I thought there was a regression.

Thanks for the screenshots!  OK, I can provide a definite answer.  Yes, what you are seeing from ver 1.25 -> ver 1.26 is the new NTSC renderer.

* 1.25 while _artificially_ sharper had horrible color accuracy,
* 1.25 has 99% accurate NTSC emulation, albeit with a blurrier image.

On real hardware, the color composite screen really is that "blurry."  If you put a composite monitor into monochrome mode you'll see we emulate 100% the dot placement -- the color "bleeds" over inbetween the pixels which is what is making the image blurry.  There is a big long discussion about this in 254

https://github.com/AppleWin/AppleWin/issues/254


Some people have asked for the old color mode back, because as you mentioned, in certain circumstances -- like reading text on the graphics screen -- the old inaccurate display mode was far easier to read.  We've only made some preliminary investigations so far but you can leave your voice here:

Can we have the option Color (TV Emulation) back?
https://github.com/AppleWin/AppleWin/issues/357

Hope this helps.

[toc] | [prev] | [next] | [standalone]

#3592

Michael,

Thanks for taking a look and for the GitHub link. I made a post to that thread.



Mark

On Sunday, June 25, 2017 at 8:10:21 AM UTC-5, Michael Pohoreski wrote:
> > I originally noticed it during Nox Archaist development and I just tried Ultima 5 and see simular results. 
> > Do you know if that >is due to further NTSC adjustments? 
> 
> At first I thought we changed the rendering mode in ver 1.24 -> ver 1.25 so when you mentioned 1.26 I thought there was a regression.
> 
> Thanks for the screenshots!  OK, I can provide a definite answer.  Yes, what you are seeing from ver 1.25 -> ver 1.26 is the new NTSC renderer.
> 
> * 1.25 while _artificially_ sharper had horrible color accuracy,
> * 1.25 has 99% accurate NTSC emulation, albeit with a blurrier image.
> 
> On real hardware, the color composite screen really is that "blurry."  If you put a composite monitor into monochrome mode you'll see we emulate 100% the dot placement -- the color "bleeds" over inbetween the pixels which is what is making the image blurry.  There is a big long discussion about this in 254
> 
> https://github.com/AppleWin/AppleWin/issues/254
> 
> 
> Some people have asked for the old color mode back, because as you mentioned, in certain circumstances -- like reading text on the graphics screen -- the old inaccurate display mode was far easier to read.  We've only made some preliminary investigations so far but you can leave your voice here:
> 
> Can we have the option Color (TV Emulation) back?
> https://github.com/AppleWin/AppleWin/issues/357
> 
> Hope this helps.

[toc] | [prev] | [next] | [standalone]

#3525

Le vendredi 9 juin 2017 01:30:32 UTC+2, anthon...@gmail.com a écrit :
> Would someone be so kind as to forward me a link to a site with some great explanations of the Apple II High Res mode, all of its quirks, and tips/tricks/hacks on how to properly display what you want on it. Also of interest to me is how Ultima V accomplished the water animation; was it via some clever palette switching or just swapping out frames of sprites?
> 
> Thanks

For Ultima V, the animation was done by cycling successive water sprites (8 different if I remember). Each new sprite has one vertical pixel offset from the previous one. Everything was pre-drawn of course.

Upon each screen refresh, the next water sprite is used, so is apparent the animation.

[toc] | [prev] | [next] | [standalone]

#3546

On Thursday, June 8, 2017 at 4:30:32 PM UTC-7, anthon...@gmail.com wrote:
>  I recall high-res games such as Where in the World is Carmen Sandiego having text that looked so mangled an almost unreadable at times due to the color artifacting.

I'm finally back home after being up for 21 hours (makes for a REALLY long day.) Having rested slightly I was able to take some pictures and screenshots of WITWICS (Where In The World Is Carmen Sandiego).

Which text in the game are you referring to ?

ACME Detective Window
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/Where_In_The_World_Camen_Sandiego_1436.JPG

Logo
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/Where_In_The_World_Carmen_Sandiego_1440.JPG

Name entry
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/Where_In_The_World_Carmen_Sandiego_1444.JPG


I'm going to assume you were referring to the text description on the right.
Lets have some "Fun With Fonts" and analyze the main WITWICS font.

When I first read your description I was getting ready for a pukefest.  Thankfully the artists/programmers did a very good job with the font -- all things considered!

An actual photo:
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/pictures/picture_original.JPG

Here is the screenshot running on AppleWin 1.26 we'll use in our comparison:
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/original_color_singapore.png

Sheldon did a good job emulating the chroma bleed without making our eyes bleed.  (My 2nd CRT monitor doesn't have the chrome bleed AS bad but it is still there.)

I'd rate the WITWICS font as a solid 94% -- for the most part it is a good, clean font -- and is quite readable on the Apple 2, minor chroma bleeding notwithstanding that most people didn't really understand digital font typography in the 80's.

Pros:

* Font has a consistent weighting -- 2 pixels wide
* Font design is mostly consistent
* The tittle of the i is at the correct height.
* The leading is consistent
* Kerning is (mostly) consistent with 2 bit gap.


Cons:

* 2 and 5 are fugly -- numerals tend to convey the "signature style" of the font but in this readability is more important IMHO.
* s, and e was designed by an amateur.  Note: Notch completely fucked up his lowercase 's' in Minecraft as well. These two glyphs are the litmus test to tell if a person is inexperienced or not.
* Top of the 'm' needs work
* The tail on the comma is mis-aligned to the left edge
* The tail on the g is too short.

Let's clean those glyphs up: 2, 5, e, s, m, and ',' -- I was too lazy to clean up the 'g':
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/fixed_color_singapore.png

Here's the zoom in of the original: s, e
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/zoom_original.png

The problem is that the it looks like the 's' is leaning 'backwords' instead of respecting the tail on the top right of the 's', and bottom left of the 's'.

And zoom in of the fixed: s, e
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/zoom_fixed.png

When looking at fonts it is very important to see how they look

* in monochrome
* at the actual resolution.

This makes very easy to see how crappy the 'e' and 's' look.

Original monochrome:
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/original_mono_singapore.png

Fixed monochrome:
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/fixed_mono_singapore.png


What a difference even a single pixel makes!  Here is a visual difference of the changes:
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/difference_mono_singapore.png


And for reference to show that AppleWin 1.25+ is accurately simulating the chroma bleeding here is the fixed version on real hardware:
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/pictures/picture_fixed.JPG


Guess I'll add two new projects to the TODO list ;-)

* [ ] Ripping the WITWICS font and incorporate into my HGR Font Tutorial
* [ ] Providing a patched WITISCS DSK image with the fixed glyphs


>  Is this something that you handle in your routines or is this impossible to overcome due to the II's color mode limitations? 

I don't handle any color artifacts because it is basically an unsolvable problem.

The only way to resolve the color artifacts are to show the pixels in monochrome.  No, that wasn't meant as a snarky response.  My CRT monitors have a push-button to toggle chroma on / off.  That fixes the text, but then kills the color of the graphics. :-/  You can have either:

* Sharp, Monochrome OR 
* Blurry, Color.

Pick your poison is the standard fare on the Apple. :-(

Color artifacts are basically impossible to fix with the current Apple hardware without modification -- you would basically need to re-implement a clean composite signal and a better CRT.

The fundamental problem is that sending an *analog* signal over a *single composite* wire to a CRT is "blurry as fuck."  You basically need:

* 3 channels, RGB or YUV to prevent pixel bleed
* A digital display to minimize cross-talk or "noise"

Keep in mind that the CRT set the "gold standard" for color gamut that only _recently_ was surpassed by OLED. i.e. There was a ~$20K "reference" CRT for color matching in the early 2000's because nothing else came close for color quality of CRT.

Also considering this is 1941's technology with color literally hacked in 1953 we can forgive National Television System Committee / Never The Same Color somewhat.  I'm more upset of the retarded 29.97 framerate instead of using a solid 60+ Hz such as 72 Hz.  That way film @ 24 Hz would be a perfect 3x multiple but I digress.

Anyways, back to playing with Signed-Distance-Fields and font rendering on modern PC's. :-)
* https://www.shadertoy.com/view/llK3Wm#

Michael

[toc] | [prev] | [next] | [standalone]

#3548

On Tuesday, June 13, 2017 at 2:31:45 PM UTC-4, Michael Pohoreski wrote:
> On Thursday, June 8, 2017 at 4:30:32 PM UTC-7, anthon...@gmail.com wrote:
> >  I recall high-res games such as Where in the World is Carmen Sandiego having text that looked so mangled an almost unreadable at times due to the color artifacting.
> 
> I'm finally back home after being up for 21 hours (makes for a REALLY long day.) Having rested slightly I was able to take some pictures and screenshots of WITWICS (Where In The World Is Carmen Sandiego).
> 
> Which text in the game are you referring to ?
> 
> ACME Detective Window
> * https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/Where_In_The_World_Camen_Sandiego_1436.JPG
> 
> Logo
> * https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/Where_In_The_World_Carmen_Sandiego_1440.JPG
> 
> Name entry
> * https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/Where_In_The_World_Carmen_Sandiego_1444.JPG
> 
> 
> I'm going to assume you were referring to the text description on the right.
> Lets have some "Fun With Fonts" and analyze the main WITWICS font.
> 
> When I first read your description I was getting ready for a pukefest.  Thankfully the artists/programmers did a very good job with the font -- all things considered!
> 
> An actual photo:
> * https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/pictures/picture_original.JPG
> 
> Here is the screenshot running on AppleWin 1.26 we'll use in our comparison:
> * https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/original_color_singapore.png
> 
> Sheldon did a good job emulating the chroma bleed without making our eyes bleed.  (My 2nd CRT monitor doesn't have the chrome bleed AS bad but it is still there.)
> 
> I'd rate the WITWICS font as a solid 94% -- for the most part it is a good, clean font -- and is quite readable on the Apple 2, minor chroma bleeding notwithstanding that most people didn't really understand digital font typography in the 80's.
> 
> Pros:
> 
> * Font has a consistent weighting -- 2 pixels wide
> * Font design is mostly consistent
> * The tittle of the i is at the correct height.
> * The leading is consistent
> * Kerning is (mostly) consistent with 2 bit gap.
> 
> 
> Cons:
> 
> * 2 and 5 are fugly -- numerals tend to convey the "signature style" of the font but in this readability is more important IMHO.
> * s, and e was designed by an amateur.  Note: Notch completely fucked up his lowercase 's' in Minecraft as well. These two glyphs are the litmus test to tell if a person is inexperienced or not.
> * Top of the 'm' needs work
> * The tail on the comma is mis-aligned to the left edge
> * The tail on the g is too short.
> 
> Let's clean those glyphs up: 2, 5, e, s, m, and ',' -- I was too lazy to clean up the 'g':
> * https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/fixed_color_singapore.png
> 
> Here's the zoom in of the original: s, e
> * https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/zoom_original.png
> 
> The problem is that the it looks like the 's' is leaning 'backwords' instead of respecting the tail on the top right of the 's', and bottom left of the 's'.
> 
> And zoom in of the fixed: s, e
> * https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/zoom_fixed.png
> 
> When looking at fonts it is very important to see how they look
> 
> * in monochrome
> * at the actual resolution.
> 
> This makes very easy to see how crappy the 'e' and 's' look.
> 
> Original monochrome:
> * https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/original_mono_singapore.png
> 
> Fixed monochrome:
> * https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/fixed_mono_singapore.png
> 
> 
> What a difference even a single pixel makes!  Here is a visual difference of the changes:
> * https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/difference_mono_singapore.png
> 
> 
> And for reference to show that AppleWin 1.25+ is accurately simulating the chroma bleeding here is the fixed version on real hardware:
> * https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/pictures/picture_fixed.JPG
> 
> 
> Guess I'll add two new projects to the TODO list ;-)
> 
> * [ ] Ripping the WITWICS font and incorporate into my HGR Font Tutorial
> * [ ] Providing a patched WITISCS DSK image with the fixed glyphs
> 
> 
> >  Is this something that you handle in your routines or is this impossible to overcome due to the II's color mode limitations? 
> 
> I don't handle any color artifacts because it is basically an unsolvable problem.
> 
> The only way to resolve the color artifacts are to show the pixels in monochrome.  No, that wasn't meant as a snarky response.  My CRT monitors have a push-button to toggle chroma on / off.  That fixes the text, but then kills the color of the graphics. :-/  You can have either:
> 
> * Sharp, Monochrome OR 
> * Blurry, Color.
> 
> Pick your poison is the standard fare on the Apple. :-(
> 
> Color artifacts are basically impossible to fix with the current Apple hardware without modification -- you would basically need to re-implement a clean composite signal and a better CRT.
> 
> The fundamental problem is that sending an *analog* signal over a *single composite* wire to a CRT is "blurry as fuck."  You basically need:
> 
> * 3 channels, RGB or YUV to prevent pixel bleed
> * A digital display to minimize cross-talk or "noise"
> 
> Keep in mind that the CRT set the "gold standard" for color gamut that only _recently_ was surpassed by OLED. i.e. There was a ~$20K "reference" CRT for color matching in the early 2000's because nothing else came close for color quality of CRT.
> 
> Also considering this is 1941's technology with color literally hacked in 1953 we can forgive National Television System Committee / Never The Same Color somewhat.  I'm more upset of the retarded 29.97 framerate instead of using a solid 60+ Hz such as 72 Hz.  That way film @ 24 Hz would be a perfect 3x multiple but I digress.
> 
> Anyways, back to playing with Signed-Distance-Fields and font rendering on modern PC's. :-)
> * https://www.shadertoy.com/view/llK3Wm#
> 
> Michael

What??!! How are you getting such crisp clean text? When I run it on my IIc using a VGA converter to my LCD screen it looks terrible. I'll have to get a screenshot and post it.

[toc] | [prev] | [next] | [standalone]

#3549

On Tuesday, June 13, 2017 at 4:25:47 PM UTC-7, anthon...@gmail.com wrote:
> What??!! How are you getting such crisp clean text? When I run it on my IIc using a VGA converter to my LCD screen it looks terrible. I'll have to get a screenshot and post it.

LCD screens in the PC world require different dithering than CRT screens.  Maybe that is the cause of your problem, that there is no dithering in the Apple II world.

[toc] | [prev] | [next] | [standalone]

#3550

<anthonypaulo@gmail.com> wrote:
> On Tuesday, June 13, 2017 at 2:31:45 PM UTC-4, Michael Pohoreski wrote:
>> On Thursday, June 8, 2017 at 4:30:32 PM UTC-7, anthon...@gmail.com wrote:
>>> I recall high-res games such as Where in the World is Carmen Sandiego
>>> having text that looked so mangled an almost unreadable at times due to
>>> the color artifacting.
>> 
>> I'm finally back home after being up for 21 hours (makes for a REALLY
>> long day.) Having rested slightly I was able to take some pictures and
>> screenshots of WITWICS (Where In The World Is Carmen Sandiego).
>> 
>> Which text in the game are you referring to ?
>> 
>> ACME Detective Window
>> *
>> https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/Where_In_The_World_Camen_Sandiego_1436.JPG
>> 
>> Logo
>> *
>> https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/Where_In_The_World_Carmen_Sandiego_1440.JPG
>> 
>> Name entry
>> *
>> https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/Where_In_The_World_Carmen_Sandiego_1444.JPG
>> 
>> 
>> I'm going to assume you were referring to the text description on the right.
>> Lets have some "Fun With Fonts" and analyze the main WITWICS font.
>> 
>> When I first read your description I was getting ready for a pukefest. 
>> Thankfully the artists/programmers did a very good job with the font --
>> all things considered!
>> 
>> An actual photo:
>> *
>> https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/pictures/picture_original.JPG
>> 
>> Here is the screenshot running on AppleWin 1.26 we'll use in our comparison:
>> *
>> https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/original_color_singapore.png
>> 
>> Sheldon did a good job emulating the chroma bleed without making our
>> eyes bleed.  (My 2nd CRT monitor doesn't have the chrome bleed AS bad
>> but it is still there.)
>> 
>> I'd rate the WITWICS font as a solid 94% -- for the most part it is a
>> good, clean font -- and is quite readable on the Apple 2, minor chroma
>> bleeding notwithstanding that most people didn't really understand
>> digital font typography in the 80's.
>> 
>> Pros:
>> 
>> * Font has a consistent weighting -- 2 pixels wide
>> * Font design is mostly consistent
>> * The tittle of the i is at the correct height.
>> * The leading is consistent
>> * Kerning is (mostly) consistent with 2 bit gap.
>> 
>> 
>> Cons:
>> 
>> * 2 and 5 are fugly -- numerals tend to convey the "signature style" of
>> the font but in this readability is more important IMHO.
>> * s, and e was designed by an amateur.  Note: Notch completely fucked up
>> his lowercase 's' in Minecraft as well. These two glyphs are the litmus
>> test to tell if a person is inexperienced or not.
>> * Top of the 'm' needs work
>> * The tail on the comma is mis-aligned to the left edge
>> * The tail on the g is too short.
>> 
>> Let's clean those glyphs up: 2, 5, e, s, m, and ',' -- I was too lazy to clean up the 'g':
>> *
>> https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/fixed_color_singapore.png
>> 
>> Here's the zoom in of the original: s, e
>> *
>> https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/zoom_original.png
>> 
>> The problem is that the it looks like the 's' is leaning 'backwords'
>> instead of respecting the tail on the top right of the 's', and bottom left of the 's'.
>> 
>> And zoom in of the fixed: s, e
>> *
>> https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/zoom_fixed.png
>> 
>> When looking at fonts it is very important to see how they look
>> 
>> * in monochrome
>> * at the actual resolution.
>> 
>> This makes very easy to see how crappy the 'e' and 's' look.
>> 
>> Original monochrome:
>> *
>> https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/original_mono_singapore.png
>> 
>> Fixed monochrome:
>> *
>> https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/fixed_mono_singapore.png
>> 
>> 
>> What a difference even a single pixel makes!  Here is a visual difference of the changes:
>> *
>> https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/difference_mono_singapore.png
>> 
>> 
>> And for reference to show that AppleWin 1.25+ is accurately simulating
>> the chroma bleeding here is the fixed version on real hardware:
>> *
>> https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/pictures/picture_fixed.JPG
>> 
>> 
>> Guess I'll add two new projects to the TODO list ;-)
>> 
>> * [ ] Ripping the WITWICS font and incorporate into my HGR Font Tutorial
>> * [ ] Providing a patched WITISCS DSK image with the fixed glyphs
>> 
>> 
>>> Is this something that you handle in your routines or is this
>>> impossible to overcome due to the II's color mode limitations? 
>> 
>> I don't handle any color artifacts because it is basically an unsolvable problem.
>> 
>> The only way to resolve the color artifacts are to show the pixels in
>> monochrome.  No, that wasn't meant as a snarky response.  My CRT
>> monitors have a push-button to toggle chroma on / off.  That fixes the
>> text, but then kills the color of the graphics. :-/  You can have either:
>> 
>> * Sharp, Monochrome OR 
>> * Blurry, Color.
>> 
>> Pick your poison is the standard fare on the Apple. :-(
>> 
>> Color artifacts are basically impossible to fix with the current Apple
>> hardware without modification -- you would basically need to
>> re-implement a clean composite signal and a better CRT.
>> 
>> The fundamental problem is that sending an *analog* signal over a
>> *single composite* wire to a CRT is "blurry as fuck."  You basically need:
>> 
>> * 3 channels, RGB or YUV to prevent pixel bleed
>> * A digital display to minimize cross-talk or "noise"
>> 
>> Keep in mind that the CRT set the "gold standard" for color gamut that
>> only _recently_ was surpassed by OLED. i.e. There was a ~$20K
>> "reference" CRT for color matching in the early 2000's because nothing
>> else came close for color quality of CRT.
>> 
>> Also considering this is 1941's technology with color literally hacked
>> in 1953 we can forgive National Television System Committee / Never The
>> Same Color somewhat.  I'm more upset of the retarded 29.97 framerate
>> instead of using a solid 60+ Hz such as 72 Hz.  That way film @ 24 Hz
>> would be a perfect 3x multiple but I digress.
>> 
>> Anyways, back to playing with Signed-Distance-Fields and font rendering
>> on modern PC's. :-)
>> * https://www.shadertoy.com/view/llK3Wm#
>> 
>> Michael
> 
> What??!! How are you getting such crisp clean text? When I run it on my
> IIc using a VGA converter to my LCD screen it looks terrible. I'll have
> to get a screenshot and post it.
> 

You just said it: VGA converter. 

That's what's mangling your text. 

Decoding NTSC composite video is non-trivial, and most VGA converters take
shortcuts that mess it up. 

BTW, 30Hz was originally chosen as the frame rate, to cause line frequency
interference to be static in the display, rather than moving annoyingly. 

The frame rate was modified very slightly for composite color, but by that
time, the prevalence of 60/120Hz interference had decreased, and having a
"hum bar" move down the screen slowly was considered acceptable. 

Of course, the frame rate could not change appreciably, since the composite
color signal had to display compatibly on monochrome sets. 

A frame rate as high as 72Hz would have been unthinkable, since, if a
nominal resolution of just 300x240 was to be maintained, a video broadcast
bandwidth of 13MHz to 14MHz would be required--a modulation bandwidth that
would have used much more spectrum than allocated and presented significant
design challenges. 

Television was always (and remains) an engineering tradeoff. Judging past
tradeoffs, with their constraints, by present standards is nonsense. 

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#3551

> You just said it: VGA converter. 
> 
> That's what's mangling your text. 
> 
> Decoding NTSC composite video is non-trivial, and most VGA converters take
> shortcuts that mess it up. 
> 
> BTW, 30Hz was originally chosen as the frame rate, to cause line frequency
> interference to be static in the display, rather than moving annoyingly. 
> 
> The frame rate was modified very slightly for composite color, but by that
> time, the prevalence of 60/120Hz interference had decreased, and having a
> "hum bar" move down the screen slowly was considered acceptable. 
> 
> Of course, the frame rate could not change appreciably, since the composite
> color signal had to display compatibly on monochrome sets. 
> 
> A frame rate as high as 72Hz would have been unthinkable, since, if a
> nominal resolution of just 300x240 was to be maintained, a video broadcast
> bandwidth of 13MHz to 14MHz would be required--a modulation bandwidth that
> would have used much more spectrum than allocated and presented significant
> design challenges. 
> 
> Television was always (and remains) an engineering tradeoff. Judging past
> tradeoffs, with their constraints, by present standards is nonsense. 
> 
> -- 
> -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

I purchased the Apple IIc VGA converter by a2heaven.com (http://a2heaven.com/webshop/index.php?rt=product/product&product_id=135). This attaches to the digital video output so it should be clean, no?

[toc] | [prev] | [next] | [standalone]

#3552

<anthonypaulo@gmail.com> wrote:
> 
>> You just said it: VGA converter. 
>> 
>> That's what's mangling your text. 
>> 
>> Decoding NTSC composite video is non-trivial, and most VGA converters take
>> shortcuts that mess it up. 
>> 
>> BTW, 30Hz was originally chosen as the frame rate, to cause line frequency
>> interference to be static in the display, rather than moving annoyingly. 
>> 
>> The frame rate was modified very slightly for composite color, but by that
>> time, the prevalence of 60/120Hz interference had decreased, and having a
>> "hum bar" move down the screen slowly was considered acceptable. 
>> 
>> Of course, the frame rate could not change appreciably, since the composite
>> color signal had to display compatibly on monochrome sets. 
>> 
>> A frame rate as high as 72Hz would have been unthinkable, since, if a
>> nominal resolution of just 300x240 was to be maintained, a video broadcast
>> bandwidth of 13MHz to 14MHz would be required--a modulation bandwidth that
>> would have used much more spectrum than allocated and presented significant
>> design challenges. 
>> 
>> Television was always (and remains) an engineering tradeoff. Judging past
>> tradeoffs, with their constraints, by present standards is nonsense. 
>> 
>> -- 
>> -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com
> 
> I purchased the Apple IIc VGA converter by a2heaven.com
> (http://a2heaven.com/webshop/index.php?rt=product/product&product_id=135). This attaches to
> the digital video output so it should be clean, no?
> 

Ah, that's one of the very few NTSC-to-VGA converters that actually works
well with Apple II's. 

It sounds like there is some other problem with your setup. Check all
connectors for good connections and, if possible, try another VGA display. 

It's always possible that there is a problem with your converter, because
you should be getting much better results. 

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.sys.apple2.programmer

csiph-web