Improved scanline renderer in FS-UAE

[FrodeSolheim]

Hi, inspired by Dr.Venom and Pixelfans ideas in http://eab.abime.net/showthread.php?t=63009, I modified FS-UAE's scanline filter to apply different intensities to the scanline effect depending on the intensity of the underlying pixel. I also blend neighboring pixels horizontally to make the output a little more "analog".

I think the result is quite nice:


Scaled 2x:

[prowler]

Originally Posted by FrodeSolheim

I think the result is quite nice

Scanlines are notoriously difficult to get in accordance with everyone's taste, but this is one of the best implementations I have seen.

Well done, Frode!

[mr_a500]

This is a huge improvement over the "bad old days", when scanlines in emulation were just black lines overlaid on the screen.

[spajdr]

Hello Frode, can you post screenshot in game? instead of main screen? :-)
By the way it looks very nice.

Regards
spajdr

[FrodeSolheim]

Sure

[Retro-Nerd]

Looks great. Is it a .shader file that work with the normal WinUAE version too?

[FrodeSolheim]

No, this is pure (CPU) software filter running in FS-UAE before the frame is rendered to screen. FS-UAE has support for loading custom OpenGL shaders from files, and it would make sense to move this work to the GPU (to offload the CPU). But this implementation would not work on WinUAE either, as WinUAE uses Direct3D and FS-UAE uses OpenGL shaders.

The implementation is trivial though, nothing technically fancy, so it shouldn't be difficult to write a shader (in any shader language).

[FrodeSolheim]

I think the Flashback title screen looks especially good:



To compare with and without filter:
Without filter: http://fengestad.no/fs-uae/wp-conten...reenshot-6.png
With filter: http://fengestad.no/fs-uae/wp-conten...eenshot-51.png

Originally Posted by prowler

Scanlines are notoriously difficult to get in accordance with everyone's taste, but this is one of the best implementations I have seen.

Well done, Frode!

Thanks

I'll also create a small guide on what display settings to use to get the best results with scanlines (and other filters). "Correct" scaling is vital to get good results on LCDs.

[Retro-Nerd]

I see, thanks for your detailed answer. Maybe somebody is willing to write the D3D shader code then.

[spajdr]

This looks great Frode. Wish i had this via some kind of plugin or screen enhancer driver for Indivision MKII AGA.

[mr_a500]

I know I'm going to sound like a picky bastard here... but although the new scanlines are a definite improvement on low-res non-interlaced screens (excellent, really), they're too strong on high-res interlace.

On real Amiga monitor, interlaced screen scanlines are much less visible than on non-interlaced screens. I'd really like to use the new scanlines only on non-interlaced screens and the fainter old scanlines on interlaced. (...yes, I already said I was a picky bastard )

[FrodeSolheim]

Originally Posted by mr_a500

I know I'm going to sound like a picky bastard here... but although the new scanlines are a definite improvement on low-res non-interlaced screens (excellent, really), they're too strong on high-res interlace.

On real Amiga monitor, interlaced screen scanlines are much less visible than on non-interlaced screens. I'd really like to use the new scanlines only on non-interlaced screens and the fainter old scanlines on interlaced. (...yes, I already said I was a picky bastard )

I understand what you mean I'll have to think a bit how to best solve this. The current scanline renderer requires a lot of CPU, so scanline rendering should be done by the shader system anyway (the scanline support in FS-UAE predates the shader support).

So perhaps I'll instead re-implement the scanline feature as shader(s), and make it possible to use different shaders on different "screen modes" (low-res, high-res, interlaced, RTG, etc) and/or make such information available to the shader.

[Supamax]

Beautiful work, FrodeSolheim!!

Wouldn't it be truly possible to make a corresponding filter for WinUae?
If so, couldn't you find the time to realize it?

I have to confess I never tried your FS-UAE... because I thought it was for Linux only and because I didn't know which benefits the Windows version has over WinUae.
Now I took a walk on the website and see that it's more focused on games and on interface simplicity/usability.

Could you kindly explain which advantages has a typical WinUae user by "switching" to FS-UAE?

Thanks,
Massimo

[AmigaFriend]

Only now have seen this thread. I have to agree that those are the sexiest scanlines i've seen on a virtual Amiga screen. Keep up the good work FS!

[mr_a500]

Originally Posted by FrodeSolheim

So perhaps I'll instead re-implement the scanline feature as shader(s), and make it possible to use different shaders on different "screen modes" (low-res, high-res, interlaced, RTG, etc) and/or make such information available to the shader.

That would be great. I can't wait.

[FrodeSolheim]

I'm playing around with scripting! I have embedded Lua and consider allowing themes to script certain parts of FS-UAE. It's mostly a fun little project, but may be useful to allow people to do more custom stuff without implementing hundreds of options.

For example, different scanlines in different video modes could (instead of having several configuration options for that) be scripted as something like this:

function on_process_frame()
    if fs_uae_is_highres_frame() then
        fs_emu_set_scanline_params(...)
    else
        fs_emu_set_scanline_params(...)
    end
end

(Of course, I still think the scanlines should be moved to a GPU shader, in which case a better example would be a script which changes the active shader).

[Toni Wilen]

Use of lua for scripting is something I have been planning to do for year or two. (for example to read and write config values, run script when some variable changes and so on)

btw, detecting if mode is lores or hires can be tricky because it is not rare to have hires scoreboard and lores game area. (Is this lores or hires or both?)

btw2, isn't this more or less same as "RGB masks" in WinUAE (which is from MAME originally I think)? I mean adjusting intensity depending on original pixel value.

[FrodeSolheim]

Originally Posted by Toni Wilen

Use of lua for scripting is something I have been planning to do for year or two. (for example to read and write config values, run script when some variable changes and so on)

Interesting! I am currently considering using Lua scripting to generate / drive the user interface, as well as allowing for user's to create themes / override the user interface with Lua scripts. Though many parts are just in the idea stage. But to allow for some flexibility, Lua would be executed from two threads, the emulation thread and the video thread (since video rendering can occur while the next frame is emulated). I will probably use a "global interpreter lock" to only allow one thread to run Lua at at time. I don't currently foresee any significant stalling with this approach since very little work will be done in Lua.

So the two parts would be:
(1) Lua functions run at certain points in the emulation (hsync, vsync for example). Lua can access the Amiga somehow - read registers, read memory,
(2) Lua functions run a certain points in the video thread. This will more FS-UAE-specific.

The "detect highres/interlaced" example could look something like this:

function on_finish_frame()
   bplcon0 = amiga_read_bplcon0()
end

function on_init_video()
    lowres_shader = fs_emu_load_shader("scanlines_lowres.shader")
    highres_shader = fs_emu_load_shader("scanlines_highres.shader")
end

function on_render_frame()
    -- checking if HIRES and LACE bits are set
    if bit32.band(bplcon0, 0x8004) == 0x8004 then
        fs_emu_set_shader(highres_shader)
    else
        fs_emu_set_shader(lowres_shader)
    end
   ...
end

on_finish_frame is called from the emulation thread, on_render_frame from the video thread. It does not make sense to read registers from on_render_frame since the Amiga emulation will have progressed.

At least the interface-with-Amiga part of the API could in theory be shared between FS-UAE / WinUAE...

Originally Posted by Toni Wilen

btw, detecting if mode is lores or hires can be tricky because it is not rare to have hires scoreboard and lores game area. (Is this lores or hires or both?)

Yes, it would only work perfectly in trivial cases, of course. But it would probably be good enough for mr_a500's purposes. Also, if the Lua script gets callbacks on each hsync, the script could also check if the mode has changed during the frame, and take that into consideration as well (would still have to choose between lores/highres shader though).

Of course, a more flexible solution would be to build a 1D texture with information about each video line, and let a shader access this information to handle each line according to highres/interlaced information, but I wasn't planning to go all the way with this one

Originally Posted by Toni Wilen

btw2, isn't this more or less same as "RGB masks" in WinUAE (which is from MAME originally I think)? I mean adjusting intensity depending on original pixel value.

Quite possibly, haven't look at it! (Oh, and it's not like I think I've discovered the wheel with the scanlines here -it is trivial solution, I was just happy about the specific end result)

[Toni Wilen]

Originally Posted by FrodeSolheim

(1) Lua functions run at certain points in the emulation (hsync, vsync for example). Lua can access the Amiga somehow - read registers, read memory,

Unfortunately just reading BPLCON0 won't really tell much because it usually will change multiple times during single frame. And I am think it will use too much CPU time to run it after each scan line. Also reading it during vblank may only return no planes active. Amiga display state is just too dynamic.

Even detecting interlace by using LACE it isn't always reliable if program tries to be tricky.

My original plan was to allow script to select when it wants to be called (at vsync or when "x" happens or when any config entry has changed)

At least the interface-with-Amiga part of the API could in theory be shared between FS-UAE / WinUAE...

Yeah, at least for register/config/memory/similar entry accesses should use same kind of API.

I never really found good enough documentation how to pass variables between lua and c code so does get_config_entry("name of config entry") work for config file access? (+matching setter) Use of function call for each config entry/register looks weird..

Yes, it would only work perfectly in trivial cases, of course. But it would probably be good enough for mr_a500's purposes. Also, if the Lua script gets callbacks on each hsync, the script could also check if the mode has changed during the frame, and take that into consideration as well (would still have to choose between lores/highres shader though).

I always plan for the complex situation first

Of course, a more flexible solution would be to build a 1D texture with information about each video line, and let a shader access this information to handle each line according to highres/interlaced information, but I wasn't planning to go all the way with this one

It would also require one texture for sprites because they can have different resolution

And then there are few programs that mix resolutions horizontally (Disposable Hero title screen is the most "popular").

I think this is only possible in theory

[FrodeSolheim]

Regarding the interlace discussion: I think we agree on the highres/interlace issue. I am aware of (some of) the problems, not as aware as you of course -thanks for the additional info . But my main point was that since stuff like this does not have a good general solution, it is be better to allow a best-effort implementation via scripting (which might be good enough for specific use cases), because it doesn't make sense to add FS-UAE options for features that cannot work properly in general. This scanline/shader example wasn't the reason I looked into Lua scripting btw, it just happened to be relevant for a request in this thread.

I'm no Lua expert, but there seems to be a way to effectively export variables by reference to Lua: http://lua-users.org/lists/lua-l/2001-03/msg00048.html, but I'm not that keen on that. The other option of pushing globals to Lua by value is not desirable either (unless the values seldom change), so this makes no sense for stuff like memory/registers.

I plan to only use functions to pass information between C/Lua, as this at least creates a clean interface without ugly hacks, and it will only incur overhead when the feature is actually used. Of course, for config variables it makes sense to have a general config getter/setter. For stuff like registers, whether it is amiga_read_bplcon0(), amiga_read_register(BPLCON0) or amiga_read_register("BPLCON0") is more of a detail, since code must be used to actually map it to the correct register anyway. I like something along the line of amiga_read_register(BPLCON0), or perhaps generalized a bit further to just read a specific amount of data from a specific memory location (which is desirable to have anyway). I really haven't planned the API, I just made up an example for the above case

Lua could also be a nice choice for some other features. I remember someone wanted to read some highscore data out of a game, and a Lua script accessing the memory every frame could be a nice choice for this. The other option was implementing a command pipe which could run commands accessing the memory. A command pipe for communication is still an option, but in this case, the command pipe handler could be implemented in Lua, to avoid creating specific command handlers in C. Or the Lua script could store data in a predetermined file (etc). I say predetermined because I run the Lua scripts in a sandbox so they can't access files. But Lua scripts could be allowed to save data to specific files in a specific location by implementing a custom output routine which goes through UAE (i.e. UAE can save data to a safe location on behalf of the script).

Lua is a really nice language to embed btw, much nicer / simpler C API than for example Python!

Btw, this is getting really off-topic