Ok so i’ll leave it as it is right now without any further improvement.
As for liblcf, i’m still waiting for a working version, i’ve tried to replace headers but nothing changed: github.com/Rinnegatamante/easyr … s/issues/8
Yeah I’m aware of this. Just got home, I try to get the toolchain working again before midnight, sorry.
Tried also with the Test Game right now and it also crashed. Anyway if the problem is not in liblcf, do you have any idea what could cause such slowdown? (Does image libraries use lots of stdio calls? Since i noticed fread for example is SLOOOOOOOW on 3DS ( github.com/Rinnegatamante/easyr … 9b6bcd1604 Without the modification in Stereo WAVs, this big amount of fread calls caused unsync issues for example).
Finally got everything setup again. I’m tired, had no time to do any testing yet :(. Hope it works:
easy-rpg.org/downloads/easyrpg_ … bs.tar.bz2
NOTE: include\boost not included, take it from your old toolchain
About the FileFinder, you spoke about directory entries. Are not folders standards? (I mean, to check what file we should open can’t we just try to open the file and check what fopen returns instead of scanning folders?)
Actually I don’t think directory reading is that slow.
Just look at e.g. ftbrony. The FTP directory listing is quite fast. And it uses the normal readdir stuff.
Even if it’s fast, it’s surely slower then just checking a couple of files. That should boost at least a bit starting speed.
I updated the portlibs dir again because I had the wrong compile flags, sorry:
easy-rpg.org/downloads/easyrpg_ … bs.tar.bz2
It extracts now to portlibs/3ds instead of portlibs/arm btw and boost is still missing.
Slow directory reading doesn’t matter anymore I found a way to make it fast… really fast. Check my pull request:
github.com/EasyRPG/Player/pull/ … -204803630
Already tried it on real 3DS hardware (O3DS)… Yume Nikki loads almost instant 
EDIT:
The Directory reading is required to make a case-insensitive table of filenames. FAT32 is not case-sensitive but I wouldn’t trust ctrulib on this. Maybe it works for ASCII but the world has more then this. Especially with unicode you need unicode lower case conversion and unicode normalisation, I bet ctrulib doesn’t do this.
[quote=“Ghabry”]I updated the portlibs dir again because I had the wrong compile flags, sorry:
easy-rpg.org/downloads/easyrpg_ … bs.tar.bz2
It extracts now to portlibs/3ds instead of portlibs/arm btw and boost is still missing.
Slow directory reading doesn’t matter anymore I found a way to make it fast… really fast. Check my pull request:
github.com/EasyRPG/Player/pull/ … -204803630
Already tried it on real 3DS hardware (O3DS)… Yume Nikki loads almost instant
EDIT:
The Directory reading is required to make a case-insensitive table of filenames. FAT32 is not case-sensitive but I wouldn’t trust ctrulib on this. Maybe it works for ASCII but the world has more then this. Especially with unicode you need unicode lower case conversion and unicode normalisation, I bet ctrulib doesn’t do this.[/quote]
That’s awesome so basically now what still needs to be changed? Only MP3 and MIDI support?
With my tone blit improvments the Speed with tone change is now 23 FPS (on the test map) with tone changed, 20 with Saturation (bottom row) and 16 fps with both.
Yeah, basicly only audio missing. rest is getting nice
EDIT
I found more speed boosts that give a nice speedup, because this also influences every other version of the Player and DS is now quite fast I will delay them until the code is good enough 
Lets make this faster (Old 3DS)
(based on the fastblit pr)
Double FPS is interesting but does it apply for each zone of the currently used core?
What do you mean with “zone”?
Of course you only get this frame rate when nothing else is happening on the map. When the event interpreter runs stuff in the background you already lose frames.
Some effects are still really slow, e.g. tone change still goes down to 30 FPS. But is more then the 5 FPS before so this got also improved.
I can’t think of any further optimisations currently so this is as good as it goes… When the game is more interpreter heavy it will get slower.
Another issue is that file reading is painfully slow and will cause a lag. No idea how to fix this yet.
[quote=“Ghabry”]What do you mean with “zone”?
Of course you only get this frame rate when nothing else is happening on the map. When the event interpreter runs stuff in the background you already lose frames.
Some effects are still really slow, e.g. tone change still goes down to 30 FPS. But is more then the 5 FPS before so this got also improved.
I can’t think of any further optimisations currently so this is as good as it goes… When the game is more interpreter heavy it will get slower.
Another issue is that file reading is painfully slow and will cause a lag. No idea how to fix this yet.[/quote]
Asynchronous file reading as you suggested or maybe pre-caching images (like Quake Engine does) are probably the only solutions.
Funny mode ON: Or maybe we can write a PC file reader that sends the stuffs through network so that 3DS should read on a socket that it’s surely faster then reading from SD 
EDIT: Currently used libraries are using a temp buffer for decoding operations or multiple fread calls? This can also reduce “stuttering” effect made by images loading probably.
[quote=“Ghabry”]What do you mean with “zone”?
Of course you only get this frame rate when nothing else is happening on the map. When the event interpreter runs stuff in the background you already lose frames.
Some effects are still really slow, e.g. tone change still goes down to 30 FPS. But is more then the 5 FPS before so this got also improved.
I can’t think of any further optimisations currently so this is as good as it goes… When the game is more interpreter heavy it will get slower.
Another issue is that file reading is painfully slow and will cause a lag. No idea how to fix this yet.[/quote]
I meant maps like snow one. Thanks for the explanation though. So dynamic games like Zelda will lag because of animations.
@Rinnegatamante : I don’t think networking would help in any matter but who knows xD
Yes this applies to all zones of the world map. The performance only depends on how many scripts execute in the background and how many events are rendered at the current viewport. Events outside of the view port are not rendered and only run a logic update.
What I also noticed @Rinnegatamante
The color of the graphic output changes when you walk to different areas. E.g. the snow world results in color changes of the character. Which is strange, probably a display issue of the 3DS because I don’t see this behaviour anywhere else.
[quote=“Ghabry”]Yes this applies to all zones of the world map. The performance only depends on how many scripts execute in the background and how many events are rendered at the current viewport. Events outside of the view port are not rendered and only run a logic update.
What I also noticed @Rinnegatamante
The color of the graphic output changes when you walk to different areas. E.g. the snow world results in color changes of the character. Which is strange, probably a display issue of the 3DS because I don’t see this behaviour anywhere else.[/quote]
I noticed that problem too but i thought it was a player issue. I’m quite sure at least for CPU rendering it doesn’t happens but i noticed a similar problem also when testing citro3D on lpp-3ds for 3D models rendering so it may be related to some GPU fail.
I’ve also thought a little tip that could probably boost the renderer.
What if we reduce the real resolution and then upscale the texture through GPU? It will cause a quality loss but in certain games it could be really useful to reach a decent framerate.
[quote=“Rinnegatamante”]I’ve also thought a little tip that could probably boost the renderer.
What if we reduce the real resolution and then upscale the texture through GPU? It will cause a quality loss but in certain games it could be really useful to reach a decent framerate.[/quote]
I thought about the same thing but it was much more of drawing one line of pixel out of 2 and then rescale to the same height but it would probably result in quality loss too. (I’m pretty sure it would even render weird on certain games where textures are higher quality ^^)
I don’t know how libpng works. Probably does single freads to extract data. This could be optimized a bit, yepp.
I don’t think downscaling is a good idea. When you reduce the size by 50% you lose 75% of the pixel information.
One useful thing would be to do the simple blit operations (except hard light) with the GPU. But I don’t know how to do this, yet.
I think the way to go here is to use Citro3D. But the current code strukture does not allow this. Needs a refactor first.
[quote=“Ghabry”]I don’t know how libpng works. Probably does single freads to extract data. This could be optimized a bit, yepp.
I don’t think downscaling is a good idea. When you reduce the size by 50% you lose 75% of the pixel information.
One useful thing would be to do the simple blit operations (except hard light) with the GPU. But I don’t know how to do this, yet.
I think the way to go here is to use Citro3D. But the current code strukture does not allow this. Needs a refactor first.[/quote]
If you tell me more about how to properly change internal player resolution, i can give it a try.