Low level Nintendo 64 emulation?
- Thread starter Lillymon
- Start date
- Thread Starter
- #3
No, but then I don't actually have any Nintendo 64 ROMs at the moment. I was running low on HD space, and they had to go. I was having difficulties with sound cracking and the sort that just wouldn't go away, so I decided to devote HD space to other stuff until an emulator lacking these problems appeared.
But looking at it, your software plugin looks very slow as it is. What kind of speed are we talking about for putting everything into LLE? I'd hope it would still be possible to use Direct3D/OpenGL hardware plugins for graphics. Some people like the authetic look, but I prefer to use my PC to make the games look better.
But looking at it, your software plugin looks very slow as it is. What kind of speed are we talking about for putting everything into LLE? I'd hope it would still be possible to use Direct3D/OpenGL hardware plugins for graphics. Some people like the authetic look, but I prefer to use my PC to make the games look better.
Well, IMO more than 50% of the graphics glitches in current plugins are caused because they use a hardware rasterizer. Then some others are there because of the HLE approach and finally some very rare glitches are caused by some emulator core bugs.
The hardest category of bugs to eliminate in the core is the timing bugs. It would probably be better with lle but still far from being perfect as many things have to be approximated.
Emulating everything into LLE (including a software rasterizer), i think it's possible to do a 2-3fps on an amd64. Then we can probably use some tricks to speed it up (disabling bilinear filtering for example)
The hardest category of bugs to eliminate in the core is the timing bugs. It would probably be better with lle but still far from being perfect as many things have to be approximated.
Emulating everything into LLE (including a software rasterizer), i think it's possible to do a 2-3fps on an amd64. Then we can probably use some tricks to speed it up (disabling bilinear filtering for example)
Orkin
d1R3c764 & g1|\|64 m4|<3R
How about emulating the RSP using LLE, and using D3D/OGL for rasterization? That would cover everything but the most difficult blender and framebuffer issues, improve image quality, and might still give playable speeds.
On a somewhat related topic...has anyone written an RSP emulator with a debugger, or even just an RSP disassembler? It might help me figure out what some of the more obscure/undocumented RSP commands and microcodes do...
On a somewhat related topic...has anyone written an RSP emulator with a debugger, or even just an RSP disassembler? It might help me figure out what some of the more obscure/undocumented RSP commands and microcodes do...
Yea, i've actually though about that, if i get it perfectly working with my software renderer, i think i will do a hardware rasterizer as an option, or maybe write some documentation on what's needed to do lle, i think it wouldn't be that hard to add in the current plugins.
I have a little disassembler in my hle rsp plugin, but it's not the most convenient thing as you have to change the source code to disassemble the part you want. Jabo's RSP plugin includes a really nice debugger, i suggest that you download the source code of BOTH the plugin and pj64. Compile them in debug mode, and execute the .reg files included in the source code. Then you can use pj64's debugger and jabo's rsp debugger.
On a side note, i've disassembled audio ucodes and video ucodes to figure some stuffs. Audio ucodes weren't easy but i could follow the code, and figure what i needed. On the other hand, video ucodes were a mess. A video ucode doesn't fit entirely in the IMEM, so it's loading little part of the ucodes as it's needed and it's very hard to follow. Not to mention it's very hard to understand what a function that's using vector opcodes do... Well i may be wrong, but i have never got any useful information of a graphic ucode, or you would have to spend a very long time locating all the variables....
I have a little disassembler in my hle rsp plugin, but it's not the most convenient thing as you have to change the source code to disassemble the part you want. Jabo's RSP plugin includes a really nice debugger, i suggest that you download the source code of BOTH the plugin and pj64. Compile them in debug mode, and execute the .reg files included in the source code. Then you can use pj64's debugger and jabo's rsp debugger.
On a side note, i've disassembled audio ucodes and video ucodes to figure some stuffs. Audio ucodes weren't easy but i could follow the code, and figure what i needed. On the other hand, video ucodes were a mess. A video ucode doesn't fit entirely in the IMEM, so it's loading little part of the ucodes as it's needed and it's very hard to follow. Not to mention it's very hard to understand what a function that's using vector opcodes do... Well i may be wrong, but i have never got any useful information of a graphic ucode, or you would have to spend a very long time locating all the variables....