[quote=“Ghabry”]“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)[/quote]
If i’m not wrong, i’m quite sure 3DS doesn’t have an fopen option for widechar usage so the win32 code it’s unusable.
Looking to stdio implementation it looks like fopen automatically converts the char* string you pass to an UTF16 so it’s quite strange that this happens:
That looks like a player bug. We don’t give support for non-official versions.
After verifying the same bug using a version from the bottom (continious build) of the download section they can open a (detailed) bug report in our issue tracker: github.com/EasyRPG/Player/issues
Tried to work a bit on the DSP audio wrapper.
Resulted in a performance kill since in standard ctrulib ndsp thread runs on main core like main thread does. (and even if you move it on syscore, if you start a streaming thread, you’ll need to start it on appcore to not have unsyncing problems and it will kills perfomance too).
So maybe if csnd is unavailable we can provide a dsp wrapper only for sounds (fully disabling BGM support). I think it’s better then nothing.
The DSP wrapper with OGG and WAV sounds support has been finished and it’s fully working. (it has some minor bugs that i’m fixxing at the moment but it generally works quite good)
Cause during buffer decoding/updating you’ll get syscore running basically ONLY streaming thread and if dsp thread is not runned at least a couple of times in a second (i don’t remember how much cycles it needs), you’ll basically get fatal errors in ndsp wrapper.
I can try to run the streaming thread on appcore or the dsp ones but both will take a good amount of resources and i think actually on O3DS code is not optimized as much to have a secondary thread on the same core running in background (maybe on N3DS could be fine but definitely not on O3DS).
I have a couple of ideas to probably bypass this problem using ndsp callbacks to fill the buffer, i should give it a try. If i can make it work, a third thread should be not needed and maybe the whole thing will run fine.
We are currently working on improving the MP3 support (the one from SDL produced noise or crashes for many files) by adding our own via mpg123 and also MIDI Support via fmmidi (to prevent shipping of 16 MB timidity Instruments).
And the API will be independed of SDL because we only need the “Feed To Audiodevice”-Loop. So in theory you can also use it when it’s ready (will take a while, we inform you)
While designing the API: What do you need to use it?
Is a ‘char* Decode(int length)’ that returns “length” bytes of PCM data and a function to query the PCM format (frequency, type [signed/unsigned, 8/16], channel) enough?
I’m assuming here that we only need MP3 and MIDI for BGM (streamed audio) because the original engine does only support WAV for sound effects (We added OGG everywhere)
[quote=“Ghabry”]We are currently working on improving the MP3 support (the one from SDL produced noise or crashes for many files) by adding our own via mpg123 and also MIDI Support via fmmidi (to prevent shipping of 16 MB timidity Instruments).
And the API will be independed of SDL because we only need the “Feed To Audiodevice”-Loop. So in theory you can also use it when it’s ready (will take a while, we inform you)
While designing the API: What do you need to use it?
Is a ‘char* Decode(int length)’ that returns “length” bytes of PCM data and a function to query the PCM format (frequency, type [signed/unsigned, 8/16], channel) enough?
I’m assuming here that we only need MP3 and MIDI for BGM (streamed audio) because the original engine does only support WAV for sound effects (We added OGG everywhere)[/quote]
MP3 and MIDI files are not supported also for sounds effects?
Anyway it could be good to have (as 3ds_decoder also does) a properly function to separate left and right channel and a function that returns some info about the file (samplerate, bytepersample, audiotype, audiosize (or total samples number), …).
No, Midi and MP3 are not supported as sound effects. And we don’t really plan adding them. OGG is superior.
function to separate left and right channel
This sounds like a 3DS only (cSnd) problem, have to check how to add this.
a function that returns some info about the file (samplerate, bytepersample, audiotype, audiosize (or total samples number), …).
Total sample number is not possible for MP3, this is not stored anywhere. To get this you must decode the whole file.
So the API will only say “Finished”.
AudioType querying could be possible but is not really needed, because the API abstracts this away.
But providing samplerate, bytes per sample and mono/stereo per frame is possible.
Are you sure MP3 total size is impossible to get? LightMp3 for PSP for example returns also total time of the song you want to play.
Talking about the shader usage to get a fast HARD_LIGHT operation: i’ve looked a bit to sf2dlib source and how it manages shaders. IT shouldn’t be too hard to swap shaders when needed so maybe we can also use it instead of citro3D.
sf2dlib uses picasso as shader assembler, this is a shader sample: github.com/fincs/picasso/blob/m … xample.vsh
And this is the current shader used by sf2dlib: github.com/xerpi/sf2dlib/blob/m … shader.vsh
I don’t know very much about shaders unfortunately, maybe you’re more experienced then me about this topic.
aliaspider (one of the main developers for Retroarch porting to 3DS) also said me that using the same workaround used by csnd but for dsp seems to not have made significative framedrops for RetroArch so i’m going to work on this at the moment (it means that we can basically delete svchax since dsp::DSP is accessible by any existent application).
EDIT: I’ve asked more info about shaders on GBAtemp and MasterFeizz replied me with this:
dsp::DSP BGM support added successfully! Seems to work quite good but it has some problems when sounds are loaded during a pretty huge loading phase (like BGMs for Main Menu). These BGMs get pratically muted (probably the cause is for dsp thread not properly get called a good amount of times in a second like i said before).
You can extract the information about the time from the ID3 Tag. But the tag can be wrong. I even have audio files that are only 3 min. length but report as 55 min. in foobar.
Great, so the DSP is the way to go :).
Yepp Hard Light is just a more complex blend operation. No idea what “diffuse color” and “texture blending function” means. I only know shaders.
Basically is something related to particular specs PICA200 have. You can find some info in the link i’ve put where MasterFeizz and elhobbs talked a bit about it. Maybe you can take a shoot and ask directly to them since i’m not so much familiar to 3D Rendering and shaders.
Yeah, I have to check citro3d and the examples, then I will create a shader that hopefully works ;).
The texture blending funcs look useless for hard light.
The PICA200 has a fixed fragment shading pipeline, you won’t be able to achieve the same results as HARD_LIGHT using shaders. The closest you are going to be able to get to the results is using texture blending.
Since i told on GBAtemp that now this is the “official” thread for 3DS port betatesting and probably that’s a pretty bad idea (:P) i decided to open a forum on my webhost which will be related only to 3DS contents (since i definitely quitted GBAshit). I’ve also opened a proper section for this porting so that this topic will not be spammed with betatest results.
Let’s return I.T.: Is there some game that currently uses OGG musics? I need to do some tests with libogg but it seems i can’t find a single game using such musics (so i’m starting wondering if it’s worth the effort to work on OGG musics support).
GbaTemp is worse today then usual.
I will monitor this thread, github and your forum then for bug reports. I will also do tests soon, tomorrow I have access to a 3DS again
No. OGG is not used by any game because it is a EasyRPG only feature. So it doesn’t really matter currently when its broken…
