CPU framebuffer editing without going low res?

[robinerd123]

When editing a framebuffer with cpu, GLideN64 handles that fine but it renders the rdram 320x240 or whatever framebuffer when it detects the framebuffer being edited, but cant it be rendered in the rendered resolution? like renderedresx/gameresx and renderedresy/gameresy or something and loop trough the pixels corresponding the pixels that are being edited by the cpu or something? isnt really an issue but i figured it could be better to emulate those effects in full rendered resolution, also because most games use a 5551 framebuffer and also the extra color data youd get from using an emu gets lost

[theboy181]

I would like to see this enhancement. How do other emulators handle this? Is it possible to render the frame in some arbitrary part of memory and map the game to use that location instead? I think that jabo does this with his plugin only it seems like it’s per game. MK64 jumbotron for example.

[robinerd123]

jabo's uses a very dirty hack to do it and it only works in mk64, but yeah, currently GLideN64 is the only lle emulator to emulate the framebuffer pretty well and thats good but i still do believe that being emulated itd be good to have some kind of enchantment related to this

[robinerd123]

oops wrong button

[CallistoNTG]

How do other emulators handle this?

The N64 does not have dedicated video memory. It stores framebuffers inside arbitrarily allocated RAM. When you play a game in high resolution mode, a completely different layout is used. There is no real analogue to other emulators. Trying to create hacks for this is a bad idea. You have to create hacks for every region. Every possible rendering resolution. Every possible edge case. And you have to be able to detect those edge cases. And in the process you're making the emulator less accurate. The N64 is not like other consoles. A lot of N64 emulation problems arise from people ignoring that the N64 isn't like other consoles.

Jabo's approach was wrongheaded. Per game hackery of the worst kind. It also literally only works in cases where no meaningful CPU manipulation of the framebuffer is taking place.

[oddMLan]

684 same issue?

[robinerd123]

not exactly, im saying that it should divide the rendered resolution and the framebuffer resolution and apply the cpu's per pixel effects per blocks or something by interpreting what the cpu is doing with the framebuffer

[gonetz]

There are several cases when N64 CPU writes directly to frame buffer:

• some 2D logos at game start: Rayman 2, StarCraft64 and others. There is no hi-res information to "emulate those effects in full rendered resolution" in that case.
• RDP renders to a frame buffer, then CPU adds some 2D graphics over it: Dr. Mario, JFG, Pokemon Snap and so on. Again, there are no hi-res data in that case.
• Post-processing of frame buffer data: blurred pause screen in Rare games, camera in Zelda MM and Pokemon Snap. In theory, plugin can use full rendered frame buffer and apply that post-processing to it. It is very hard hack to implement. Besides, it will not work correct for camera case because low-res picture must be saved in RDRAM, otherwise the game will not recognize your picture.
• CPU copies part of frame buffer to some other place and then that part is used as texture: MK64 jumbotron, BAR environment reflections on your car. It is not exactly CPU rendering, but related to it. Again, plugin could use full rendered frame buffer there, but, as CallistoNTG explained, it would be per game hackery of the worst kind.

[robinerd123]

i meant in the last case, the cpu still could be used without special hacks by dividing/multipliyng the display resolution and the game's framebuffer size and instead of applying the effects to that applying it to rectangles of the same size of the original framebuffer pixel

[gonetz]

I don't understand what do you mean by "cpu could be used". Graphics plugin does not control CPU. CPU reads/writes to RDRAM whatever it needs. If CPU supports FBRead/FBWrite extension, it can inform graphics plugin that it will access data in frame buffer memory space, but only inform. If FBRead/FBWrite is not supported (or enabled), the only things graphics plugin can do is either copy video card buffer to RDRAM so CPU can read it, or clear frame buffer area in RDRAM, check whether data in frame buffer have been changed since the last time, and apply these changes somehow. There is no way to avoid special code and hacks there.

[oddMLan]

Duplicate of #791 and #378 ?

[gonetz]

No, those issues are different.

[oddMLan]

OK, but they're related aren't they?. The jetforce gemini one is the same issue described here. The CPU edits the framebuffer, shrinking the image to fit RDRAM, and displaying the low resolution version. Same issue as described here, except for a more general situation. The first ticket is one approach that could solve the issue described here. So I guess these tickets can have a common tag