Dreamcast Widescreen Hacks

I've expanded the horizontal area extremely in DOA LE ,and the code posted in this thread does actually expand the area in which the geometry is rendered.

Widescreen hack Nulldc vs Codebreaker code.










So I assume it should be possible to change the clipping area in other games.

 

What yzb37859365 provided sounds like it's the area where the value is initially populated. Based on the code it appears the value is not pulled from anywhere in 1ST_READ.BIN, but rather it is calculated programatically.

0x3F000000 (0.5) is multiplied by something to produce 1.25, (or 0x3fa00000) the value that the address we modify is initialized to. It's probably multiplied by 2.5, but it's not apparent where that 2.5 came from in the code snippet above.

Is there a DC emulator with breakpoints that you used to find that, yzb37859365?

Update: Without knowing where the other value comes from, I decided to patch the 0.5 to 0.4 so that the address we want would end up as 80 instead of A0. As it turns out, that was a bad idea, but the results are very promising.

That code appears to initialize more than just the horizontal scaling of the screen. It seems to be used for vertical too, AND the clipping. After changing it, the aspect was still 4x3 but now suddenly the game was clipping objects in the 4x3 aspect ratio not only on the left and right but also on the top and bottom. This is promising, because I'm hoping that same method is involved with the clipping and we might be able to not only hack the aspect ratio but fix clipping at the same time. I need to figure out what emulator has breakpoints so I can step through the game to find out how it knows when it's processing the horizontal scale.

The clipping we're talking about is done by the game itself, not by the PowerVR. The game has to do it's own logic to decide how much data to send to the PowerVR, so that it doesn't waste time sending things that are off-screen. It's more time consuming to "break" an object apart and only send the visible polygons, so of any part of an object is on-screen it will still send the entire thing.

In the case of Shenmue, they're doing additional work beyond what the SDK is doing to send the least amount of data as possible to the PowerVR to maintain good framerate.


---
Regarding other games, I remembered a forum post by the guy who hacked Widescreen for the PC version of Sonic Adventure. He mentioned that the game actually scales vertically instead of horizontally and required code hacks to do proper widescreen. This might explain why I had issues finding codes for the DC version, and SA2, and Jet Set Radio. For all 3 of those games, the stuff I found all behaved the same way. He has a page here explaining how it works. It seems like a lot of DC games work this way, so it may take a bit longer before we get widescreen codes for those. Once someone does one, similar games should work the same way though.

 

Then we should figure out where it comes from! But I must admit I don't have a nulldc build which I can use to mess in the ram.

It may be easier to patch the IP.BIN to write the right value in ram after loading the bootbin, just before executing it. I'm sure yzb can do that sort of thing if he wants to!

 

I think I found the code for Code Veronica lol




But I don't know how to convert it to a Codebraker compatible code.

 

Just tell us what address you patch in memory to what value.

It's, 02yyyyyy aabbccdd
0x8cyyyyyy is the address in memory (or 0x0cyyyyyy)
ddccbbaa are four bytes to patch, endianess is the reverse of the DC one for CB so it aabbccdd.

 

Since you're using Demul, Dreamcast 8C is 2C in Cheat Engine.

Replace 2C in the memory address you found with 02. The value will be the 4 bytes in memory at that address, but backwards. So if you saw 00 00 A0 43, you want 43A00000.

On a related note, I've been informed that makaron should have a debugger with breakpoints. I'll check that out later today so we can solve the Shenmue patching situation.

 

@S4pph4rad
I use nulldc+OllyICE for debugging, more trouble, I can not debug EMU


@Esppiral
thank you

In the memory address 0x8c329E40 0x8c329E54 ang 0x8c329E68 can be adjusted horizontally and vertically

 

Edit wrong values, update in my latest post.

 

I found a solution. There's a debugger version of Demul 0.49 floating around, that works fine. You need to run demuld and set the CPU type to interpreter for the debugger to appear.
There's a really big problem with it though... all of the floating point registers in the register display are off by one. So the value for FR4 appears in FR3, etc. This confused me a lot until I figured out that was wrong.

Using Demul's debugger, I realized what was actually going on when Shenmue sets the value that I changed to affect the aspect ratio. For some reason, I mistakenly mentioned that 43A00000 was 1.25, but it's not. It's actually 320.0. When the logic executes, it's loading 0x44200000 from memory and multiplying it by 0x3F000000. That happens to actually be 640.0 * 0.5, which results in 320.0 going into the address we change. The code is changing it to 256.0, to basically squeeze everything into the center. For proper 16x9, I should have used 438e38e4, which is 284.44.

So the codes so far actually make the screen slightly wider than it should be.

Anyway, changing the source 640.0 that eventually ends up as 320.0 where we modify into 720 actually has no real effect on the game. It results in a different value ending up in memory, but all of the other aspect ratio calculations depend on that same number so they all change too resulting in 4x3 anyway. If you go through 1ST_READ.BIN and change every single instance of 640.0 into 720.0, it's the same thing. I decided to modify the code that does the 640 * 0.5 multiplication to populate our desired address and just replace the multiplication with code to throw our desired value in there, and that actually wasn't a good idea either. The game ends up in widescreen like we want it to be, but the value is used somewhere after it gets set there which results in the camera being panned further to the right than it should be. I can tell you what to patch to do that, but it's not very useful to see.

In summary, I think the best option for applying the resolution patch directly to 1ST_READ.BUN would be just to tack some code on after the game is done loading to patch the address we already know about. Actually figuring out how the game calculates its aspect ratio is an exercise for someone really into reverse engineering, I don't think I'm going to do it. This also means that auto-patching games for widescreen doesn't seem like it's going to be possible. Searching memory for the data to change is pretty easy, but actually searching 1ST_READ.BIN for logic that populates that memory doesn't seem like something I can automate. Sorry. :-(

I'll start looking at other games to help build the list of games with widescreen codes. Is there a Wiki somewhere that would be a good place for them? It's probably easier than having me update a post somewhere.

 

@S4pph4rad can you upload this demul?
thank you`

 

I got it from here:
http://www.theisozone.com/downloads/dreamcast/emulators/demul-049/
Be careful, the download link had a few malicious ads.

 

Anyone familiar on how to hook into a binary? *wink* @SiZiOUS, *wink* @yzb37859365?

 

I just can't find the horizontal address in many games, I did find the vertical one and other addresses that control the camera position, I am doing some widescreen patches widening the vertical view+moving the camera further, its not perfect but better than 4x3 aspect ratio.

 

I think I've found how to reescale the game horizontally.

 

So let me see if I get this straight.

The DC doesn't output 16:9 not even on VGA.
So what's happening here is that you plug the DC into a widescreen tv, set the TV to strech and makes the FOV bigger? That way the game looks correct on widescreen showing more content?

IF I'm not mistaken that's exactly the same way PS2 do it. If you set widescreen on FFXII you get squeezed characters, set your tv to stretch and you are set. Still the PS2 sends 640x480 (4:3).

Also, if that's the case, you can patch the same games to run on any kind of widescreen, like ultra wide 21:9 monitors. Or triple monitors.



This was done the widescreen hack from jabo's old graphical plugin but the new and very much improved GlideN64 also has this feature.

Back to the DC
Also you guys are getting codebreak codes that can be patched into the ISO or gdi images? Correct me if I'm wrong but aren't those values different from each compression, like ISO hex address would be one and GDI a completely different address?

 

The code path the memory once the game is launched. That has nothing to do with the iso/gdi/bin/cdi for now.
If we manage to hack it well into the binaries directly, then the patch will depend on the format that's being patched, of course.

 

Yes, you are correct. I believe I mentioned in a previous post somewhere, it's anamorphic widescreen like PS2 and Gamecube games.

 

I've patched a few games so far,(soul calibur, blue stinger, the house of the dead 2, doa2, virtua fighter 3, sonic adventure, etc.. and all of them display the extra geometry outside the 4x3 area, no matter how wide you make the horizontal fov, there is no geometry popping, the only exception seems to be Shenmue, so somehow this is something hardcoded in its game engine?

 

Awesome work! Thanks for clearing that out for me.

...But what happens when you try that on 2D games?

I imagine that fighting games like Street Fighter and King of Fighters will not expand the stage which the character may use.

But what about the extra stage that can become visible when doing the ws hack?

The only one I've tried was Killer Instinct Gold for the Nintendo 64 with jabo's plugin and there was garbage outside of the area.

I'm curious if any 2D games would improve from bigger FOV or if that's impossible.

 

@S4pph4rad thank you, but this demul debug Not easy......

@-=FamilyGuy=- how to hook into a binary? ？？