Database of high quality original N64 HW screenshot for emulator reference?

[Narann]

I was wondering if there was any kind of database or archive with high quality (pixel perfect?) screenshots of games running on real N64 hardware.

I don't have any N64 so I can't see if what I see is visually good or not.

This would provide good references for the HLE community. For now, I try to do it myself but I'm sure there is some peoples here with this kind of images.

A big thanks in advance all!

 

[Fanatic 64]

There's a few YouTube videos with games running on the real console, and you may be able to find HW screenshots at http://64dd.net/modules/games/index.php?system=n64.

 

[Narann]

There's a few YouTube videos with games running on the real console

Yes, and they help me a lot but they are still blurry because of the compression (and maybe video composite quality), even in full HD.

and you may be able to find HW screenshots at http://64dd.net/modules/games/index.php?system=n64.

Thanks for the link. Its a shame almost every screenshots are in native resolution but use jpg... A true pixel perfect (png) images of N64 games would be highly valuable.

As I work on the Rice Color Combiner (mupen64plus), I try to mimic some N64 effect that was hard to do before and are now easier using GLSL.

 

[AIO]

http://forum.pj64-emu.com/showthread.php?t=4538

 

[Narann]

Thanks AIO!

lol I'm still banned on EmuTalk, still proud of it, still not going to create a new account to bypass it

As I'm very new to the N64 HLE scene I don't really know about (what look like) a lot of legacy of the 2000s. As a newbie, I just thinks there is a lot of skilled peoples but in various places and I think it's sad N64 scene doesn't deserve this.

But your answer was valuable so I quote it there (hope there is no problem...

But there is one thing I want to address (or at least rant about) from this thread.
I would say that about 95% of the "real n64 screenshots" in that collection are, while certainly correct/accurate, potentially misleading. First, they are all taken from various TVs that do various methods of scaling the 640x240 image DAC'd from the VI to whatever scanning/filtering the TV does.

I agree. It's the best I could find for now and its surprising how "real N64 screenshots" can be rare/difficult to find...

Second, he specific this:

As I work on the Rice Color Combiner (mupen64plus), I try to mimic some N64 effect that was hard to do before and are now easier using GLSL.

It is a fascinating objective (and certainly something Rice's color combiner needs) but it doesn't need anything from the VI filters which are impertinent to the actual rendering of the graphics.

Don't get me wrong, I don't try to reproduce VI filter stuff but mainly weird effect of the Color Combiner and Blender (alpha blending, alpha cutof/noise/dither, etc...).

The best way to get "real N64 screenshots" for the sole analysis of rendering before the intervention of blurring/interlacing of VI filters is to dump RDRAM 4/8 MB from n64, then jump VI_ORIGIN_REG offset into dram and read these pixels out as a 16- or 32-bpp image format of some kind.

Have you heard anyone using a such technique? I would be interested by the results.

My fork of angrylion's plugin already has this feature implemented internally except it uses emulated RDRAM not physical real RDRAM from actual system, but there have been no RDP bugs of notice to anyone.

Interesting, where is the repo?

 

[Narann]

Answer here.

onice, cross-forum posting!

:blush:

In essence, anybody who has ever used a GameShark or Action Replay [Pro] cart to take screenshots of n64 games has used such a technique. The problem however with using a GameShark is that it appears to interfere with the 16-bit R5G5B5 pixel storage in the resulting bitmap and stores it as a 24-bit-per-pixel with some slightly off colors--those which would not possibly be stored into RDRAM. Instead, I recommend using a GS/AR to dump the RDRAM and get the screenshot from that using something like Dextrose tools or LemAsm to analyze the RDRAM in R5G5B5 pixel mode, or a 64drive possibly if you're a homebrew developer.

Actually I got someone to take RDRAM screenshots using a GameShark pro and I compared it to the results of this plugin. The results:

With enough camera repositioning I was able to rule out the TC division differences as a matter of Mario's viewpoint.

I've also analyzed other RDRAM dumps of n64 frame buffer sent by RDP, and hex-edit compared their exact bitmaps to the ones my plugin logs as screenshots. They are an exact match, so there is no longer a need to use a real N64 to get pixel-accurate screenshots.

Thanks for the informations. Impressive screenshot, which one are from your plugin and wich one are the original? Top left/Bottom right and Top right/Bottom left seems to be the same.

Do you have other screenshots like this? From other N64 games? Maybe less know or known to have some troubles with HLE? Extreme G, Mace the Dark Age, Jet Force Gemini, Excitebike 64, Donkey Kong 64, Armorines etc...

Thanks in advance!

 

[ExtremeDude2]

Well since I am the one who took said screenshots... *hides*

------------------------------------------------------------------------

Actually the only game on that list that I have is dk64 and I can't use the GS to dump memory (I'm actually not sure about pictures, but I doubt it) and what not on games the require the expansion pak (as the GS uses it for stuff and obviously can't if the game is using it)

 

[Narann]

I take all what you have!

Any archive?

Thanks in advance!

 

[ExtremeDude2]

Well like he said, the screenshots I have are too bright, but I got some RDRAM dumps if you want to try those

-----------------------------------------------------------

Here are some pics anyway (640x480 pics get cut in half for some reason)

http://www.mediafire.com/view/4m06gwa3w184j7w/Virtual Chess 0.bmp
http://www.mediafire.com/view/h4uo3axw8m3s16g/Virtual Chess 1.bmp
http://www.mediafire.com/view/fdvdafxkby8251t/Virtual chess 2.bmp
http://www.mediafire.com/view/v8fak9mfojku3ae/Virtual Chess 3.bmp
http://www.mediafire.com/view/h82hzbz4cdbag6x/starfox.bmp
http://www.mediafire.com/view/7wd3qoi9988c9xj/sm64_title.BMP

 

[Narann]

I got some RDRAM dumps if you want to try those

No thanks, I don't feel comfortable yet.

Thanks for the screenshots.

 

[dsx]

Well like he said, the screenshots I have are too bright, but I got some RDRAM dumps if you want to try those

-----------------------------------------------------------

Here are some pics anyway (640x480 pics get cut in half for some reason)

http://www.mediafire.com/view/4m06gwa3w184j7w/Virtual Chess 0.bmp
http://www.mediafire.com/view/h4uo3axw8m3s16g/Virtual Chess 1.bmp
http://www.mediafire.com/view/fdvdafxkby8251t/Virtual chess 2.bmp
http://www.mediafire.com/view/v8fak9mfojku3ae/Virtual Chess 3.bmp
http://www.mediafire.com/view/h82hzbz4cdbag6x/starfox.bmp
http://www.mediafire.com/view/7wd3qoi9988c9xj/sm64_title.BMP

oh man these are sexy

 

[zoinkity]

Hardware screenshots won't necessarily match what is displayed in the way you think they will. For instance, the easiest HW screenshot method would be to rip one of the frame buffers. That's the method used for all GameShark screenshots, but the issue is only one of the buffers is displayed at a time. Not all pixels are "visible" either, with the intent that a CRT TV will not "draw" a black pixel but simply fail to write anything at that location. That allows the original projected color from the previous buffer to leak through, since fade out occurs at a predictable rate on CRT screens. Some titles use this as a cheap form of blending. That causes problems with non-CRT screens obviously; they will inherently display differently from a CRT TV, when when interlacing issues are solved.

So, the seemingly easiest pixel-perfect method--reading the pixels being sent for display--will not give you a pixel-perfect image of what is expected to be displayed. Minimally, you need to read as many unique frame buffers in a row (which is usually 1 or 2) and layer them. This is rather similar to the way certain debug tools accidentally left in commercial titles work, except they give you the option of flipping into 32bit output mode.

Before you do anything, decide on a standard to use for comparison. Everything should be captured using only a particular method.

 

[Narann]

Thanks for the in depth explanation, interesting to see how hard it can be to get a framebuffer screenshot.

Before you do anything, decide on a standard to use for comparison. Everything should be captured using only a particular method.

Actually, It more for a reference than a per pixel comparison. What I mean is a lot of N64 picture over the internet are poor or use emulators (or both) so I can't use them as a reference. As I don't have any n64 hardware here, I'm not able to say if what I see on my plugin is what I'm suppose to see on real hardware.
For example, the relation between CVG_X_ALPHA and ALPHA_CGV_SEL is difficult to observe/analyze on real hardware (and often poorly emulated). That's why high quality (even CRT) screenshot, help you a lot to realize if you are emulating the thing the good way.