SoftGraphic graphic plugin

[HatCat]

Well there's sete (set on equal), setne, and some others, like sets and setns (signed and not signed).

So I believe SETS is the x86 equivalent of the SLT equivalent on MIPS you may be thinking of (set on less than).

http://www.penguin.cz/~literakl/intel/s.html#SETS

(edit) sorry strictly speaking, `setl` is the x86 equivalent of your MIPS SLT, but obviously for comparison to 0 we prefer SETS.

[mudlord_]

Originally Posted by MarathonMan

Look around for benchies -- they're supposedly miracle workers when it comes to emulation: http://www.mameui.info/Bench/Bench.htm

If you're into this stuff, they have pretty beefy vector units vs. SB/IB, as well as AVX2 for 256-bit ops.

Thats exactly the point: I am interested now in SIMD coding for CPUs since parallel coding via shaders for graphics coding is starting to wear thin in terms of fun. Plus I need a new CPU anyway, since this cpu doesnt support SSSE3, and is quite pathetic.

[the_randomizer]

Originally Posted by FatCat

SoftGraphic rewrite by suanyuan is entirely closed-source and has no current intention of merging in angrylion's optimizations.

Ah bollocks. Guess no speed boosts then.

[angrylion]

Originally Posted by haxatax

Already checked blender/combiner, but then AL said something about some games using previous pixels as info when doing ops....

So what exactly is not clear about these inter-pixel dependencies from my posts on emutalk? Results that belong to previous, next and, amusingly, later pixels are needed to accurately compute the color of the current pixel under some circumstances. These are bugs or side effects of RDP pipelining. The only game that actively uses this for its visuals, to my knowledge, is Monster Truck Madness 64. It is perfectly possible to create an endless dependency chain of millions of primitives, where each pixel of each primitive would ultimately depend on results belonging to the very first pixel. These inter-pixel dependencies can be grouped into 5 categories:
1. memory color/alpha
2. blender shifters
3. texel 1 color / alpha
4. combined color
5. lod fraction and tile indices

That's why I have global variables like pre_memory_color, pastblshifta, etc.

[mudlord_]

k, so that rules out SIMD of blender/combiner, since you will get apeshit over emulating ONE game 99% correct instead of 100%

[HatCat]

Downgrading from 100% accuracy to 99% accuracy is a lot easier than going the other way to add accelerations like SSE or SIMD in the process so I would rather start with that.

Sort of like working with lossless data.
Restoring missing/undocumented data in a lossy-compressed JPEG or MP3 sound image is more difficult than compressing it for transfer speeds off an originally lossless PNG or WAV.

[mudlord_]

guess you are correct. Would be interesting if its true that only one game uses such precise RDP pipeline behaviour.
I wonder if one of us should just make a FOSS github repo since saunyan has no intents of fossing the plugin.

[HatCat]

As usual I have most of my current work on my own GitHub repo.
And as usual I prefer it not being publicly linked to (not like I really control that anymore), but you know it already.
It has my fork of angrylion's work on it merged in with my changes, and finishing merging his r60 in as of yet.

[mudlord_]

at least one of the forks is FOSS, thank heavens for that.

[HatCat]

angrylion: Can you verify that your dithering implementation is used as often as it is in the emulator, on the physical system?

On a couple of ROMs (Virtual Chess 64 is one of them.) there seems to be dithering in the black background (unused bits of the screen for drawing any other pixels) whereas the screen captures of real N64 video output show no such dithering.

He took his screen shot of Absolute Crap PD ROM:


There is no dithering in this 640x480 video output (partially distorted by his video cable).

It looks like this as of r64 of your plugin (r65 and later revisions is still in progress for me to finish merging.):



So on the emulator the background is dithered.
Real N64 then it's not dithered.

Is this an implementation fault of your plugin?

(Yes I know the right half of the emulated screen shot is slightly blurred; it's because I haven't figured out how to make it go away! But angrylion you said you're unable to reproduce the partially blurred screen on different video cards so I guess I'm missing some sort of DirectDraw build config parameter or something; we can figure that out later.)