Closed dirkwhoffmann closed 2 years ago
Bump up the texture size in vAmiga and measure the performance hit.
Maybe there is a better solution...
Goal: Keep performance impact minimal, because the new modes will be rarely used.
Proposal: Instead of doubling the texture width inside the emulator, utilize the merge shader to compose the super hires texture. Right now, the merge shader is used to mix the lines from the short frame texture with the lines from the long frame texture. The new merge shader will mix both lines and columns. In normal modes, the emulator will create a single emulator texture and pass this texture to the merge shader twice. Hence, the merge shader will mix this texture with itself (columns are doubled). In super hires modes, the merge shader will be fed with two different textures (one for even columns and one for odd columns).
Next step: Evaluate the performance impact caused by a more complex merge shader which has to read pixels from four textures instead of two.
Reference images (taken with A500plus, WB 2.04 rev. 37.67)
SuperHires:
SuperHires Interlaced:
Update:
Utilising the GPU to merge even and odd columns in SuperHires mode worked, but turned out to be too complex. Hence, I've abandoned this idea.
Instead, I've added a compile-time constant called TPP (Texels Per Pixels) which can be set to 1 or 2. If set to 1, the texture is created the same way as in previous versions. That is, one texel is created for each Hires pixel. If set to 2, each texel corresponds to a SuperHires pixel.
New vAmiga compiled with TPP = 2 (texture has SuperHires resolution):
New vAmiga compiled with TPP = 1 (every other pixel is missing in SuperHires mode):
SuperHires mode is not fully working, yet. I.e.,
A closer look at the generated texture reveals something interesting (at least for me):
Commodore was using stripe patterns to make the user think the image contains more colors than there actually were. Indeed, on a real monitor it works well. It looks like we had 8 colours instead of 4:
We can do the same in the TPP=1 case where a single texel represents two super-hires pixels. Instead of throwing away one of them, we can merge them together. The result is pretty nice, I think:
Now, sprites are drawn correctly in SuperHires mode:
Next step: Implement 70ns sprite positioning (see HRM 3, p. 303).
SuperHires modes are supported in v2.1b4 which is online.
In the past, there have been multiple requests to support SuperHires mode (ECS Denise, A500+).
SuperHires mode is pretty much useless, but a nice-to-have for the sake of completeness.
However, before implementing this mode, some evaluation has to be done. Supporting a 35ns pixel raster requires the internal texture size to be doubled which has a yet unknown impact on performance. It needs to be evaluated how big this impact is. What I want to avoid is to use mode-specific texture widths, because it would require many additional code paths.
TODOs: