Release Pcsx-Rearmed

[meandu229]

I installed this emulator. Works really perfect for the most part, but I still have few issues with some of the games.
Can you help me figure out what I do wrong, because in compatibility list these games stated as "green = works good".
Okay here's the games:
Metal Gear Solid - just black screen... (I use iso rip from original cd).
Diablo - seems to work fine, but controls just doesn't register, like I press buttons but nothing happens.
I use r7 version with bios.

For metal gear solid for whatever reason I always had a 15-20sec black screen, leave it for a bit it should work , then i just made a save state of the menu

 

[GuchaRU]

mindlord, meandu229, Thank you! I'll try it. Hope it works

 

[skyeyemachine]

Hi Notaz,

First of all, thanks for this release, I've really been enjoying it so far. At one point I was going to post about speed issues in a few games, but then I realised I was two releases behind, and an update resolved my problems quite nicely. You know your stuff.

I have one issue, though, although it may be more of a feature request I guess. I've learned how to use the analog controller setting in the emulator's settings, and for games that support that feature it works well. However, in some games without native joystick support (Armored Core, for instance), there seems to be no way to, for example, configure one of the nubs to emulate the D-pad or other controller buttons, something that would be very handy at times.

In short, if it would be possible to make the joystick axis values visible to the keymapper in the same way that other button presses are, it'd be really appreciated.

EDIT: One other thing I forgot; to get around the above problem I've used an external controller at times, via a USB hub. The system recognises it as a DragonRise type controller. The problem is thus; when I set up the controller initially, everything seems to work fine. However, usually next time I start the emulator (but sometimes things mess up while I'm in the middle of a session too), one of two things will happen;

- The emulator outright crashes, and will continue to crash immediately on future attempts to start it again. This is easily fixed by clearing out any config files holding saved keymap settings for the USB controller.

- The emulator starts, but as soon as I load an image, the controls behave extremely erratically. For instance, the emulator controls no longer respond, so I can't get back into the menu to quit (requiring a restart to escape), and single buttons seem to register multiple inputs when pressed. Again, removing the USB controller configs fixes this.

The above occurs for both system-wide and image-specific configuration saves, and seems to occur regardless of whether I've disconnected the USB controller or not since my last session. Please let me know if you require further info, but I've posted everything I can think of related to the problem.

Thanks again for a great port!

 

[ari64]

I don't have much luck with this. Well it mostly works but the register allocator occasionally allocates the same ARM register for r31 and whatever the delay slot uses. And I have hard time understanding how you did delay slot allocation (pre-alloc and post-alloc?). Maybe it decides r31 is unneeded or something.
Some advice would be helpful.

So the reason that the delay slot evicts the branch instruction's registers, but not vice versa, is because when it allocates registers for the delay slot, it does not distinguish between the case of a taken branch and a not-taken branch. So when analysing the delay slot instruction, it gives the registers used by the following instruction the same priority as the preceeding (branch) instruction. I guess it could be changed so that if an instruction is in the delay slot of an unconditional branch, then it ignores the registers used by following instructions. When allocating registers for the branch instruction itself, it only looks at that and the delay slot, and so gives these registers a high priority.

Optimal register allocation is hard...

 

[notaz]

In short, if it would be possible to make the joystick axis values visible to the keymapper in the same way that other button presses are, it'd be really appreciated.

It would be possible but is it really practical? You don't get feedback from the nubs that you get from a button when you press it. This would add additional complexity to the code (would need a deadzone option too I guess) for something that not many users would ever use (correct my if I'm wrong), and I'd like to avoid maintaining dead code.

EDIT: One other thing I forgot; to get around the above problem I've used an external controller at times, via a USB hub. The system recognises it as a DragonRise type controller. The problem is thus; when I set up the controller initially, everything seems to work fine. However, usually next time I start the emulator (but sometimes things mess up while I'm in the middle of a session too), one of two things will happen;
problem.
...

Never tried external controllers so not surprised they are broken, will check.

Optimal register allocation is hard...

I bet it is. Test results for that hack I did look good so far, so I'm happy with this for now.

To everyone reporting broken games, keep those reports coming. Even if I don't respond I do look at each report.

 

[skyeyemachine]

In short, if it would be possible to make the joystick axis values visible to the keymapper in the same way that other button presses are, it'd be really appreciated.

It would be possible but is it really practical? You don't get feedback from the nubs that you get from a button when you press it. This would add additional complexity to the code (would need a deadzone option too I guess) for something that not many users would ever use (correct my if I'm wrong), and I'd like to avoid maintaining dead code.

Never tried external controllers so not surprised they are broken, will check.

Well, I don't know about other users' control-configuration habits as far as the Pandora goes, so I can't really speak for anyone besides myself at this point.

A thought on implementation, though (at risk of flaunting my own ignorance); what would work for me would be to simply have the maximum/minimum range values for the nubs counted, so for example, X(1.0), X(-1.0), Y(1.0) and Y(-1.0) could be recognised as button presses, and as long as the nub position range stays within something like 0.95-1.0, that would count as the relevant button being 'held down'. A position change outside that range, such as the nub going back towards the rest position (<0.95), would count as a button release.

EDIT: I guess, in thinking about it, that D-pad functionality would be pretty broken in that case (no diagonals, if I understand right you'd need a range more like 0.50-1.0, not sure how sensitivity would work), but you'd know more about it than I. Still, I guess the key point is that I'm more interested in just registering on-hold-off button presses than in having true gradients of joystick values...

Anyway, I of course lack an understanding of what's involved ton a technical level, so that's probably oversimplified, and I respect the fact that there may be substantial work involved on your end. If something like what I propose could be done without generating a ton of excess work for you, I know I'd really appreciate it; if it's a real pain in the ass to do, then I understand. And thanks for looking into external controllers.

Oh, one final thing I forgot to mention in my first post regarding existing features; I noticed that in Megaman Legends 2, analog control is a bit broken; diagonal motions don't work. Moving forward, back, left or right works fine, but for example, if you're moving to the right and then push the nub 45* so you're moving forward, Megaman pauses for an instant before changing direction, rather than transitioning smoothly from moving right to moving forward. The D-pad displays no such problem, by comparison. Not sure if that counts as a 'broken game', but there you go. It's not a big deal, but I did find it odd since analog works fine for other games I've tried so far with built-in support.

Thanks for your consideration.

 

[skyeyemachine]

One last amendment; I realised in looking back over my post that I never really explained the reason why I wanted this feature. If you're going to be the one implementing it, I should at least explain my thinking fully. This is the last I'll bother you with the subject.

Specifically, I've found in a few games in which play often involves many different button inputs in a very short span of time, the shoulder buttons and XYAB buttons don't quite do the trick. Armored Core suffers from this the most, as I can do just about everything except tilt the camera comfortably, and this doesn't sound like a big deal until you realise that this means you basically can't adjust your firing angle upwards or downwards without becoming a sitting duck. Either that or you trade angle tilt for something similarly important, like strafing. Anyway, the best I've been able to come up with short of an external controller is to use either the '0' and 'DEL' or 'O' and 'P' keys for the L2 and R2 buttons, but it's still problematic at best. I figure that with at least the right nub available as another set of thumb-friendly buttons, I can set up a control scheme that overcomes this limitation, at least as well as can be done on Pandora hardware. If that doesn't happen, I guess I'll just make do with external controller support once it's fixed.

 

[gruso]

Mupen64 maps the right nub to C-buttons. The default is not great for the reason Notaz describes - there is no good feedback or accuracy. I moved my C buttons to ABXY, now I use the right nub for one function only: down = B. It's a quick flick of the thumb which seems to suit most games I've tried. Maybe later on I'll map something to right-nub-up too.

I think the trick for mapping digital functions to a nub is to only use one axis, or you end up hitting the wrong things. You could widen the deadzone to compensate, but you increase travel and lose responsiveness.

I would probably use the mapping option if it was there. For single axis use there would be no need for deadzone settings.

 

[skyeyemachine]

Mupen64 maps the right nub to C-buttons. The default is not great for the reason Notaz describes - there is no good feedback or accuracy. I moved my C buttons to ABXY, now I use the right nub for one function only: down = B. It's a quick flick of the thumb which seems to suit most games I've tried. Maybe later on I'll map something to right-nub-up too.

I think the trick for mapping digital functions to a nub is to only use one axis, or you end up hitting the wrong things. You could widen the deadzone to compensate, but you increase travel and lose responsiveness.

I would probably use the mapping option if it was there. For single axis use there would be no need for deadzone settings.

I agree with you in general that it's not precise, and have had the same experience with Mupen64. At the same time, what you describe ("Down = B") is pretty much exactly what I'm looking for at minimum, but I can't even do that much at present due to how the nubs interface with PCSX, which is why I made my posts as I did. (Not that it's Notaz' fault that the game devs for certain titles ignored then-well-established analog support, of course. =P )

Even if I could just get something like "AxisX=L2, AxisY=R2" using single axes as you suggest, that'd probably work better than my best attempts at present, TBH. If that's easier on Notaz, I would be content with that much.

 

[Michoko]

Hi,

Just played this amazing emu again. I tried Castlevania SOTN and even if the emulation is really impressive, I still get some slight stutter during scrollings. Overclocking doesn't seem to change it. It is subtle, but when you see PicoDrive for example, you then know what a silky smooth scrolling is.
I understand that the emu is still under heavy work, but I was wondering what were the recommended settings for best performance right now? Like what kind of GPU plugin is recommended? Is the "old frameskip" a good option for the builtin GPU? I'd like to get the max out of this great emulator.

Thank you for your tips!

 

[Lorkile]

I think on the nubs for controls debate/idea it would be useful in some regards. I'm uncertain how difficult it would be to implement, since deadzones would ideally be customizable.

Still, what comes to mind is that the left nub (all directions) be L2 by default and the right nub be R2 be default. For me this would make it easier to play the (few) games that make use of those controls, but in general I just plan to avoid them until either a solid modification comes out to add in L2/R2 controls or the next gen Panda comes out.

 

[Blue Protoman]

What, is mapping them to the keyboard not an option?

 

[j6cubic]

Does this emulator support memcards? All Google gave me regarding that topic was something ED said dozens of pages ago in this thread (they don't work) and something someone said on the German board (they do work). When I tried to use them I found that only the second card was writable (accessing the first one caused the game to freeze) and when I later restarted the emulator and wanted to load the game neither card was accessible. A diff revealed that no file had been written to, even though the running emulator displayed the blocks I had written to correctly.

Is there something I overlooked? I've created appdata/pscx_rearmed/memcards and put in two freshly-generated Bleem-type card files. Everything was done using an SCPH3000 BIOS as the HLE couldn't handle memcard access at all.

 

[slaeshjag]

r7 has some memcard issues. If the game you want to play cannot save, try r6.

 

[j6cubic]

Ah, good to know. Thanks.

I'll stick with r7, though. As long as I don't want to use another BIOS save states are a decent substitute. (Unless it turns out that save states are incompatible between versions...)

 

[skyeyemachine]

What, is mapping them to the keyboard not an option?

As I did explain in one of my posts on the previous page, yes, that is certainly possible, and I've tried it. The problem is that with some games you need to also be able to press R2/L2 (or some other pair of buttons) with the same response time as L1/R1, [], O, X and /\, and the D-pad. Easily done on a PSX controller, but more challenging on Pandora hardware due to the lack of a second pair of shoulder buttons. Despite my best efforts, mapping even two buttons to keyboard keys reduces response time drastically enough that Armored Core, my example case, is just tolerably playable under most circumstances, and just about unplayable in a few (jumping enemies especially are a nightmare for this reason, but swapping L2/R2 for another pair of buttons introduces similar problems in different ways). I'm not sure how many other games demand controller input of similar diversity and rapidity, and my issue may be quite isolated; I may simply have to make do with an external controller for some games, a point I already acknowledged, but I thought I'd post the idea anyway since I've seen similar functionality in other emulators. Take a look at my other posts for the rest of my thinking if you're still interested.

EDIT: It just occurred to me that another potential way around this problem could be to introduce a macro key that, while pressed, swaps one controller layout for another. Or maybe better, a combination of the two ideas; if the macro toggle were assigned to a nub (either axis, or both), that would double the Pandora's button limit, not including the nubs, although there would of course be some practical usage restrictions in practice. Using a nub to toggle would probably be faster than fumbling for a particular keyboard key (or keys), and would avoid the problem of having to assign one of the other critical keys to the macro switch, such as the shoulder buttons or ABXY buttons.

Anyway, I wouldn't know what's easiest to implement, but there's another idea for you, Notaz...perhaps a macro-based approach would let you take better advantage of the keymapping code already in place?

 

[skyeyemachine]

Does this emulator support memcards? All Google gave me regarding that topic was something ED said dozens of pages ago in this thread (they don't work) and something someone said on the German board (they do work). When I tried to use them I found that only the second card was writable (accessing the first one caused the game to freeze) and when I later restarted the emulator and wanted to load the game neither card was accessible. A diff revealed that no file had been written to, even though the running emulator displayed the blocks I had written to correctly.

Is there something I overlooked? I've created appdata/pscx_rearmed/memcards and put in two freshly-generated Bleem-type card files. Everything was done using an SCPH3000 BIOS as the HLE couldn't handle memcard access at all.

Speaking for myself, I've been using R7 thoroughly and have had no noticeable memcard issues; all the games I've tried seem to save and load from both cards, at least as far as I've tested. I've been using SCPH1001, if that makes a difference. The emulator makes its' own new memory card files when you first try and save a game, if not on first startup (I'd have to check to be sure). Perhaps your memory card files are incompatible, or corrupt?

If anything, beyond what I've already posted, the only ongoing issue I sometimes notice is that the emulator goes into inexplicable minor slowdown, usually after extended play (an hour or two). Restarting the emulator fixes the slowdown. As far as I can recall, this has happened for multiple games.

Oh, I do note though that when I try to run the BIOS, it freezes upon entering the menu. I found this out when I wanted to try and edit my memcard's contents once, and saw no way to do this via the emulator frontend itself.

I'd list all these bug reports in a single post if I could only remember all of them at once...I think that's everything I've seen as far as errors go, though. o.o;

 

[j6cubic]

Huh. Turns out that the files are in a different place than I thought (they're in ./.pcsx/memcards which resolves to appdata/pscx_rearmed/.pscx/memcards) and they're actually there, complete with content. I could've sworn PCSX looked in another place for them before.

However, while I can read and write card 2 just fine, I can only do so if I do so if I have loaded a save state from the same playthrough where I have written to it. Just loading the ISO and trying to load a game puts the game in an infinite loop of trying to read the card and rejecting it. Loading the BIOS shows both memory cards as empty.

I let Dexter (a memcard manager/editor from back when the Derive was in fashion) have a look at it. Card 2 looks just fine (as do the save files on it) but card 1 prompted a warning about "inconsistencies". Since there's nothing on it anyway I just formatted it. Didn't change a thing about not being able to load from the cards without first restoring a save state, though.

PS: I tried it with SCPH1001, SCPH3000 and HLE. No difference except for HLE failing to access the memcards at all.

 

[snurty]

As per my previous comments this is a really impressive emulator.

I did mention the music sometimes had problems. I know I wasn't very specific as I meant to acknowledge how good this was rather than to raise any issues. However I have now deleted the apps data and this seems to have resolved most things. The only sound issues I now experience are:
- F1 97 - the commentary during races get cut off/starts and stops a little randomly
- Dino Crisis 2 - similar things to the voices in the cut scenes which aren't pre-rendered. Things like it stops and starts or cuts off and restarts at the beginning.

I don't think either of these are R7 specific as I am pretty sure I had them under previous versions.

These are tiny issues really and this is really excellent in it's present form.

 

[Schnatterplatsch]

In Final Fantasy 9, in the first battle (against the wannabe dragon), do you get the HP(...) of the player displayed?

I haven't played much more of it, but the statusbar(you know what I mean? This blue box?) didn't appear in game, but did appear on the screenshot of the savestate.