ata4 / angrylion-rdp-plus Goto Github PK

There are a number of N64 games that support 16:9 resolution, and it would be nice to be able to emulate them accurately. Something with a hotkey toggle would probably be ideal.

In Windows, selecting the "Parallel" option works (mupen64plus). In Linux, the application freezes and must be force closed.

Hi,
Fantastic work on this plugin!
I'm just wondering if it's possible to implement some sort of stretch to full screen size option? The reason i ask is i'm running a Windows emulation machine hooked up to a 15KHz standard definition CRT TV running at low resolutions.
When i run this plugin at 320x240 it seems to be squished both vertically and horizontally for some reason, instead of taking advantage of the full screen size as i would expect it should.
As you can imagine it's causing lots of unwanted artefacts from the image being squeezed.
I understand this is a very niche setup i have, but thought i'd see if it's possible to implement regardless.

Cheers.

Upon starting the game the splash screens tear/flash. The symptoms appear using angrylion plus, when using cxd4 or hle rsp, and when using the dynarec, cached interpreter, and pure interpreter (in m64p, February 5th 2018 release). I've also verified the behavior in parallel n64 when using angrylion with cxd4 and the dynarec.

Here is a video comparing the opening with angrylion in m64p, gliden64 in m64p (which has similar behavior), and parallel n64 (with parallel rdp) in retroarch which seems to have the correct behavior.

Welcome friends!

I'll try updating with new builds of this awesome plugin as frequently as I can, so be sure to stop by as often as you can!

Builds of the plugin are going to be 32-bit (x86) ONLY and will of course work perfectly with Project64 1.7 or 2.x

angrylion's RDP Plus r4-56 with all commits up to 5099be6

angrylion-plus (17-10-08).zip

I have this weird issue with Perfect Dark with Unfiltered output in Mupen64Plus and I have a hard time figuring out whether I should report it here or at Mupen64Plus because Project64 is unaffected.

My issue is this, with Unfiltered selected and with either Nearest-neighbor or Linear the screen freezes when you press start during the intro to start the game.

Take notice that I said that the screen freezes because the rest of the game is still working/running with sound but all you see is the last image before it froze.

Filtered seems unaffected as it works OK.

@ata4 , @loganmc10
Just thought I would give a heads up on this.

On Archlinux I'm having some issues with compiling this video plugin for mupen64plus, but in the end it still build a working .so library.

$ make -j8
[ 4%] Generate Git version
Scanning dependencies of target gl-screen
[ 13%] Building C object CMakeFiles/gl-screen.dir/gl-screen/gl_core_3_3.c.o
[ 13%] Building C object CMakeFiles/gl-screen.dir/gl-screen/gl_screen.c.o
Scanning dependencies of target core
[ 30%] Building C object CMakeFiles/core.dir/core/file.c.o
[ 30%] Building C object CMakeFiles/core.dir/core/core.c.o
[ 34%] Building C object CMakeFiles/core.dir/core/msg.c.o
[ 30%] Building C object CMakeFiles/core.dir/core/rdram.c.o
[ 30%] Building C object CMakeFiles/core.dir/core/rdp.c.o
[ 39%] Building C object CMakeFiles/core.dir/core/trace_write.c.o
[ 43%] Building C object CMakeFiles/core.dir/core/trace_read.c.o
[ 47%] Building C object CMakeFiles/core.dir/core/vi.c.o
[ 56%] Building CXX object CMakeFiles/core.dir/core/parallel_c.cpp.o
[ 56%] Building CXX object CMakeFiles/core.dir/core/parallel.cpp.o
[ 60%] Linking C static library libgl-screen.a
[ 60%] Built target gl-screen
[ 65%] Linking CXX static library libcore.a
[ 65%] Built target core
Scanning dependencies of target retrace
Scanning dependencies of target mupen64plus-video-angrylionplus
[ 78%] Building C object CMakeFiles/retrace.dir/retrace/screen_sdl.c.o
[ 78%] Building C object CMakeFiles/retrace.dir/retrace/plugin_retrace.c.o
[ 78%] Building C object CMakeFiles/retrace.dir/retrace/screen_headless.c.o
[ 82%] Building C object CMakeFiles/retrace.dir/retrace/retrace.c.o
[ 86%] Building C object CMakeFiles/mupen64plus-video-angrylionplus.dir/plugin-mupen64plus/plugin_m64p.c.o
[ 91%] Building C object CMakeFiles/mupen64plus-video-angrylionplus.dir/plugin-mupen64plus/screen_opengl_m64p.c.o
[ 95%] Linking CXX executable retrace
/usr/bin/ld: cannot open output file retrace: Is a directory
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/retrace.dir/build.make:174: retrace] Error 1
make[1]: *** [CMakeFiles/Makefile2:68: CMakeFiles/retrace.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[100%] Linking CXX shared library mupen64plus-video-angrylionplus.so
[100%] Built target mupen64plus-video-angrylionplus
make: *** [Makefile:84: all] Error 2

For emulators that don't have a builtin vsync option like Project 64, I think it would be nice to include a vsync setting in the video plugin. Mupen64plus has a vsync option within the emulator itself, and it appears to work well with no stuttering in angrylion, so having the ability to do that with project 64 would be nice since the performance is much better there.

I've tried forcing vsync at the driver level but still get stuttering. This is on Windows 10, 1050 ti, 8700k. This is of course with games already running at full speed.

Is it possible to correct FPS problems in Vigilante 8 and 8'2 games? They are emulating perfectly, but in the phases they emulate between 15 to 25 FPS, which ends up leaving very slow .... any tips? Thank you . (My video card is (EVGA 1050 GTX - 2GB)

Hi
Maybe can possible add linux support aka mupen64plus
Thanks

Finally got the chance today to try out the new release and it's looking good so far except that Perfect Dark crashes immediately, something that has not happened before using angrylion's RDP Plus r3 or a compiled version from 2017-09-14 which shows up as "angrylion's RDP Plus r3-85 dirty" in Project64

There has to be something that have changed since 2017-09-14 up till now that have broken Perfect Dark and I have tried both Zilmar's RSP (1.7.1.9999) and cxd4's RSP and it still crashes.

Dynamic Shadows are broken with AL+

Can you please add the webhook for Yappybot (discord)

This will allow the Discord community get update information from your project

Create webhook to https://www.yappybots.tk/

More information here.
https://github.com/YappyBots/YappyGithub

I just got my new laptop and its 120hz and supports G-sync. I was hoping that you could looking at adding support for the advanced syncing of Nvidia and AMD.

ATM I have to manually set the monitor to 59hz and turn off the frame limit. The plugin drops a lot of frames for some reason..

3rd world problems, I guess.

Hey there,

getting compiler warnings, maybe they are fixable:

CMake Warning (dev):
  Policy CMP0042 is not set: MACOSX_RPATH is enabled by default.  Run "cmake
  --help-policy CMP0042" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.

  MACOSX_RPATH is not specified for the following targets:

   mupen64plus-video-angrylion-plus

This warning is for project developers.  Use -Wno-dev to suppress it.

/Users/stenapp/mupen64plus-GLideN64/angrylion-rdp-plus/plugin-common/gl_screen.c:197:13: warning: implicitly declaring library function 'memcpy' with type 'void *(void *, const void *, unsigned long)' [-Wimplicit-function-declaration]
            memcpy(buffer + od, tex_buffer + os, tex_width * sizeof(int32_t));
            ^
/Users/stenapp/mupen64plus-GLideN64/angrylion-rdp-plus/plugin-common/gl_screen.c:197:13: note: include the header <string.h> or explicitly provide a declaration for 'memcpy'
1 warning generated.

In file included from /Users/stenapp/mupen64plus-GLideN64/angrylion-rdp-plus/core/rdp.c:433:
/Users/stenapp/mupen64plus-GLideN64/angrylion-rdp-plus/core/rdp/vi.c:275:27: warning: add explicit braces to avoid dangling else [-Wdangling-else]
                        } else {
                          ^
/Users/stenapp/mupen64plus-GLideN64/angrylion-rdp-plus/core/rdp/vi.c:292:19: warning: add explicit braces to avoid dangling else [-Wdangling-else]
                } else {
                  ^
/Users/stenapp/mupen64plus-GLideN64/angrylion-rdp-plus/core/rdp/vi.c:570:19: warning: initializing 'uint32_t *' (aka 'unsigned int *') with an expression of type 'int32_t *' (aka 'int *') converts between pointers to integer types with
      different sign [-Wpointer-sign]
        uint32_t* dst = prescale + y * hres_raw;
                  ^     ~~~~~~~~~~~~~~~~~~~~~~~
/Users/stenapp/mupen64plus-GLideN64/angrylion-rdp-plus/core/rdp/vi.c:617:27: warning: passing 'uint32_t *' (aka 'unsigned int *') to parameter of type 'int *' converts between pointers to integer types with different sign
      [-Wpointer-sign]
            gamma_filters(&r, &g, &b, ctrl, &rdp_states[worker_id].seed_vi);
                          ^~
/Users/stenapp/mupen64plus-GLideN64/angrylion-rdp-plus/core/rdp/vi/gamma.c:24:45: note: passing argument to parameter 'r' here
static STRICTINLINE void gamma_filters(int* r, int* g, int* b, union vi_reg_ctrl ctrl, int32_t* seed)
                                            ^
In file included from /Users/stenapp/mupen64plus-GLideN64/angrylion-rdp-plus/core/rdp.c:433:
/Users/stenapp/mupen64plus-GLideN64/angrylion-rdp-plus/core/rdp/vi.c:617:31: warning: passing 'uint32_t *' (aka 'unsigned int *') to parameter of type 'int *' converts between pointers to integer types with different sign
      [-Wpointer-sign]
            gamma_filters(&r, &g, &b, ctrl, &rdp_states[worker_id].seed_vi);
                              ^~
/Users/stenapp/mupen64plus-GLideN64/angrylion-rdp-plus/core/rdp/vi/gamma.c:24:53: note: passing argument to parameter 'g' here
static STRICTINLINE void gamma_filters(int* r, int* g, int* b, union vi_reg_ctrl ctrl, int32_t* seed)
                                                    ^
In file included from /Users/stenapp/mupen64plus-GLideN64/angrylion-rdp-plus/core/rdp.c:433:
/Users/stenapp/mupen64plus-GLideN64/angrylion-rdp-plus/core/rdp/vi.c:617:35: warning: passing 'uint32_t *' (aka 'unsigned int *') to parameter of type 'int *' converts between pointers to integer types with different sign
      [-Wpointer-sign]
            gamma_filters(&r, &g, &b, ctrl, &rdp_states[worker_id].seed_vi);
                                  ^~
/Users/stenapp/mupen64plus-GLideN64/angrylion-rdp-plus/core/rdp/vi/gamma.c:24:61: note: passing argument to parameter 'b' here
static STRICTINLINE void gamma_filters(int* r, int* g, int* b, union vi_reg_ctrl ctrl, int32_t* seed)
`

Commit 422b8dc causes a regression in the intro of Perfect Dark, preventing the logo label from disappearing until the next scene.

Is there any way to enable a dithering pattern? The picture above is from a speedrun youtube video. The one below is how it looks in m64p.

This issue is happening yet again I'm afraid, I have tested the latest r5 release on both Project64 2.4.0.9999 from 2017-10-03 and the m64p project from 2017-10-22 and it's the same issue as last time.

Perfect Dark is really sensitive to this and no other games that I own is crashing with Unfiltered set to startup value.

It's dead easy to reproduce too, start with a fresh angrylion-rdp-plus configuration on Project64 or mupen64plus-gui and change Filtered to Unfiltered.
Then save and close either emulator, start Perfect Dark and BAM a crash.

Thanks in advance!

https://github.com/ata4/angrylion-rdp-plus/tree/d4f023cf3973e697068d8ebdf25158c6f4c39b06

Gets about 8DLs slower for me in Kirby after this change.

This is my current emulation machine: I5 3570 , 8GB RAM, R9 270X 2GB, windows 10 creators update.
All drivers updated.
Project64 2.4.0.9999 default plugins and angrylion-plus r4:

banjo kazooie and tooie graphic tremble. ( angrylion-plus r3 work good)

donkey kong 64 crash in logo rare. ( angrylion-plus r3 work good)

F1 WORLD GRAND PRIX in start race show error SP_DRAM_ADDR_REG not in RDram space

V-Rally Edition 99 (U) no boot project64 stopped working

Hi. I use dual monitor in my setup, my vga card ia AMD Radeon 260x. When i go to full screen in PJ64 using Angrylion RDP Plus, the screen has been cuted, Something with fifty percent of the image is shown on each monitor. it appears that the centering is incorrect. Thank you.

With ViMode set to 0 (filtered), the resolution of the screenshot is the size of the window.

With ViMode set to 1 (unfiltered), the resolution of the screenshot is the resolution of the game.

Tested with mupen64plus, latest master

[ 21%] Building C object CMakeFiles/alp-plugin-common.dir/src/plugin/common/gl_core_3_3.c.o
In file included from /mupen64plus-GLideN64/angrylion-rdp-plus/src/plugin/common/gl_screen.c:7:0:
/mupen64plus-GLideN64/angrylion-rdp-plus/src/plugin/common/screen/gl_screen_3_3.c:1:25: fatal error: gl_core_3_3.h: No such file or directory
compilation terminated.

This is on Linux after latest changes

I don't know what have happened to the plugin but now I got serious performance issues with practically all games I have in my collection.

I have been using r5-6-dirty for a good while now and performance have been great!

On r6-56 the performance is very very bad and I rarely get full speed anymore.

There have been quite a lot commits between r5-6-dirty (13c4b89) and r6-56 (eef6466) and the size of the plugin have shrunk from around 607kb to 492kb

To put it simple, games are running slow as if you were using vanilla angrylion.

On the latest WIP build from January 10th (r6-94) GoldenEye runs incredibly slow while older versions ran it fine. Perfect Dark in the other hand, runs perfectly fine with no drops with the WIP build.
Could this be related to how GoldenEye has no z-buffering?
I'm using the latest Project64 developer build.

Specs:
[email protected]
GTX 1070 OC 8GB

I'm sure that both SDL and SDL2 are installed on my MSYS2/MinGW-W64 setup... but for some reason, when I try to compile this, it doesn't see it. http://paste.debian.net/989661/

hi, and first thanks -this is hands down one of the most impressive achievements i've seen on the N64 emu scene for years

after you tell me where to donate ;) would be interested to know what you think of my observations

-setup: Win10, i7 980x 6 cores / 12 threads @4.1Ghz, Project64 default plugins else your plugin

-issue: somewhat bizarrely in a heavy game like Indiana Jones an odd number of threads seems to be faster (60fps vs 55-56, 5 threads vs 6)

-it still often bottlenecks though, of note it looks like the bottleneck might be the core running the main program thread? this seems to also have an RDP thread running in it (i'm guessing this from the similar utilisation patterns)

-Windows does seem to be doing smart allocation of threads but using real cores only (vs HT) seems to be at least as fast but with lower utilisation

Thought I might post some test results now that I got everything setup properly (which I didn't before thanks to the cxd4 RSP mishap)

This is my current emulation machine:
i7 4790K at stock clock, NVIDIA Strix OC 1060 6GB, 16GB RAM and Windows 10 2016 LTSB

For my tests I have also used Project64 1.7.0.50 rev23 with my custom .rdb which is still holding up today!

1. 007 - GoldenEye (Europe)
Works as expected with no major issues, fullspeed most of the time with small occasional drops if there is explosions and smoke on screen

2. DOOM 64 (Europe)
Works as expected with no major issues, fullspeed

3. Legend of Zelda, The - Majora's Mask (Europe)
Works as expected with no major issues, fullspeed with small occasional drops

4. Legend of Zelda, The - Ocarina of Time - Master Quest (Europe) (GameCube Edition)
Works as expected with no major issues, fullspeed

5. Legend of Zelda, The - Ocarina of Time (Europe)
Works as expected with no major issues, fullspeed

6. Mario Kart 64 (Europe)
Works as expected with no major issues, fullspeed

7. Paper Mario (Europe)
Works as expected with no major issues, fullspeed

8. Perfect Dark (Europe)
This game is a little problematic to get going because if you press start too quickly it will freeze at the Perfect Dark logo forcing you to restart, something that does not happen using GLideN64 and the regular RSP (1.7.0.3)

However if you wait patiently for the intro sequence to finish then you can press start and the game proceeds as usual. The game then works as expected, fullspeed with small ocassional drops

9. Star Wars - Shadows of the Empire (Europe)
Works as expected with no major issues, fullspeed

10. Super Mario 64 (Europe)
Works as expected with no major issues, fullspeed

11. Super Smash Bros. (Europe)
Works as expected with no major issues, fullspeed

12. Yoshi's Story (Europe)
Works as expected with no major issues, fullspeed

That's all the games I own physically I'm afraid but never the least I was very satisfied with these results, and as you said in a post on Reddit, the project is WIP so it can only get better from here.

To be able to have this experience without worrying about performance that is absolutely outstanding!

Hi and thanks for this wonderful plugin @ata4

I was just about to post earlier an issue that seemed to break many games with graphical issues and gave exceptions until it struck me that you have to use cxd4's RSP for Angrylion, this fork included.

To avoid future issue reports that would have been similar to the one I was about to create, could you update the Readme.md to reflect this.

cxd4 haven't got any releases but this is a precompiled RSP plugin (which I have attached) that works perfectly with your fork of Angrylion and it's relatively new from this summer.

You could attach it to the Readme.md to if you want.

cxd4 rsp.zip

we're all always chasing faster performance ;) so a quick question

based on the assumption that traffic is always one way (RDP pipelines ->VI ?valid) would it be possible to use OpenGL hardware to do the grunt work of the VI?

possibly even port in code from GLideN64 or ParaLLEl to do it?

This isn't an issue per se, just me wondering what the current goal for this project is?

It's a pretty darn good plugin today as it is that faithfully replicates the look and feel of the N64 and it has only got better the more it have been worked on.

@ata4

What are you're future goals with this excellent plugin? I know there is only so little time every day/week/month/year you can work on this and I'm just curious, what's left to improve?

Unfiltered works as expected as you can see here:

The window/resolution when played with Unfiltered is very small, 320x240

However when you open the Bombers Notebook the window/resolution changes to something bigger (this particular screenshot is somewhere around 576x451 cropped)

With Filtered it's a different story as you can see here:

There is clearly something off here as you can see the Sub-Screen menu behind it and if you unpause there is small garbage left behind on the bottom of the screen.

Toggling between Filtered and Unfiltered removes the garbage.

I assume Unfiltered is the way it's supposed to be because it's the Video Output causing least trouble (none)

Just want to say that I stumbled on this plugin today and I'm really pleased with what it does. Games run at 60fps while producing everything almost perfectly! I am using Project 64 2.3.2 with the RSP that it comes with. Have not experienced any game breaking issues.

There is pixel noise in the background of space in the intro and also in-game. I've provided screenshots to clear things up. Is this caused by the low-res of this plugin? This does not get reproduced if I use Glide64 or any other HLE plugin.

Can you tell me how you can say how the'types.dat'file is generated?

期待您的回答,

Will no longer build with one click.

vi.c(750): error C2220: warning treated as error - no 'object' file generated [C:\mg\angrylion-rdp-plus\core\core.vcxproj]
vi.c(750): warning C4098: 'vi_update': 'void' function returning a value [C:\mg\angrylion-rdp-plus\core\core.vcxproj]

Mupen64plus build in Visual Studio

I noticed in various games I've tried that if you use unfiltered the aspect ratio goes all wonky. Indiana Jones and The Infernal Machine it stretches to a strange vertical aspect. Supercross 2000 it goes into an ultra widescreen view. These are just a couple examples, seems okay in Goldeneye and other games.

With filtered, aspect ratio remains perfectly intact. So I don't know why this happens.

I was having an issue getting consistent timing as expected from mupen64plus (m64p - March 26, 2018 Release) with Angrylion when running with PeterLemon's NTSC timing test ROM located here:

https://github.com/PeterLemon/N64/tree/master/CPUTest/CPU/TIMINGNTSC

Related discussion:

mupen64plus/mupen64plus-core#543

I believe I've tracked this down to the reported value of VI_V_CURRENT_LINE (which I believe comes from angrylion, but correct me if I'm wrong) when rolling over from even-to-odd and odd-to-even interlaced fields. Rolling over from an even-to-odd field my half-line numbers reported by VI_V_CURRENT_LINE are:

208, 20a, 20c, 0, 1, 3, 5

Going from an odd-to-even field my half-line numbers are reported as:

209 20b, 20d, 1, 0, 2, 4

I believe that the expected behavior would be:

even-to-odd: 208, 20a, 20c, 1, 3, 5
odd-to-even: 209 20b, 20d, 0, 2, 4

I am using the latest r3 version of the plugin.

I opened Banjo-Tooie with PJ64 2.4.0-444 with a command line shortcut to only use my 2 physical cores and after I stretched the window to a larger more comfortable size on my 2048x1368 screen resolution some moment later,my mouse stopped interacting with PJ64 and everything else.

I had to use ALT+TAB to regain access to mouse interactions (clicking/visual cues of hovering/etc.) and once I clicked on the PJ window again the issue returns.

I have mostly accurate settings set just to test some things and didn't expect this odd issue to occur.
I am on a dual-core (4 threads/2 logical) Intel i5 6200U via an ULV laptop with the cores unparked.

When forcing PJ64 to only use the 2 physical cores,it runs faster (other plugins) than leaving it to use all threads.

As I'm currently using Unfiltered majority of the time right now I was just wondering if you have plans for implementing saving changed settings preferably to a .ini or .cfg file?

That would be really great and help a lot when testing things further.

I know I have created a few things here already but this is what I got at the moment, great job otherwise @ata4

I'll keep on testing things as much as I can, thanks in advance!

will you keep on working on "disunity"

Seems like something have happened, although you can't see it on this static image this screen is actually shaking/wobbling like crazy on newer builds with filtered as selected output mode:

These are my settings:

And this is the plugin information screens:

This only happens with filtered and NOT with unfiltered as unfiltered is unaffected and works properly.

Every build below angrylion's RDP Plus r4-52 seems to work like normal with filtered like angrylion's RDP Plus r4-34-dirty, angrylion's RDP Plus r4-8, angrylion's RDP Plus r3-85-dirty etc.

So it must be a recent commit that broke something.

not a gameplay issue but interesting behavior : title screen goes down to <50FPS while CPU usage maxes out at a steady 80% on each core
parts of the intro where the logo appear also show an increase in CPU usage, as if the logo itself consumed a lot of CPU time

gameplay however never even reach 50% per core on that system

on a xeon x5675@ 4.3ghz ( 6-core , 12 threads)

the 2 main goemon games on n64 are very hard on several plugins, angrylion RDP runs near perfectly, i only noticed this odd slowdown :)

goemon's great adventure ( the 2nd goemon game) also displays similar slowdown during the game intro dialog, down to 40FPS with CPU usage reaching only 60% per core...
but gameplay is here again smooth

Tested Linux and Windows, both now crash when trying to take a screenshot. No screenshot is produced

I am using m64p on ArchLinux here. This does not happen in filtered mode. I also tried some other games like Mario 64, Blast Corps, Turok and Mario Golf and it does not happen there.

on the main 'mario head' screen there is pixel crawl over the background text that goes away with the VI filter off, is this just a feature of the filter or a longstanding bug?

have noticed this in hatcat's angrylion plugin too

ps either way still the top N64 plugin ;)

The screen looks pretty pixellated as it is now.

Unfortunately, taking a screenshot crashes m64p (build date: 22 jan 2018) with angrylion-plus GFX plugin (latest, 7adc5d6)

I am using m64p on ArchLinux here. This does not happen in single thread mode. These lines are jumping around and are not static. Also the amount of lines changes all the time.