#31  
Old 28th May 2013, 05:20 AM
bryc bryc is offline
Junior Member
 
Join Date: Jun 2011
Posts: 9
Talking

I'm surprised the MESS RDP core could be implemented in a PJ64 plugin.. hot damn, must have been a lot of work
Reply With Quote
  #32  
Old 28th May 2013, 05:37 AM
AnnaW's Avatar
AnnaW AnnaW is offline
Junior Member
 
Join Date: Nov 2010
Posts: 7
Default

Quote:
Originally Posted by suanyuan View Post
This plugin is an open source project without questions, since it is base on other open source project.

But it is still in very early stage, I didn't touch any rendering code yet, so if you think it is not proper to put the binary for download without source code, I have no problems to take out the download.

If someone else wants to contributes time and intelligence to N64 emulation, why not start from z64gl or angrylion's rdp.
@suanyuan

May you can contact MooglyGuy aka Just Dessert for further questions. He made the N64 driver core for MESS.
You are welcome on the MESS Emuversal Board.

Quote:
forums.bannister.org/ubbthreads.php?ubb=postlist&Board=1&page=1
Reply With Quote
  #33  
Old 28th May 2013, 06:00 AM
AnnaW's Avatar
AnnaW AnnaW is offline
Junior Member
 
Join Date: Nov 2010
Posts: 7
Default

I forgot to mention, he is a nice and helpful guy.




Anna's Playground for QMC2
Official MESS Forum

Last edited by AnnaW; 28th May 2013 at 06:02 AM.
Reply With Quote
  #34  
Old 28th May 2013, 06:05 AM
AnnaW's Avatar
AnnaW AnnaW is offline
Junior Member
 
Join Date: Nov 2010
Posts: 7
Default

I forgot to mention, he is a nice and helpful guy.


Anna's Playground for QMC2
Official MESS Forum
Reply With Quote
  #35  
Old 28th May 2013, 06:14 AM
the_randomizer's Avatar
the_randomizer the_randomizer is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Sep 2008
Location: USA
Posts: 1,136
Default

Quote:
Originally Posted by FatCat View Post
Well, I'm not going to like, ask you to remove it.

I never really understand the point of software licenses as anybody can still physically do what they want over the Internet and get away with it, even construct artificial evidence with enough changes claiming the code is actually all theirs.

I think what will happen is a lot of people will download this and be like ewwwwww not yet finished/not fast enough/too blurry without even knowing the facts about what it could become later. It's for reasons like that, that I would much rather have not released anything, but, in a final optimized product I wouldn't mind if you took my modifications, modified them etc.
Yep, and that's why I need to keep my "opinions" or "observations" to myself
__________________
My rig:
CPU: Intel Core i7 4470 3.4 GHz to 3.9 GHz
Video card:: MSI nVidia GTX 970 4 GB GDDR5
OS: Windows 7 Professional 64-bit
RAM: 16 GB DDR3 SDRAM 10600
HDD: 2 x Western Digital 1 TB HDDs
Monitor: 23" Asus Full HD LED

Oh, and Snes9x > Zsnes in every way
Reply With Quote
  #36  
Old 28th May 2013, 10:16 AM
angrylion angrylion is offline
Member
 
Join Date: Oct 2008
Location: Moscow, Russia
Posts: 36
Default

Quote:
Originally Posted by FatCat View Post
I really dislike, strongly have a distaste for the way the original code was organized/not optimized, though; I will say that.
If you have any ideas about what can be optimized without losing any accuracy or leaving the realm of pure C, I'm willing to listen. Except for creating more function pointers to reduce the number of branches, which doesn't seem very effective.

Quote:
Originally Posted by suanyuan View Post
there are several rdp commands need to lock out screen surface to fill the frame buffer with primitive, such as showtile()
showtile() is not an RDP command, it's my debugging function and it's never called in the publicly available code.

I don't have any problems with DirectDraw fixating a blur somewhere on the screen, I've just checked this on two GPUs by two different IHVs.
Reply With Quote
  #37  
Old 28th May 2013, 02:17 PM
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

Quote:
Originally Posted by angrylion View Post
If you have any ideas about what can be optimized without losing any accuracy or leaving the realm of pure C, I'm willing to listen. Except for creating more function pointers to reduce the number of branches, which doesn't seem very effective.
I don't believe I've created any function pointers.
Changed only one pre-existing function pointer; that's the RDP command pointer table, or the DP XBUS "command shuffler", which I rewrote to use more of the "internal" names while also including their original names used in the MESS source in the include directives as external file names, just for readability, organization:

Code:
#include "commands/noop.h"
#include "commands/tri_noshade.h"
#include "commands/tri_noshade_z.h"
#include "commands/tri_tex.h"
#include "commands/tri_tex_z.h"
#include "commands/tri_shade.h"
#include "commands/tri_shade_z.h"
#include "commands/tri_texshade.h"
#include "commands/tri_texshade_z.h"
#include "commands/tex_rect.h"
#include "commands/tex_rect_flip.h"
#include "commands/sync_load.h"
#include "commands/sync_pipe.h"
#include "commands/sync_tile.h"
#include "commands/sync_full.h"
#include "commands/set_key_gb.h"
#include "commands/set_key_r.h"
#include "commands/set_convert.h"
#include "commands/set_scissor.h"
#include "commands/set_prim_depth.h"
#include "commands/set_other_modes.h"
#include "commands/load_tlut.h"
#include "commands/set_tile_size.h"
#include "commands/load_block.h"
#include "commands/load_tile.h"
#include "commands/set_tile.h"
#include "commands/fill_rect.h"
#include "commands/set_fill_color.h"
#include "commands/set_fog_color.h"
#include "commands/set_blend_color.h"
#include "commands/set_prim_color.h"
#include "commands/set_env_color.h"
#include "commands/set_combine.h"
#include "commands/set_texture_image.h"
#include "commands/set_mask_image.h"
#include "commands/set_color_image.h"

static void (*const DP_XBUS_CS[64])(void) = {
    NOOP             ,reserved         ,reserved         ,reserved         ,
    reserved         ,reserved         ,reserved         ,reserved         ,
    TRIFILL          ,TRIFILLZBUFF     ,TRITXTR          ,TRITXTRZBUFF     ,
    TRISHADE         ,TRISHADEZBUFF    ,TRISHADETXTR     ,TRISHADETXTRZBUFF,

    reserved         ,reserved         ,reserved         ,reserved         ,
    reserved         ,reserved         ,reserved         ,reserved         ,
    reserved         ,reserved         ,reserved         ,reserved         ,
    reserved         ,reserved         ,reserved         ,reserved         ,

    reserved         ,reserved         ,reserved         ,reserved         ,
    TEXRECT          ,TEXRECTFLIP      ,LOADSYNC         ,PIPESYNC         ,
    TILESYNC         ,FULLSYNC         ,SETKEYGB         ,SETKEYR          ,
    SETCONVERT       ,SETSCISSOR       ,SETPRIMDEPTH     ,SETRDPOTHER      ,

    LOADTLUT         ,reserved         ,SETTILESIZE      ,LOADBLOCK        ,
    LOADTILE         ,SETTILE          ,FILLRECT         ,SETFILLCOLOR     ,
    SETFOGCOLOR      ,SETBLENDCOLOR    ,SETPRIMCOLOR     ,SETENVCOLOR      ,
    SETCOMBINE       ,SETTIMG          ,SETMIMG          ,SETCIMG
};
may have noticed this line:
`static void (*const DP_XBUS_CS[64])(void) = {`
is because I remove the call frame for passing 2 32-bit parameters; instead I'm preparing a 64-bit union that the command data gets passed to so that we can rely on compiler intrinsics to memory-decode the bit fields out for us:

Code:
static union {
    UINT64 cmd; /* 64 bits in RDP command FIFO */
    UINT32 data[2]; /* 2 MIPS/IA-32 words in RDP command FIFO */
    unsigned char B[8]; /* 8 bytes in RDP command FIFO */
 // (to-do) per-command fifo structures to be added here
} fifo;
An example of a smaller, nit-pick optimization so far I have done, was, you know how there is that DP command length size array of constants, for quickly looking up the size of a RDP command? Well I determined when calling process_rdp_list, effectively the size in 32-bit words is desired, not the size in bytes, so I have the original size array, renamed to DP_CMD_LEN_B[64], and one calculated based off that >> by 2, DP_CMD_LEN_W[64]. LEN_B is used a lot more in the disassembler, while LEN_W seems to be used much more often in ProcessRDPList.

I'm not leaving the realms of pure C. In fact, I'm enhancing it actually because right now you surely know this code isn't ANSI-C-compliant. It's actually C++, which makes MinGW use a linker plugin statically/dynamically in the plugin and to get rid of that I think I have to rewrite it to build in the C compiler anyway (or use MSVC).

Quote:
Originally Posted by angrylion View Post
I don't have any problems with DirectDraw fixating a blur somewhere on the screen, I've just checked this on two GPUs by two different IHVs.
Strange...it was happening ever since my initial built of the --nocomment version.
I have not tired the fptr version; I guess that means "floating-point texture rendering" but I don't know exactly.
I figured I would try to optimize the readable version for simplicity even if maybe it's not as accurate as fptr.

Maybe something about my compiler libs ? dunno
Reply With Quote
  #38  
Old 28th May 2013, 04:00 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 angrylion View Post
showtile() is not an RDP command, it's my debugging function and it's never called in the publicly available code.

I don't have any problems with DirectDraw fixating a blur somewhere on the screen, I've just checked this on two GPUs by two different IHVs.
Thanks for your correction.
__________________
---------------------
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
  #39  
Old 28th May 2013, 05:11 PM
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

Sorry, lazy me.
I didn't think to give a screen capture of the version in this thread.

Okay, so I had the issue with angrylion's --nocomment (my build of it at least).
The version in this thread was based on --fptr, according to suanyuan.

So I finally gave his plugin a try just to make sure it's not my build setup (he uses MSVC).

It still looks like this:


You can see the right-hand pixel columns are all more blurred than the rest of the screen.
The font is easy to judge by. Only the texts "Mario A", "Mario C", "Score" and "Copy" seem pixel-accurate; the others are too blurry.
Reply With Quote
  #40  
Old 28th May 2013, 07:50 PM
MarathonMan's Avatar
MarathonMan MarathonMan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jan 2013
Posts: 454
Default

Quote:
Originally Posted by FatCat View Post
I really dislike, strongly have a distaste for the way the original code was organized/not optimized, though; I will say that.
Keeping in mind that they only use conformant C, it's /very/ clean and optimized code.
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 09:03 AM.


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