forums.ps2dev.org

[mrbrown]

I've just released rRootage for PSP v1.5. Get it at http://psp.jim.sh/mrbrown/rRootage_PSP-1.5.zip.

Screenshots:



From README.PSP (included in the archive):

[Wraggster]

wow, i thought i was seeing things but Deniska has also ported this game to the PSP and released it yesterday --> http://www.dcemu.co.uk/vbulletin/showthread.php?t=14995

Great work from both of you :)
_________________
Webmaster of http://www.dcemu.co.uk

DCEMU The Worlds Only Homebrew & Gaming Network of Sites.

[mrbrown]

In case folks are wondering, the following is a list of features that my release has that the deniska release doesn't have:

• Graphics are full 32-bit RGBA (deniska's release uses 16-bit color). Compare the screenshots.
• Pause using Start.
• Toggle music using Select.
• The entire screen is supported for gameplay (in deniska's release the ship can't move all the way to the edge of the playfield borders).
• Screenshots using L+R (a bit buggy in this release).
• Minor speed improvements that make it a bit faster overall.

[dot_blank]

[Kojote]

Let me quote something from a big PSP news page regarding THIS release:

[mrbrown]

rRootage for PSP v1.1: Screenshots should now work for 1.0 and 1.5 users. The Home button will pause the game.

[mrbrown]

rRootage for PSP v1.2: Disabled antialiasing; graphics are MUCH improved. Fixed a bug in the way boxes were being drawn.

[mrbrown]

rRootage for PSP v1.3: Tried to make PSPGL's initialization code more compatible with 2.0 PSPs. Hopefully this release works under 2.0. If you had previously tried it on 2.0 and it crashed, you should reinstall rRootage from the v1.3 .zip. Any feedback appreciated.

[tjbrosnan]

Unfortunately version 1.3 didn't work for me under 2.0 using the 0.85 eboot loader. Screen just stayed blank when i tried to load the game, also the eboot loader reported that the game is kernel-mode app.

[StereoMike]

Doesn't work for me either, tried loader v0.7, 0.8 and 0.85. Same problem, blank screen, as above.

[bobcobb]

Hmm, did not work for me either. It says it is a kernel mode app. Damn I really wanted to play this one too.

[mrbrown]

If you are a user experiencing crashes in PSY mode, I need the full text of the line that begins with "psp-addr2line" from the BSOD.

[sjk1]

there you go:

psp-addr2line -e target.elf -f -C 0x8902cfc 0x1952b988 0x8904f10

hope this helps! :-)

[mrbrown]

[mrbrown]

rRootage for PSP v1.4: Fixed the Psyvariar crash bug that happened to 1.50 users. Thanks goes to ReKleSS for helping me track this down on his 1.5. Fixed the GL_LINE_LOOP primitive in immediate mode, graphics are noticeably improved. Added the performance meter used in PSPGL - it can be used for measuring performance and testing optimizations. Added TODO.PSP.

I've also found the location of the crash on 2.0 systems (in v1.3), thanks to jimparis. I don't have a fix for it yet. 2.0 users may still want to give v1.4 a shot as I couldn't find any 2.0 users to test before the release.

Keep the feedback coming.

[Nic]

Sadly 1.4 still crashes on 2.0 using the EBOOT loader.

What line is causing the crash out of interest? If there's anything you'd like tried with the code or test binary i'm sure they'd be many people that would oblige (including myself).

-Nic

[mrbrown]

[dem1980]

hi mrbrown

thank you very much for your work ;-)
i have a psp 2.0 with eboot loader
i have 0.7, 0.8 and 0.85
i have tested your eboot.pbp but i have a black screen again

here is the log :

[mrbrown]

[Nic]

@MrBrown: I got exactly the same log as dem1980. I let the PSP run till it turned itself off after the crash.

Might try debugging this myself. Could be fun :)

Anything else you want trying let me know,
-Nic

[mrbrown]

There's no way it should be crashing within the logging function, because calls to the logging function use atomic writes to log.txt - the file is closed at the end of each call. This suggests that the bigger problem could be coming from the EBOOT loader. It's already been shown that the EBOOT loader leaves the VSH and threads from previously run homebrew in an unknown state - I wonder if there's a timing issue involved from some other thread?

There's a new EBOOT at http://psp.jim.sh/mrbrown/rRootage-EBOOT.zip. This time it will delay 2.5 seconds before attempting to load each XML file. If it crashes within this time and there's nothing logged, then it's something external to rRootage that's causing it to crash.

[Nic]

@MrBrown: Think i'm getting a caching issue or something because the eboot in the zip i'm downloading is the same as the last one. I'll try getting it through a proxy, but if you could give it a different name easily, that would help.

Just got rRootage compiling. Very nice and straightforward :)

-Nic

EDIT:
Even through a proxy I get the same .zip. Timed at 10/13/2005 10:21

[mrbrown]

Ok, I've put it up as http://psp.jim.sh/mrbrown/rRootage-EBOOT-2.zip

[Nic]

Just tried the new zip. Still exactly the same log as posted before.

Guess it may be a problem that needs correcting in eboot loader (if possible) :(

Sorry I don't have better news,

-Nic

[dem1980]

i have tested the new file too
and i have the same log :

[mrbrown]

Yeah, it's a bit disappointing that there's no precise way to pin this down. About the kernel flags, all apps linked against libSDL_main.a will show up as kernel apps, but they don't use anything that the EBOOT loader doesn't already patch out. Other people have tested SDL-based apps using OpenGL and they've worked fine.

[Nic]

MrBrown:
Yes very weird, I've put my own debug logging in to have a look.

in "readBulletMLFiles"
the line "new BulletMLParserTinyXML(fileName)" does return a pointer. It just crashes when trying to assign it ?

So if you do:-
ptr = new BulletMLParserTinyXML(fileName);
logging continues, it's only when you assign it to barragePattern does it crash. I've tried accessing barragePattern by name rather than by "brg[]". Makes no difference (not surprisingly). I've tried creating barragePattern on the heap rather than the stack (Makes no difference, again not surprisingly).

V. Strange...

-Nic

EDIT:
Ok, don't think it's the assignment. Think my debug log wasn't being flushed completely. Looks like it fails in build(). Which makes more sense.

EDIT2:
Ok, This time I think it's in IDPOOL::Init in bulletml
Specifically:
map_.insert(std::make_pair(BulletMLNode::bullet, KeyToID()));
What a fun bit of STL that is :(

Think i'll leave it for tonight

[mrbrown]

The patch I used to do debug logging in libBulletML is here (it applies in the src/ directory). It just uses PSPGL's __pspgl_log() function. You can see I had a call in IDPOOL::Init(), that should just print "enter\n".

HOLY CRAP!!!!!

I know why it's not working now. The EBOOT loader patches out the call to _init(), which is responsible for calling C++ global constructors. The std::map IDPool::map_ is never initialized, which is why map_.insert() crashes the machine.

Now the tricky thing is, SDL has a .init contructor function that sets up exception handling and does other things that would immediately break the app on 2.0. If I had a way to detect if the EBOOT loader was running, then I could fixup SDL to skip over the kernel calls and call _init() manually to initialize any other static classes.

BTW, if you comment out the call to build() in the barrage manager the game will happily load, except that the bosses become ... passive :P.

[Nic]

:) Glad you've figured out what needs doing.

You're right it loads up fine if build() is removed.

Hope you'll be able to release a 2.0 version for us. Or I can keep hacking away at it. But it's nearly midnight so i'm off to bed.

Thanks for this great port. Very much looking forward to playing it in its entirety on v2.0. :)

-Nic

[ector]