joshuabrookover/bigg

bgfx, imgui, glfw, glm

bigg

Simple framework bringing together bgfx, imgui, glfw, and glm.

Checkout

git clone https://github.com/JoshuaBrookover/bigg.git
cd bigg
git submodule update --init --recursive
mkdir build
cd build
cmake ..

bigg's Issues

add_shader not working

Hello, examples/cubes will crash when it is running because shaders.bin not found, I run on osx

Cubes example crashes (SIGSEGV) with no errors if executed from other directories

In the ExampleCubes::initialize function the application builds a relative path to the files (v/f)s_cubes.bin. If your working directory is the same as the application, it works fine, but crashes if you try to execute from any other directory.

How to reproduce:

1. mkdir build && cd build
2. cmake .. -DBIGG_EXAMPLES=ON
3. make
4. examples/cubes/cubes <-- Crashes with SIGSEGV, no error messages
5. cd examples/cubes && cubes <-- Works fine

Crash happens on cubes.cpp:78, mProgram = bigg::loadProgram( vsName, fsName );, actually inside of bigg::loadProgram.

Fixing the example so that the file loading works independently from the working directory would be nice.
But this still leaves an undesirable behavior for anyone using the bigg framework, as bigg::loadProgram simply crashes without any error output in case the parameters passed to it are invalid. As a user, I can either use exceptions or do something like this (resulting in unnecessary file open/close calls):

std::ifstream tesingVS( vsName, std::ios::binary | std::ios::ate );
std::ifstream tesingFS( fsName, std::ios::binary | std::ios::ate );

if (tesingFS.is_open() && testingVS.is_open()) {
    testingVS.close();
    testingFS.close();
    mProgram = bigg::loadProgram( vsName, fsName );
} else {
    //Return some error or crash out
    std::cerr<<"Failed opening file " << vsName << " or " << fsName << std::endl;
    exit(EXIT_CODE);
}
//Continue

Though I guess I'd be satisfied if the function outputted some "failed to open file" logs to cerr before crashing out.

asm.js support

Hey,

Is compiling for asm.js supported with this particular build setup? I can compile just fine with VS2017 but I'm struggling to get it to work with CMake and the Emscripten toolchain file.

I tried different CMake generators:

• MinGW or Unix Makefiles: CMake complains about CMAKE_MAKE_PROGRAM not being set
• Ninja: Can't find X11
• NMake Makefiles: Can't find Threads library

I'm wondering if this is a problem with the libraries being used or a mistake on my end.

Segmentation Fault with Windows 10 (MSYS2 MinGW 64-bit)

I successfully built the project using "MSYS2 MinGW 64-bit" under Windows 10 (gcc 8.2.0, GNU make 4.2.1, make 3.12.2). However both the cubes and imgui demos trigger a segmentation fault as soon as the bgfx::init() call.
I also built and ran the original bgfx project using the same environment (mingw-gcc-release64) without any issue and all demos work just fine.
Any idea?

OSX compilation error

bigg/deps/bgfx.cmake/bgfx/tools/texturev/texturev.cpp:6:10: fatal error:
'common.h' file not found

add glfm?

Hi,

Thank you for this awesome skeleton framework. Is it possible to add glfm into the mix so it supports mobile as well?

Update imgui

The current imgui version used is 1.60, which is about a year old, the newest release as of this post is 1.69 which came out about a month ago.

Edit: Or I suppose you'd be limited to 1.63 which is what bgfx has right now. Which makes me wonder, why do you even have imgui as a submodule as well? bgfx already does.

Can't initialize Application derivatives with specific size

Either I'm missing something or (at least) these two fields should be protected.

Timer resolution too low

https://github.com/Josh4428/bigg/blob/e714c764b4e1b272722870a0580328b0db0fcd79/src/bigg.cpp#L233-L235

Sometimes the dt calculation comes out as 0, causing this assert in Imgui to hit

https://github.com/ocornut/imgui/blob/e7e170c534d27ae32f7b87d17295036ed9c9af81/imgui.cpp#L7146

Not sure why Imgui absolutely requires dt to be greater than 0, but it might be helpful to increase to double precision, or just clamp it to always be something small.

Update IMGUI to the docking branch

Is it possible for bigg's imgui to be updated to the docking branch of imgui?

ImDrawCmd::TextureId not copied properly

I'm setting a texture handle for font rendering, and the texture ID carried through cmd->TextureId never makes it. The bug is here:

bigg/src/bigg_imgui.hpp

Line 112 in 8bad04f

union { ImTextureID ptr; struct { uint16_t flags; bgfx::TextureHandle handle; } s; } texture = { cmd->TextureId };

If cmd->TextureId is 2, then flags wrongly ends up being 2 and handle 0. This looks like an issue with endianness. Not sure why that flags bit is there, it should be enough to simply cast cmd->TextureId to a uint16_t for bgfx.

I'd be happy to send a PR with a fix.

Issue in OSX Catalina

Mac OS Catalina changed the signature of objc_msgSend, so it has to be casted using a function pointer. The file to change is bgfx.cpp, adding this line of code:

id (*objc_msgSend2)(id obj, SEL sel) = (id(*)(id, SEL))objc_msgSend;

Segmentation Fault with Ubuntu 18.04.1

I built the project under Ubuntu 18.04.1 and both the ‘cubes’ and ‘imgui_demo’ produce a Segmentation Fault. I have however no problem building and running the bgfx examples embedded in the bgfx folder. Note that I also successfully built the bigg project and ran the demos on macOS without any issue.

I have been able to narrow down the issues to the call to bgfx::createTexture2D in imguiInit (“Create Font” section), and the ‘Valgrind’ tool indicates an issue with bx::alloc which is quite weird:

==5527== Invalid read of size 8
==5527== at 0x179457: bx::alloc(bx::AllocatorI*, unsigned long, unsigned long, char const*, unsigned int) (in /home/whab/Documents/bigg/build/examples/cubes/cubes)
==5527== by 0x1714F8: bgfx::alloc(unsigned int) (in /home/whab/Documents/bigg/build/examples/cubes/cubes)
==5527== by 0x171535: bgfx::copy(void const*, unsigned int) (in /home/whab/Documents/bigg/build/examples/cubes/cubes)
==5527== by 0x167F6E: imguiInit() (in /home/whab/Documents/bigg/build/examples/cubes/cubes)
==5527== by 0x169340: bigg::Application::run(int, char**, bgfx::RendererType::Enum, unsigned short, unsigned short, bgfx::CallbackI*, bx::AllocatorI*) (in /home/whab/Documents/bigg/build/examples/cubes/cubes)
==5527== by 0x1652ED: main (in /home/whab/Documents/bigg/build/examples/cubes/cubes)
==5527== Address 0x0 is not stack'd, malloc'd or (recently) free'd

Any idea?