I was wondering if there was any plan to "left a place" where Cen64 could let a HLE RDP backend.

Please don't scream, I explain: With new OpenGL (and DirectX) versions it easier now to write a "not too ugly" HLE RDP.

I don't know how Cen64 do the relation between the various component of the N64 but if the code could let a place for HLE RDP, Cen64 could be the N64 emulator everyone was waiting for: The emulator that trash the plugin system (the one which totally break the N64 HLE Community).

Don't get me wrong, I don't want MarathonMan waste his precious time with OpenGL/DirectX stuff of course (please MarathonMan don't waste your time with HLE), but if the code allow a place where the RDP backend can be switched, Cen64 could gather N64 HLE developers on the most difficult place of the N64 emulation (the RDP) and be the Dolphin of the N64, one single emulator made of community compromise.

Maybe it's not technically possible, I know the relation between RDP/TMEM/CPU is tight (this is what make RDP HLE very hard actually) but if the code is flexible enough (or this is think with that in mind from the beginning), I would definitely love to be part of the project.

CEN64 uses the a (fork?) of the MAME RDP (which was a forked version of of z64gl itself)? I can't really keep track of everything anymore. It's more or less the same source that FatCat/Iconoclast forked his PJ64-based plugin that he's now working on.

And, an old version of what is now the CEN64 RSP, I once converted to a PJ64 plugin.

So yes, I would argue that it's possible to use HLE-type plugins, even those from other emulators.

Narann wrote:Arf, I would have dream Cen64 cut the gate with all of this and force peoples to work on one single efficient HLE RDP.

Hi Narann, I felt exactly the same way, so I decided to try my hand at programming an HLE RDP OpenGL port of cen64 many months back...
I checked the sources for some current HLE plugins & they were so high level as to only emulate the N64 SDK GFX Lib functions!
So I just used the old cen64's RDP source code, & cut away everything until I was left with a bare skeleton of the RDP engine.
Then using my understanding from my RDP/Rectangle tests I implemented every rectangle mode & Texture/TLUT mode for 16BPP & 32BPP screen modes, using the modern day OpenGL equivalents.
Everything looked perfect and scaled upto high resolutions, so for instance in Mario 64 everywhere rectangles were used, were the correct GFX, textured & alpha blended =D
So I started to work on triangles... I had a really crude understanding of drawing filled triangles already on the N64, so I just shoved in some crude code to try to display triangles on the screen.
As my understanding of the N64 ZBuffer was not quite upto par, I stopped at this stage, as I needed to make some RDP/Triangle demos to know exactly what is going on to program them in properly!
But even with my bad understanding of triangles, games show loads of stuff e.g Zelda scene with the horse galloping, Mario Kart Nintendo Logo shows & spins etc...
So after only 1 day of coding, I got quite far into programming an HLE GFX RDP cen64 driver, so I think it is definitely possible, & once MarathonMan gets the RDP into the new cen64 I'll give it a go again =D

Sintendo wrote:Well yeah, that's what precisely what makes them HLE. Sounds like you were working on a GPU-accelerated LLE renderer instead, which seems more interesting to me.

Yeah you are totally right, I am making a GPU-accelerated LLE renderer! Do any other N64 GPU-accelerated LLE renderers exist, I seem to only be able to only find software LLE renderers?
If I am the 1st todo this I will be really surprised as the OpenGL spec retains some of the exact same functionality of it's RDP grandfather, so it has been really easy to implement loads of stuff directly in HW!

Narann wrote:Wow! I wonder how a GPU LLE is possible but if it provide good performance I would really love that. I hate high resolution low poly.

I explained above how this is easily possible! If you hate high resolution low poly, my GPU-accelerated LLE renderer is not for you, as it produces extremely high resolution low poly scenes! I could easily hack in per-pixel lighting to make it look nicer for you =D

If you wanna know about performance, offloading the RDP emulation from cen64 onto the GPU, gives lots of extra VI's per second: e.g some games that run at 40 VI's, run at 60 VI's using my GPU driver. (Windows XP 64, I7 2.9 GHz, NVIDIA GTX 280, mingw64-bit compiled binary)

Last edited by krom on Sun Jul 27, 2014 2:36 am, edited 1 time in total.

Ah cheers for this sintendo, I'll read that whole forum topic as it is right up my street, it looks really nice =D

I must check out their source... The only thing I can fault them on is that I saw that they use the extra lib glew to implement their cross platform shader inclusion...
I will not be using glew, as I know howto make cross platform shaders work without it, also I feel it bloats out programs with it's libs/dll files etc =D

Narann wrote:Seriously? How a LLE plugin can render other thing than native resolution?

Hi Narann, it took me a while to code up some hardware triangle demos to help explain, so sorry for the late reply...
If you check out my filled triangle demo here: https://github.com/PeterLemon/N64/tree/ ... gle320x240
You will find a simple set of 2 python scripts that can calculate the same triangles in my demo using hand Y sorted floating point X,Y input data for the coordinates.
If you have N64 documentation (even the free patents), you will see how triangle slopes are defined using different variables:
Namely YL,YM,YH & XL,XM,XH which are needed to calculate the slopes DxLDy, DxMDy, DxHDy.
You can see how the demo displays triangles on the real N64 hardware from the FillTriangle32BPP320X240.png screen shot I have taken.

Now if we do the reverse of the python calculations to these low level RDP triangle commands, what we are left with are the same 2D floating point X,Y coordinate values that we started with.
If we then sort them into clockwise order we have the exact numbers we need to put into an OpenGL GPU filled triangle polygon.
If you make a skeleton RDP driver for cen64, and place the code to calculate this non-shaded / non-zbuffered triangle X/Y coordinates into the corresponding RDP opcode command (0x08),
and use the OpenGL command to display the triangle, you will see the exact same output of my triangle demos using the GPU to emulate the LLE commands of the RDP.
In a 640x480 window, this should be almost bitperfect with a real N64 screen, with the only differences being how your GFX card GPU decides how it creates the slopes for an OpenGL triangle on it's hardware.
If you then resize the OpenGL window to full screen of your monitor it automatically makes the same triangle demo hi-resolution,
e.g. the triangles in my demo will have sharp edges, and is running the same LLE RDP triangle command.

Rectangles are even easier to implement as they have really simple X/Y coordinates, that are easy to translate to direct OpenGL GPU quad commands.
I have tried my best to explain to you how this is possible, sorry it took so long =D

Narann wrote:Anyway, as soon the new core boot commercial roms, I would definitely help on this project!

We need all the the help we can get, thanks so much for taking an interest =D

Last edited by krom on Wed Jul 30, 2014 9:29 pm, edited 1 time in total.

z64 lets you choose whether VI emulation is being done from frame buffer read-back or not being done with hardware-accelerated geometry scaling simply, so regardless of being a LLE plugin it would let you use native or high resolutions based on your settings in the plugin.

MarathonMan wrote:CEN64 uses the a (fork?) of the MAME RDP (which was a forked version of of z64gl itself)? I can't really keep track of everything anymore. It's more or less the same source that FatCat/Iconoclast forked his PJ64-based plugin that he's now working on.

z64gl was a forked version of MAME itself, including MAME RSP as z64-rsp.
ziggy started the project to port the work of Ville Linde from MAME, to the zilmar plugin system, for all to see. It was before MooglyGuy got really involved.

It would also not be accurate to say that CEN64 is a fork of the MAME RDP, directly. angrylion's SGI-refined repository was, but less than 25% of original z64/MAME code survives in it.

AIO wrote:Is this still being worked on? I think an accurate HLE RDP would be amazing!

Hi AIO, the RDP OpenGL backend is not being worked on at the mo, I got side tracked with HW RSP tests
I am waiting for the latest cen64 to become more complete before I get back to work on this, my earlier attempt was just a proof of concept to show MarathonMan the speed increases when offloading the RDP work to the P.C GPU...
I'll update people here when I resume work on this =D

krom wrote:Hi AIO, the RDP OpenGL backend is not being worked on at the mo, I got side tracked with HW RSP tests
I am waiting for the latest cen64 to become more complete before I get back to work on this, my earlier attempt was just a proof of concept to show MarathonMan the speed increases when offloading the RDP work to the P.C GPU...
I'll update people here when I resume work on this =D