Homebrew Homebrew Development

Rinnegatamante · Mar 30, 2015

Is a file openable through FS and stdio both at the same time?

elhobbs · Mar 30, 2015

Rinnegatamante said:
Is a file openable through FS and stdio both at the same time?

Stdio is just a wrapper around FS. I imagine it would depend on the mode.

Rinnegatamante · Mar 30, 2015

elhobbs said:
Stdio is just a wrapper around FS. I imagine it would depend on the mode.

Seems to partially work if i use sdmcInit() just before using fopen but if i use sdmcInit at homebrew startup, it seems fopen fails to open any file. :/

elhobbs · Mar 31, 2015

Rinnegatamante said:
Seems to partially work if i use sdmcInit() just before using fopen but if i use sdmcInit at homebrew startup, it seems fopen fails to open any file. :/

The current release and the git version of ctrulib already call sdmcInit for you. So you do not need to call it yourself. They also protect against multiple init calls so it will not hurt to call it multiple times. Are you using a really old version of ctrulib?

daxtsu · Mar 31, 2015

Has anyone noticed that pushing the home button to pause a ctrulib application when using the GPU to render causes everything rendered to disappear until you quit? It sort of reminds me of old Windows programs that can't handle the UAC prompt coming up in Windows Vista or higher, where the graphics surface is lost and not reinitialised properly. I first noticed it when messing around with Steveice10's port of NEStopia, and when I used a sample from sf2dlib, so I'm pretty sure it's an issue with ctrulib itself.

elhobbs · Mar 31, 2015

I personaly use ninjhax for development and launching homebrew built with ctrulib. Since the home button does nothing when using ninjhax I don't really pay much attention to coding for it properly.

Rinnegatamante · Mar 31, 2015

elhobbs said:
The current release and the git version of ctrulib already call sdmcInit for you. So you do not need to call it yourself. They also protect against multiple init calls so it will not hurt to call it multiple times. Are you using a really old version of ctrulib?

I use only an old CSND revision, the rest of my ctrulib is updated to the last revision. (And also my ctrulib is compiled with mfloat-abi=softfp.

Has someone tried to access CARDSPI, NAND and BOSS_EXTDATA archives?

Tried with this code but still get all 0xD8E007F7 as response (Obviously, i'm trying this with a CIA file with a proper AccessControlInfo):

Code:

#include <string.h>
#include <malloc.h>
#include <inttypes.h>
#include <stdio.h>
#include <3ds.h>
 
int main(int argc, char** argv) {
    gfxInitDefault();
    consoleInit(GFX_TOP, NULL);
    fsInit();
    Handle nandHandle;
    Handle cardHandle;
    Handle nandROHandle;
    Handle nandRWHandle;
    Handle bossHandle;
    FS_archive CARD1 = (FS_archive){ARCH_CARD_SPIFS, (FS_path){PATH_WCHAR, 2, "/"}};
    FS_archive rawNAND = (FS_archive){0x567890AF, (FS_path){PATH_WCHAR, 2, "/"}};
    FS_archive NAND_RO = (FS_archive){ARCH_NAND_RO, (FS_path){PATH_EMPTY, 1, (u8*)""}};
    FS_archive NAND_RW = (FS_archive){ARCH_NAND_RW, (FS_path){PATH_EMPTY, 1, (u8*)""}};
    u32 extdata_archive_lowpathdata[3] = {mediatype_SDMC, 0x00000000 , 0};
    FS_archive BOSS = (FS_archive){ARCH_BOSS_EXTDATA, (FS_path){PATH_BINARY, 0xC, (u8*)extdata_archive_lowpathdata}};
    //Result NandAccess = FSUSER_OpenArchive(&nandHandle, &CARD1);
    //Result CardAccess = FSUSER_OpenArchive(&cardHandle, &CARD1);
    while (aptMainLoop()){
        printf("Check access privileges...\n\n");
        gfxFlushBuffers();
        gfxSwapBuffers();
        gspWaitForVBlank();
        printf("RAW NAND: ");
        Result rawNandAccess = FSUSER_OpenArchive(&nandHandle, &rawNAND);
        if (!rawNandAccess) printf("OK!\n");
        else printf("Error: 0x%X\n",rawNandAccess);
        printf("RAW CARD1: ");
        Result CardAccess = FSUSER_OpenArchive(&cardHandle, &CARD1);
        if (!CardAccess) printf("OK!\n");
        else printf("Error: 0x%X\n",CardAccess);
        printf("NAND: R: ");
        Result nandROAccess = FSUSER_OpenArchive(&nandROHandle, &NAND_RO);
        if (!nandROAccess) printf("OK!");
        else printf("Error: 0x%X",nandROAccess);
        printf(" W: ");
        Result nandRWAccess = FSUSER_OpenArchive(&nandRWHandle, &NAND_RW);
        if (!nandRWAccess) printf("OK!\n");
        else printf("Error: 0x%X\n",nandRWAccess);
        printf("BOSS Extdata: ");
        Result BOSSAccess = FSUSER_OpenArchive(&bossHandle, &BOSS);
        if (!BOSSAccess) printf("OK!\n");
        else printf("Error: 0x%X\n",BOSSAccess);
        gfxFlushBuffers();
        gfxSwapBuffers();
        gspWaitForVBlank();
        for (;;){
            hidScanInput();
            if (hidKeysDown() & KEY_A) break;
        }
        break;
    }
    fsExit();
    gfxExit();
return 0;
}

elhobbs · Mar 31, 2015

Any reason you are holding out on updating ctrulib? The csnd stuff is not that different.

Rinnegatamante · Mar 31, 2015

elhobbs said:
Any reason you are holding out on updating ctrulib? The csnd stuff is not that different.

Updating CSND to latest revision caused my interpreter to just crash with any music file and i don't want to check whatever change has been made in CSND module to fix issues.

elhobbs · Apr 1, 2015

It was a little odd they introduced csndInit but didn't remove the old init function as it is called by the new one. I do not think you can use csnd without using the new init function.

DiscostewSM · Apr 10, 2015

I finally made some leeway as to why blargSNES has problems with the newest CTRULIB (and its revamped GPU functions). Within "programShaderUse", it contains these lines....

GPUCMD_AddWrite(GPUREG_VSH_OUTMAP_MASK, vshDvle->outmapMask);
GPUCMD_AddWrite(GPUREG_024A, vshDvle->outmapData[0]-1);
GPUCMD_AddWrite(GPUREG_0251, vshDvle->outmapData[0]-1);

Previously in the writing of these values, the outmapMask (formerly called "attr_mask") was a value of 0x3 (with "num_attr" being 0x2, current now outmapData[0]), so hard-coding those values into their respective parts in those functions resulting in the top screen not flickering anymore and the emulator runs as it did before. The thing is, these writes are reliant on what is processed from the shader files (specifically the outmap), but comparing what is in those shader files vs examples from both the library and even portal3DS don't seem to reveal anything different. Maybe someone can help me spot the problem. Here what is in "final.vsh"

Code:

; -----------------------------------------------------------------------------
; Copyright 2014 StapleButter
;
; This file is part of blargSnes.
;
; blargSnes is free software: you can redistribute it and/or modify it under
; the terms of the GNU General Public License as published by the Free
; Software Foundation, either version 3 of the License, or (at your option)
; any later version.
;
; blargSnes is distributed in the hope that it will be useful, but WITHOUT ANY
; WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
; FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
;
; You should have received a copy of the GNU General Public License along
; with blargSnes. If not, see http://www.gnu.org/licenses/.
; -----------------------------------------------------------------------------
 
; setup constants
.const c5, 0.0, 0.0, 0.0, 1.0
 
; setup outmap
.out o0, result.position, 0xF
.out o1, result.color, 0xF
.out o2, result.texcoord0, 0x3
 
; setup uniform map (not required)
.uniform c0, c3, projMtx
 
.vsh vmain, end_vmain
.gsh gmain, end_gmain
 
;code
vmain:
mov r1, v0 (0x4)
mov r1, c5 (0x3)
; result.pos = projMtx * in.pos
dp4 o0, c0, r1 (0x0)
dp4 o0, c1, r1 (0x1)
dp4 o0, c2, r1 (0x2)
dp4 o0, c3, r1 (0x3)
; result.texcoord = in.texcoord
mov o1, v1 (0x5)
 
end
nop
end_vmain:
 
gmain:
; turn two vertices into a rectangle
; setemit: vtxid, primemit, winding
 
; v0 = vertex 0, position
; v1 = vertex 0, texcoord
; v2 = vertex 1, position
; v3 = vertex 1, texcoord
 
; x1 y1
setemit vtx0, false, false
mov o0, v0 (0x5)
mov o1, c5 (0x8)
mov o2, v1 (0x5)
emit
 
; x2 y1
setemit vtx1, false, false
mov o0, v2 (0x6)
mov o0, v0 (0x7)
mov o1, c5 (0x8)
mov o2, v1 (0x6)
mov o2, v3 (0x7)
emit
 
; x1 y2
setemit vtx2, true, false
mov o0, v0 (0x6)
mov o0, v2 (0x7)
mov o1, c5 (0x8)
mov o2, v3 (0x6)
mov o2, v1 (0x7)
emit
 
; x2 y2
setemit vtx0, true, true
mov o0, v2 (0x5)
mov o1, c5 (0x8)
mov o2, v3 (0x5)
emit
 
end
nop
end_gmain:
 
;operand descriptors
.opdesc x___, xyzw, xyzw ; 0x0
.opdesc _y__, xyzw, xyzw ; 0x1
.opdesc __z_, xyzw, xyzw ; 0x2
.opdesc ___w, xyzw, xyzw ; 0x3
.opdesc xyz_, xyzw, xyzw ; 0x4
.opdesc xyzw, xyzw, xyzw ; 0x5
.opdesc x_zw, xyzw, xyzw ; 0x6
.opdesc _y__, yyyw, xyzw ; 0x7
.opdesc xyzw, wwww, wwww ; 0x8

elhobbs · Apr 11, 2015

What was the value being generated?

DiscostewSM · Apr 11, 2015

elhobbs said:
What was the value being generated?

finalShader->DVLE[0].outmapMask = 0x7
finalShader->DVLE[0].outmapData[0] = 0x3

DiscostewSM · Apr 11, 2015

Ok, I think I found the problem. Currently with the example shader file shown, both the vertex and geometry shader are using the same outmap setup. So, both when writing to the aforementioned writes are expecting an attribute count of 3 with the related outmapMask. However, the vertex shader is only using 2 output registers. So, I threw in a dummy output register (o2) to accomodate filling in that 3rd register. However, by doing that, it altered the arrangement of input registers for the geometry shader, now having 3 inputs per output from the vertex shader instead of two. So, in order to fix it from thre, I had to adjust the geometry stride from 4 to 6, and offset the input registers by +1 (v2->v3 and v3->v4), and that fixed everything.

While I was gonna ask if a future update to ctrulib and/or aemstro could implement having different outmaps for each shader type within the same file, but I am now thinking that if I were to separate the vertex and geometry shaders to their own separate files, load them up individually but combine them to the same shader program, that would also fix the issue without a change to ctrulib or aemstro.

Rinnegatamante · Apr 11, 2015

Someone knows technical differences between a decoded Vorbis audiobuffer and an original PCM16 audiobuffer?

I'm trying to fix desynchronization issue with my video player but, according with SAME videobuffer streaming function for SAME videos but with different audiocodec (so, same samplerate, duration, audiofile) i get correct stream with PCM16 audiocodec and desyncrhonization with VORBIS audiocodec.

For example, for a video of 24:30 minutes, 24000 HZ samplerate with vorbis i get:
0:00 - 1:00 ~ quite good synchronization
1:00 - 4:30 ~ 1/2 secs desyncrhonization
4:30 - 7:00 ~ 3/4 secs desynchronization
and so on.
At the end of the file the desynchronization is ~ 40 secs ( :/ ): The audio ends first and after ~ 40 secs, it comes the real video ending.
All these issues are only Vorbis audiocodec related.

This is my actual code: https://github.com/Rinnegatamante/lpp-3ds/blob/master/source/luaVideo.cpp
(streamOGG and streamWAV are used to stream audiobuffer, lua_loadJPGV is used to load info from video file, lua_startJPGV is used to init audiobuffer and start video, lua_drawJPGV is used to send audiobuffer stream request and to stream videobuffer).

elhobbs · Apr 11, 2015

Are you using system ticks or ostimer for tracking sound position? I found that I had quite a bit of drift using that. I switched to using csndGetState. It returns the position in the loop. So it requires accumulating the difference over time to get an absolute position but I resolved the drift issue for me.

Rinnegatamante · Apr 11, 2015

elhobbs said:
Are you using system ticks or ostimer for tracking sound position? I found that I had quite a bit of drift using that. I switched to using csndGetState. It returns the position in the loop. So it requires accumulating the difference over time to get an absolute position but I resolved the drift issue for me.

I'm using ostimer.
Audiobuffer for both Vorbis and PCM16 audiocodec are reproduced perfectly without any noise, overlap, etc...

elhobbs · Apr 11, 2015

Rinnegatamante said:
I'm using ostimer.
Audiobuffer for both Vorbis and PCM16 audiocodec are reproduced perfectly without any noise, overlap, etc...

depending on the sound issues might not be easily heard. your audio and video seem to think the time is different. Did you verify that the end times agree for sound and video? Are you doing anything special when things get behind to sync back up?

Rinnegatamante · Apr 11, 2015

End times obviously agree for video and sound cause sound is only converted from a correct ones through ffmpeg. (So videobuffer "duration" for video framerate is the same of audiobuffer duration for video samplerate).
No, currently i'm doing anything to sync back up cause i've no idea what cause this issue.

Batch script for encoder, here you can see how video is converted.

Code:

echo vid2jpgv - JPGV Encoder
echo -----------------------
set /p input= "Insert input filename: "
set /p fps= "Insert framerate: "
set /p chn= "Insert audiochannels number: "
set /p res= "Insert resolution (HEIGHTxWIDTH): "
set /p smp= "Insert samplerate (Default: 44100): "
set /p ac= "Insert audiocodec (1 = PCM16, 2 = Vorbis): "
set /p vq= "Insert video quality (1 = HQ, 2 = LQ): "
echo Starting video extraction through ffmpeg, please wait...
IF %vq%==1 ffmpeg -i %input% -r %fps% -qscale:v 2 -vf "transpose=1" -s %res% "temp\output%%1d.jpg"
IF %vq%==2 ffmpeg -i %input% -r %fps% -vf "transpose=1" -s %res% "temp\output%%1d.jpg"
echo Starting audio extraction through ffmpeg, please wait...
IF %ac%==1 ffmpeg -i %input% -acodec pcm_s16le -ac %chn% -ar %smp% temp\audio.wav
IF %ac%==2 ffmpeg -i %input% -acodec: libvorbis -ac %chn% -ar %smp% -vn temp\audio.ogg
echo Starting video encoding, please wait...
jpgv_encoder.exe %fps%
echo Deleting temp files...
del /q ".\temp\*.*"
echo Video converted successfully, you'll find an output.jpgv file...
set /p dummy= "Press ENTER to exit"

elhobbs · Apr 11, 2015

I think I may have misunderstood your issue. Is the issue with the encoded file such that a different player- for instance on a pc - exhibits the same playback sync issue? Or is it only an issue on the 3ds?

Homebrew Homebrew Development

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Similar threads

Popular threads in this forum