Thread Rating:
  • 5 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
No interlacing codes
#31
(08-07-2018, 10:38 AM)asasega Wrote: I have a little bit of free time, you can request games

If you're still available for requests, may I request a No interlace code for Ace Combat Zero: The Belkan War?
Reply

Sponsored links

#32
Id like to know the value of ridge racer v and any other game that you have found deinterlace for if the initial value isnt 64420008
Reply
#33
Very interesting topic, I didn't tink this was possible! I am a longtime lurker but this post finally made me register!

I tried your method on "Crash Bandicoot - the Wrath of Cortex" (NTSC-U 1.01) but to no avail, there is still some weird flickering.
I found 2 values @ 01025a80 and 0025a894 but noping them out did nothing. Maybe the flickering is due to something else entirely?
If you have free time, maybe you can look into it?
Reply
#34
@RadiantYeti, nor time nor access to that game, but I'm sure is the same engine like AC4,5 so code would be similar

@Kooler186 as mentioned in the first post, those values are for games which use the standard sony libraries. If that's not the case the game is using custom routines, so mips assembly language and familiarity with the debugger are required (so there are no universal values to search for). Bellow I will explain the code for crash bandicoot. sometimes the games are using both(sony libraries and custom)

@Mastervoldt bellow I'll try to describe the steps I took with this game, maybe others will find it usefull and try making new codes
Some games have in their code both the sony instructions and custome routines. Sometimes they use both ways, sometimes only the customs, and other time they are using the standard for menus etc and custom for gameplay.
Anyway as you observed this game(crash) contains the standard routines but the game still shakes after disabling them, meaning is using custom routines too.

Disclaimer the things bellow are my speculations, meaning maybe they are correct or maybe wrong or jargons are not correct, ps2devs and emu programmers know better(I'm neither of them)

1. I set an write breakpoint to address 12000090. This is a  special GS register along with 12000070 which tells the ps2 from where to read  the framebuffers. In 98% of the games this will give us a framestep option(because this address is written at every frame in most cases), meaning every time the break occurs the game advanced 1 frame.  You will notice the image jump up and down at consecutive frames.

2. I searched for a 0 value when the image is up, then step a frame and searched for value 1 when the image jumped down. In other games is inverted 1 when up and 0 when down. In other cases you can search for 0 and 8 or viceversa like in the sony routines(daddiu ...8)

3. You will find a few addresses, from trial and error we conclude that address 00641E40 is responsible for the shaking

4. The instrucion @0016A048 is writing this address during gameplay, and instr @0016A054 is writing the same address during loading screen

5. So in the final code we will force these two instruction to always write 0, instead writing alternating 0 and 1

0016A048 AF80E750
0016A054 AF80E750

and that's it, that's the code, you just need to make a pnach from it, which I posted on the first page
Reply
#35
Wow, fantastic work. And thank you for the explanation about the custom routines.
I'm trying out the patch right now and it already feels like a much smoother experience.
Reply
#36
tested Onimusha 2: Samurai's Destiny on real hardware and with patch game looks too pixelated (seems resolution after patch is halfed)
Reply
#37
those patches are only meant to be used with pcsx2 set to Interlacing=None, it doesn't serve any purpose on real hardware
Reply
#38
It looks pixalated because those deinterlacing modes are actually hidding the pixelation(try them on pcsx2 at native resolution)

I wonder if there will be any effect if they are used together with the upscaler in Open PS2 Loader
Reply
#39
(10-27-2018, 10:50 PM)nemesis2000 Wrote: tested Onimusha 2: Samurai's Destiny on real hardware and with patch game looks too pixelated (seems resolution after patch is halfed)
You are right the res is "halved". I put it in quotes because the original res is 240p but becuase of field rendering you perceive 480i normally.
I explained this on the second page where I explained how Gran Turismo 3 works.
There are two type of field rendered games on ps2.
1. backbuffers @ 240p
2. backbuffer @ 480 from which 240p downsampled frames are generated for front buffers.
In both cases the final front buffers are always 240p displayed in field rendering for perceived 480i signal.
Field rendered games works similarly to 480i ntsc signal, in the sense that distinct frames are never full 480 height.
Field rendered games have 240p res distinct frames, but because of the interlacing you perceive 480i res. Frame A 240p displayed on even lines, frame B 240p displayed on odd lines. In the timeline, A is older then B and so on ...
These codes are meant for pcsx2 with the HW renderer where you can crank up the rendering resolution.
Reply
#40
This was probably the biggest problem with PCSX2. Awesome work. Off the top of my head the Fatal Frame/Zero series and The Bouncer were some of the blurriest games at higher res. Going to attempt fixing the NTSC-J versions when I get more free time.

EDIT: Here's Fatal Frame/Zero (NTSC-J). Will try more games another day


Quote:    

   


Attached Files
.pnach   9883194E.pnach (Size: 88 bytes / Downloads: 179)
Reply




Users browsing this thread: 1 Guest(s)