LorenzoGatti

Members
  • Content count

    1965
  • Joined

  • Last visited

Community Reputation

4452 Excellent

About LorenzoGatti

  • Rank
    Contributor

Personal Information

  • Interests
    Art
    Audio
    Design
    Production
    Programming
    QA

Recent Profile Visitors

20364 profile views
  1. Really micromanaged audio programming (C++)

    Rigid? How can you feel constrained by an API that lets you fill a buffer with arbitrary samples and play them? Are you attempting something impossible like going back in time and altering sample buffers that have already been sent to playback? Are you disoriented because a relatively low-level interfaces forces you to do all mixing, synthesis etc. on your own with little or no help? Are you in trouble with some specific task? i'm sure these libraries are adequately organized into many modules, both in the actual DLLs and in header files for C and C++ and in namespaces for C++ and C#, and you'll be able to leave out unneeded parts. And even if you accidentally linked your program with something pointless, it would be very unlikely to cause trouble with OpenGL.
  2. 3D Emulate FAST tripple buffering in Direct3d9

    Can you also explain what do you mean by emulating triple buffering? Either your rendering occasionally halts to wait for the previous frame to be presented in full before reusing its buffer or it doesn't wait because it writes to a different buffer, there's no middle ground.
  3. Status Effects (Buffs Debuffs) in an ECS Architecture

    A set of indices instead of a single index would imply a significantly greater complexity, e.g. because values have a variable size, with performance ranging between slightly worse and much worse. But all suggestions so far simply don't need this kind of multidictionary (linking an entity to the set of its buffs) because they are about navigating the association only in the opposite direction (from a buff to the entity it affects), which is simpler, "more ECS", more flexible, etc.
  4. C++ General C++ class questions

    Regarding exceptions from the constructor, in a good design the constructor should put the object in a reasonably complete and valid state; doing it without throwing exceptions is nicer, but if the constructor needs to do something that throws exceptions, handling exceptions (typically by throwing the towel at a fairly high level) is less inconvenient and less dangerous than handling invalid objects (everywhere and every time). "Initialization" methods should be present for a specific reason: they are optional, they need to be called multiple times (e.g. to recycle old object in a pool), you don't know whether you want to call them (e.g. mutually exclusive alternatives like digesting two different types of 3D model), they cannot be consolidated into the constructor (e.g. the object is constructed in one thread and completely initialized in another thread), etc.
  5. Creating card template around mechanics?

    The example card images in your post are fine for a prototype. Pick the easiest one to draw, add and remove lines and markings as stats and attributes come and go, and worry about graphics only after playtesting fixes the game rules and the card ontology they rely on. For example, you might find out that the bone club attack is a good fit only for certain troops and others should have nothing, or a special attack that works differently, or up to N different special attacks; only after determining all the variants of this sort of thing you'll be able to consider what graphics for them look good and are easy to read and distinguish.
  6. It's not like you have the option to not take object ownership seriously. Whatever you do, your objects will need to be allocated before use, kept live with valid pointers while they are in use, and deleted or recycled after use, with the risk of errors resulting in dereferencing null or invalid pointers or prematurely destroying data. You need to be sure that your smart pointers do what you want, with the same standards and the same complexity as manual memory management. You aren't doing less memory management only because it's hidden away in a class; explicitly deleting pointers only means that your needs aren't a good fit for the available smart pointers, object pools etc.
  7. C++ IO approach in engine/framework

    You should not only avoid assuming all files exist within a common root, but also support a choice of multiple possible locations for various groups of writable or temporary files (e.g. saved games in the official recommended location in the user profile or in an arbitrary user-specified path on Windows, downloaded updates in a path with plenty of space and no backup) and a hierarchy of places to load read-only files from (e.g. levels from arbitrary user-selected archives, overriding user-installed packages of assets, overriding patch archives of changed and added core assets, overriding the originally shipped archive of game assets). Note that some of these locations might not be proper files (e.g. some console-specific API for saved games and downloaded content, or virtual file systems from inside an archive); separate abstract locations and maybe names for various resource types from the lower-level concern of actual access to a file system.
  8. Cache Coherency and Object Update

    What are these proxies? surely the same mesh data structure can be updated or replaced by an animation/movement update in one thread and read out to be rendered in another thread, and the two (or more) threads can simply iterate over all meshes in use, in the same data structure, in a plain producer-consumer pattern. You just need to ensure, with appropriate locking, that the rendering thread doesn't attempt to render meshes before they are updated; there's no need to create "messages" for each mesh. For example, if there is a collection of "mesh" components (or "mesh animation state" components, referencing shared immutable and read-only mesh data) and the threads process items in order, you only need to maintain the index of the last updated mesh.
  9. Cache Coherency and Object Update

    This makes BusData an abstract type. Even if you are bending over backwards to avoid ordinary polymorphism and virtual method calls, you still have an abstract class that contains infrastructure but no useful data, several derived concrete classes that add useful data, and an update processing that treats these objects uniformly (everything is a BusData) as far as possible.
  10. It seems to be a known misunderstanding of SDL API. Your joystickIdToGamepadMap is written and read with incoherent indices from different event types. See https://discourse.libsdl.org/t/controllerdeviceremoved-which-increments-on-each-unplug/21019/2
  11. You can write an ad-hoc code generation tool with any text templating system. I tend to use the string formatting features in Python: templates for different files and fragments can be placed in easy to write and freely indented multiline strings, placeholders support padding and numeric formatting if needed, input data can be produced in a dictionary and referenced by name, file handling is easy and convenient, data structures and facilities to manage iteration, staged transformations, file fragments etc. (e.g. list and dictionary comprehensions) are very powerful and convenient. You might be able to dispense with input files and place lists and dictionaries of source data in the code generation script. Another possible simplification is receiving a fixed set of output file names (e.g. a pair of .cpp and .h files) as command line parameters.
  12. Any gun enthusiasts here?

    No. The performance difference in different guns depends only on barrel length (less power is wasted with a longer barrel, as gases have more time to push the bullet forward before dispersing) and rifling. The bullet is the same (provided it isn't damaged in strange ways) and the power of the charge is the same. Moreover, cartridge size is usually as large as possible given constraints on weapon size, weight and number of shots (if you need more, they need to be smaller), and of course unit cost.
  13. Constexpr doubt :/

    Declaring a function constexpr means that it is "certified" for compile-time use, to compute constants, in addition to being compiled and callable like a non-constexpr function. In your program there is no call with constant arguments (which would be optimized away) and the two functions are basically identical. See them on Godbolt: https://godbolt.org/g/JJ4LsQ
  14. Focal Point Question, Computer Graphic

    The focal distance BZ is the distance between a point (the camera location) and a plane (the image plane). Both are under your control, so the computation is straightforward. There are very simple formulas. Of course, as Hodgman noted, BZ doesn't have any useful role to play. Can you explain why you care about this distance?
  15. Regarding correctness, if two heuristics give different results and not only different counts of expanded nodes it is crushing evidence there are bugs in the heuristics and/or in the A* search. Judging from the screenshots the so-called "current" heuristic is inadmissible or worse and the Manhattan distance heuristic is OK.