cancel
Showing results for 
Search instead for 
Did you mean: 

Dolphin Emulator DK2 compatibility

lohan
Honored Guest
The title pretty much says it all. I would like to know if anyone here has already tried to run the dolphin emulator with the DK2. Some say it should work. If yes this one should give us hundreds of titles to try out during the "starving period" even if those Wii/Gamecube titles don't use the full potential of the DK2.
1,298 REPLIES 1,298

Anonymous
Not applicable
"2EyeGuy" wrote:
I fixed the morphball "scale" bug (which doesn't actually have anything to do with the scale, the world was being recognised and rendered as a HUD element because of the severe letterboxing the game uses).
I also probably fixed the shadow rendering in most games that use projected shadows.
And I fixed the helmet and map rendering in the metroid prime 1 demo.
And added the action replay codes for Metroid 1 NTSC 0-00 and the demo.


Great work, but now if you walk around in the first level with the scanner view, Samus appear in the top left corner of one of the screen with the feet on the air.
http://imgur.com/gMCTC1o
In the third level she apears in the normal view
http://imgur.com/Juxoq8K

In addition in scanner mode there is an eye with more brightnees than the other and the bright eye changes randomly of eye, I was touching efb copies settings and I managed to remove it, but when I restart the game the brightness bug still there.

@cegli, you have said that you have been making tests with okami, it works well for you? I got a super annoying strobing effect that make the game totally unplayable.

cegli
Honored Guest
I've now merged the new D3D mode to trunk, along with 2eyeguy's changes to Metroid rendering!

I've found two sources of judder in Metroid 1, and fixed one so far:

Source 1:
When I have my "Remove 16:9 Bars" object removal code enabled, combined with the culling codes, it causes a slow down that pulls the frame rate under 75fps. The start of the problems lies with the culling codes upping the number of times the function "RunVertices" is called to almost 40,000 times per frame! This causes a couple things:

1. The increased number of RunVertices calls for all the non-culled objects puts a much larger load on the GPU and CPU.
2. The object removal code gets called once per "RunVerticies", so it was getting called a ton of times, making a much larger load on the Object Removal Code code.

What I ended up doing was doing a serious optimization of the Object Removal Code code, and now I'm not getting judder when it's on! Users should see a boost to FPS on games/scenes that are CPU limited, when using object removal codes. Also, more should be able to be added before it slows down as well.

Source 2
I just found this one, and it's very confusing. Fugazi alluded to this in his last post. If I start on the first platform, I get some odd judder. As soon as I hit the "Graphics" button, the judder goes away and locks to a smooth 75fps, and a copy of Samus appears in the upper left corner of my view. The Samus doesn't go away until I restart the game. Ideally it should always run as smooth as after "Graphics" button is hit, but without the Samus copy in the corner.

"fugazi" wrote:
@cegli, you have said that you have been making tests with okami, it works well for you? I got a super annoying strobing effect that make the game totally unplayable.

Here are the settings I use to get it to work:
1. Direct3D
2. EFB Copies Disabled + Remove Blank EFB Copy Box
3. Timewarp 30fps to 75fps.

I don't get any flashing in the newest version with the S3D code. I used to get some in the menu's/cutscenes, but the game has been stable. Opcode Replay Buffer does not work on this game right now.

"gmichaelcaputo" wrote:
Since people are knee-deep in the code here, have the contributors of this thread seen anything that indicates what might solve the rendering issues that cause the skybox to appear so prominently? Even the indications of a hack so that we can get a playable version going? I'd be happy to contribute however I can.

Looks like it's been a tough bug to track down! I haven't gotten that deep into the rendering code, but eventually I might have time to take a look. Problem is there are so many big VR bugs that need looking at right now, it might be pretty far down on the list!

2EyeGuy
Adventurer
"cegli" wrote:
I've now merged the new D3D mode to trunk, along with 2eyeguy's changes to Metroid rendering!

Me too. Also I merged the latest changes from master.

"cegli" wrote:

When I have my "Remove 16:9 Bars" object removal code enabled, combined with the culling codes, it causes a slow down that pulls the frame rate under 75fps. The start of the problems lies with the culling codes upping the number of times the function "RunVertices" is called to almost 40,000 times per frame! This causes a couple things:

I try to do my layer removal/adjustment when the projection matrix changes, which is about 15 times per frame. It is good for games like Metroid when I want to hardcode recognition of the helmet or HUD and attach them to your face in just the right way. For example I can easily remove that Samus in the corner with no reduction in speed. But...

"cegli" wrote:
Fugazi alluded to this in his last post. If I start on the first platform, I get some odd judder. As soon as I hit the "Graphics" button, the judder goes away and locks to a smooth 75fps, and a copy of Samus appears in the upper left corner of my view. The Samus doesn't go away until I restart the game. Ideally it should always run as smooth as after "Graphics" button is hit, but without the Samus copy in the corner.

Rather than hiding graphical artifacts, the correct approach is to understand why they are there and fix Dolphin VR so that the bug or missing feature doesn't cause the artifacts to happen in other games. Also the game is trying to render a feature that we probably want, so we should try to get it working in VR.
In this case the game first draws the terrain from the point of view of the light, to a square viewport in the bottom left corner, which is our projection shadow texture. This is then copied from the EFB to the shadow texture, and I'm guessing that part of the screen is supposed to be cleared after the EFB copy. Then it renders Samus probably from the point of view of the light, to a square viewport in the top left corner, which is either a projection shadow or projection reflection texture. This is also copied from the EFB to a texture, and that part of the screen is supposed to be cleared (make sure you haven't turned on cegli's EFB screen clearing disabling which disables the second and subsequent clears). Then the world is rendered, using the surface textures and also the shadow/reflection textures at the same time. The problem seems to be that the screen clearing isn't working. Before the S3D merge I knew one eye wasn't being cleared properly (although I couldn't work out why), but I thought the S3D merge would fix it.
Anyway, you will notice that shadows in Metroid Prime (and probably other games) now work, whereas before they didn't (and probably rendered 3D black garbage objects). I am detecting when all games try to render projection shadows and I'm rendering them in mono without head tracking to the FOV specified. So it is very close to being how it should be. I just need to work out why the screen isn't clearing and see if I can fix that.

BTW, Opening the graphics menu does two things... reloads the settings from the graphics INI file, overriding whatever per-game settings were in the game's INI file. And it resets the stereo mode to Oculus if your Rift was detected.

Anyway, I'll get back to work.

EDIT... Did we just disable culling of shadow-casting objects to the light source's stationary frustum? I think we probably did! Which might greatly slow down rendering for no gain. I'm going to have to hack deeper into the game's code and see if I can get it to cull shadows but not things outside the player's FOV.

cegli
Honored Guest
"2EyeGuy" wrote:
I try to do my layer removal/adjustment when the projection matrix changes, which is about 15 times per frame. It is good for games like Metroid when I want to hardcode recognition of the helmet or HUD and attach them to your face in just the right way. For example I can easily remove that Samus in the corner with no reduction in speed. But...

Hmm... Yeah I was looking at this code briefly yesterday. I'm going to check to see if it makes sense to move my code to this section once I review it further.

"2EyeGuy" wrote:
The problem seems to be that the screen clearing isn't working.

I was actually looking into this bug last night! It's messing with the Opcode Replay Buffer and making it flicker, and it also probably causes corruption in some games. I've been able to use my layer removal to remove everything from the scene to make it easy to use the graphics analyzer. I've narrowed it down to the exact draw call (with related settings) that cause it. Once I have a bit of time, I hope it won't be too hard to fix.

"2EyeGuy" wrote:
BTW, Opening the graphics menu does two things... reloads the settings from the graphics INI file, overriding whatever per-game settings were in the game's INI file. And it resets the stereo mode to Oculus if your Rift was detected.

Good to know. Maybe that will help me track it down.

2EyeGuy
Adventurer
"cegli" wrote:

"2EyeGuy" wrote:
The problem seems to be that the screen clearing isn't working.

I was actually looking into this bug last night! It's messing with the Opcode Replay Buffer and making it flicker, and it also probably causes corruption in some games. I've been able to use my layer removal to remove everything from the scene to make it easy to use the graphics analyzer. I've narrowed it down to the exact draw call (with related settings) that cause it. Once I have a bit of time, I hope it won't be too hard to fix.

I'm not sure what you mean.

cegli
Honored Guest
"2EyeGuy" wrote:
"cegli" wrote:

"2EyeGuy" wrote:
The problem seems to be that the screen clearing isn't working.

I was actually looking into this bug last night! It's messing with the Opcode Replay Buffer and making it flicker, and it also probably causes corruption in some games. I've been able to use my layer removal to remove everything from the scene to make it easy to use the graphics analyzer. I've narrowed it down to the exact draw call (with related settings) that cause it. Once I have a bit of time, I hope it won't be too hard to fix.

I'm not sure what you mean.


It was just isolated to my Opcode Replay Buffer, and I've fixed it now! The thing that confused me was that sometimes the first draw call (the clear draw call) actually "clears" the screen to a color besides black. I was analyzing a frame where the clear draw call made an odd white square in the middle of the screen, plus swirling colors on the side. I thought the clearing wasn't working correctly. It turns out that the GG/Wii programs the BPMEM_CLEAR_AR and BPMEM_CLEAR_GB register with various colors depending on the situation. For instance, the menu of Smash Bros. Brawl clears to a white screen. Might be obvious if you've been working with the rendering a lot, but I'm still learning all the inner workings of the GC/Wii.

Anyway, I've matched the Opcode Replay Buffer to work the same way, and now most of the corruption is gone in D3D and OpenGL! I'm still testing it now, but I'll check in the changes soon. Now if I could just fix the random "Unknown Opcode" errors in certain scenes we'd be set :).

shinyquagsire23
Explorer
So I decided to boot into my Windows partition and try this, holy crap Animal Crossing is amazing. Haven't got the chance to test Metroid Prime as of yet, but I'll probably do that later.

The one thing that's bugging me though is the culling, but I happen to also be fairly decent at ASM hacking (although for GBA). Because this happened to bug me enough, I've already set up an IDB for Animal Crossing and I'm looking for the culling code. Luckily Animal Crossing has two .maps so I have fully labeled code now, and I've managed to remove culling on all 2D/pseudo-3D objects like trees, weeds, flowers, etc. Although since their renderer is split by seasons (of all things...) this fix only works in winter (or rather, on items specifically rendered with winter decorations in mind). And I believe it also will probably bork up the talking culling, since each season is also split between what to render while talking and what to render while walking. Although for VR it might be worthwhile to remove the talking camera stuff since it messes with the camera a bit.

And since pics are nice, here's a comparison of before and after removing the culling checks I found so far.

Before:


After:


So far this fix doesn't seem to account for fruit trees, buildings, people, and (again) other seasons. But if you want to apply the fix manually, you can patch memory offset 804CC3EC with 9bdc0046. I'll probably make an AR/Gecko code later after I find all the culling checks and fix them. The best part about this though is that since this game was designed to run on the N64, and the amount of vertices rendered is already so minimal, there's absolutely no negative performance impact. Most of the frequently-draw-in-numbers objects are just 2D billboards anyhow so it's not too hard to draw things. Although the one thing that's been getting in my way so far is clipping planes (I think these are removed in VR anyhow) and the fact that sometimes the game decides to not even draw neighboring "boxes" at all. So it's obviously still a work in progress, but very exciting!

EDIT: Managed to disable cull checks on actors (buildings, people, etc) as well. However, this doesn't fix the issue of other nearby "squares" not rendering. This code isn't season-specific, so you only have the one offset to patch. No significant performance hits yet, but the FPS seems to have dropped from what it was before I had it set to render with culling. However, this might just be my GPU telling me to get an upgrade.

As you can see above, the train station now renders from a relatively farther distance, and the post office is visible as well. For this one, you just need to nop out 80374B58 with a 60000000. It also seems that this doesn't force 100% of all objects to render in the surrounding squares, it only prevents culling checks on them. So if the game decides not to even bother rendering the stuff in the surrounding blocks you're kinda out of luck getting those. That'll probably come once I figure out how to force a majority of the blocks to render.

2EyeGuy
Adventurer
Very nice work on Animal Crossing. I'll have to give it a try.
I haven't implemented a way of adjusting the near and far clipping planes yet, because I have some strange issues trying to extract the values from the projection matrix. But my work on the single-pass Stereoscopic 3D has given me better insight into how the projection matrix works, so maybe I'll give it another go.
I also want to try implementing depth clamping in OpenGL.

cegli
Honored Guest
"shinyquagsire23" wrote:
EDIT: Managed to disable cull checks on actors (buildings, people, etc) as well. However, this doesn't fix the issue of other nearby "squares" not rendering. This code isn't season-specific, so you only have the one offset to patch. No significant performance hits yet, but the FPS seems to have dropped from what it was before I had it set to render with culling. However, this might just be my GPU telling me to get an upgrade.

Awesome work! Looking forward to AR codes for this one once you've finished! Even the state you've gotten it to looks way better than before. I peeked at the .map file for this one for a little bit, but didn't spend much time looking for the codes.

I've spent a long time yesterday and today working on the Opcode Replay Buffer. I think I've finally fixed all the frame clearing bugs, which means all the weird solid color strobing and flashing is gone now. I also fixed the audio in Synchronous GPU mode, which works really well with the Smash Bros. series.

Every bug so far has been hard fought though... It's really a struggle to debug this thing. I hope there aren't too many more bugs in it, but it's always hard to say how many there are until they're all fixed! Some games are starting to become stable though. Some that I've tested:

Working really well at normal game speed with 75fps head-tracking:
1. Smash Bros Melee with GPU Synchronization checked, frame-limiter at 60fps works wonderfully.
2. Smash Bros Brawl with GPU Synchronization checked, frame-limiter at 60fps works great as well.
3. Wind Waker seems to be working perfectly, though I've only ran around the first area for about 10 minutes.
4. Both Mario Karts seem to be working well.
5. Pikmin works butter smooth with it enabled.
6. Animal Crossing.
7. Kirby's Epic Yarn.
8. Zelda: OoT
9. Bomberman Generation
10. Sin and Punishment: Star Successor

Games that have issues:
1. Okami (tons of opcode desyncs)
2. Metroid 1 (some random flickering/corruption)
3. Super Mario Sunshine (works if you enable it once you're in game, otherwise locks up).
4. Super Mario Galaxy 1 - Random Stuttering. Works perfectly with 60->75fps timewarp though!
5. F Zero GX (opcode desyncs)

So it seems about 2/3rds of games are working with it now (from a random sample of 15). I think it's getting close to time to make a new release!

shinyquagsire23
Explorer
So while I was trying to fix some more culling issues in Animal Crossing I ran into Resetti for the 50th time and I just remembered that this was apparently a thing:


I'm not sure if it just sets the camera to a static position or if it actually adjusts properly for the player, but it's definitely interesting. I'm actually curious if I can utilize this for VR as well.

I also encountered some weird bugs with my previous culling code; Apparently the game has a certain limit to how many actors it has up at once, and after a certain point it just doesn't render or even process certain actors (except for their collision boxes). So some houses, on a few occasions, actually just disappeared leaving their collision box. I'm hoping it's just a malloc issue and I can just force it to allocate a bit more memory for that and have it all fine and good, but we'll see.

Example of said invisibility: