HD Homebrew Project Developement (Old Thread)

[gamecubesuxs]

I don't know what I'm doing wrong here Ive tried 2 games that have been confirmed working (Devil May Cry 2 & Dark Cloud) and I get a black screen upon boot. Ive tried using both the clean MC bins and a dump of my own with no success. Ive saved the bins to hdd0:MCSIOEMU/MemoryCards and am using 1.02 version of the program.

[wardog]

it seems to take about 10 seconds for the game to boot

[romz]

I suspect there is a problem with configuration files. I didn't save configuration to memory card and no games are working for me (I didn't insert a real memory card at all.).

[romz]

Btw, here is a sample configuration file for my version of GUI:

SLUS_211.15,cdrom0:\MODULES\IOPRP300.IMG;1
SLUS_208.27,cdrom0:\SYSTEM\IOPRP270.IMG;1
SLUS_206.78,cdrom0:\IOPRP252.IMG;1
SCES_507.59,cdrom0:\IOP\IOPRP242.IMG;1

[dlanor]

I use ps2link to launch GUI (NapLink can't load it) and I see exception information instead of blank screen.

Oh, I didn't know that the PS2Link drivers could survive the kind of IOP resets performed by the GUI. Then I too will launch it that way for future tests.

Btw, uLaunchElf has the same "feature" and I don't understand why not to support power-off request from "reset" button.

That's just part of an old policy we had to never bend any system vectors or load any extra drivers, unless somehow requested by user operations, or unavoidably needed by the program's basic features (such as for MCMAN). This policy made it possible to have the program working in some different situations with opposite requirements, such as would not have worked if we had installed all possible vectors and device drivers by default. But in the case of the power-off stuff the time may be right to install that one by default, or at least add an option for it in the 'Startup Settings..." configuration menu.

The menu blinks when I move selection among the files in a folder.

Really ? In all the file selections or just in some few of them ?
I didn't notice any such blinking here...

But I do notice some other odd phenomena in the file selectors, appearing to cause corruptions of the drive specifiers, so that mc0: and mc1: are sometimes displayed as mx0: and mx1:, while hdd0: is sometimes displayed as hfd0:, or even hff0: (some font rendition problem ???).


----- snip ----- re: on the need for separate MC images

I didn't try it by myself but I believe it is possible to create a really big virtual memory card, 1GB for example.

I'm sure it can be done, if not with current code then through modifications, but I still think it would be useless. First of all there is little chance that the average game will be able to cope with directories of such nonstandard huge size. That alone would probably ruin compatibility with a lot of games. And then there are the speed issues, as I believe there is a square-law involved in the time consumption for standard MC directory operations, relating mainly to the used size. (It's definitely not just a linear function of size, judging by my combined experience of both 8MB and 32MB cards.)

But more importantly, it would become next to impossible to maintain backups with all game saves for all games in one huge directory or two like that. Remember that game drivers do NOT allow subfolders or even user-chosen names, so there is no way whatever to organize the saves, apart from that of separating them into different MC images, which is why I consider that very important.

AFAIK, pfs partitions allow to use symlinks (I didn't try to use that feature by myself.) so the GUI could link the selected files to "/MemoryCards/memorycard0.bin" and "/MemoryCards/memorycard1.bin". I believe it can solve some problems.

Yes, I agree, and it would tie in very well with the use of symlinks for a later version using a custom partition, like we discussed the other day.

Is it really difficult to create a new 128M PFS partitions to store virtual memory cards and configuration files for game loader ?

Not at all. Creating new user partitions (with "+" prefix) is a standard command in the HddManager of uLE. And once it exists it can be used just as easily as any other, of course.

I believe it's good idea to allow users to select an existing partition to store memory card since they can create a lot of partitions to store MP3s and so on but I am not sure it is reasonable to use an arbitrary folder to store card images. The storing of memory cards in a folder like "/MyFav0riteGirlzNak3dPh0t0z/" looks like a total mess for me.

Sure, but that's not a valid reason to forbid some other user from having such MC images in a user defined partition and folder with a less messy name, such as "hdd0:/+McEmu/Active MC images/", perhaps with a companion folder (never directly used by the program) defined as "hdd0:/+McEmu/Alternate MC images/". I don't see the problem.

The degree of 'messiness' is up to each user and not something we need to interfere with, since it won't affect the functionality of the program one way or another.

Best regards: dlanor

[dlanor]

I finaly found a game which give me same exception, so i'll investigate the problem.
It's WORMS 3D.

Are you saying that the launcher works well with most games for you ?!?
If so, please name a few (preferably RPGs since that's what I mostly have).

As yet I have not seen a single successful launch by the GUI, although the same games launch just fine through the same mcemuloader ELF as embedded in the GUI when that ELF is launched via PS2Link instead of the GUI.


On another note:
Are you sure that no changes to PS2SDK or any other libs are needed (apart from such as I already have for uLE) for proper compilation of this project ?

I ask this because I have been unable to compile a version of the GUI that behaves identically to your precompiled one. The ones I compile always crash before having displayed anything on screen. The last sensible feedback message I've got (when disabling IOP reset) concerned the loading of FONTM.

Note that the mcsioemu and mcemuloader components of this project both compile fine and work well. It is only the GUI I have problems with.

I'll try adding in some more printf calls to pinpoint the crash, but it could help if you can recall any lib changes that may be needed.

Best regards: dlanor

[dlanor]

games working on emulater

devil may cry 2
legacy of kain defiance
yu-gi-oh coliseum
yu-gi-oh duelists of the roses

For me "Legacy of Kain - Defiance" crashes just like all other launch attempts through the new GUI. Only launches made by the separate mcemuloader, launched directly by PS2Link without GUI, work correctly here.

(as for the other games you mention I can't say for sure, since I don't have them)

Best regards: dlanor

[dlanor]

I don't know what I'm doing wrong here Ive tried 2 games that have been confirmed working (Devil May Cry 2 & Dark Cloud) and I get a black screen upon boot. Ive tried using both the clean MC bins and a dump of my own with no success. Ive saved the bins to hdd0:MCSIOEMU/MemoryCards and am using 1.02 version of the program.

I believe the report about "Devil May Cry 2" may have related to the older method for launching the games, without the new GUI.

As for "Dark cloud", which I've made some report on earlier, that report definitely related to the GUI-less launch method. With the GUI that game crashes in exactly the same way as all others I've tried so far. So I rather think it's the GUI itself which somehow crashes the mcemuloader ELF in launching it.

Btw:
In my report on "Dark Cloud" I gave it a 3 on a scale from 0 to 5 for mcemuloader launch compatibility. This means that it launches and plays without any visible problems, but also without any virtual MC functionality. All MC access in this game did reach the physical MCs currently inserted, even when the game was launched by the MC emulator.

Best regards: dlanor

[dlanor]

Btw, here is a sample configuration file for my version of GUI:

SLUS_211.15,cdrom0:\MODULES\IOPRP300.IMG;1
SLUS_208.27,cdrom0:\SYSTEM\IOPRP270.IMG;1
SLUS_206.78,cdrom0:\IOPRP252.IMG;1
SCES_507.59,cdrom0:\IOP\IOPRP242.IMG;1

Does that mean you've modified the program so as to save those settings for each game launched ?

The GUI code by Polo I downloaded (v1.02) does not seem to have such an ability yet. Whenever I launch a game this launch proceeds without any option to save any info, and such saving is not done automatically, so I have no per-game settings at all in my CNF.

Best regards: dlanor

[dlanor]

@Polo35:
Like I said before, my version of the GUI crashes before even having displayed anything, even though it is virtually unchanged from your sources. I've now added lots of printf statements to pinpoint where this happens, so I can now say with certainty that it happens inside the call to "jpgOpenRaw" in the Load_Skin function of the draw.c source file.

Naturally I'm using the "libjpg" version that was patched earlier for uLE, and I assumed that you use the same. That's also indicated by the fact that you have 3 arguments to the "jpgOpenRAW" function, as opposed to the original 2. But some other patch variants also use the same (eg: the myPS2 stuff by ntba2), and I'm not sure if they're fully compatible.

Please confirm exactly which version of the lib you are using, and/or how it was patched.

Best regards: dlanor