SoftGraphic graphic plugin

[shunyuan]

Just find a rdp demo sample.

[GPDP]

Just gotta say, the accuracy of the MAME RDP, and this plugin by extension, is simply amazing.



When I first booted this up, I thought it looked pretty good, but out of curiosity, I turned on the filter.



At first I thought it looked a bit too blurry and bright, but then I went and checked it against the real N64 and game, and lo and behold, they look pretty much exactly alike. It's the first unfiltered image that is too dark and full of obvious dithering.

Such a shame that the filter causes such a massive loss in performance. Also, I'd like to know what's up with the "static" effect on the black border area.

[angrylion]

Originally Posted by GPDP

Such a shame that the filter causes such a massive loss in performance.

I've improved the performance of VI filters in revisions 64 and 65 of my plugin a bit, so maybe suanyuan could merge these changes.

Originally Posted by GPDP

Also, I'd like to know what's up with the "static" effect on the black border area.

If you're talking about black spikes, they happen on hardware, only in most cases you need a capture card to see.
Star Fox 64 video from real hardware:
https://www.youtube.com/watch?v=_DNhvjWjQI0
at 1:06, 1:07
Snowboard Kids video from real hardware, black spikes happen constantly on the right border:
https://www.youtube.com/watch?v=6ru21VEK1IY

[mudlord_]

Oh yeh, MG is planning to rewrite some parts into SSE2/whatever...

Might piss off angrylion for not using pure C, but whatever.

[HatCat]

lulz

Before I knew angrylion made (or well, released publicly the source to) his own RDP plugin, I was determined to start from ziggy's software renderer and sync up step-by-step with every single one of the MAME commit updates, like there was no tomorrow / no other solution.

But the further deeper I got into the MESS/MAME change logs, the more C++ code I saw. (I more-or-less cannot stand C++.)

Then I saw it near the end where it was mostly C++-related changes or optimizations, and I was like, NO, WAY.
Am I implementing this kind of shit.

I was very, very grateful when you showed me angrylion had a C version up (technically C++ strictly speaking but definitely C enough for me to work with).

I am still syncing his recent updates to my build of the plugin.
I got interrupted by a few things today but I hope to have that done soon so I can continue optimizing.

[shunyuan]

Originally Posted by haxatax

Oh yeh, MG is planning to rewrite some parts into SSE2/whatever...

Might piss off angrylion for not using pure C, but whatever.

Didn't see this in his to do list:

MooglyGuy's To-Do List

My To-Do list, in no particular order:

    Finish writing "Let's Emulate Space Invaders!" article for MAME dev wiki.
    HLSL short-term plan: Improve shadow mask simulation by operating at very-high-res internally and splitting the frame across multiple quads in order to stay below individual texture size limits, then performing repeated 4x4-averaging downsizing passes to scale to the target resolution for maximum visual quality.
    HLSL mid-term plan: Vector post-processing support. This is tricky, as currently there is a non-trivial amount of overhead from dispatching quads in immediate mode, and with each vector as an individual quad, performance goes south very quickly. However, this will need to be rectified in order to eventually support hardware rendering of individual polygons for 3D hardware.
    HLSL long-term plans:
        Add a GLSL port of my CRT shader suite.
        Add support for shader-based hardware rendering of 3D hardware polygons. 
    N64 driver improvements (MAME/MESS):
        Continue performance profiling and branch flattening in the RDP renderer.
        Accelerate the RDP renderer by threading off non-overlapping triangles.
        Emulate the 64DD peripheral.
        Emulate the Transfer Pak peripheral. 
    Continue improving the 8-bit Atmel AVR core and emulate "Craft", by [lft], in MESS.
    CD-i Improvements (MAME/MESS):
        Work out more of the communications protocol in later versions of Quizard. This may require decapping or an actual CD-i unit on which to run tests, as inputs and possibly other things like protection are handled by a small PCB with an 8051 MCU on it that communicates with the base CD-i unit through the standard rear serial port.
        Work out more of the CDIC behavior. Specifically, work out how to make Zelda's Adventure not hang when walking onto the next screen while also not making Lemmings crash immediately upon playing PCM audio.
        Possibly emulate other CD-i models in order to improve compatibility by cross-checking behavior on different hardware revisions. 
    Palm improvements (MESS): Add support for more hardware revisions by emulating the different 68k system-on-a-chip revisions. 

If anyone wants to take these tasks off my plate, please feel welcome to do so.

[ExtremeDude2]

Originally Posted by suanyuan

Didn't see this in his to do list:

MooglyGuy's To-Do List

My To-Do list, in no particular order:

   Emulate the 64DD peripheral

Interesting :3

[mudlord_]

suanyuan: maybe because he told me on IRC?

[shunyuan]

Originally Posted by haxatax

suanyuan: maybe because he told me on IRC?

Sure, no offense just curious.

[HatCat]

As I'm finishing up merging revision 56 of angrylion's recent changes (sorry lol I am way behind), I am just now catching something.

In ProcessRDPList, there appears to be somewhat of a redundancy:

cmd = (rdp_cmd_data[0] >> 24) & 0x3f;
cmd_length = rdp_cmd_ptr << 2;

if (cmd_length < rdp_command_length[cmd])
{
	dp_start = dp_current = dp_end;
	return;
}

This is a little redundant, because it immediately precedes a `while` loop that performs nearly this exact behavior.

The `while` loop also, like this code before it, fetches cmd = 6 bit pointer.
The loop also, like the code before, fetches cmd_length = len in bytes >> 2.

The loop also, like the code before, then checks if cmd_length is too big.
If so, go to this line of code:
`dp_start = dp_current = dp_end;`
...And exit the function through the return slot.

This ultimate result is reached either way--whether the if() code before even entering the while loop exits, or whether it makes it to the while() loop first and breaks from inside that.

However, I might be overreacting here.
First, this has almost nothing to do with efficiency.
It's more of a simplicity thing--merge an if() inside of an identical while() after it. It's just more maintainable and readable by programmers.
Second, merging the if into a do..while(){} or a while(){} loop might not be as easily possible as I'm thinking, due to the changed algorithm in the while() on testing the legal limitation of the RDP CMD length.

It will take further analysis later. Again, it's not a very important change (let alone significantly efficient), just something I realized at the end of --nocomment b56 change file.

Originally Posted by suanyuan

Didn't see this in his to do list:

MooglyGuy's To-Do List

My To-Do list, in no particular order:

    Finish writing "Let's Emulate Space Invaders!" article for MAME dev wiki.
    HLSL short-term plan: Improve shadow mask simulation by operating at very-high-res internally and splitting the frame across multiple quads in order to stay below individual texture size limits, then performing repeated 4x4-averaging downsizing passes to scale to the target resolution for maximum visual quality.
    HLSL mid-term plan: Vector post-processing support. This is tricky, as currently there is a non-trivial amount of overhead from dispatching quads in immediate mode, and with each vector as an individual quad, performance goes south very quickly. However, this will need to be rectified in order to eventually support hardware rendering of individual polygons for 3D hardware.
    HLSL long-term plans:
        Add a GLSL port of my CRT shader suite.
        Add support for shader-based hardware rendering of 3D hardware polygons. 
    N64 driver improvements (MAME/MESS):
        Continue performance profiling and branch flattening in the RDP renderer.
        Accelerate the RDP renderer by threading off non-overlapping triangles.
        Emulate the 64DD peripheral.
        Emulate the Transfer Pak peripheral. 
    Continue improving the 8-bit Atmel AVR core and emulate "Craft", by [lft], in MESS.
    CD-i Improvements (MAME/MESS):
        Work out more of the communications protocol in later versions of Quizard. This may require decapping or an actual CD-i unit on which to run tests, as inputs and possibly other things like protection are handled by a small PCB with an 8051 MCU on it that communicates with the base CD-i unit through the standard rear serial port.
        Work out more of the CDIC behavior. Specifically, work out how to make Zelda's Adventure not hang when walking onto the next screen while also not making Lemmings crash immediately upon playing PCM audio.
        Possibly emulate other CD-i models in order to improve compatibility by cross-checking behavior on different hardware revisions. 
    Palm improvements (MESS): Add support for more hardware revisions by emulating the different 68k system-on-a-chip revisions. 

If anyone wants to take these tasks off my plate, please feel welcome to do so.

If all MooglyGuy is updating about the RDP at this point is C++ changes/optimizations then I have nothing to fear with from this point forward concerning myself with just the changes to the my little plugin --nocomment.

Unless he finds something contributing to the accuracy of the MAME RDP emulator I am not really concerned.