byuu's message board

Framebuffer emulation is disabled, if my own experiences with N64 emulation are any indication.

I just grabbed a screenshot off Google Images, because it happened to show the area of the game I was referring to. Perhaps I should've searched harder to find one either properly emulated, or from real hardware, as well as a better explanation what I mean.

Framebuffer emulation is indeed totally disabled or not working properly in the shot I found before, so here's a better one I took myself.



My point is, if you give the game's framebuffer one texture and the final output another, that screen over the tunnel will show the original regardless. If you give the framebuffer a 240p render of the screen and the final output a high-res render, fullscreen framebuffer effects will display at the lower resolution regardless.

In cases like these, if you're attempting to enhance the game, it really is preferable to just give it the wrong framebuffer in the first place. Accuracy has its place in the world, but enhancements really do give a better experience when applied consistently across the board.

> I'm not sure what you mean by IIR.

Infinite input response.

The idea would be that you render a hires, texture-pack framebuffer off to the side (obviously it can't exist in actual N64 memory space due to its larger size and because you don't want it read anyway.) When the game goes to say, "draw the framebuffer to the screen at these coordinates", you actually use the hires version.

The new screen will have the hires Mario Kart track, and a hires screen capture of the track on the display monitor. Obviously scaled down, but presumably still sharper looking, especially if you are running on a 4K display and the little monitor alone is 640x480+.

Obviously if the game starts writing raw pixels into that frame buffer before displaying it, then you're kind of fucked there.

This is much like the idea of using cubic interpolation for SNES audio. It has an echo buffer that mixes in previous samples, and the game can read out that buffer. So you could keep a cubic echo buffer and a gaussian echo buffer, but each time a sound repeats, the repeated sound with the current sound are mixed in, hence IIR.

Like looking into a mirror inside a mirror image, it repeats infinitely until the difference is too small to be noticeable.

I don't see any potential problems with having an extra cubic buffer, or an extra hires framebuffer, so long as the game doesn't actually *write* to the raw contents of said buffers. But, yeah, maybe there's a reason it won't work.

> In cases like these, if you're attempting to enhance the game, it really is preferable to just give it the wrong framebuffer in the first place. Accuracy has its place in the world, but enhancements really do give a better experience when applied consistently across the board.

Reminds me of HQ2x on 2D. You can see it falsely blending sprites with background tiles all the time. So the obvious thought is, "make each layer render in ARGB and blend them together!", but then you run into problems with games that use multiple layers to display a cohesive image with more colors than is ordinarily allowed, or with some kind of cute tile-offset effects applied. So you think to have per-game blending rules for layer cohesion, but then it varies based on certain scenes within the same games.

The more you try and hammer down the edge cases, the more extreme edge cases pop up.

Yep, and eventually arrive at the point where every game has it's own special set of fixes, and enhancements working in their own unique ways. Which can give great results, and improve the experience immensely.

However, then you run into another argument over accuracy. Is your new enhanced version still in the same spirit/vision of the original?
I generally can't stand texture packs (n64, PC, or whatever) for that exact reason. The original artists (with QA people help) often went through and hand tweaked textures so everything looks like it belongs, or at least doesn't look weird. That often gets lost when you replace them with "improved" versions, or goes completely weird when a small part of a huge texture is used "out of place" because no one playing would know better. This makes the game feel way different, and I don't end up liking it as much. It might be better to someone who hasn't played the game before, but to me it's hideously inaccurate and spoils it.

Generally, I agree, with one exception: Minecraft's default textures are hideously amateurish, and the game looks much better when a good third-party texture pack like Painterly Pack is applied. (I get the feeling the developers agree, given the presence of a "Resource Packs" button right there on the main menu.)

[quote="noiii"That often gets lost when you replace them with "improved" versions, or goes completely weird when a small part of a huge texture is used "out of place" because no one playing would know better. This makes the game feel way different, and I don't end up liking it as much.[/quote]
This isn't a problem inherent to texture packs, but certainly common among them. A skilled modder can absolutely get this right, they just generally don't.

Of course, of course. There are very much texture packs that can improve a game. However, once you get into the territory of replacing assets (even if you're just doing some sort of up scaling/filtering) accuracy goes directly out the window.
If the result is better or not is obviously subjective, but maintaining the exact same look/tone throughout literally 100% of the whole game, is effectively impossible. And now you're into a completely separate (and parallel) argument of what is "accurate enough". You are into a territory that makes the differences of unfiltered and HQ2x look unnoticeable.

Can someone convert the absurdly large images to links, or just delete them from the quotes so that the thread isn't so... awful to read?

Texture packs would be a high-impact enhancement, basically.

I'd agree, but then, well... there is the Quake Retexturing Project.