Scanline artifacts in laced modes. Problem?

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser Please create an account and log in to see all content by default. This is a limitation of the forum software.
Don't Panic. Please wash hands.
  • Hi all,

    I've been playing around for a while with my MK3. The overall picture quality is incredible, crispy and smooth scrolling in all games. Although, I'm experiencing some behavior that I could not find if it has been already addressed: laced screen modes give strange scanline artifacts (both in games and WB). Something that looks like if it is drawn every other line.

    Within the WB (3.1.4.1), this is very noticeable on the mouse pointer but also on every moving object (windows borders, windows fills, icons...).

    Also games seem to be affected, no matter what VGA mode I choose. The only way I've found to avoid it is to avoid laced modes.


    Is there something that I'm doing wrong/missing? Any hint on what settings should I play with?


    TIA


    /D





  • Something that looks like if it is drawn every other line.

    Yes, because that is exactly what an interlaced screen means, it is drawn in two passes. First all even lines and then all odd lines. So for moving items you get these "hair comb" effects.

  • Ok. That clarifies what I'm seeing, thanks. Is still not clear to me if this comb effect can be avoided/reduced or it is something that I should accept and live with it :(

    Never seen that before with external scart-hdmi adapters. Very annoing to me, for instance when scrolling a whole laced screen, like in pinball games.


    /D

  • The obvious cure is to not use interlaced screenmodes whenever you can (eg for the Workbench).


    Other than that, there isn't much you can do. Any Filtering would just blur the picture, or half the framerate.

  • You could try enabling "doublebuffer" mode in the advanced settings of the config tool in some cases that can help, but in other cases it makes it worse as you half the update rate of the screen. Pinball in interlace? Yeah I can image how that looks converted to progressive scan, doing that conversion correctly requires a huge amount of video processing. Basically you need to estimate the movement between frames and interpolate that movement across frames. Definitely something outside the scope of the Indivision products.

  • Non-CRT TVs tend to have good deinterlacers that will use the full resolution on static images but make a full frame out of each half frame when there is action. This of course adds blur but our brains expect to see motion blur on movement anyway, so usually this is not a problem.


    These are complex algorithms, however, so it would be difficult to impossible to implement this in real time in the Indivision.

  • Ok guys thanks for all explanations. I will give a try on doublebuffering.

    Is there any other thing that I can tweak to reduce this effect? VSync values?

    Could this comb effect caused by my monitor configuration?

    I'm running on a samsung gaming monitor (max 120hz via HDMI) with low latency (1ms). Enabling VSync produced no image (no signal detected) on any indi mode i tried (@60hz).

  • Is it possible to output interlaced modes over HDMI?

    At this point, the whole design is geared towards progressive output with a frame- or a line buffer in between. In theory, it's possible to bypass most of that and transfer the Amiga-pixels directly to the HDM! encoder chip, but that is subject to being verified, as the chip's documentation is very vague about interlaced output modes.


    Interlaced outputs require a lot of Indivision's features to be disabled, so please understand that I can't give this any high priority. It would merely be an academic exercise, which doesn't really fit our schedule. We still have a bug or two to fix, so I'm in a "stop feature-creeping" mode :-)

  • I understand. A solution to the artifacting I've been thinking about is making a monitor file that lets the Amiga to use a lower framerate progressive scan mode such as 25p/30p/36p or something. I'll let you guys know if I have any success.

  • A solution to the artifacting I've been thinking about is making a monitor file that lets the Amiga to use a lower framerate progressive scan mode such as 25p/30p/36p or something. I'll let you guys know if I have any success.

    According to André (author of HighGFX) there's not many monitor type IDs free on top of what he created, and I suggest to not just occupy one. He has something planned for the remaining one or two IDs that might be what you need.

  • According to André (author of HighGFX) there's not many monitor type IDs free on top of what he created, and I suggest to not just occupy one. He has something planned for the remaining one or two IDs that might be what you need.

    Don't worry. :)


    What I did is take the Euro36 monitor driver and change the number of scan lines ((TOTROW) to ~ 565 and reduce the TOTCLK to 211. This allows for a 960x540 @ 30 Hz resolution in SHires. So no more interlacing artifacts, although quick mouse movements make the mouse pointer move in a choppy way.


    However, there's one issue I haven't been able to solve: the Euro36 non-interlaced resolution has an overscan graphics size of 654x200 and a maximum size of 764x200. So although the Amiga has no trouble displaying the 480x540 resolution (ignoring SHires for a moment), it thinks that everything beyond line 200 is off-screen so you can't put the mouse pointer beyond line 200. If you try that, the image scrolls.


    It is possible to solve this with the MonSpecsMUI program that I used to change the settings (= tool types) of the Euro36 monitor driver, but for some reason these settings don't survive a reboot.


    So if anyone has a tip on what to do to make this work across reboots that would be really helpful.


    (Of course this only works for Workbench programs and programs that let you select a screenmode, not games that use PAL or NTSC.)

  • Annoyingly, the reset of the overscan limitations only happens under AmigaOS 3.1.0, not under 3.0. Copying over the (larger) 3.0 monitor file doesn't help, and trying to patch the monitor file doesn't work either. So these overscan limits must be coming from somewhere else, but I have no idea where.

  • I guess this is why the source code of the monitor driver is required to do changes - the different monitor ID seems to be required for integrity with other parts of the OS.

  • I've tried looking for the source fo a monitor driver, but there doesn't seem to be any available, and building one from scratch looks very complicated.


    But I've been able to get the overscan issue solved: the MonSpecsMUI tool that I used to change the Euro36 monitor comes with an extra program that reads the tool types that MonSpecsMUI writes to the monitor driver .info file and sets up the right overscan settings. Running this program from my s:user-startup makes everything work.


    The advantage of this solution is that it can be done by anyone through MonSpecsGUI. I doubt anyone is using the Euro36 driver in its original form, and this way no new IDs are used up and settings related to Euro36 don't have any impact on settings for other modes.


    I'll do a writeup for my blog (where I already posted a review of the MK3) and I think I'll upload the modified Euro36 monitor file to Aminet the next few days.


    Only remaining problem: the mouse pointer looks low resolution horizontally and high resolution vertically. But I can solve that to a reasonable degree by drawing a taller mouse pointer.

  • I've tried looking for the source fo a monitor driver, but there doesn't seem to be any available, and building one from scratch looks very complicated.

    The Amiga OS source code did leak at one of the CCC Xmas meetings a few years back. I'm sure that it's available on some FTP server somewhere on this planet. I never even attempted to get access to the source code, as I don't even want to come near the suspicion that any of our developments are based on that source. If you find it, please do NOT post the location here.


    André signed NDA to get access to that part of the Amiga OS, and he is officially entitled to use it for the purpose of creating new monitor drivers. I'm still hoping that he finds the time to make a monitor driver that is configurable with tool types. For that, we'd only need a single monitor ID, and be set "once and for all future".

  • Well, it seems that MonSpecsMUI already does that, it allows changing very many monitor driver settings. I just don't know what most of them mean or do. Perhaps there is documentation for this, but I suspect there isn't.


    With the changes I made to Euro36 I get 960x540@30, which is half of 1920x1080x60 for each of the three variables, I think we get a very good result considering the limitations of the Amiga and the fact that the Amiga predates the start of the shrinking pixels where ultimately individual pixels would become invisible to tell apart. (I.e., "retina" displays.)


    For this mode, I'm using very close to the minimum number of scanlines that still works and I reduced the number of pixels per line (in the form of TOTCLK) a bit to hit 30 Hz. This actually leaves something like 20% of the available scanline pixels unused. I also think it should be possible to reduce the horizontal sync and blanking, but clicking around in MonSpecsMUI didn't give me any results.


    However, in my opinion, it's not a great idea to go for the maximum number of pixels the Amiga can show by shortening all the sync and blanking periods, because that way, screen output uses up much more chip memory bandwidth so less is left for the blitter and the CPU so redrawing all those pixels will become extremely slow, especially in 32 - 128 color modes and double especially in 256 colors.


    Now if only somehow the mouse pointer could be made to look nice and move smoothly. I guess if you guys are taking feature requests that could be done with a sprite on the Indivision hardware at the full HDMI/VGA resolution overlaid on the Amiga image and making the Amiga mouse pointer sprite invisible.

  • I also think it should be possible to reduce the horizontal sync and blanking,

    Be careful with that - the refresh cycles of Chip ram are located "just after a sync", and the number of cycles is static per line. If you go below 15kHz horizontal frequency, the number of refresh cycles is lower than most memory's specification, which means that it may still work on your computer, but doesn't on others with a different memory chip vendor. If you want your software to work "in the field", it should not rely on out-of-spec behaviour.


    Now if only somehow the mouse pointer could be made to look nice and move smoothly.

    The mouse pointer will of course only update with the vertical source frequency of the Amiga. That means that the 30Hz is your limiting factor.


    I guess if you guys are taking feature requests that could be done with a sprite on the Indivision hardware at the full HDMI/VGA resolution overlaid on the Amiga image and making the Amiga mouse pointer sprite invisible.

    I fear that even this won't improve the situation, as the mouse movements are handled by the OS in the VBlank IRQ. You'd maybe improve the looks of the mouse pointer, but the slow movement would have to be solved with yet more software that is called more often than the VBlank. This bears the danger of the image looking different if viewed through the DB23 RGB port and the Indivision output - something that I would not like to have. If you attempt to make both usable, then the "hires" mouse pointer would have to cover the AGA-mouse pointer, and you'd always see that being dragged after the Indivision pointer. To get around this, you could of course make the AGA-mouse poitner "totally empty", but that would result in the RGB output being totally unusable. Both options don't sound like desirable options.


    You might know the A2024 monitor driver ("Hedley monitor" as the developer's last name was Hedley). This transferred the picture in four different fields, and the field where the mouse pointer is located is transferred more often. This resulted in a teared mouse pointer if you moved it along the edge between two fields. So the problem was already known at Commodore, and they came across it with more and more complicated software. The A2024 was my main monitor for years; it was mainly a text/shell machine (running as a BBS which was my mail client), and I remember that I was prety happy with the 15Hz update rate, as the mouse movements were not all that jerky. However, I believe that the mouse-update rate was in the 30Hz area, so pretty much where you have it now.


    I guess that this boils down to something between "it's a matter of taste" and "it's what you can expect from a computer that was developed over 30 years ago". The amount of work to be done on the OS side would be considerable, and I wouldn't attempt to do this without a close cooperation with the classic OS team of Hyperion. Adjusting/adding interfaces in OS3.2 in order for P96 to not require bad patches has proven to be very effective, though requires two code paths to be available in P96 (one for all versions up to and including 3.1.4, and another for OS3.2 and higher). However, the feature set of OS3.2 is pretty complete to my knowledge, so even if we decide to allow feature-creeping to happen again in Indivision AGA MK3, the OS may require over a year to support it. In other words: Don't hold your breath :-)


    Jens