Homebrew Segfault when using C3D_DrawArrays()

[catlover007]

just a note from me, it probably won't fix the code, but it isn't a very good idea to reallocate the memory each frame. Allocate the memory once and use it for drawing and when the application is closed, deallocate it with linearFree

EDIT: didn't read it after writing it

 

[StuntHacks]

Okay so it doesnt draw anything at all right now. I noticed before that Citro3D will softlock if nothing gets drawn during a frame and that's exactly what happens right now.

Anyways, thanks for the tip @catlover007

 

[TarableCode]

Try not drawing anything but seeing if it still hardlocks and if your clear colour shows up with what you passed to RenderTargetSetOutput.
Also both code blocks you posted earlier are the same, can you paste rendertarget.cpp?

 

[StuntHacks]

Try not drawing anything but seeing if it still hardlocks and if your clear colour shows up with what you passed to RenderTargetSetOutput.
Also both code blocks you posted earlier are the same, can you paste rendertarget.cpp?

Oh, is it? My bad. Anyway, yes, it still locks and no, the clear colour doesn't show up.

The rendertarget.cpp looks like this:

#include "graphics/renderTarget.hpp"
#include "graphics/color.hpp"

namespace m3d {
    RenderTarget::RenderTarget(int t_width, int t_height) :
                                     m_width(t_width),
                                    m_height(t_height),
                                    m_clearColor(RGBA8(0, 0, 0, 255)) {
        m_target = C3D_RenderTargetCreate(t_width, t_height, GPU_RB_RGBA8, GPU_RB_DEPTH24_STENCIL8);
        Mtx_OrthoTilt(&m_projection, 0.0f, t_width, t_height, 0.0f, 0.0f, 1.0f, true);

        u32 color = RGBA8(255, 0, 0, 255);
        color = ((color>>24)&0x000000FF) | ((color>>8)&0x0000FF00) | ((color<<8)&0x00FF0000) | ((color<<24)&0xFF000000); // reverse byte order
        C3D_RenderTargetSetClear(m_target, C3D_CLEAR_ALL, color, 0);
    }

    C3D_RenderTarget* RenderTarget::getRenderTarget() {
        return m_target;
    }

    C3D_Mtx* RenderTarget::getProjectionMatrix() {
        return &m_projection;
    }

    int RenderTarget::getWidth() {
        return m_width;
    }

    int RenderTarget::getHeight() {
        return m_height;
    }

    void RenderTarget::setClearColor(u32 t_color) {
        u32 color = ((t_color>>24)&0x000000FF) | ((t_color>>8)&0x0000FF00) | ((t_color<<8)&0x00FF0000) | ((t_color<<24)&0xFF000000); // reverse byte order
        C3D_RenderTargetSetClear(m_target, C3D_CLEAR_ALL, color, 0);
    }

    u32 RenderTarget::getClearColor() {
        return m_clearColor;
    }
} /* m3d */

 

[TarableCode]

I would look at the flags you're passing in the last parameter of C3D_RenderTargetSetOutput.

For example mine is:

// Used to transfer the final rendered display to the framebuffer
#define DISPLAY_TRANSFER_FLAGS \
(GX_TRANSFER_FLIP_VERT(0) | GX_TRANSFER_OUT_TILED(0) | GX_TRANSFER_RAW_COPY(0) | \
GX_TRANSFER_IN_FORMAT(GX_TRANSFER_FMT_RGBA8) | GX_TRANSFER_OUT_FORMAT(GX_TRANSFER_FMT_RGB8) | \
GX_TRANSFER_SCALING(GX_TRANSFER_SCALE_NO))

Try changing that and see if the clear colour shows up.
If it's still hardlocking comment out things bit by bit until it stops and work from there.

Good luck

 

[elhobbs]

BufInfo_Add expects the size of the data buffer - same value passed to linearAlloc. It looks like you are sending the size of a single vertex.

 

[catlover007]

BufInfo_Add expects the size of the data buffer - same value passed to linearAlloc. It looks like you are sending the size of a single vertex.

I don't think so. BufInfo_Add asks for the stride of one vertex to the next, which is indeed sizeof(your vertex data structure)
https://github.com/fincs/citro3d/blob/master/include/c3d/buffers.h#L18
The amount of data which is used from the buffer is determined by the amount of vertexes you specify in DrawArrays or DrawElements

 

[StuntHacks]

Okay so now things get even weirder...
In Citra, the screen gets cleared with the color I set and it doesn't softlock, yet it doesn't draw anything. On hardware, it doesn't clear the screen and it locks.

 

[elhobbs]

I don't think so. BufInfo_Add asks for the stride of one vertex to the next, which is indeed sizeof(your vertex data structure)
https://github.com/fincs/citro3d/blob/master/include/c3d/buffers.h#L18
The amount of data which is used from the buffer is determined by the amount of vertexes you specify in DrawArrays or DrawElements

Yes - my bad. Sorry about that.

 

[TarableCode]

Start commenting things out until hardware no longer hardlocks.
It might help to throw in a bunch of debug printfs( ) if you comment out the sub screen render target stuff and call consoleInitDefault() during your video init.

From my experience the 3DS hardlocks if you give the GPU something it doesn't like and it's a pain in the ass to track down.

 

[StuntHacks]

Okay now the following is the current state of the software: If I don't start a frame and don't draw something, it runs. If I don't start a frame but draw something, it crashes after a few seconds and doesn't draw anything (which is to be expected). If I start a frame but don't draw anything, it hardlocks (as shown in this issue: https://github.com/fincs/citro3d/issues/35). And if I start the frame and draw something, the screen gets cleared in citra but nothing is drawn and the 3DS hardlocks.

 

[TarableCode]

I don't have my toolchain set up at the moment and antihistamines have my brain in one hell of a fog but can you try and see if you can draw a triangle using immediate mode?

Like, start say https://github.com/devkitPro/3ds-examples/tree/master/graphics/gpu/immediate here and try to line up what your code is doing with what the example is doing.
This is something that has helped me track down problems when the GPU was being a fart.

 

[StuntHacks]

I don't have my toolchain set up at the moment and antihistamines have my brain in one hell of a fog but can you try and see if you can draw a triangle using immediate mode?

Like, start say https://github.com/devkitPro/3ds-examples/tree/master/graphics/gpu/immediate here and try to line up what your code is doing with what the example is doing.
This is something that has helped me track down problems when the GPU was being a fart.

Okay so I litterally replaced the entire render function with a hardcoded shaped drawn in immediate mode and it's still the same issue.

 

[elhobbs]

Okay so I litterally replaced the entire render function with a hardcoded shaped drawn in immediate mode and it's still the same issue.

Are you able to compile and run any of the citro3d examples provided with devkitpro? And are you using the citro3d and libctru from the devkitpro installer, or did you build the source from git?

 

[StuntHacks]

Are you able to compile and run any of the citro3d examples provided with devkitpro? And are you using the citro3d and libctru from the devkitpro installer, or did you build the source from git?

Yes, the examples compile perfectly. I think I built the sources from git since I'm on linux so I didn't use the devkitpro installer.

 

[elhobbs]

Yes, the examples compile perfectly. I think I built the sources from git since I'm on linux so I didn't use the devkitpro installer.

ok - if the examples run fine then that rules out version/lib issues.

 

[TarableCode]

The examples run and behave correctly as well?
It might help if you can upload all your project sources in a zip so we can take a better look at the whole picture.

 

[StuntHacks]

Okay so I played around with the simple_tri-example and managed to draw my own shapes with my own colors. I then tried to "copy" my code from that example over to the actual source and it's still the same issue, so I'm probably missing something very simple. Anyway, here is the current source code.

https://drive.google.com/file/d/0B_WX-NKTX7-zUF9udnZ2dFF2bGc/view?usp=sharing

 

[TarableCode]

I took a quick look and ran my own tests but here is what I have found.

You should be calling aptMainLoop during your main loop, instead of app.isRunning( ) change it to while ( aptMainLoop( ) ) and check app.isRunning
inside the loop instead.
m_projectionDesc Is NULL and that's a hardlock right there, I don't know a whole lot about shaders and I have to go out so I can't look any deeper atm.

I can look again this evening but for now I'd toss in a bunch of NULL pointer checks and set up a debug console on the bottom screen so you can do some printf debugging.
Take a look at your shader and the example it came from, it might just be something simple.

 

[StuntHacks]

Okay, I managed to get it running. The problem was that the shader was corrupted, so that's probably why m_projectionDesc was NULL. Thank you all so much, especially @TarableCode, for your patient help!