PS2 [Open PS2 Loader] Game Bug Reports

Yes, that's pretty much when the mega-commits happened.

I suppose there is a small bug in there, which makes multiple games incompatible.

Sadly @sp193 doesn't remember all of the changes (hence he didn't do any mega-commits since then), so they need to be tracked down. :-|
 
Sadly @sp193 doesn't remember all of the changes (hence he didn't do any mega-commits since then), so they need to be tracked down. :-|
As much as I would say it isn't the best practice today, it was just once a way of doing things.
Since we cannot possibly remember why all changes exist, it's why Git exists...
I've made hundreds of commits since 2012 - how do you expect me to remember what I changed? If you ever touched code, I'm sure you cannot remember what you coded nearly 10 years ago and have not touched it ever since. That's just being human.
Nearly all my commits have commit messages that detail what was changed. Even if not, the differences are displayed by Git. It's more like, we cannot possibly tell whether each and every commit is surely good and/or why it is a bad change; you know how difficult it is to do proper planning without the design documents that Sony had. And without actual development tools.

I once made large commits because I started learning how to use SVN that way. Cloud space in the 2000s wasn't as cheap as now, so the idea that we could have a lot of commits seemed hard to believe. The knowledge that we can have "unlimited" commits, along with the design of Git eventually encouraged me to split up my commits, as it became easier to track and reverse individual changes.
A set of changes can be grouped together as a set in a pull request, which was also one thing I wanted since the SVN days.

You don't need to go back to the past to fix something in the present. Sometimes, a change was made to address a different problem. Simply reversing a change might not be the answer. Go debug it.
 
You don't need to go back to the past to fix something in the present. Sometimes, a change was made to address a different problem. Simply reversing a change might not be the answer. Go debug it.
While I do agree that proper debugging and fixing would be great, the sad fact of the matter is that the number of active developers that know how to debug games and fix issues right now seem to be quite low.
I would love to learn how to debug a game to help out when I can. But I haven't been able to find a guide on how to start and finding someone to help has the same issue of active devs that know how.

Regression testing is relatively easy for most people to do and even if it doesn't find the real issue it might help someone that do know how to do proper fixes, will it not?

Or are you saying that the exercise of having people go back to previous builds to see if it has ever worked correctly is a waste of time?
I do want to help, but since I don't know how to code (and definitely not C systems programming), debug games nor the inner workings of how the PS2 was built, what would be your suggestion if not doing regression testing?
 
Form:
Title = Ninja Assault
ID = SLUS_20492
Media = CD (Converted from BIN+CUEto .iso using UltraISO)
OPL version = 0.9.3 / Stable r582 / 1767-DB-TA-19884cf /1831-Beta_DB-TA-0c9fb18
Device = HDD
Mode(s) = 1+2/1/2
IGR = Untested
VMC = Untested
Compatible = Yes
MD5 Checksum = 74c0fb5dbd2a941dc85317af24a1638a
Notes = Depending on settings , may either infinitely load or freeze after ~1 second

wKGlTiK.jpg
https://imgur.com/a/EzyyNyo.
 
Last edited by a moderator:
Or are you saying that the exercise of having people go back to previous builds to see if it has ever worked correctly is a waste of time?

Sorry, but you have misunderstood. You see, I had a problem was with what he wrote, specifically:
Sadly @sp193 doesn't remember all of the changes (hence he didn't do any mega-commits since then)
He blamed me for this. I will not take responsibility for a set of commits that were there since about 8 years ago. You know that it's not impossible to know what was changed, since SVN/Git shows you each set of changes. What we don't know, is which change mattered for this particular game - and it's got nothing to do with me not remembering something from 8 years ago. There are multiple ways to solve a problem like this, and as you also said - looking back at the commit history isn't the one and only way for that.

One could say I nitpicked something that wasn't so pleasantly worded, at the wrong time - and that could be true. Even if I am not a very good developer, I felt that it wasn't right to lay blame on somebody else like that.
 
Sorry, but you have misunderstood. You see, I had a problem was with what he wrote, specifically:
My main "issue" was with the "Simply reversing a change might not be the answer. Go debug it."
As if that was simple for the average person to do. But I guess you were making a point and I shouldn't have taken it as literary, sorry.

He blamed me for this. I will not take responsibility for a set of commits that were there since about 8 years ago. You know that it's not impossible to know what was changed, since SVN/Git shows you each set of changes. What we don't know, is which change mattered for this particular game - and it's got nothing to do with me not remembering something from 8 years ago. There are multiple ways to solve a problem like this, and as you also said - looking back at the commit history isn't the one and only way for that.

One could say I nitpicked something that wasn't so pleasantly worded, at the wrong time - and that could be true. Even if I am not a very good developer, I felt that it wasn't right to lay blame on somebody else like that.
I really shouldn't be arguing for TnA as I believe he is perfectly capable of doing so himself. But I do not think he blames you nor do I believe anyone here think of you as "not a very good developer" since much of what is the PS2 scene today wouldn't be what it is without your efforts.
The fact that commits covered multiple changes back then does make bisecting a bit harder, but it is certainly no ones fault. Just a part of legacy development.

BTW, are there no guides or tutorials to debug games without source code or debug symbols? There are issues with games that only manifest if the game is started through OPL, even on PCSX2 which has a built in debugger. But where do one even start?
 
Form:
Title = Ninja Assault
ID = SLUS_20492
Media = CD (Converted from BIN+CUEto .iso using UltraISO)
OPL version = 0.9.3 / Stable r582 / 1767-DB-TA-19884cf /1831-Beta_DB-TA-0c9fb18
Device = HDD
Mode(s) = 1+2/1/2
IGR = Untested
VMC = Untested
Compatible = Yes
MD5 Checksum = 74c0fb5dbd2a941dc85317af24a1638a
Notes = Depending on settings , may either infinitely load or freeze after ~1 second

View attachment 27366
https://imgur.com/a/EzyyNyo.

What do you mean by Stable r582?
OPL 0.9.3 = rev851
0.9.1 = rev644

Did you try mode 6+3 or even 2+3+6.

Can you try different tool to convert from BIN to ISO.
E.g. WinBin2Iso:
https://www.psx-place.com/resources/winbin2iso.671/.

Can you try OPL 1559:
https://github.com/ps2homebrew/Open-PS2-Loader/releases/download/latest/OPNPS2LD.ZIP.

What tool you used to transfer ISO into HDD?

Does your console has got any modchip?
 
Last edited:
Form:
Title = Ninja Assault
ID = SLUS_20492
Media = CD (Converted from BIN+CUEto .iso using UltraISO)
OPL version = 0.9.3 / Stable r582 / 1767-DB-TA-19884cf /1831-Beta_DB-TA-0c9fb18
Device = HDD
Mode(s) = 1+2/1/2
IGR = Untested
VMC = Untested
Compatible = Yes
MD5 Checksum = 74c0fb5dbd2a941dc85317af24a1638a
Notes = Depending on settings , may either infinitely load or freeze after ~1 second

View attachment 27366
https://imgur.com/a/EzyyNyo.

I have this game on HDD since OPL 0.9.3 and never had problems. I didn't need to enable any mode for it.
 
Form:
Title = Ninja Assault
ID = SLUS_20492
Media = CD (Converted from BIN+CUEto .iso using UltraISO)
OPL version = 0.9.3 / Stable r582 / 1767-DB-TA-19884cf /1831-Beta_DB-TA-0c9fb18
Device = HDD
Mode(s) = 1+2/1/2
IGR = Untested
VMC = Untested
Compatible = Yes
MD5 Checksum = 74c0fb5dbd2a941dc85317af24a1638a
Notes = Depending on settings , may either infinitely load or freeze after ~1 second

View attachment 27366
https://imgur.com/a/EzyyNyo.

My bad, I didn't pay attention you have the NTSC version :hopelessness:

I have the PAL game SCES_508.89

Anyway what if you boot the game without any mode and using a 8MB VMC (this is the way I played the PAL version).
I re-checked the game just before with OPL rev. 1319 and 1537, all is fine.

If you can't manage to make the game to work, try the PAL version. It has a PAL/NTSC selector at game's launch.
 
I wish sp193 had more time to polish OPL. He's the best developer this app ever had. Everybody makes mistakes, especially in this field of work, but he fixed a ton of games. Even if there are some regressions, I'm sure it's just minor timing issues which could be fixed relatively fast.

BTW, I recommend using PCSX2 as a debugging help. On the other hand, these games shouldn't be fixed with patches. We should strive for a better CDVD-ROM emulation, so that they work even if they were coded poorly.

BTW2, how do we currently change the speed of OPL for those few games - like Phantasy Star - which need very slow speeds? A normal user won't be compiling some special version of OPL. Is there anything in the GUI to do it?
 
Hello everyone , I'm currently using opl latest build, I'm curious about "The Guy Game" SLUS_210.74, the game often randomly freeze, on both SMB and USB , I try different mode but still freeze most of the times , some help would be appreciated :)
 
Latest version is not telling me anything.
You can get OPL 1562 from here:
https://www.psx-place.com/threads/open-ps2-loader-v0-9-3.13415/page-51#post-255460.

This game is on DVD-9 media:
http://redump.org/disc/21519/.
Recently support for these games was fixed.

What tool you used to get it on USB device (with FAT32 file system)?

You can try USBUtil v2.2 - rev1.0 ("USBUTIL_v2.2_rev1.0_EN (English).7z"):
https://www.psx-place.com/threads/usbutil-by-iseko.19048/.

Did you also try combination of modes (3+6, 2+3+6)?
 
Last edited:
But I guess you were making a point and I shouldn't have taken it as literary, sorry.
There's no harm done.

BTW, are there no guides or tutorials to debug games without source code or debug symbols? There are issues with games that only manifest if the game is started through OPL, even on PCSX2 which has a built in debugger. But where do one even start?
I don't know. But I cannot imagine there being a generic "how to debug" sort of guide.
Maybe it's because the way each game works, is different. Being made by different developers, who have different ideas, development methodologies and access to technologies. The way in which the game doesn't work right, can also vary.

So one would have to understand how the game works (at least the part concerned), why it isn't working and then finally the actual method to solve it.

Some of them are difficult to solve, like those that are experiencing memory corruption - since the source of corruption tends to not be obvious. Even if the code execution flow seems sane, it's difficult to pinpoint the source of corruption since it only occurs during runtime. If it is caused by the hardware, then it's nearly un-debuggable.
 
Trying to debug commercial games for consoles is a sure way to go mad. Many of them work by chance, as a by-product of some bug in the libraries and/or hardware, which was never debugged because it simply passed the Q&A during development.

The sanest way to go about this business is to ensure that the CDVD-ROM emulation is as close to the real thing as possible, especially timing-wise because a lot of these issues come from the fact that data isn't travelling in the exactly same amount of time as it does from real discs.
 
My bad, I didn't pay attention you have the NTSC version :hopelessness:

I have the PAL game SCES_508.89

Anyway what if you boot the game without any mode and using a 8MB VMC (this is the way I played the PAL version).
I re-checked the game just before with OPL rev. 1319 and 1537, all is fine.

If you can't manage to make the game to work, try the PAL version. It has a PAL/NTSC selector at game's launch.
Hey! Sorry for not responding for a bit. Didn't think to try the PAL version, cuz its a lightgun game and i have an NTSC CRT, but i had no idea about the selection at the beginning! Works like a charm! Thanks!
 
@jolek ,,Thank you so much for clarify everything ,, OPL version I'm currently using is "OPL_1831_DB-TA". I think I used to try combination mode 2 , 3 and 6 but still no luck , games always freeze , Freeze happened most of the time when I playing on usb from my external hard drive already fat32 format,and yeah I split the game using usb util v2.2 ,,sometime I usually connecting my external hard drive to my PC then playing the game through SMB , on SMB mode , freeze error still happened but not too often like from usb connected directly to my PS2.
 
Le OPL-093 rev1442 peut-il créer des VMC qu'il peut lui-même relire ??? J'en doute car dès qu'il est nécessaire d'utiliser la VMC (de 8Mo) qu'il vient fraîchement de créer, il répond qu'elle est fragmentée et ceci sur tous les supports qu'il peut gérer (USB, HDD et ETH). Il me faut signaler que uLE gère parfaitement la VMC fraîchement créée par cet OPL093 (lecture / écriture) donc c'est OPL qui a un souci.

Ma question, quelle est la révision de OPL093 qui gère correctement les VMC (création et gestion) ? Une solution ?


In English via Google :

Can the OPL-093 rev1442 create VMCs that it can read back ??? I doubt it because as soon as it is necessary to use the VMC (of 8Mo) that he has just created, he answers that it is fragmented and this on all the media that he can manage (USB, HDD and ETH). I must point out that uLE perfectly manages the VMC freshly created by this OPL093 (read / write) so it is OPL that has a problem.

My question, what is the revision of OPL093 which correctly manages VMC (creation and management)? A solution ?
 
Back
Top