Dragonball Z Budokai Tenkaichi 3 [SLES 54945] (E)
CPU: Intel Core i5 2500K @ 4.3Ghz
GPU: Nvidia Geforce 9800 GTX+
Build Description: PCSX2 1.0.0 Release Pack - Windows
If other please specify: N/A
BIOS Used: Europe v01.70(27/02/2003) Console
EE/VU Clamp modes: Normal/Normal
EE/VU Rounding: Chop/Chop
Gamefixes Used: N/A
Amount of testing done (little/medium/much/completed-game): medium
Works great. Miseru99's trainer adds wide screen support and better aura effects: http://forums.pcsx2.net/Thread-Sparking-...ner-editor
Missing aura effects in HW mode, use SW mode or miseru99's modified GSdx
08-12-2012, 01:37 PM
Ooops. how Could I forgot that.
Yeah! Miseru99 GSdx works better. Why don't the pcsx2 coder implement it. I contacted Miseru99 and he said that he asked rama and then avih but to no avail.
I would love to see it the SVN.
08-12-2012, 01:37 PM
There probably was a reason, they're not evil or something
08-12-2012, 03:38 PM
It's not like I heard a "no":], Rama actually didn't got my message from what I heard(through I had it in sent ones;P), and Avih explained me how to improve it by hiding it in existing hacks, to not cause any slowdowns in the bottleneck area of gsdx which is nice even if it wasn't any measurable slowdown.
Have no clue what it's status now, but gonna add the last patch I made for (actually whole Budokai Tenkaichi series;]) in case anyone wish to look at it or maybe even mess around by himself:
GSdx dbzbt123.7z (Size: 2,11 KB / Downloads: 750)
This one requires both offset hack to be applied manually in upscale, through works as it is on native res.
08-18-2012, 01:10 PM
This patch is changing rendering in a performance critical part of the code and generally bad practice.
We could make it a special compiled build just for this game and attach it here.
08-18-2012, 01:56 PM
If that's the case, then it won't update itself with the New SVN.
08-18-2012, 03:09 PM
I can understand the bad practice, not counting restoring the effects that work fine in native and are removed this change doesn't fix anything(at least in this game - BT2 story mode graphics are broken in current SVN and that's a fact), just moves the stuff to correct place, but is it still, soo bad while it's fully hidden within existing offset hacks?
Nothing of the "bad code" is used nor even checked for without turning on those offset hacks, soo it's kind of like saying those offset hacks shouldn't be there as they aren't soo universal either ~ fixing like one or two series completely in the rest of the games fixing same problems only partially or generating new problems by itself. I cannot really catch that as an argument when everything around is made of workarounds to make picked up games simply look nicer, but I'm also not really into arguing about that.
Not my project, soo I'm not really trying to change any decisions, at least I not know it'll not be added now, instead of waiting for any reply. Thanks for that. If anyone could keep the build in those fixed games threads instead of posting the link somewhere around youtube to avoid breaking the rules(like I do;P) that could be fine as well, at least we could link people to something "more official".
08-19-2012, 04:13 PM
Can you explain how this line is okay to have in GSdx?
It doesn't make sense to me.
Then there's this part which is missing an else condition:
Many rendering calls will have a 0.0 modx/mody. Is that intended?
The CRC parts are fine to change but I don't know if they work without the other hacks.
08-19-2012, 04:48 PM
That check is inside Wild Arms offset Basically it says:
"if game is different than BT2/3 run the code normally",
"if the game is BT2 or BT3, also check the further lines to affect only choosen frame.Blocks",
If you ask me that's not really an important part, this hack works more or less well without it, but Avih noticed slight font missplacement while testing my patch and it was caused by activating Wild Arms offset actually, soo I added that check to limit it only to what must be affected to fix that slight font glitch.
As for the Half Pixel Offset part, the else to that part doesn't need an condition it just runs the default hack when the condition of "game being BT2 or BT3" is not meet and hack is activated - as that's also hidden within existing hack;P and if the game is BT2 or BT3 then it also checks for choosen frames to activate only on them - that's couse that offset hack breaks other stuff when simply activated to everything.
One could ask also why simply not modifying just one of the hacks, that fix was based purely on halfpixeloffset before and even when using it only on choosen parts the higher the internal res was, the more correction had to be applied and the more visible artifacts caused by it were(to an awfull size on x6), when using both hacks the correction actually starts at lower value and get's smaller with higher res making it looks good on all native multiply.