Jump to content
  • Advertisement

GuyWithBeard

Member
  • Content Count

    542
  • Joined

  • Last visited

Community Reputation

1918 Excellent

3 Followers

About GuyWithBeard

  • Rank
    Advanced Member

Personal Information

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

Recent Profile Visitors

13393 profile views
  1. https://docs.microsoft.com/en-us/windows/uwp/xbox-apps/
  2. Yes, Bullet3 runs on the GPU afaik. Bullet2 (which is still regularly updated) runs on the CPU. When setting up PhysX you provide it with a dispatcher, which the library uses to do its work. There is a default one which sets up a thread pool and uses that, ie. it runs on the CPU too, or you can provide your own. You can also run parts of the simulation on the GPU, although I don't have any experience with that. This is a difficult question to answer, because it worked like that from the very beginning. There is actually very little up-front work to do to make it work like this. Basically you need to: Make sure the simulation code does not use any Unity code (it is easy to make the server compilation fail, by accidentally using unity code later on), but this is easy to do if you know of the limitation from the start. Write some kind of bootstrapper for the server code. This can be a simple as a main method which starts up the server loop. On the client this is typically handled by the game engine, ie. Unity in this case. (Optional) Write tests that verify that the code behaves the same on both C and S. When we did this Unity was using a very old Mono runtime, which caused some headaches. Certain code behaved differently on Unity vs the MS .net runtime. Afaik Unity now uses a more modern runtime, so this might not be an issue. There could still be some problems, eg. if you run the clients on ARM hardware and the server on x86 etc. I am glad you figured it out, good luck with your project!
  3. As for simulating the server-side physics, there are several ways to do that. You can write all of your physics code yourself, which may or may not be feasible. That way the exact same code can run on the client and server. Another way is to use a physics engine. If you are using C# you may have to use a wrapper for this as most physics engines are native code. I have used a wrapper for the ODE physics engine in the past. AFAIK there are c# wrappers for Bullet as well. Unity obviously uses PhysX under the hood so you may have to experiment a little to get your server-side physics to match the client(s). This is also true if you use PhysX directly on the server, as Unity has its own layers in between in the game code and the raw physics code. This is what I was referring to earlier (the "tinkering" part). However, with state replication, you'll be doing gradual corrections on the clients so it shouldn't be too difficult to get it working quite well.
  4. Well, the trick is not to use an engine for those parts. Write a "text" program in C++ (or C# or whatever you are comfortable with) and link to the physics library. In the case of Bullet this is a collection of headers/classes. Everything runs completely on the CPU. I do recognize this might require you to write parts of the simulation code twice, ie. once for the server and once for the client, but you can be smart about it. I have worked on a project in Unity where we separated the simulation code from the presentation code. The simulation code was not allowed to access any of the unity classes, only standard C# library code. This meant writing your own Vector3 classes and other helpers you needed to run the simulation. The presentation code was allowed to reference everything in the simulation code + all of unity, and it was responsible for rendering (or "presenting") the world. The simulation code was then easily packaged into its own C# "console program" and run on a server without Unity.
  5. That is exactly my point. You can make the server a windowless program. It won't require any graphics hardware, it won't even require a window system. I don't see how this is incompatible with server authoritative physics. You can have a system where server instances are spun up depending on need and player count. (Obviously this all depends on the game type). If the server is only responsible for simulating the gameplay-relevant physics and propagating that to all clients you can even attempt to run multiple server instances on a single machine. Anyway, you seem to have a direction you want to go, so that's probably what you should do.
  6. Does the server have to be a c#/unity program? If server hardware resources are limited, I would set up a simple server program running the absolute minimal physics simulation you can get away with, on a physics engine such as Bullet. This would be authoritative over the player movement. You can then use unity, or whatever you are using to power your clients, to drive a local physics simulation on the clients for a kind of client-side prediction. These could also simulate extra visual objects that the server does not need to care about, for nicer visuals etc. Using two physics engines like this obviously requires a bit of tinkering to get them to agree on everything, but for simple player locomotion, that should not be that much work (disclaimer: I don't know if your locomotion is indeed simple).
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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!
  12. 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.
  13. 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.
  14. 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.
  15. 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!
  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!