How do you include the SDL & Vulkan dependencies?

[Iseeicy]

Hey there, I just discovered this went open source and I'm super excited to see how it evolves :)

I'd love to contribute in any way that I can, though I'm struggling to build on my Ubuntu machine - specifically with including the runtime dependencies. Where do these deps go, or how do you link them in to the project?

Currently, when I run autoreconf --install it prints out a warning:

configure.ac:23: warning: macro 'AM_PATH_SDL2' not found in library

I guess this is because I haven't really included SDL2 in any way, right? I'm more experienced w/ micro-controller development than I am with c++ desktop development so this is all a little new to me..!!

[Iseeicy]

Once I get this built on my machine I'll submit a PR adding some extra build details to the readme!

[spinnylights]

Hi, I'm so glad to hear you're excited! :smile_cat:

Hmmm...I wonder what's going on. It should bring in SDL automatically (as long as you've got it installed, which I would imagine you do since you're on Ubuntu). The macro AM_PATH_SDL2 comes from this file so you shouldn't need to do anything there either—the line AC_CONFIG_MACRO_DIR([m4]) in configure.ac is meant to ensure that. Just out of curiosity, which version of Autoconf are you using? I wonder if that has anything to do with it.

I'll admit that the build instructions are pretty provisional and I haven't tried building it on a wide variety of systems or anything, so I'm very glad you're interested in helping out there. I'm not exactly a wizened old hand with the Autotools yet—I've used them on other projects but this is definitely the most complex one—so it could well be that I'm missing something I would need to do to make the build configuration more portable. In any case, if you figure out any improvements you want to make to the docs, definitely feel free to send a PR as they're still in a pretty rough state.

[spinnylights]

Also, I guess, just as a heads-up, if you do get it to build, it doesn't really do much to see yet—it has a mode where you can run a compute shader written a certain way and it will show graphics based on that, but otherwise it mainly just prints heaps of diagnostic output describing the construction/deconstruction of the graphics infrasctructure (for instance if you pass -ld). I'm busy right now learning 3D-graphics-related math, but once I'm done with that I'm going to come back and actually get the engine rendering models and make the first proper development tools and things, so then it will be more exciting.

[Iseeicy]

Just out of curiosity, which version of Autoconf are you using? I wonder if that has anything to do with it.

autoconf --version shows me that I'm running 2.69. Same thing with autoreconf --version.

[Iseeicy]

Hmmm...I wonder what's going on. It should bring in SDL automatically (as long as you've got it installed, which I would imagine you do since you're on Ubuntu).

I don't know how I missed this. I was compiling SDL from source...! Looks like I already had SDL2 installed system-wide, but I also used apt-get to grab the libsdl2-dev package as well which has resolved this warning!

[spinnylights]

Oh hooray! Okay, so maybe we should highlight that more in the build instructions—right now it says "SDL development libs + headers" under "Build dependencies" but maybe that's too out-of-the-way. Ideally I think it would be great to just have a list of what packages to install for each distro but I just haven't gotten around to it, so maybe now's the time.

[Iseeicy]

Just getting back to this! I'll try to help and compile a list of those packages if u'd like.

Next question - what version of version of g++ should I be using? I think I'm using g++ 10, and upon running make in the build directory I get:

In file included from ../include/vulkan.hpp:34,
                 from ../include/engine.hpp:26,
                 from ../src/main.cpp:22:
../include/device.hpp: In static member function ‘static constexpr std::string cu::Device::qflav_str(cu::Device::QueueFlavor)’:
../include/device.hpp:81:34: error: invalid return type ‘std::string’ {aka ‘std::__cxx11::basic_string<char>’} of ‘constexpr’ function ‘static constexpr std::string cu::Device::qflav_str(cu::Device::QueueFlavor)’
   81 |     static constexpr std::string qflav_str(QueueFlavor f)
      |                                  ^~~~~~~~~
In file included from /usr/include/c++/10/string:55,
                 from ../include/instance.hpp:29,
                 from ../include/sdl.hpp:25,
                 from ../include/engine.hpp:25,
                 from ../src/main.cpp:22:
/usr/include/c++/10/bits/basic_string.h:77:11: note: ‘std::__cxx11::basic_string<char>’ is not literal because:
   77 |     class basic_string
      |           ^~~~~~~~~~~~
/usr/include/c++/10/bits/basic_string.h:77:11: note:   ‘std::__cxx11::basic_string<char>’ does not have ‘constexpr’ destructor
In file included from ../include/image.hpp:26,
                 from ../include/swapchain.hpp:25,
                 from ../include/vulkan.hpp:35,
                 from ../include/engine.hpp:26,
                 from ../src/main.cpp:

[Iseeicy]

Additional info on the above:

For laughs I tried this on a new install of Ubuntu 22.04 via WSL and I receive the same error:

iseeicy@Sleeper:~/crypt_underworld/build$ make
make  all-am
make[1]: Entering directory '/home/iseeicy/crypt_underworld/build'
g++ -std=c++20 -DPACKAGE_NAME=\"Crypt\ Underworld\" -DPACKAGE_TARNAME=\"crypt_underworld-UNKNOWN\" -DPACKAGE_VERSION=\"UNKNOWN\" -DPACKAGE_STRING=\"Crypt\ Underworld\ UNKNOWN\" -DPACKAGE_BUGREPORT=\"https://github.com/spinnylights/crypt_underworld/issues\" -DPACKAGE_URL=\"\" -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -DHAVE_VULKAN_VULKAN_CORE_H=1 -DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -DPACKAGE=\"crypt_underworld-UNKNOWN\" -DVERSION=\"UNKNOWN\" -I. -I..    -I../include -pthread -D_REENTRANT -I/usr/include/SDL2 -g -O2 -MT src/crypt_underworld-main.o -MD -MP -MF src/.deps/crypt_underworld-main.Tpo -c -o src/crypt_underworld-main.o `test -f 'src/main.cpp' || echo '../'`src/main.cpp
In file included from ../include/vulkan.hpp:34,
                 from ../include/engine.hpp:26,
                 from ../src/main.cpp:22:
../include/device.hpp: In static member function ‘static constexpr std::string cu::Device::qflav_str(cu::Device::QueueFlavor)’:
../include/device.hpp:81:34: error: invalid return type ‘std::string’ {aka ‘std::__cxx11::basic_string<char>’} of ‘constexpr’ function ‘static constexpr std::string cu::Device::qflav_str(cu::Device::QueueFlavor)’
   81 |     static constexpr std::string qflav_str(QueueFlavor f)
      |                                  ^~~~~~~~~
In file included from /usr/include/c++/11/string:55,
                 from ../include/instance.hpp:29,
                 from ../include/sdl.hpp:25,
                 from ../include/engine.hpp:25,
                 from ../src/main.cpp:22:
/usr/include/c++/11/bits/basic_string.h:85:11: note: ‘std::__cxx11::basic_string<char>’ is not literal because:
   85 |     class basic_string
      |           ^~~~~~~~~~~~
/usr/include/c++/11/bits/basic_string.h:85:11: note:   ‘std::__cxx11::basic_string<char>’ does not have ‘constexpr’ destructor
In file included from ../include/image.hpp:26,
                 from ../include/swapchain.hpp:25,
                 from ../include/vulkan.hpp:35,
                 from ../include/engine.hpp:26,
                 from ../src/main.cpp:22:

Attached is the full paste of the error. 04_01_2023__crypt_underworld__compile_err.txt

[spinnylights]

Yes, that's because the codebase (at least at the moment) uses some C++20 features that GCC 10 doesn't support (I'm using GCC 12.2.1). In this case it's constexpr std::basic_string. That variable could just be const instead without breaking anything, so for the sake of supporting earlier GCC versions we could change it to that. If not I should add a feature test for constexpr std::basic_string to the build process—I haven't updated the compiler checks since pretty early in the development process so they're woefully inadequate right now I'm sure.

There's a lot of things like this in the codebase I've been betting on being able to use—GCC 11 added support for most of the remaining C++20 features GCC 10 lacked, and Debian Testing is on GCC 12 now, so I was figuring that by the time anyone else was working on it maybe everyone would have moved to GCC 12 and I wouldn't have to worry about it. :stuck_out_tongue: If you want to work on it now, though, that implies that GCC 10 support is more important than I was anticipating. Off the top of my head it's hard for me to say how much would need to be changed to make that happen, but of course it's definitely possible.

For the immediate time being, if you just want to get it building right now, you may have better luck if you use GCC 12 or at least 11. I'm willing to alter the codebase to be GCC-10-compatible though—if there's any interest in this project right now it's important, since even just for the sake of distributing binaries we'll have to worry about libc compatability. One thing I will say though is that I would prefer to make a large structural change to the codebase like that after unit tests are in place; I haven't added any yet because the code has been in rapid flux and pretty experimental and so on, but if I'm going to do something that would invite regressions that tells me the time has come to pin things down a bit. That will be a project in-and-of-itself so it may take some doing to get all the way to the older-GCC -friendly point, but I think that's a reasonable roadmap for the immediate future.

If you want to put together a list of required development packages for your distro (or any other), feel free, that would be a big help! ^^ EDIT/P.S.: I think right now the only two build dependencies (aside from the Autotools) are SDL and Vulkan, including whatever development packages the distro might provide. Once I reach the point of adding new features again, I'm planning to also introduce a dependency on SQLite, so although we don't have to worry about that now it's maybe worth keeping in mind.

[spinnylights]

3

[Iseeicy]

I'm willing to alter the codebase to be GCC-10-compatible though—if there's any interest in this project right now it's important, since even just for the sake of distributing binaries we'll have to worry about libc compatability.

One thing I will say though is that I would prefer to make a large structural change to the codebase like that after unit tests are in place;

This makes sense. I'm def not expecting any huge changes to the codebase right now - I think it makes sense to get what is already here working. I'm going to venture into trying to get GCC 12 working on my machine so I can compile on my end!

[Iseeicy]

Hm, after upgrading to gcc / g++ (what is the difference here?? I'm new) 12.1.0, it builds a bunch of files but chokes here:

g++ -std=c++20 -DPACKAGE_NAME=\"Crypt\ Underworld\" -DPACKAGE_TARNAME=\"crypt_underworld-UNKNOWN\" -DPACKAGE_VERSION=\"UNKNOWN\" -DPACKAGE_STRING=\"Crypt\ Underworld\ UNKNOWN\" -DPACKAGE_BUGREPORT=\"https://github.com/spinnylights/crypt_underworld/issues\" -DPACKAGE_URL=\"\" -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -DHAVE_VULKAN_VULKAN_CORE_H=1 -DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -DPACKAGE=\"crypt_underworld-UNKNOWN\" -DVERSION=\"UNKNOWN\" -I. -I..    -I../include -pthread -D_REENTRANT -I/usr/include/SDL2 -g -O2 -MT src/crypt_underworld-shader_module.o -MD -MP -MF src/.deps/crypt_underworld-shader_module.Tpo -c -o src/crypt_underworld-shader_module.o `test -f 'src/shader_module.cpp' || echo '../'`src/shader_module.cpp
../src/shader_module.cpp: In constructor ‘cu::ShaderModule::ShaderModule(cu::Device::ptr, std::string, const cu::BinFile&)’:
../src/shader_module.cpp:57:41: error: passing ‘const cu::BinFile’ as ‘this’ argument discards qualifiers [-fpermissive]
   57 |     : ShaderModule(l_dev, name, file.u32(), file.size())
      |                                 ~~~~~~~~^~
In file included from ../include/shader_module.hpp:27,
                 from ../src/shader_module.cpp:22:
../include/bin_file.hpp:62:26: note:   in call to ‘const uint32_t* cu::BinFile::u32()’
   62 |     const std::uint32_t* u32()
      |                          ^~~
make[1]: *** [Makefile:870: src/crypt_underworld-shader_module.o] Error 1
make[1]: Leaving directory '/home/iseeicy/crypt_underworld/build'
make: *** [Makefile:418: all] Error 2

Any thoughts? Thanks big time for your help so far, it looks like I'm getting closer!!

[Iseeicy]

Hm. I think I know just enough to be dangerous here rather than helpful, but declaring cu::BinFile::u32() as a const function resolves this build error. Will the project function as intended if I make this change..?

This

const std::uint32_t* u32()
{
    return reinterpret_cast<const std::uint32_t*>(dta.data());
}

changed to this

const std::uint32_t* u32() const
{
    return reinterpret_cast<const std::uint32_t*>(dta.data());
}

[Iseeicy]

^ Extra info on the above, blindly changing this fixes the compile error but I get a segfault when running the compiled project :(

[spinnylights]

^ Extra info on the above, blindly changing this fixes the compile error but I get a segfault when running the compiled project :(

Yes, unfortunately that's expected just at the moment which I forgot, you're doing a very good job of catching me out :sweat_smile: Try running it from the build directory as ./crypt_underworld -m shaders/comp.spv—you should see a little animation. It doesn't deal gracefully with not being passed a compiled compute shader with the -m flag right now. Obviously that's not the intended behavior ultimately, it's just an artifact of the state I left the project in after getting it displaying graphics back in January.

I wouldn't commit code to a "real" public repo that had these kinds of issues, but I have to sheepishly admit that I wasn't really thinking of this that way; I was going to get it rendering 3D graphics, tidy everything up, and then post an update on the old Kickstarter about it. But I'm very pleased that anyone is taking an interest now. Basically, a few months ago, I got it doing something visible, realized I needed to study math more before tackling the 3D engine, and just left the project in a kind of messy state to come back to after I learned the additional math. That's what I've been doing since then (I just learned about the trigonometric functions from the perspective of calculus!! They're so cool and I can't stop talking about them!! :smile_cat: anyway...). So, it needs some tidying up to really meet the proper standards of a public free software project, I would say. Of course, unit tests will go a long way towards supplying that.

I'm not sure exactly how that problem with BinFile ended up in the repo here but it was probably just the result of a sloppy commit on my part, I think 64dbf59 to be specific (sorry about that!). My local copy of the project doesn't have that issue (I made the same change you did so you're on the right track there :wink: ); to be honest there's a fair amount of uncomitted, tentative code on my computer right now. For the sake of writing the unit tests I need to make some hard decisions about what to keep and how there anyway, so these problems should go by the wayside shortly (that's what I've been working on since yesterday).

[Iseeicy]

...Obviously that's not the intended behavior ultimately, it's just an artifact of the state I left the project in after getting it displaying graphics back in January...

Totally get it, this is how all of my public repos are so no shame 😊

... I got it doing something visible, realized I needed to study math more before tackling the 3D engine, and just left the project in a kind of messy state to come back to after I learned the additional math. That's what I've been doing since then (I just learned about the trigonometric functions from the perspective of calculus!! They're so cool and I can't stop talking about them!! 😸 anyway...)....

I've been very lightly keeping tabs on the render tests - the math-side of graphics is completely beyond me but it's still exciting to see progress.

...so these problems should go by the wayside shortly (that's what I've been working on since yesterday).

Copy that!

[Iseeicy]

I'm nearly ready to close this issue (considering I know how to include SDL & Vulkan now!) - I know that you're going to bring in a bunch of uncommitted code soon, but I want to make sure I'm on the same page and as far as I can get w/ the current commit.

Passing in the computer shader with ./crypt_underworld -m shaders/comp.spv presents this empty window - is this something I should expect, or should it be that test circle?? (This is from an Ubuntu 22.04 VM in VMBox. I don't think Vulkan is the issue, because the vkcube command displays a cube demo correctly)

[Iseeicy]

If this is not what I should expect, here is what I get if I enable log output: 04_03_2023__crypt_underworld__black_screen_log.txt

[spinnylights]

Wow, interesting! That is definitely not the intended behavior—you should see some graphical stuff happening in that window. Thank you for sending the log, that's a huge help! It looks like it's failing to acquire swapchain images but also failing to notice that it failed to acquire them. :P So um, there's probably a check missing somewhere. Why that problem is happening in general, though, I'm not sure. Would you be willing to send the log also with the -d flag (so ./crypt_underworld -ld -m shaders/comp.spv > $log_name.txt or w/e)? That enables the Vulkan validations layer which may help track down what's happening here. (As I write this I'm kinda thinking Vulkan validations should be on by default if you pass -l and maybe there should instead be a switch to turn them off—I almost always use -ld right now because they don't add a lot of noise to the log and they're very helpful. Note for the future, I guess.) Thanks for letting me know about the vkcube demo—that's reassuring (and provides a known-good working example! ^^).

As a side note it's really great to have someone testing this in a different environment, so thank you for doing that. I've run it on my and Lily's computers but it's a much stronger and more useful test to have someone doing this at a distance. Don't worry about running it in a VM—as long as Vulkan works there in general I'd definitely like to make sure the engine does too.

[Iseeicy]

Would you be willing to send the log also with the -d flag

Sure thing, coming right up!

it's really great to have someone testing this in a different environment, so thank you for doing that.

🦾 I figure it's the least I can do to help

Don't worry about running it in a VM—as long as Vulkan works there in general I'd definitely like to make sure the engine does too.

As we work through this I'm also testing it with WSL2 (which has Vulkan support now apparently...?), and then verifying it with an Ubuntu VM. I'd dual boot and run Ubuntu natively but my current Ubuntu partition is practically full + it'd be cool to see this running through WSL2!!

[Iseeicy]

@spinnylights here is that better log 04_04_2023__crypt_underworld__black_screen_log_ld.txt

[spinnylights]

Thank you, that did point out the issue I think! Try building from the latest commit? Hopefully it will work this time.

As a side note, sorry for my slow pace in addressing all this stuff. I have severe ADHD + Tourette's syndrome, and normally I take medication for it that allows me to basically function at the level of a normal person, but because of the nationwide shortage I haven't been able to fill my prescription for weeks, so as it is right now I think it takes me about ten times as much effort as normal for about a tenth of the results. I guess I just want to say like, it's not for lack of effort or concern that it's taking me so much time. You've been very gracious and I appreciate your patience. Hopefully the shortage will end soon and I can go back to my normal life.

[Iseeicy]

...sorry for my slow pace in addressing all this stuff...

Absolutely no problem. I totally get it, there are some people close to me that are struggling right now for the same reasons. I have my fingers crossed that the shortage will be resolved soon...!

I appreciate your patience

This has been a fun pace for me actually, it's great to clock out of work and make just a little bit of progress each day.

[Iseeicy]

...and without further ado:

The shader test now runs!!! and it runs through WSL2!!! woah!!!!

[Iseeicy]

I guess that means this issue is complete! I believe the install steps I've written in #6 are good to go, and include some examples of how to include the SDL & Vulkan deps, and get the project to run. Woo!!!

Thanks for helping @spinnylights !

[spinnylights]

My pleasure, congrats!! ^^ It's very pleasing to me to see it running at a distance like that. Thanks for your efforts (and for being understanding of my slow pace—I'm glad it works nicely with your daily rhythm at least).