#121  
Old 10th June 2013, 12:00 AM
shunyuan's Avatar
shunyuan shunyuan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2013
Posts: 491
Default rdp sdk sample

Just find a rdp demo sample.

__________________
---------------------
CPU: Intel U7300 1.3 GHz
GPU: Mobile Intel 4 Series (on board)
AUDIO: Realtek HD Audio (on board)
RAM: 4 GB
OS: Windows 7 - 32 bit
Reply With Quote
  #122  
Old 11th June 2013, 08:07 AM
GPDP GPDP is offline
Senior Member
 
Join Date: May 2013
Posts: 147
Default

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.
Reply With Quote
  #123  
Old 11th June 2013, 02:52 PM
angrylion angrylion is offline
Member
 
Join Date: Oct 2008
Location: Moscow, Russia
Posts: 36
Default

Quote:
Originally Posted by GPDP View Post
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.

Quote:
Originally Posted by GPDP View Post
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
Reply With Quote
  #124  
Old 12th June 2013, 12:59 AM
mudlord_ mudlord_ is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Dec 2012
Posts: 383
Default

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

Might piss off angrylion for not using pure C, but whatever.
Reply With Quote
  #125  
Old 12th June 2013, 02:23 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

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.
Reply With Quote
  #126  
Old 12th June 2013, 06:57 PM
shunyuan's Avatar
shunyuan shunyuan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2013
Posts: 491
Default

Quote:
Originally Posted by haxatax View Post
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:

Code:
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.
__________________
---------------------
CPU: Intel U7300 1.3 GHz
GPU: Mobile Intel 4 Series (on board)
AUDIO: Realtek HD Audio (on board)
RAM: 4 GB
OS: Windows 7 - 32 bit
Reply With Quote
  #127  
Old 12th June 2013, 09:24 PM
ExtremeDude2's Avatar
ExtremeDude2 ExtremeDude2 is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2010
Location: USA
Posts: 2,863
Default

Quote:
Originally Posted by suanyuan View Post
Didn't see this in his to do list:

Code:
MooglyGuy's To-Do List

My To-Do list, in no particular order:

   Emulate the 64DD peripheral
Interesting :3
__________________
Quote:
Originally Posted by dsx! View Post
are you american or something
Reply With Quote
  #128  
Old 13th June 2013, 12:07 AM
mudlord_ mudlord_ is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Dec 2012
Posts: 383
Default

suanyuan: maybe because he told me on IRC?
Reply With Quote
  #129  
Old 13th June 2013, 01:18 AM
shunyuan's Avatar
shunyuan shunyuan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2013
Posts: 491
Default

Quote:
Originally Posted by haxatax View Post
suanyuan: maybe because he told me on IRC?
Sure, no offense just curious.
__________________
---------------------
CPU: Intel U7300 1.3 GHz
GPU: Mobile Intel 4 Series (on board)
AUDIO: Realtek HD Audio (on board)
RAM: 4 GB
OS: Windows 7 - 32 bit
Reply With Quote
  #130  
Old 13th June 2013, 03:14 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

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:
Code:
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.


Quote:
Originally Posted by suanyuan View Post
Didn't see this in his to do list:

Code:
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.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 03:33 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.