Jump to content
  • Advertisement

Wyrframe

Member
  • Content Count

    1433
  • Joined

  • Last visited

  • Days Won

    2

Wyrframe last won the day on May 15

Wyrframe had the most liked content!

Community Reputation

2487 Excellent

About Wyrframe

  • Rank
    Contributor

Personal Information

  • Role
    Programmer
  • Interests
    DevOps
    Programming

Recent Profile Visitors

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

  1. Why would you parameterize that with a macro, when you can just isolate that implementation detail into its own .CPP? // service.h #pragma once class ServicePayload { ... }; class Service { public: void send_operation(ServicePayload const &); void default_operation(void); }; // common/service.cpp #include "../service.h" void Service::default_operation() { ServicePayload basic( /* ... */ ); send_operation(basic); } // windows/service.cpp #include "../service.h" #include <windows.h> void Service::send_operation(ServicePayload const &p) { // ... } // linux/service.cpp #include "../service.h" #include <iostd.h> void Service::send_operation(ServicePayload const &p) { // ... } ... and then always link against common/*.o, and link against only windows/*.o or linux/*.o depending on which EXE you're building.
  2. That's... not what I said. What I said was, your syntax is wrong, and your description of how you think the language and its compilers works, is wrong. I then illustrated how you could get the access to the "T" used in parameterization by giving it an explicit name, by using the type system the way it actually works. Reading back to @l0calh05t's description, I think what you're talking about is this "explicit [self]"... class MyClass(object): def __init__(self, x, y): self.x = x self.y = y To which my counterpoint is, which of these functions has a `this` implicit variable? int foo::bar(void) { return 42; } int foo_bar(void) { return 42; } To wit: you can't declare non-member functions while defining the interface of a member-possessing structure, so don't try... and when not defining the interface of such structures, you have to explicitly name the type to which you are defining a member by using :: syntax. So where is the ambiguity? Either the function declaration is inside a structure definition, or it has a :: in the name.
  3. You seem to be confused about the distinction between types and members. "T" in those examples is a typename, not a variable. The operator -> expects an rvalue and an lvalue (both of which are values, not typenames) as its operands, respectively. You might be mistaking it for the operator :: which expects a namespace or typename, and a typename or member, respectively. If you have conflicts between a nearby T and a distant T, that's a design error you've made, not a syntax problem for the language to solve for you. If you need to expose the type T to users of your class, the correct syntax would be something like... template <typename T> class Bar { public: typedef T value_type; value_type val; Bar(T foo); // Mutates 'foo' somehow and stores it in val. }; // ... template<typename X> X use_bar(X reference) { auto transformed = Bar<int>( (int) 7 ); auto minval = std::numeric_limits< decltype(foo)::value_type >::min(); return minval + transformed.val; }
  4. In main.cpp, you're #include'ing Game.cpp and TextureManager.cpp, instead of Game.h and TextureManager.cpp.
  5. That is a plausible solution. Try it, and see if it's performant enough for you. If you're worried about efficiency... which kind of efficiency are you worried about? Mesh count? Configuration ease? Ability to dynamically create enemies of various kinds? You also don't need to use the same type of actor for all situations. Having an "attached armour piece" actor with a mesh while it's on-bone, which deletes itself and creates in its place a "detached armour piece" actor using the same mesh, so that you can decouple or even parameterize the two sets of behaviours independently, is a perfectly legitimate strategy.
  6. What Sacaldur and I are trying to tell you is that an organization tree and a transformation heirarchy tree are orthogonal concepts, that their definitions have no interrelation. If you choose to implement it by mixing them as heterogenous types of node in a single tree, that's your choice, but you might find it easier or nicer or more reliable or more performant or... to have them instead be two (or more) separate systems. I fear you've misunderstood. That 3-way field is an optimization declaration, used by the engine to discover the boundaries of where it can do mesh/material combining and physics baking and such. It's related to the transformation heirarchy, but it's not a way to opt out of it; it's a way to flatten it by declaring what objects cannot be moved at runtime (relative to their parent's coordinate space). There is no way to prevent a transformation-heirarchy child from moving with its parent (assuming you have a working transformation heirarchy), although you can compensate for it by manually adding an inverse transform to that child whenever you add a positive transform to its ancestors. Mind the cumulative error term. Again; organization parentage is not transformation parentage. You will get a lot of mileage out of not conflating or combining the two.
  7. Graphs are hard to visually represent, but trees are easy. The UI doesn't make them easy to spot. In Unreal's editor, you have access to a bunch of UI organization tools that are not part of the transformation heirarchy. Folders, Layers, Levels. With the exception of Folders, which are discarded at build time, you can iterate over those as easily as iterate over the transformation heirarchy. These are all parts of a graph which has nothing to do with transformation. In UE4, at least, blueprints are composed of two varieties of components; those which are part of a transformation heirarchy, and those which are not. When you instantiate a blueprint, you're actually instantiating a statically-flattened version of that blueprint, all the way to the root blueprint inheritance nodes. If you have static meshes at several layers of the inheritance, for instance, and all set as Dynamic or Static, instead of Movable, they actually get baked into a single megamesh up to the nearest Movable point in the heirarchy (give or take batch size contraints). All connections between objects are part of the scene graph; even when the editor doesn't provide a visualization for them. If in Unity or Unreal you set up a "Gang Boss" relationship between a bunch of mooks and their elite leader by assigning the leader object as the value of the myBoss field of the mooks, that's part of the scene graph, too. And either the engine or the mook's code will have to be able to handle the situation that the boss just got excised from the scene graph by a player's sword.
  8. You seem to be operating under a misapprehension of what a graph is, versus what a tree is. Relationships in one space (e.g. transformation heirarchy) does not need to have any relation whatsoever to another space (e.g. order and nesting shown in the GUI map editor; or inheritance of textures & shaders; or model used to render; or connection to the "sector/level" which an object was loaded with and should be unloaded with; etc). A scene graph is a way of describing and defining the relationships between your objects, as a means of codifying and prescribing how you implement those relationships and objects... not merely a tree that happens to be notionally created by adding an `SceneObj *parent;` field to all your SceneObj's.
  9. 👍 I guess I understand the autocomplete fail, but that doesn't mean you have to keep the "new T(" prefix after you've gotten the help. Unless VS doesn't detect it properly as a reference to the constructor when you're refactoring/searching for references, either? Does VS understand move constructors well enough to suggest the insertion without the new? e.g. `.emplace_back(T(...))`? Although I guess that requires you haven't deleted or disqualified your move-construction operator (that is, `T(T&&) noexcept`).
  10. 99 little bugs in the code, 99 little bugs, Take one down, patch it around, 117 bugs in the code! In all seriousness, when fixing one bug causes two more to raise their heads, that suggests to me that the act of fixing the logic or design failure which induced the one bug, you also produced the side-effect of scraping away the crud which was hiding the other bugs... ... and that would corroborate it. You might feel like the code is "fixed", but you should reconsider from a design perspective how you even reached that point. In particular, if you're using C++11 or C++17, and your application code includes any uses of the new/delete operators... you probably have a bug you haven't spotted yet.
  11. We're missing some important context, here... it sounds like you are using Unity? You should try some Unity-specific forums (either the Middleware subforum here, or another forum). That said, from what I know of Unity, it sounds like you need to add the "edge grab" colliders to the components of your "specific corner tile" prototype. When that tile is instantiated, it will come along with all its components.
  12. Wyrframe

    adopting to C++17

    https://en.cppreference.com/w/ The entire standard library docs, which includes rich notations on which parts were introduced when, and which parts were deprecated when. And watch lots of CppCon talks on YouTube. Especially the ones by Jason Turner, Andrei Alexandrescu, and all the guys who work at Facebook. This video is an amazing eye-opener about the C++ mantra "you don't pay for what you don't use"...
  13. I've had to handle streams of continuous events (as in, plural dozens per second, not several per minute) only in two contexts. In one, eventual consistency was adequate. Events don't need to be sorted except against internal resolution. For this, each broadcasting subsystem had their events in a rotating buffer, and it doesn't matter if events get consumed from different subsystems in different orders, so long as events from the same subsystem are processed in order. In particular, events are generated by each subsystem by only a single thread, so there is no lock contention or unfairness between generators inserting into the queue. In the other, order of processing was of critical importance, but there was only one thread which could generate events. I set it up so that events were processed at the top level of the loop, so no processing of events can be done until all possible event generation in response to the previous event has been completed. Sorting was thus a natural property of the event-response cycle, where event propogation is by definition asynchronous, and you can't block on the event broadcast waiting for a response. Without knowing more about your problem space and its timing constraints... I think if you have to respond to events in a very specific and critical timestamped order, you need to establish an upper bound of how long you're willing to hold on to an event, waiting for events older than it to arrive, before that event can be processed. Your heap should be fine, just don't pop the head element from it until it is at least a certain threshold age. If the access patterns you're talking about are cache friendliness... don't. Unless you can fit several event structures in a single cache line, it's not going to matter.
  14. Wyrframe

    World position from depth

    Have you verified that your visualization lines work as intended? Have you tried adding a few on constant vectors, and making sure they show up as you expect them to? Are you certain you're casting the lines once, saving them, and then viewing those same lines later, and not accidentally re-calculating some part of them based on the constantly-changing depth buffer you're using to view them?
  15. Photoshop and GIMP work with huge images by loading them as a number of smaller tiles; something configurable but on the order of 256px² each.
  • 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!