Fixes eyes rendering in Jak games both ingame and in cutscenes.
Previous method yielded no eyes in Jak 2/3/X cutscenes.
- Generalized offset search logic with caching system (works for BW > 1
and any PSM, limited to PSMCT32 for now)
- CRC Flags mechanism for default behavior enabling in Jak games
Fixes eyes blinking in Jak games with tex in rt search
enabled.
- Target TEX0 in Source is Source TEX0 if the Source is
not build from Target, otherwise it is the Target TEX0,
allowing improved Source invalidation
Add XgKickHack gamefix for Dog of Bay., fixes corrupt textures. Issue
#3041
Add some crc ids. Big Mutha JP version(Bakusou Convoy Densetsu - Otoko
Hanamichi America Roman),
Jak X Public Beta v.1 US, Sly 3 EU Prototype.
Developed a new SW sprite render function, which is used to fix
Jak and Daxter colors in Jak games and to remove the old Jak games hack
which yielded wrong colors and clashed with TC search texture in RT function.
- Remove OO_JakGames hack for palette readback from framebuffer (slow,
clashes with texture in RT TC function, clashes with Target readback logic)
- Developed new method SwSpriteRender with CPU rendering logic
- Add OI_JakGames method using SwSpriteRender for CPU palette rendering (fast,
does not clash with texture in RT TC function, no readback required)
Bonus: fps also sees an improvement in Jak games 3-5 increase.
It will allow to render the shadows properly.
Rendering pattern is:
Save RG channel with a kind of a TS (replaced by a copy in this hack),
compute shadow in RG,
save result in alpha with a TS,
Restore RG channel that we previously copied to render shadows.
Seems like Texture shuffle/depth is not handled properly in all cases so
revert the change until we fix it properly. Move it to gl level too.
Commit:
11cd6b56cd
With the sprite hack removed it was no longer possible to toggle this
hack on nvidia gpus, the toggle has been moved to Disable Safe Features.
It some issues caused by the hack in sotc, fatal frame and border offset
issues.
The adapter ID was needed to be passed before for a legacy DX9 hack which is no longer present, I figured it could cause a potential conflict when the adapter value stored at INI is outdated. (which is now a possibility after
lightning removed reference device)
The other alternative would be to just force set the INI value on dialog initialization to avoid unavailable values in the INI file, but that would be a rough for a person transitioning from debug build to release build using the reference device
option, so just removing this outdated variable for now, I rather doubt we'd be needing it in the future, in case we need adapter passing to subdialogs, the former suggestion needs to be implemented. Not implementing it right now since there's no need for it.
lightningterror