nesdev.org

I could swear I saw this option for hi-res mode7 on the first versions of zsnes, but I'm certainly not understanding what this is all about

Surely actual texture filtering would be way faster than rendering at 16x and downsampling.

The way it works is you originally had a 256x240 output, right? So to get to 1024x960, we generate 4x4 output pixels where there was only one pixel (1x1) originally. We pick the values of those 16 pixels by interpolating along the X/Y axis and the A/B/C/D mode 7 parameters for either the most immediately scanlines (no 3D perspective) or the first and last mode 7 scanlines (3D perspective.)

My idea for naive supersampling was to add all 16 pixels together, divide by 16, and that's the output value. This would not need a giant buffer and could be done in place, but would need a separate mode 7 renderer.

But if supersampling requires inspecting nearby input pixels (eg other 4x4 blocks), then that information won't be available until the image is generated (the entire frame is being generated in parallel via OpenMP.) We could only realistically be confident that pixels to the left of the current pixel are valid, and certain that pixels to the right are not. Above and below would be race conditions. So in that case, we would have to render a 1024x960 texture, and then downsample that to 256x240, which would be brutally painful.

Also, neither bsnes_hm7_b2.exe nor bsnes_hm7_b1.exe works on my computer.

Try my official release.
https://twitter.com/byuu_san/status/1118762842453241856

[1:46 AM] Quantam: What is the reason bsnes' HD mode 7 took so long to implement? Hasn't this kind of thing been implemented in PSX and other emulators for many years?

I can't speak for other emudevs, but in my case ... I frankly didn't know the results would look this good.

I implemented hires mode 7, using twice the precision on the horizontal axis for 512x240. The result was decent, but barely perceptible. I felt that increasing the resolution higher would yield rapidly diminishing returns. The reality was the complete opposite. I wish I had come up with this. I am jealous that DerKoun beat me to this idea. But, I'm very happy he found this, and he deserves all the credit for this.

I can also say that no emulator had the framework to do this until recently. bsnes' multi-threaded PPU renderer is what made this possible. And I don't say that to take credit from DerKoun, I didn't design the new PPU with this idea in mind. But as I said before, scanline 1 needs to know about the mode 7 parameters on scanline 239 to render optimally with 3D perspective. Doing that requires all of the work needed to parallelize the SNES PPU.

If not for the very recently written bsnes parallel PPU, this mod would not have been possible. And as such, it's never been possible in ZSNES, SNES9X, higan, etc. So that's probably why it wasn't done before.

If DerKoun or anyone else had to rewrite the entire PPU to try out this idea, not even knowing if it would work, I doubt anyone would have bothered.

I could swear I saw this option for hi-res mode7 on the first versions of zsnes, but I'm certainly not understanding what this is all about :P

Yeah, I need to post an article with screenshot comparisons. The difference is truly night and day. bsnes already had hires mode 7 as well. It's not impressive in the least, unfortunately.

This high-resolution mode 7 only make sense for games who shrink the image. Those who zoom in the image are better with good-old SNES9x's bi-linear mode 7 feature, already implemented decades ago. Ideally a "perfect" emulator would allow both simultaneously.

I'm not familiar with this ... assumed Snes9X was the same kind of horizontal sampling precision increase.

Can someone show me some examples of this versus bsnes' hires mode 7, and explain the technical details?

I'm on-board implementing whatever works well into bsnes.

[4:05 AM] koitsu: a large percentage of bsnes/higan's user base is about "true accuracy", which that enhancement certainly is not

Yeah, bsnes is very much off-brand for me. The key point of bsnes though is that you can turn off every last enhancement and get higan's level of obsessive accuracy if that's your dig. bsnes is about options and having fun.

I really screwed up with how I handled things in the past. I wanted an emulator that was as perfect as possible. And now that I've made one, I don't mind maintaining a fork that focuses on quality of life improvements.

Hopefully this will go a ways toward showing that I can be reasonable about things, while also giving me more freedom to experiment with higan. And boy, higan is about to get weird with the next release. The MSX really broke every expectation for how my original bsnes project worked. I don't expect anyone will like it; it'll very much be avant garde.

I think high resolution mode 7 on older emulators may have done one or more of three things:

1. 512 pixels per line by stepping the texel coordinate by half AC per half pixel
2. Draw the top half of a scanline using start and end texel coordinates 50/50 interpolated between those of the previous line and this line, then draw the bottom half normally
3. Bilinear filtering

Technique B is analogous to this technique, except using a separate quad per scanline. Where it breaks down, however, is at the higher magnification levels near the bottom of the floor area (or the top of the ceiling in HyperZone), as the limited precision for the parameters causes adjacent scanlines to use the same parameters. This is what I plan to fix with a smoothing technique once I have some dumps of test data.

The question about PSX or other emulators can be simply answered that it's massively more straightforward when you're already in a 3D rendering context. Triangles are already a resolution agnostic format to begin with, so in a lot of cases it's a relatively trivial extension.

On the SNES you have a completely different rendering paradigm for everything else except this one thing which is sort of a textured quad rasterization, sort of. Kinda unfair to compare systems where everything is natively triangles to a system where everything but this one thing isn't.


Though on the subject of using hardware to do it, if you rendered the source memory to a texture, you could use 3D hardware to just draw a quad with texels from that buffer, at least across scanlines that don't have a change. Otherwise you'd have to generate a separate quad at each scanline split... though I'm not sure if any of that would be worthwhile vs. just doing it in software, especially because of the first step of generating the texture.

Another question I have is where your texel coordinates are supposed to be... like is the 0,0 pixel of a 4x4 oversampling block a match for the original resolution's pixel? Or would you shift that to 2,2? Would it make an improvement in the alignment/feel of where sprites appear on the screen relative to the BG layer?

The thought of trying to smoothly interpolate the extrapolation parameters to accommodate smoothly changing scanline parameter variations is interesting. You have to decide what's a disconnected scanline or not, I suppose, but I suspect existing games would play nice with something like that?

Bregalad wrote:This high-resolution mode 7 only make sense for games who shrink the image.

I don't think I agree. When magnified, you can still get better defined edges of the large texel squares, and that's worthwhile.

Though on the subject of oversampling when minified, maybe consider doing this at the texel lookup level (like a modern GPU would, e.g. mipmaps or anisotropic filtering) rather than generating a high resolution image then downsampling.

byuu wrote:I'm not familiar with this ... assumed Snes9X was the same kind of horizontal sampling precision increase.

Can someone show me some examples of this versus bsnes' hires mode 7, and explain the technical details?

SNES9x 1.42 has a bilinear Mode7 feature (in addition to its bilinear OpenGL output driver) that was removed somewhere before 1.52.

In Super Metroid's title screen intro it's immediately noticeable.

rainwarrior wrote:Though on the subject of oversampling when minified, maybe consider doing this at the texel lookup level (like a modern GPU would, e.g. mipmaps or anisotropic filtering) rather than generating a high resolution image then downsampling.

Just to rephrase this more simply, if that was too jargonny:

It might be more efficient to generate 4 texels and blend them before storing to your output buffer, instead of storing all 4 and then blending them in a second pass.

(Was making the suggestion because that's what GPUs do, i.e. texture filtering during rasterization is much cheaper to implement than anti-aliasing as a post process.)

In particular, you can do Scale2x in shader language nowadays to make the source data even higher res.

rainwarrior wrote:Though on the subject of oversampling when minified, maybe consider doing this at the texel lookup level (like a modern GPU would, e.g. mipmaps or anisotropic filtering) rather than generating a high resolution image then downsampling.

Wouldn't that require you to do the downsampling operation on the source image in order to obtain the desired mipmap? Alternately you could do it at load time instead of at render time, but the quality would be worse, and I'm not sure you'd save time because to be effective you'd need multiple mipmaps to fade between.

Modern GPUs use mipmapping because the multitexture can be prebaked.

I'm not an emu author or expert or anything, but in looking at some graphics errors (3-D correction is OFF here), I notice that there is a single scanline of erroneous Mode 7 BG when the BG modes are switched (eg Mode 0/1/2 -> 7) so perhaps you need to reset the "interpolation" anew whenever Mode 7 is deactivated/activated.

Also, for games that also have H-Sync scrolling changes (think Actraiser's title fade-in or Puggsley's Scavenger Hunt) could you also interpolate the X-scroll values per rendered line so that there isn't a jerky change of the scroll offsets every 4 lines (when in 2x or 3x mode, etc.)?

93143 wrote:Wouldn't that require you to do the downsampling operation on the source image in order to obtain the desired mipmap? Alternately you could do it at load time instead of at render time, but the quality would be worse, and I'm not sure you'd save time because to be effective you'd need multiple mipmaps to fade between.

Modern GPUs use mipmapping because the multitexture can be prebaked.

Well, I tried to clarify what I was really suggesting in my followup post.

I mentioned mipmaps because they are related to the goal of anti-aliasing a minified texture. Dynamic mipmaps could be done somewhat efficiently I think, but that's not really what I was suggesting so I won't try to describe that here. My main point was more generally doing the anti-aliasing at the texture lookup stage, and not as a post-process on the output. Mipmaps are an example of that general concept.

Okay, I think I see. I read your post too fast and assumed you meant doing the same thing the N64 does, which is pick four adjacent texels and interpolate between them. That method requires mipmapping to avoid Nyquist folding.

What I now think you meant is to draw a single screen pixel's worth of high-resolution subpixels, and just average them right away rather than waiting until the end of the frame. This would have an identical result to byuu's method, assuming simple block averaging.

Is that right?

byuu wrote: Hopefully this will go a ways toward showing that I can be reasonable about things, while also giving me more freedom to experiment with higan. And boy, higan is about to get weird with the next release. The MSX really broke every expectation for how my original bsnes project worked. I don't expect anyone will like it; it'll very much be avant garde.

On the one hand parts of the MSX standard is defined loosely on purpose so that makers could have some freedom in how to make their computers while software still being compatible with any MSX. On the other hand programmers didn't always follow the rules and relied on all sorts of assumptions that only works on certain MSX systems. And I guess 100% universal compatibility isn't realistic since there are so many little things that may turn out in unexpected behaviour on certain hardware, even though the software seems to be following all the rules. I'm not sure if anyone can expect bsnes level of accuracy on MSX unless you emulate every MSX model out there.

new version: https://www.reddit.com/r/emulation/comm ... idescreen/

creaothceann wrote:new version: https://www.reddit.com/r/emulation/comm ... idescreen/

Still doesn't work for me...

Try a VM with an English Windows? Or a different account with an English display language.