Homebrew Development

Trust me, do the wrapper.

— Posts automatically merged - Please don't double post! —

Shouldn't even work without APT_SetAppCpuTimeLimit, but otherwise seems ok.

 

Yeah I do my basic testing on citra to spare the hinges on my n3DS and move it to hardware every few times or so.
I don't get why it's not blocking for the duration of the mutex lock though,
svcWaitSynchronization( RenderThreadReadyEvent, INT64_MAX ) seems to return instantly.

Normally this won't be a problem since I'm not planning to block, but for testing it really should so I can measure how speedy it runs.

 

If you are testing on citra, then that's probably the problem.

 

That was it lol.
*sigh*

Okay so I've been trying to teach myself arm assembly in an attempt to speed up graphics conversion.
I kind of succeeded in a sort of way.

The speed difference between (on o3ds hardware at 30% syscore):

Code:

void Unpack8BPP( const uint8_t* PixelsIn, uint16_t* PixelsOut, size_t InputLength ) {
    while ( InputLength-- ) {
        *PixelsOut++ = ConversionTable_8BPP[ *PixelsIn++ ];
    }
}

This code gives proper output and takes roughly 100ms.

Code:

.arm
.align 2

.extern ConversionTable_8BPP

@ r0: Src
@ r1: Dst
@ r2: Length
@ ----------
@ r3: Table pointer
@.global Unpack8BPP
Unpack8BPP:
    push {r3-r7}
    ldr r3, =ConversionTable_8BPP
Unpack8BPP_Loop:
    ldr r4, [r0], #4    @ AABBCCDD

    mov r5, r4, lsr #16
    and r5, r5, #0xFF

    mov r6, r4, lsr #8
    and r6, r6, #0xFF

    and r7, r4, #0xFF
    mov r4, r4, lsr #24

    @ 54ms
    ldrh r7, [r7,+r3]
    ldrh r6, [r6,+r3]
    ldrh r5, [r5,+r3]
    ldrh r4, [r4,+r3]

    strh r7, [r1], #2
    strh r6, [r1], #2
    strh r5, [r1], #2
    strh r4, [r1], #2

    subs r2, r2, #4
    bne Unpack8BPP_Loop

    pop {r3-r7}
    bx lr

And this takes only ~55ms, but the colours are inverted.

The conversion table is set up by:

Code:

uint16_t ConversionTable_8BPP[ 256 ];

void Init_8BPP( void ) {
    int r = 0;
    int g = 0;
    int b = 0;
    int i = 0;

    for ( i = 0; i < 256; i++ ) {
        r = ( ( uint16_t* ) CLUT_reds )[ i ] >> 11;
        g = ( ( uint16_t* ) CLUT_greens )[ i ] >> 10;
        b = ( ( uint16_t* ) CLUT_blues )[ i ] >> 11;

        ConversionTable_8BPP[ i ] = RGB565( r, g, b );
    }
}

I can understand the assembly straight up not working, but inverted?!
I'm sure my assembly is garbage, but I don't understand why the garbage has molded itself into this form.

 

Is it possible to work with raw pixel data in Citro2D? I've taken a look at various examples online, however, all examples I've seen only load textures from a t3x file. Specifically, I was wondering how one would go about loading pixel data into a buffer, having C2D_Image's tex parameter point to said buffer, configuring the subtex parameter properly (I'm lost on this bit in particular), and then drawing the image to the screen. Citro3D documentation is rather sparse, and there don't appear to be any Citro2D functions that automate this process any.