Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

1648 Excellent

About Eternal

  • Rank

Personal Information

  • Role
    Voxel Artist
  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Eternal

    Compile time tricks

    The other advantage of the function template is that it can be overloaded, so it will still work if you ever decide to change to a different container. And for anyone new to C++ 'std::size' should be easier to remember than the sizeof trick.
  2. Consider https://github.com/fmtlib/fmt instead, as it's faster than Boost.Format and at least the formatting part of it will be in C++20 as std::format.
  3. A large number of profiling samples on an opening brace like that points to a stall of some kind. In this case there seems to be a lot of pointer chasing going on here: MapRectangleShapeBuffer((RectangleShape*)renderLayerManager.renderLayers[i]->renderables[j]); From the cast it looks like renderables is something like std::vector<Renderable*>, so for each iteration you're probably loading from main memory instead of from cache. And then it will also re-load the RenderLayer and the renderables vector/array again and again, unless the compiler can prove that nothing could possibly change them between iterations. To fix it: Store your "Renderables" by value, If you have different types of Renderables keep them in seperate vectors. Your for loop should look something like this: for(const auto& renderLayer : renderLayerManager.renderLayers) { for(const auto& sprite : renderLayer.sprites) //sprites is std::vector<RectangleShape> { MapRectangleShapeBuffer(sprite); } }
  4. I thought that implementing the default <=> operator would automatically implement all the other comparison operators? The syntax for implementing your own <=> is hideous, though.. They designed it to support all the cases where <=> isn't really the right operator to use (while trying to please everyone with academic correctness)... JS-style || chaining would be so much prettier. Yes, you do get all comparison operators if you implement/default operator <=>, but Oberon's point was that the default <=> should also be implicit, like copy assignment for example. Can you elaborate what you mean by JS-style || chaining and how it would help make things cleaner? I'm very unfamiliar with JS. I think you'll find lots of agreement on the odd naming (vector? map / unordered_map? iota? C++20's co_derp?). But at this point we're stuck with it. For the map thing: In most cases, if you don't need ordering, you want a hash map aka unordered_map (or a non-standard replacement), not map. Ideally unordered would be the default. Then for iteration, the "modern" way would be to use structured bindings like this: for(const auto&[key, value] : my_map) { std::cout << key << " : " << value << "\n"; }
  5. That's fair, and I don't know why implicit definition of operator== didn't make it, it was proposed at some point. I wouldn't be too surprised if it was just lower priority and will appear in C++23.
  6. Unless I misunderstand you're getting exactly that, plus auto-generated ordering: https://en.cppreference.com/w/cpp/language/default_comparisons
  7. With C++20 we're also getting defaultable equality and ordering operators along with operator <=>, so in most cases you'll have to write 0 or 1 comparsion operators yourself, instead of the whole set. It's already available in the latest version of MSVC and hopefully GCC and Clang won't be too far behind.
  8. Also make sure you're compiling in Release mode, with optimizations enabled.
  9. When in doubt... add more braces... (std::array is an aggregate of a C array of complex numbers): std::array<std::complex<float>, 3 > b = {{ {boundaryStrength, 0.0f}, {boundaryStrength, 0.0f}, {boundaryStrength, 0.0f} }}; This should work. Or using literals (which would be so much nicer without having to plaster using namespace statements everywhere you want to use them): using namespace std::complex_literals; std::array<std::complex<float>, 3 > b = { boundaryStrength + 0if, boundaryStrength + 0if, boundaryStrength + 0if }; Strangely enough, no extra braces necessary anymore.
  10. Eternal

    Motion-planning for spaceships with physics

    Okay, time for an update, took me a while to get back to this and make some progress. Thanks for your suggestions, even if my description of the problem wasn't the clearest. So here's a picture showing some examples of the trajectories I am trying to get. Starting positions at the origin, initial velocities (-1,-1) or (0,-2) and the dots on the graphs showing where the acceleration direction changes: But finding that point to switch acceleration (or the acceleration directions / times themselves) seems more difficult than I first thought. As for progress: I've given up on finding an explicit solution, even if it exists, as @SyncViews noted, it would probably be impossible to adapt it to any more complicated problems. Instead I've implemented a numerical solver using Newton's method, so basically the not-so-hacky version of starting with an initial guess and then adjusting depending on how far off the result was. So far, after fixing the initial bugs, this seems to work well, although I'm worried about stability issues. Time to write some more tests and then fix the problems if they actually exists... Now the next step is to make this a bit more flexible... Intercepting moving targets doesn't sound too complicated, I just hope I'm not totally wrong about that again! And then there's relaxing the "always accelerating" constraint, having a speed vs fuel use trade-off would be nice, but I'm not sure how to approach that yet.
  11. Hi, I am currently working on a 2d strategy game/simulation involving spaceships moving around in a solar system and have hit a problem I'm not sure how to solve. The basic idea is, I have a spaceship at some position and want to move to some other position, the ship can only accelerate along a fixed axis, with a fixed magnitude of acceleration, change of acceleration and orientation of the ship can be treated as instant. So far I've only dealt with the situation where the initial (and final) velocities were zero. Accelerate towards the target for half the distance, turn around, brake. Now I've been trying to extend this to ships already moving, without much success. I figured that I could still use the same approach of splitting the movement into two segments, first accelerating (or aligning the velocity with the vector towards the target) and then braking, as before, but I can't solve the resulting equations and I'm hoping one of you can help me or tell me that I'm stuck with numerical methods. The equations I have are: P=v0*t1+0.5*a1*t1^2+v1*t2+0.5*a2*t2^2 //We want to end up at our target v0+a1*t1+a2*t2 =(0,0) //and standing still with P being the target position, v0 initial velocity,a1, a2 and t1,t2 the direction vectors and durations of the acceleration burns and finally v1 = v0+a1*t1 the velocity after the first burn. And for example we can now eliminate a2 = normalize(-v1) and t2 = ||v1||, to leave only a1 and t1 as unknowns, but the result is still a mess that I can't solve. Does anyone have a suggestion?
  12. Eternal

    Creating a global thread

    The temporary is already an rvalue, so what's the std::move for? (And the lambda also isn't useful, if you don't need the capture.)
  13. Eternal

    Creating a global thread

    This should do it: std::thread t1; int main() { t1 = std::thread(functionToThread); t1.join(); return 0; }
  14. Have you rebuilt the library with the new runtime library settings? (And do the other build settings match?)
  15. Eternal

    Epoch Realtime Raytracing Demo

    Really nice. ~11 fps on a 3.2GHz AMD Phenom X4
  • 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!