Jump to content
  • Advertisement

GuyWithBeard

Member
  • Content Count

    536
  • Joined

  • Last visited

Community Reputation

1911 Excellent

3 Followers

About GuyWithBeard

  • Rank
    Advanced Member

Personal Information

  • Role
    3D Artist
    Level Designer
    Programmer
  • Interests
    Art
    Design
    Programming

Recent Profile Visitors

13242 profile views
  1. GuyWithBeard

    DirectX 11 Device context queston.

    Excellent explanation MJP, thanks. I have been using deferred contexts solely because they more closely match the command list/command buffer concept used by DX12/Vulkan. While I support all three APIs my renderer is in fact still single threaded so I haven't done any serious multithreaded command submission yet, which is why I haven't looked all that much into the performance of the deferred contexts vs. immediate contexts on my AMD machine.
  2. GuyWithBeard

    DirectX 11 Device context queston.

    Hmm, where did you read that? I have been using deferred contexts quite happily for the last year or so. My main development machine has a Radeon RX 580.
  3. GuyWithBeard

    Symbol lookup error on Linux

    Allright, I actually got it working, but I am not sure why it didn't work yet. So, I had a look at the problematic call, and as I suspected it was surrounded by #ifdefs (usually profiling code like this can be compiled out). #ifndef BT_NO_PROFILE CProfileManager::Reset(); #endif //BT_NO_PROFILE All I did was make sure BT_NO_PROFILE was defined when compiling both the plugin library and bullet itself. Not sure why I would have to do this though, as I have used the exact same way of building everything on OSX and Windows. But it works and that's the most important thing.
  4. GuyWithBeard

    Symbol lookup error on Linux

    I don't doubt the Bullet source code is "correct". I meant I should check if the call in question is surrounded by #ifdefs or something similar which would explain why that one symbol is missing, maybe I am compiling it wrong. I am quite sure my building or linking to Bullet is to blame here... I should also add that I have almost no first-hand experience building for anything other than Windows. Anyway, this will have to wait until my current task is done.
  5. GuyWithBeard

    Symbol lookup error on Linux

    Yeah, I need to have a look at Bullet's code and see if there is anything related to that one call that could cause this. Thanks!
  6. GuyWithBeard

    Symbol lookup error on Linux

    I don't quite understand what the problem is. I have a shared object library, libBulletBackend, which links to Bullet which is a static library. This obviously happens at compile and/or link time. Only the shared object library uses Bullet internally. My exe then loads the shared object library at runtime through dlopen() and uses its public API, ie. not Bullet. The so has a class Scene with a method step(), which is called by my exe. The step() method calls Bullet's stepSimulation() method internally. For some reason this results in the following error: symbol lookup error: libBulletBackend.so: undefined symbol: _ZN15CProfileManager5ResetEv I am quite aware that the exe does not link to Bullet, nor do I want it to. What I don't understand is why this lookup fails because Bullet should have been linked to the so already at compile/link time.
  7. GuyWithBeard

    Symbol lookup error on Linux

    To be clear, I don't reference the static library outside of the shared lib that links to it. That would obviously defeat the purpose of the plugin in the first place.
  8. GuyWithBeard

    Symbol lookup error on Linux

    I do use makefiles but they are generated by CMake and I don't exactly know how to read (or write for that matter) them. I don't use libraries form the standard paths, but I have every library set up manually in CMake with their proper paths and the libraries get linked to properly. I can create bullet dynamic worlds properly, ie. the library is linked to correctly. It is only when I call one specific method, ie. when I start stepping the simulation, that this one symbol is resolved which leads to the crash.
  9. Hi, I am porting my engine to new platforms and I have a symbol lookup error when trying to load a plugin on Linux (Ubuntu 18.04). First a little background: My app links to a core engine library which contains mostly platform-independent code. Functionality is largely brought in through plugins, ie. DLLs/SOs loaded at runtime. This works great on Windows and macOS but now I have trouble loading my Bullet Physics backend plugin on Linux. When trying to step the world I get the following error: symbol lookup error: libBulletBackend.so: undefined symbol: _ZN15CProfileManager5ResetEv The shared object libBulletBackend is the dll loaded at runtime through dlopen(). I hunted down the symbol _ZN15CProfileManager5ResetEv and found that it is the CProfileManager::Reset() static method in the LinearMath static library which is part of bullet. If I run "nm -C libBulletBackend.so" and search for the symbol it is in the list with a "U" in front of it which, as far as I know, means that it is indeed undefined. However, when I run "nm -C libLinearMath.a", ie. on the static library directly the symbol has a "T" in front of it, ie. it is defined. So in short, I build a shared lib which links to a static lib and a symbol from the static lib gets lost in the process. What is the correct thing to do in this case? Am I missing a linker flag or something? Thanks!
  10. Now that Apple platforms have semi-official support for Vulkan it makes Vulkan the graphics API to target if cross-platform support is important for you. It is still not supported on all platforms (eg. Xboxes still support only DX and Sony has their own APIs too) but porting from Vulkan to another low-level API is actually not that difficult as opposed to porting from, say, OpenGL to DX11. Another option would be to look at a library like LLGL which abstracts away most (but not all) of the API differences and gives you a somewhat unified API to work with.
  11. GuyWithBeard

    Targeting both Win32 and UWP

    Excellent, yeah it seems like it was added in 2015. There is no such project type in VS 2013. Thanks for your help, I have some stuff to try out now
  12. GuyWithBeard

    Targeting both Win32 and UWP

    Sounds like something I should look into. Is this a scenario VS supports directly? Eg. what kind of project is the shared code project? Do you have to make it an actual C++ project (and if so, what kind?) and then just skip building it when building the solution or is there a special project type for these kinds of things? Thanks!
  13. GuyWithBeard

    Targeting both Win32 and UWP

    Interesting. Does the shared project produce a library which is then consumed by the other projects, or is it just a container for the shared code in VS?
  14. Hey folks! I have a question about how I should organize my Visual Studio project and/or solution to allow targeting both Win32 and UWP with as little resistance as possible. Currently my project consists of a game exe project and a few dll projects, all sitting under the same solution, and all targeting plain old Win32 with Visual Studio 2013. I have been thinking about porting the project to UWP for some time now, mainly to be able to run on the Xbox, but there are some things I haven't wrapped my head around, mainly how to organize the projects in Visual Studio. As far as I know, to build for UWP I would need to update to VS2015 and I would need to make the project an "app container" project. Codewise there shouldn't be that much to do, except change the main loop to work through the CoreApplication system as well as remove some uses of LoadLibrary() etc. However, it seems that if I change the project to an "app container" project I loose the ability to build for Win32. I was hoping I could simply add a new UWP configuration to the solution which would make all projects build "app container" targets, but that does not seem to be possible. Creating a new empty UWP project in VS and opening the vcxproj file up in a text editor reveals things like this in the "Globals" property group: <AppContainerApplication>true</AppContainerApplication> <ApplicationType>Windows Store</ApplicationType> <WindowsTargetPlatformVersion>10.0.14393.0</WindowsTargetPlatformVersion> <WindowsTargetPlatformMinVersion>10.0.10586.0</WindowsTargetPlatformMinVersion> <ApplicationTypeRevision>10.0</ApplicationTypeRevision> Namely, they are not part of a configuration, but instead make the whole project an "app container" project. What I would like to do is have one project (eg. the exe of the game) where I could flip between Win32 and UWP easily through configurations, using #defines to enable/disable parts of the code that does not apply to the current configuration. Is there a way to do this? One way I have been thinking about is having the Win32 project be the "main" project and have a UWP project which simply includes links to each and every source file in the Win32 project. This sounds cumbersome and error prone and I would like to avoid it if possible. Another way would be to autogenerate both projects with something like CMake, SharpMake or premake, but I would not want to get into that either right now. Any other options? Cheers!
  15. GuyWithBeard

    Networked Physics sanity check

    Seems like a solid version of the Quake networking model. We do something similar, except we keep the server ahead of the clients, ie. we never extrapolate on the clients, only interpolate. One thing missing from your description is lag compensation. Depending on the gameplay this may or may not be needed, but if you have hit-scan weapons you might want to have the server doing some kind of lag compensation, to counter the fact that the client and server are on different timelines.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!