Supposing you've handled your global bariables in a more sensible way than written in quiestion, problems I've noticed so far:

• DrawTriangle passes 3 points to SDL_RenderDrawLines. To draw a triangle, you have to draw 3 lines, and each line consists of 2 points, so total number of points in triangle is 6:

    SDL_Point points[] = {
        {x1, y1}, {x2, y2},
        {x2, y2}, {x3, y3},
        {x3, y3}, {x1, y1},
    };


    int ret = SDL_RenderDrawLines(p_renderer, &points, sizeof(points)/sizeof(points[0]));

• in render, you iterate over sizeof(meshCube.tris), but sizeof of any pointer type is sizeof(void*) (e.g. 8 or 4 or 32bit system). You need to save number of vertices, e.g. add int num_tris to your mesh structure and fill it with meshCube.num_tris = sizeof(cubeTris) / sizeof(cubeTris[0]); in your window_init, where cubeTris is not a pointer but an actual array

• you set tris as pointer to temporary array of triangles. When you render, this array may be stomped already. You have to either allocate space for that data or set it as global/static. Declaring it as static triangle cubeTris[] = { .... } would suffice

As a side note, with more-or-less modern C you don't need true/false defines, as we have #include <stdbool.h> since C99. Also note that in C, in contrast to C++, void foo() is not function that takes no arguments but rather function that takes unspecified number of arguments; function thaking no arguments would be void foo(void). [this should no longer be true with recent C2x, which is to be released "soon" as C23]

Yes you can do your own rendering engine (just google rasterization) in C alone without any libs however to output gfx to screen (or any other device) You have to interface with device and here OS/platform stuff goes in. I assume PC (x86)...

For example in old MS-DOS you could use BIOS (with few lines of inline assembly) and or use direct in,out functions (yes there where time that in,out was in C) however in nowadays C/C++ languages there is no in,out so you have to use assembly again. With such you could set up desired video or text mode and from there just use direct access to framebuffer on VGA (as simple as writing to array + some page flipping for bigger resolutions)

On modern OS is this no longer possible as all HW and Memory access must comply priviledges ... So in order to access gfx card you have to connect to gfx driver or write its own however that requires ring0 priviledges so you either need to create and install device driver (not easy and from win10 also not cheap and you need Driver SDK for that which is also sort of lib) or use universal driver like JUNGO or use OS and gfx vendor provided gfx api like OpenGL,DirectX,GDI however all of these are considered lib,api ...

The only workaround is use what you have at disposal which is text console output (text mode window or console) along with ASCII art.

see Display an array of color in C

If you are on MCU or whatever platform where you have unrestricted access then writing own driver is OK for example see:

• 2D,3D rendering engine for SSD1306 LCD

However writing driver for gfx on PC is not good idea as you would need to support all the gfx cards used and that is too much work (and you would have hard time to obtain relevant info needed to do it anyway) so in reality using existing gfx api along with existing drivers is the only way which means you HAVE to use libs/apis if you want "real" graphic...