The slow part during startup is probably the parsing code of liblcf. It issues tons of “fread” calls. The 3DS probably doesn’t use buffered IO and just passes every request to the service.
Place the TestGame in a subdirectory of the folder where the 3dsx is. This will open the game browser. If the game browser starts fast it is 100% certain a liblcf issue.
About the audio issue: Couldnt figure it out yet, have to test this on real hardware during the weekend to hear something…
But I will quickly try to provide a version of liblcf that has a custom buffer…
If i put the game in a subfolder, easyrpg logo stands for few seconds but then it take a while to load the game browser too (not as much as loading the game for sure). From Game Browser when i select the test game folder it takes a lot of time too to load.
About in game performances, looks like recent changes to implement BGM dropped a bit framerate (now is like 23/24) but i got a slight speedup (to 25) using this setting: github.com/Rinnegatamante/easyr … mat.h#L523
Seems to not have broken the graphic quality (maybe cause N3DS screen is pretty small?). Maybe it should be enabled by default on N3DS build?
EDIT: I’ve also noticed that using this in 3ds_ui seems to patch the alpha problem we had but the game is like in blue scale. I don’t know very much how does it work so maybe you have some idea:
Updated the portlibs with a buffered liblcf which will read in 100 kbyte blocks… instead of many small freads (you will also need to update the lcf headers in your repo, they changed) easy-rpg.org/downloads/easyrpg_ … bs.tar.bz2
The change to ONE is a placebo. It looks like dead code, is not referenced anywhere. Pixel_format.h is black magic invented by a dev who is not working on the project anymore…
Conerning software rendering we already use the fastest lib available (Pixman)
The DynamicFormat you specify must match the framebuffer the bitmap is copied to (or in that case what sf2dlib expects, no idea what that is).
In your code you define it as “ARGB” because the argument order is R, G, B, A and the 0xFF00000 stands for the first byte, 0x00FF0000 for the 2nd and so on. You could also try other combinations like RGBA (0xFF000000, 0x00FF0000, 0x0000FF00, 0x000000FF).
Just found a way to save lots of CPU time on my Windows PC (~10% according to the profiler). Function BaseUi::AddBackground. Change the Fill to FastFill and add the following Code to bitmap.cpp (and func name to .h of course):
You can’t noop the AddBackground because it’s required by games with transparent chipsets (Yume Nikki). But I have another idea to save additional ~3% of processing time. Will provide the code during the Weekend.
What does addbackground do? Just add a background under the render scene? If so, i can just change the color of clear screen of sf2d to the desired color i think.
Hm, yeah. It just draws the background in the desired color. Correct.
Wow, the Profiler of Visual Studio didn’t lie when he said 10%… 25 to 32 FPS, impressive (with the new code it went down to 1.2% for me). We reached the “Enjoyable” state now. Is above 30 FPS. (though on more complex scenes it will go below).
So you can also overload AddBackground in 3dsui and use sf2d for it ^^ (which should be even faster ;)). But sf2d will also color the left and right border I assume?
But maybe this looks nice… because that’s the system graphics background. So in the menu it will extend to the outside then
EDIT:
The hardcore performance test si btw blending operations which modify the whole screen.
Talk with the guy next to the bridge (on the other side, not on the island), he says “Map Events”. Then talk with the 2nd person (blue hair girl) in the 5th row from the bottom. She will say “Screen Tone”. Now just talk with the different people. They will do different changes to the screen :). Though with broken alpha this will probably break the game fully
Atm the screen tone seems to break the game (for example talking with the guy in 2nd row 1st column make the whole screen grey until i press B to open the menu). (I’ve not tried with sf2d_clearscreen yet. )
EDIT: Using sf2d_clearscreen instead of AddBackground made FPS from 32 to 33/34 but Alpha problem is still here.
EDIT: I’ve also moved the sf2d texture to VRAM, resulting in another frameboost (33/34 -> 36/37) even if it seems to cause some stuttering. I’ll probably revert to linear heap.
Okay the Tone has then same problem as the other alpha…
Is it possible to do the Tiling and the screen blit in one step?
I mean the UpdateDisplay is “fill_texture_from_RGBA8” which causes a CPU-GPU roundtrip and then the texture is drawn to screen via draw_texture. No idea how the 3DS GPU is designed but this sounds like wasted time because the tiled texture is copied back once. Is it possible to skip the intermediate GPU-CPU-GPU step so that the tiled texture is directly written to the display?
Direct framebuffer drawing is possible but there is a little problem, 3DS screens are first of all RGB (so 24bpp) and secondary they are rotated by 90° degrees (like if screens are 240x400 and 240x320).
Ah okay. I have further ideas how to make the software renderer faster. I’m expecting at least 40 FPS on the map :D.
But I will need a while to write and test this.
I’ve pushed the fastfill update so it now uses sf2d_clearscreen. Yesterday, when i was on train returning home for easter holiday, i’ve also wrote a basic skeleton for OGG music support (theoretically it should work but sometimes it should generate some noise due to how libogg decodes pcm blocks but it seems to not work at all (quite sure secondary thread crashes since BGM is not updated at all) and i’ve also made syntax a bit more simple.)
EDIT2: Speaking about performance tips, is it possible to pass to pixman custom draw/get pixel funcs? (i’m assuming pixman works drawing pixel per pixel)
Also BGM::OnPlayedOnce and BGM::Pitch what should do?
Pixman does the same…
Though you will probably not beat Pixmans OP_SRC or OP_OVER. Pixman is the fastest opensource software rendering library available. It uses highly optimized code (ARM NEON SIMD assembler code in the case of 3DS) and your solution will be probably slower.
So if you really want to do it faster you must ask the GPU. The raw pixel data is “bitmap”
I also made tests about OP_SRC vs. OP_OVER. OVER is ~0.1% slower then SRC so replacing this does not give any speedup at all.
Blending is super slow (HARD_LIGHT) and we know that this is a problem. But usually the systems are fast enough to handle this :/.
And your FastFill implementation for the 3DS is incorrect because you don’t “clear” the bitmap (see the pixman version)
Yep, in my local repository i’ve already reverted the clear thing with FastFill since it’s basically impossible to use it in that way.
If pixman could take custom functions, it could be used with sf2d_set_pixel / sf2d_get_pixel or even with some custom drawing funcs to write directly on framebuffers (like these used by lpp-3ds: github.com/Rinnegatamante/lpp-3 … #L285-L307
But you can get access to the raw pixel data (function pixels() of Bitmap) and operate on this data with any lib you want.
Pixman is only responsible for all bitmap operations but this doesn’t mean you need it, you can just take the raw data.
The format of the raw data returned by pixman matches the DynamicFormat you specified at startup.
Couldn’t HARD_LIGHT be replaced with a less stressfull operation with a similar output? Watching the cairo operations description you linked me i was thinking for example to OP_OVER or OP_ADD (But probably i’ve just got caught in error due to sample images).
No because it depends on the color of the destination if MULTIPY or SCREEN is executed. I tested both of them and they don’t give an acceptable result.
We are probably lost here with software rendering and need hardware support
As for the performances, i can try to use citro3D instead of sf2dlib but since it’s a library used principally for 3D rendering (lpp-3ds uses it for 3D models rendering) and since it doesn’t have any kind of documentation, it could take a long amount of time to figure out how to properly use it for 2D rendering.
As for the HARD_LIGHT, using citro3D couldn’t the light color be used as a vertex shader attribute to drastically increase framerate? ( github.com/Rinnegatamante/lpp-3 … #L770-L774 ).
EDIT: Speaking about this error: gbatemp.net/attachments/scr_16_c … png.43538/ , is this an EasyRPG problem or just (most probably) a ctrulib problem? I know that ctrulib can handle UTF-16 filenames with romFs filesystem but i don’t know very much about sdmc filesystem.
“OnPlayedOnce” is not part of the interface.
“Pitch” is the speed of the music playback, we dont support this in SDL because SDL lacks this feature ;). The value goes from 50 to 150 (as far as I know), so 100(%) is default speed, 150 is double, 50 is half.
That is probably a ctrulib problem. The Player is Unicode aware (as you can see in the ingame-console because it shows Japanese). You can add 3ds specific code to fopenUTF8 in the FileFinder. If you need UTF16 look at the _WIN32 code, which converts the string to utf16.
Of course you can use a shader for this. But just lighten will not work because it darkens or lightens depending on the color of the source. The Cairo website mentions the formula to calculate resulting RGBA of a pixel:
aR = aA + aB·(1−aA) <- Alpha calculation for each color (A = source, B = destination)
xR = 1/aR · [ (1−aB)·xaA + (1−aA)·xaB + aA·aB·f(xA,xB) ] <- Color calculation for any of RGB
Where f(xA,xB) is:
if (xA ≤ 0.5) <-- 0.5 = 0-128
f(xA,xB) = 2·xA·xB
else
f(xA,xB) = 1 − 2·(1 − xA)·(1 − xB)
I guess you can also google glsl shaders that do hard light (and try to convert them to citro3d shader syntax)
(with the new code it went down to 1.2% for me). We reached the “Enjoyable” state now. Is above 30 FPS. (though on more complex scenes it will go below).
