..:: PCSX2 Forums ::..

All of those are awesome guys! I just found this thread yesterday and I am simply amazed
Keep up the good work. Definitely keeping watch for Crash/Croc/Spyro and Medal of Honor games.

Cool! Can anyone help with Tomba 2, US ver preferable. No matter what I tried, no luck

Did anyone tried The Legend of Dragoon ? I really want to replay that game and it would be awesome with a widescreen fix.

Edit: Never mind, i don't know i missed it the first time...

Thank you very much for all your hardwork.

I've been trying to understand what is the idea behind the "1000" value and the "1999". These selections are not random and I think I start to understand what these are.

Since PS1 does nothing in float, technicaly this renders some stuff rather imposible to achieve without big inaccuracies. For example, the values that store the fov should always be float values, it just can't be anything else. Since PS1 does not use floats it still has to "fake" them someway in order to calculate values that are floating point without truncating everything. What I understand is that PS1 tries to store a float value with a small range at some slight cost of accuracy with some tiny help of rounding.

It seems like devs tried to find a value that when you subtract 1 and then divide it with (as many integers as possible?) 2 , 3 , 4 , 5 , 7 , 8 and 9 you would recieve an integer and when you don't, leave it as is (without subtracting 1), retry, and then you would and it would work, leaving the smallest error possible. Let's see what I mean with an example.

1000 represents the number 4096:

(4096 - 1) / 2 = no integer retry - 4096 / 2 =2048
(4096 - 1) / 3 = 1365
(4096 - 1) / 4 = no integer retry - 4096 / 4 =1024 <- 1024 in dec = 0400 in hex which results into Eyefinity
(4096 - 1) / 5 = 819
(4096 - 1) / 7 = 585
(4096 - 1) / 8 = no integer retry - 4096 / 8 =512
(4096 - 1) / 9 = 455

So in the case of widescreen that we need to multiply with 0.75

(4096 - 1) * 0,75 = no integer retry - 4096 * 0,75 =3072 <- 3072 in dec = 0C00 in hex

So logically:

1000 in hex is 1.0 as float for PS1
0C00 in hex is 0.75 as float for PS1
0400 in hex is 0.25 as float for PS1

So the values that don't subdivide/multiply perfectly into an integer the emulator kinda "knows" what values is actually there with such a slight inaccuracy that it doesn't matter.

Very clever precision trick. I wonder if that could be used for subpixel calculation too.

And asking from my ignorance, for what be useful if this can be used for subpixel calculation too?

What would be ideal if someday we can have a method for encounter the values in the ELF files only, which
can offer also te possibility to use the hexadecimal values, because the ones we have now are all mainly
values in memory, and values in memory causes a lot of problems in various games which i encountered.

For example i encountered a value that works in the first Tombi game, but only works using it in the Cheat Engine,
Not works in epsxe at all although you use a savestate, and not works in other emu.

For the first Medievil i encountered one that works in epsxe but not for other emulators.
For Medievil 2 in epsxe the value causes a freeze in the loading screens, only works using a savestate.

And encountered values for other games that they work fine in epsxe but for other emus causes
serious graphic glitches or strange hangs.

I don't tried this games using physical discs but probably happens all this same problems playing from disc,
after a lot of work searching the correct value on the games for having this poor results
is so very frustrating and disappointing...

Best regards.

I merely pointed out that PS1 tries to store float point values with somekind of single precision method (with slight accuracy penalty) which kinda contradicts what we've known for PS1 till today.
1999 is another value that follows the same idea. This helps us find what other possible values we can add to the list of our search (if they follow the same rule, most possibly they are pseudo float values aswell). An emulator with a realtime debugger would possibly help me alot (I'm starting to get familiar with MIPS).

I see, well, thank you for your steps, the psxfin emulator have a debugger maybe can help or not, keep the good work.

Best regards.

UmJammer Lammy  NTSC U. (SCUS_944.48) 









Thanks VIRGIN KLM for pointing me to this thread

(11-21-2015, 08:36 PM)Esppiral Wrote: [ -> ]UmJammer Lammy  NTSC U. (SCUS_944.48) 

Code:

801C4B28 0C00

Thanks VIRGIN KLM for pointing me to this thread

Glad to see you here! Thanx for your work! I hope you can help us a bit here!

(07-16-2014, 04:41 AM)PsxFan107 Wrote: [ -> ]Making an ISO patch is slightly complicated but not too difficult. It also requires use of a debugger.

Here's an example with pac-man world:

First I get into gameplay



Next, I open psxfin's debugger (Debug>Monitor>R3000) and set a "Write" breakpoint on 80150FF0 (Widescreen value).



Now, I go back to the game and switch from normal tv to widescreen tv. This causes the game to freeze because the debugger is halting execution of the game's programming to show me what is writing to the address that holds the widescreen value.

I had to press F9 after it initially snapped because it didn't put me in the right spot. This is where I landed:



The 0x0E00 at address 800245d8 should look familiar. That is because this is where the widescreen value is stored. All we must do now is open the iso in a hex editor and look for 00 0e 03 24 (It will be the 3rd result). Then replace the "e" with a "c" and now the value will be patched into the iso.

Wow thank you! I have patched Um jammer lammy's iso