Ok now these are just suggestions for future builds, these aren't bashings or anythings - just things i've induced from taking a quick look over hte source code.

Right now you have a fatal error if a music directory can't be opened, now I'm not sure failing to open a music directory is a fatal error, but hey tomato, tomato lol

You have the same thread-setup as my current BOXHEAD build and it doesn't run on some PSPs (3.xx kernel and / or slims cant say for sure ) so I don't think this will either, but it's a relatively simple quick fix (start in
user mode, start kernel mode thread initializing ME that starts the user_main() function in your case).

I see you have a kinda weird mp3 playing setup (in my opinion lol). The ability to play both MP3s and AT3s is there, you even initialized the ME to do so, yet you're only allowing mp3s to be loaded

Because you're placing all filepaths into the array that holds a max of 1000, all of those non-mp3 (future at3 i hope) files are also being put in there meaning there's that many less songs to be played.  Since all those non-mp3 files are in there, they won't pass the .mp3 extension check and since it doesn't automatically load the default background music when this mp3 extension check fails, no background music will play (right now you only have it playing the default background music if there are no files found, not specifically any mp3 (soon at3) files found).  Now I doubt anyone will have more then 1000 objects in their MUSIC directories, and it's real easy to support more after a quick change and recompilation, but dynamic support is the fastest, memory-efficient way to do it.  you are currently checking the file extension on-the-fly, when you are about to load a random song on-the-fly, when this should be done upon loading the array with song filepaths, much like how you're filtering the . and .. directories out of the array on loading.  If you did the checks upon filling the array with file paths to mp3s and at3s, that's a speed up and it will mean all 1000 file paths loaded are in fact playable music formats   Still, the dynamic support isn't there and only 1000 mp3s and at3s will be playable. To fix that, you'd need a dynamically allocated template class - since you're using C++ (your main source file has a .cpp extension, however hte makefile isn't linking -lstdc++ so I can't say for sure lol) it makes perfect sense to use STL vectors   But if you're truly interested in switching to those I'll PM you a sample i made that makes use of them to do just what you're doing

</ramble>

But hey this has gone a long way from just a small thing you've made quite a while ago (I remember you showing me a long time ago ) great job

Last edited by SG57 (2008-04-30 02:25:06)

Oh hey slicer, i found out a way around our little problem   Oslib has it built in to init the ME using user-mode functions if under non-1.5 kernel.  So screw the threading, just start in User mode and init the ME the same you would oslib   Only draw back this causes is that this isn't 1.5 supported, you must be under 3.xx kernel. I suppose you could make 2 versions of your game, one with the threading and in kernel mode at start up requiring 1.5 frimware for phats, then one iwthout the threading and it started in usermode requiring 3.xx .

Last edited by SG57 (2008-05-03 17:52:19)

Well, it's either do this or require people to set the kernel to 3.xx to run it (like irshell) but hey, i say that with this current teetering situation of whether ot develop on 1.5 kernel or 3.xx kernel, why not support both if the ability is there (however some things may require 3.xx so... lol)