Ok then. See you in February I guess, I’ll do some more tests with other games in the meantime
Alright, better late than never. Missed 0.5.1 by about 2 weeks… everything because I didn’t check the blog…
Oh well, unfortunately I’m coming with bad news for old3ds users…
I’ve been testing the latest build as Ghabry stated to do in EasyRPG’s Gbatemp thread and I’m afraid to say that the performance is bad if using an old3ds. Framerate is pretty unstable in most of situations and the player managed to crash several times running out of memory, whether using the homebrew launcher version or the cia one. Did tests with games that supported midi music as well, and the truth is that it works, but performance makes the audio cut briefly, loop sound effects and accumulate sound playbacks up to when the player manages to play them all together. One point to mention though, Ghabry stated that if using an old3ds audio pitch wouldn’t take place, but I noticed that audio still pitches in some instances. In any case, besides the audio pitch I seem to notice that there’s something else that causes framedrops: battle animations. These are the most common reason for Standstill Girl to crash for instance.
As a minor detail, I noticed a graphic issue in Wadanohara and the Great Blue Sea’s intro cutscene when the Sea Witch gets a panoramic scrolling from bottom to top. The rightmost pixel line of the screen shows incorrectly.
Unfortunately there’s a specific point in the game where the player runs out of memory and thus makes it unplayable without exporting saves from other ports. This moment is right before the game begins, after the screen displaying the title and the ocarina.
Not gonna lie, I don’t blame you if you choose not to fix these issues as they may not be present when testing on New3DS, but whether this happens or not I will keep testing
1 Like
tl;dr: You have to wait until August, when I have access to a 3DS again. Have basicly no hardware at all at my current location besides my Laptop. 
Thanks for the feedback. When I have a 3DS again will try to find the reason for the bad performance. I already observed in January that the performance regressed a bit. I was e.g. unable to reach 60 FPS (which worked before).
Right, the audio does actually pitch: For SEs due to how they are handled (they are decoded once and kept in memory) compared to BGMs which are streamed (to clarify: BGMs are not pitched on old3ds). That SEs play all at once or cause BGM issues makes no sense either because BGM runs independend of SE (I think the problem is here that both BGM and SE (while decoding) read from the SD card at the same time and that’s too much for the slow SD card interface of the 3DS)
BattleAnimations were already a problem on the Wii afaik, maybe we should really investigate whats wrong with them :o
This out of memory problem was also one thing we tried to solve but always when increasing the heap (the space in memory where stuff is allocated) it worked in Citra but crashed on hardware :/. We also have something else planned to reduce memory usage in general, but this isn’t ready yet ^^.
Btw is the data abort when closing the CIA is gone? We had a double free in our code (deleted a texture twice).
I never got the data abort issue when closing the cia version, but if you say it’s fixed I guess it is 
Noticed that you can use Select to reset the game now, that’s cool.
Well, see you around
In theory this version should give a slightly higher framerate and should reduce MIDI stuttering:
https://easyrpg.org/downloads/tmp/easyrpg-player-3dsx-test.zip
But actually I assume that it will run worse or result in a data abort because I use an ugly trick that probably doesn’t work on real hardware
Tested it, as you said, yes, framerate is a little better, plus kinda more stable. I actually didn’t have any issues with background midi playback; the screen doesn’t display properly but midi music plays as intended. However, this only seems to apply to midi songs, the other formats don’t work as intended, which are the ones that get looped, cut and so on.
Crashes still occur sadly, but the overall performance looks more stable imo (it still has a long road ahead but it’s pretty more stable compared to the continuous builds I tested yesterday). Guess the stable performance had a price for it though, as graphic issues seemed to increase.
Anyway, that’s mostly it. Overall it’s a little better than the continuous builds imo
Could you explain “screen doesnt show properly” more? Have a picture for me with examples? As said I only have Citra and there it looks fine. And i’m surprised it didnt crash. 
Oh I thought midis play badly, okay will try to check this.
I also experienced some stuttering when playing BGM + SE at the same time.
The screen has small details when rendering. The 1 pixel line detail happening in WATGBS I mentioned about the continuous builds seemed to spread to every test when testing the .3dsx you linked. The screen wouldn’t move properly, like, the stuff that gets moved whether it’s a frame or the whole screen it looks like resizing for a frame, moving, then resizing back after the movement. What I noticed the most in the .3dsx you linked was that the fps counter which I keep enabled most of the time, seemed to go darker at times, also the numbers would get overlapped when the framerate was low. And don’t get me wrong, it crashed, got the red screen with instructions, although in the 3ds port causes it forces the user to restart the console.
Added to this, there’s this triangle that seems to desynchronize when the player has issues to draw the screen (mostly at framedrops), which is prefectly noticeable the moment the 3ds runs out of memory and the triangle gets caught drawing something different (image cropped with Ps) : 
Here’s a show of the pixel line issue, when the movement starts (it pans from bottom to top) :
But when it’s done…
In case you’re wondering, no, it still remains when stretching the screen with R or resetting the size
The pixel line is the rightmost one, I will check if this is reproducable in Citra.
I’m aware of this triangle flickering and I have no idea yet how to fix it. This happens since sf2dlib uses Citro3d for rendering. Older versions of sf2dlib didn’t expose this issue (and this is only reproducable on hardware which makes it hard to debug)
Guys, I have some temporal bad news as things go. It seems that the new implementation of the latest custom firmware loading system known as boot9strap has brought some problems. The latest version of the custom firmware used for the system implemented 3dsx homebrew loading as a feature, which broke one of the requirements EasyRPG needs in order to boot through the Homebrew Launcher: target selecting. It’s impossible to use homebrew applications that require target selecting on the latest version of Luma3DS at the moment, which sadly as it states of today, is the only cfw supported on end-user consoles by the latest implementation of boot9strap (v1.2 as of today). When trying to use EasyRPG through the new system, it prompts a message telling that target selecting is not supported and it tells to use another exploit; however, trying to use another exploit simply doesn’t load the HBL at all, and trying to use the old homebrew launcher crashes the console when selecting any application that requires target selecting.
So for now, I’m afraid that the only possible way to launch EasyRPG on 3ds is through the cia application or custom built cia games. Hopefully this will get fixed in the future as it breaks other things as well
Really great
In the github releases is a point about “3dsx loading”: https://github.com/AuroraWright/Luma3DS/releases
Probably won’t have time to investigate this before my summer break. Will take a look in August.
Question is do we still need target selecting when launched from Luma3DS?
I would assume it allows to use the whole memory.
As far as I could see in other places it’s said that userland homebrew doesn’t make use of all the avaliable memory even with target selecting, as well as this memory not being all the avaliable memory in the chip at least on o3DS, yet it seems that now that Rosalina is out homebrew gets full ARM11 access which I don’t know if it has something to do with memory avaliability, but it was mentioned as one of the reasons for Rosalina devs to remove target selecting support, aside from considering it “obsolete”.
Anyway, I myself don’t know the true purpose for target selecting on homebrew applications that don’t get involved with the title used for targeting (like save managers, secondary entrypoint exploit installers or HANS/regionFOUR), nor if any issues appear with EasyRPG if not using target selecting; but if the implementations of Rosalina actually help EasyRPG in a way that it doesn’t require target selecting anymore, I’d say that you should remove it. However there’s something that happened recently (and reminded me that I’m mad at people behind Rosalina because of this), which is that payloads for userland homebrew loading on o3DSs with firmware 11.4/11.5 got released along with a primary entrypoint (which uses RPG Maker Player lol, must be some kind of wink towards you :P). This means that if you manage to remove target selecting from EasyRPG, people without cfw would have the issues that made EasyRPG need target selecting to work on non-cfw consoles (assuming there are any?).
Oh well, for now I can confirm that EasyRPG should boot with the new payloads on o3DS v11.5 using the legacy version of Luma3DS which mostly removes the limitation to target selecting. Will try to get someone with a stock 3DS to boot it someday. Later for now
The target selecting is only required because the homebrew channel copies the executable code of EasyRPG in the executable section of the target app because the homebrew channel can’t mark memory as executable, so it just overwrites other executable mem ^^. As a side effect you get access to the savegame data of the target app but we only use this because of memory limits.
So yeah, it’s for systems without custom firmware.
The selection has nothing to do with the available RAM. This can be configured but last time I tried this only worked in Citra and crashed on real hardware 
. But with this we could easily get much more memory (currently the memory is splitted: Half app, Half audio/gpu). Currently we only have around 64 MB, with proper settings around 120 MB. (minus RAM for the system, no idea how much is reserved).
Try deleting the easyrpg-player.xml file. Then target selection is disabled.
Haha yeah I’m aware of this. Really funny 
E.g. this video https://www.youtube.com/watch?v=IpDDvTVoj2o has the description “thanks to rpwng for finally being a 11.5 homebrew”
We had one a few days ago in our chat channel. We figured out that the new homebrew channel (2.0) has some bugs with the target selection. But with the 1.0 version he was able to select Pokemon X (he had no youtube channel installed) as a target and boot easyrpg player 
I still had no time (or motivation?) to “upgrade” from Luma3DS to Bootstrap9/Rosaline. But when this is done I can do some more tests in HBC.
If you’re interested on continue doing tests with HBL make sure not to upgrade to boot9strap 1.2 but boot9strap 1.0 instead (aside from Rosalina, there’s no difference whatsoever…). boot9strap 1.2 came along with Luma3DS 8.0, which has the Rosalina implementation and breaks all homebrew entrypoints. Otherwise, you should install the legacy version of Luma3DS, which is a version forked off from Luma 7.1 which is compatible with b9s 1.2 but doesn’t have the Rosalina implementation, allowing the usage of homebrew entrypoints. Also you might want to have both the starter kit that comes with hax 2.8 and hax 2.9, as hax 2.9 has some issues as I could see