Homebrew Homebrew Development

[Tjessx]

It's a common issue of httpc service, filfat reported this also on ctrulib repo if i'm not wrong.

So there is no homebrew that can download multiple files at this point?

 

[Rinnegatamante]

So there is no homebrew that can download multiple files at this point?

I think so, i was also working on a Weather API for SunShell but when i realized that after some status updates it always crashes i just stopped all works on it.

 

[Tjessx]

That's pretty weird.
I was working on pictochat3DS, and wanted to use http requests to log in and receive new messages.

logging in was just "visiting a webpage" so i wrote a ping command which never stopped working.
But after a few times, receiving new messages doesn't work anymore.

 

[Rinnegatamante]

That's pretty weird.
I was working on pictochat3DS, and wanted to use http requests to log in and receive new messages.

logging in was just "visiting a webpage" so i wrote a ping command which never stopped working.
But after a few times, receiving new messages doesn't work anymore.

Why using httpc service and not socketing? ( http://3dbrew.org/wiki/Socket_Services )

 

[Tjessx]

Why using httpc service and not socketing? ( http://3dbrew.org/wiki/Socket_Services )

I'm planning on doing that now.
It would be easier to host the server.

--------------------- MERGED ---------------------------

sockets works, right?

 

[zoogie]

It's funny how many people are exporting 3dsexplorer to Github.
12 times and still going strong.

 

[onepiecefreak]

Yeah, showing my code isnt that bad, isnt it?

main.c

#include "draw.h"

#include <3ds.h>
#include <stdio.h>

int main (int argc, char **argv) {
    gfxInitDefault();
   
    PrintConsole topScreen, bottomScreen;
    consoleInit(GFX_TOP,&topScreen);
    consoleInit(GFX_BOTTOM,&bottomScreen);
   
    while (aptMainLoop()) {
        u8* screenBottom=gfxGetFramebuffer(GFX_BOTTOM, GFX_BOTTOM, NULL, NULL);
       
        hidScanInput();
        touchPosition touch;
        u32 kDown = hidKeysDown();
        hidTouchRead(&touch);
       
        if (kDown & KEY_A) break;
       
        //u32 v=(240-1-touch.py+touch.px*240)*2;
       
        consoleSelect(&topScreen);
        printf("\x1b[0;0Hx: %03d",touch.px);
        printf("\x1b[1;0Hy: %03d",touch.py);
        printf("\x1b[2;0Hv: %06lu",v);
        consoleSelect(&bottomScreen);
       
        if (touch.px>0 && touch.py>0) {
            drawPixel(screenBottom,touch.px,touch.py,0xFF563F6D);
        }
       
        gfxFlushBuffers();
        gfxSwapBuffers();
       
        gspWaitForVBlank();
    }
   
    gfxExit();
    return 0;
}

draw.h

#ifndef DRAW_H
#define DRAW_H

#include <3ds.h>
#include <stdio.h>

/*void drawPixel(u32 v, int r, int g, int b, u8* screen) {
    screen[v]=b;
    screen[v+1]=g;
    screen[v+2]=r;
}*/

void drawPixel (u8* screen, int x, int y, u32 color) {
    int idx=(((x)*240) + (239-(y)))*3;
   
    printf("\x1b[0;0Hidx: %06d",idx);
   
    *(u32*)&(screen[idx]) = (((color) & 0x00FFFFFF) | ((*(u32*)&(screen[idx])) & 0xFF000000));
}
#endif    // DRAW_H

And now you can hopefully see the error!
P.S: the drawPixel function is the same from Rinnegatamante, except the printf.

 

[filfat]

Yeah, showing my code isnt that bad, isnt it?

main.c

#include "draw.h"

#include <3ds.h>
#include <stdio.h>

int main (int argc, char **argv) {
    gfxInitDefault();
  
    PrintConsole topScreen, bottomScreen;
    consoleInit(GFX_TOP,&topScreen);
    consoleInit(GFX_BOTTOM,&bottomScreen);
  
    while (aptMainLoop()) {
        u8* screenBottom=gfxGetFramebuffer(GFX_BOTTOM, GFX_BOTTOM, NULL, NULL);
      
        hidScanInput();
        touchPosition touch;
        u32 kDown = hidKeysDown();
        hidTouchRead(&touch);
      
        if (kDown & KEY_A) break;
      
        //u32 v=(240-1-touch.py+touch.px*240)*2;
      
        consoleSelect(&topScreen);
        printf("\x1b[0;0Hx: %03d",touch.px);
        printf("\x1b[1;0Hy: %03d",touch.py);
        printf("\x1b[2;0Hv: %06lu",v);
        consoleSelect(&bottomScreen);
      
        if (touch.px>0 && touch.py>0) {
            drawPixel(screenBottom,touch.px,touch.py,0xFF563F6D);
        }
      
        gfxFlushBuffers();
        gfxSwapBuffers();
      
        gspWaitForVBlank();
    }
  
    gfxExit();
    return 0;
}

draw.h

#ifndef DRAW_H
#define DRAW_H

#include <3ds.h>
#include <stdio.h>

/*void drawPixel(u32 v, int r, int g, int b, u8* screen) {
    screen[v]=b;
    screen[v+1]=g;
    screen[v+2]=r;
}*/

void drawPixel (u8* screen, int x, int y, u32 color) {
    int idx=(((x)*240) + (239-(y)))*3;
  
    printf("\x1b[0;0Hidx: %06d",idx);
  
    *(u32*)&(screen[idx]) = (((color) & 0x00FFFFFF) | ((*(u32*)&(screen[idx])) & 0xFF000000));
}
#endif    // DRAW_H

And now you can hopefully see the error!
P.S: the drawPixel function is the same from Rinnegatamante, except the printf.

Why not use the GPU? Check out sf2dlib

 

[onepiecefreak]

I thought I already use the GPU. Yeah, I'm new.
Thx for that. I test it.

 

[Rinnegatamante]

If you have to write on the screen some particular forms (like triangles) using the GPU is weird (You can see what i'm talking about trying CPU and GPU rendering from my Asteroids 3D homebrew ( https://gbatemp.net/threads/release-asteroids-3d.385600/ )

 

[onepiecefreak]

Hmm... I see what you mean. Only to draw some simple 2D forms using GPU isnt a good idea, because using the GPU is less accurate, right?
I begin to learn

But all in all, the first question is, why does the functions doesnt draw the pixel at the given values?

 

[filfat]

Hmm... I see what you mean. Only to draw some simple 2D forms using GPU isnt a good idea, because using the GPU is less accurate, right?
I begin to learn

But all in all, the first question is, why does the functions doesnt draw the pixel at the given values?

It's just as accurate, however as @Rinnegatamante said, it can be a lot harder drawing certain shapes.
You could always check out https://github.com/filfat/3DS_UI for references (though the project isn't being updated anymore due to time constraints, I hope to start working on that again sometime next year)

 

[onepiecefreak]

Hmm, my compiler says it can't find the cosf, sinf and tanf function.
I included the math.h and I read that these functions are only included in the C++ version of the math.h.

Why isnt that included in devkitARM or do I do things wrong?

 

[Rinnegatamante]

Hmm, my compiler says it can't find the cosf, sinf and tanf function.
I included the math.h and I read that these functions are only included in the C++ version of the math.h.

Why isnt that included in devkitARM or do I do things wrong?

You can wright your own math functions in ASM or C.

 

[Shadowtrance]

Just wondering, Is there a way to shutdown/poweroff from homebrew (normal ninjhax homebrew, not arm9 stuff) at all?

 

[AlbertoSONIC]

Just wondering, Is there a way to shutdown/poweroff from homebrew (normal ninjhax homebrew, not arm9 stuff) at all?

I don't think so...

 

[Shadowtrance]

I don't think so...

Well that sucks.

 

[DiscostewSM]

Ok, I believe I got rendering to a texture working, but now I'm having an issue elsewhere. When testing my stuff, for some reason it tears on the left side. Thinking I was doing something too process-intensive, I went back to the original project I began with, which was the texture_cube example that came with ctrulib. I took that, and forced translation to -1.0 to make it fill the screen and ran it. It too was showing the tearing on that side. I understand that on the 3DS, the refresh is not from top to bottom, but from side to side (don't know from which side first), but with so little happening, I don't know what's going on. Is it still too intensive (GPU-wise)? Is it not waiting for something like the VBlank or is it transferring over to the display at the wrong time?

edit:

Ok, so I tried swapping the "gspWaitForVBlank()" and "gfxSwapBuffersGpu()" functions, and I'm not noticing any tearing anymore (the VBlank function was first prior to switching them). However, this doesn't exactly make a lot of sense, because if I'm switching the buffers prior to waiting, surely that would cause tearing, but it isn't. It seems to have the opposite effect.

edit #2:

Ok, hopefully this is the last one, since posting more than once in a row is considered improper here. I looked into ctrulib's source to see what "gfxSwapBuffersGpu" was doing, and from the look of it, it was just writing values into its own structure. I saw there was a "gfxSwapBuffers" version (no Gpu attached) that actually sent data via service requests, so, I used the non-Gpu version, and moved it back after the WaitForVBlank function. Sure enough, no tearing. So what exactly is the purpose of the Gpu version? Is that for if the GPU is currently processing, and becomes a pre-emptive action for when it is told to wait for the VBlank?

 

[geocool]

hey guys.

Does anyone know if there is a way to get available memory in runtime ?
I'm building a C++ engine for my game and I would like to know how much memory it consumes and if there are any memory leaks.

@DiscostewSM
I started with the template that latest ctrulib has and they use gfxSwapBuffers there, so you may have found the right function to use.

 

[DiscostewSM]

hey guys.

Does anyone know if there is a way to get available memory in runtime ?
I'm building a C++ engine for my game and I would like to know how much memory it consumes and if there are any memory leaks.

@DiscostewSM
I started with the template that latest ctrulib has and they use gfxSwapBuffers there, so you may have found the right function to use.

I believe linearSpaceFree() is what you're looking for. Also, thanks for telling about ctrulib being updated. I guess they must have updated recently if they changed it.

Maybe a more recent update is also what's fixes a black screen problem that's happening to me with my current build. I took the texture_cube example, and trimmed the polygon list so it would only show one side of the cube. When I ran it, it froze with a black screen. But (and this is the weird part), when I removed the flags for the texture assignment (set to 0 to have no filtering, wrapping, etc), it ran fine.