ApochPiQ

Moderators
  • Content count

    11176
  • Joined

  • Last visited

  • Days Won

    3

ApochPiQ last won the day on September 10

ApochPiQ had the most liked content!

Community Reputation

23069 Excellent

1 Follower

About ApochPiQ

  • Rank
    Moderator - General Programming

Personal Information

Social

  • Twitter
    ApochPiQ
  • Github
    apoch
  1. Unloading a DLL while any thread has a function in that DLL in its callstack = bad juju. The stack will unwind to a bogus address and you will (if you're very lucky) crash. This includes the original thread proc. IIRC there is the option of using ExitThread to try to avoid this but I don't remember if it's advisable. Check MSDN. The most robust thing to do is only fork threads from the main EXE *or* DLLs which you don't plan to reload. https://msdn.microsoft.com/en-us/library/windows/desktop/ms683153 if you're feeling bold :-)
  2. Just traverse the octree from the root down to the leaves. If you traverse through a cell that is not occupied and is a leaf cell, you can create a corresponding AABB that surrounds the node and place it into your graph. Creating edges is just a matter of checking all octree neighbors and seeing which ones have vacant cells.
  3. Steering should be able to trivially handle static obstacles. What forces are you applying?
  4. What do you think about JAI

    No, I'm not going to waste my time finding references. Either you can choose to ignore my opinion (which is fine) or you can do your own research and draw your own conclusions for yourself.
  5. Long ago I also wished for a hybrid interpretation/compilation model. Then I started writing programming languages. Nowadays I'd much rather see a really stupidly fast compile model that can do subsets of a program (incremental builds) fast enough to implement something like a good REPL, but without the inherent cost of maintaining two complete forks of a language's execution model. Of course, I say this mostly because implementing both interpretation and compilation is a giant headache and maintenance nightmare, not because the fast-compile solution is inherently better :-)
  6. Just a word of warning - a lot of people will (rightly) feel hesitant to badmouth services they actively work with, because disparagement is frowned upon and potentially very damaging to relationships. Technical criticism may fly a little bit, but you're still asking people to openly talk bad about business partners.
  7. Javascript is actually quite similar to the original C in abstract philosophy: hide the details of the underlying machine under a uniform interface, and be prepared to execute in a broad variety of environments. Yes, JS is at least one layer of abstraction higher than C in terms of its "platform", but it's still a similar thought process. Maybe you don't see the "use" of the similarities, but dismissing the parallels is a bit hasty IMO. And I don't see why having written a game in a language suddenly makes you authoritative on whether or not anyone else should make observations about that language and its similarities to others ;-)
  8. What do you think about JAI

    This has come up periodically in the GDNet forums. My opinions are essentially unchanged since the last time this thread happened. Jai may well represent the pinnacle of productive programming languages for Jon Blow, I don't know and I frankly couldn't care less. I'm not Jon Blow and I don't like his style. I will not adopt Jai personally. Merits (or lack thereof) of the actual language aside, I have a strong problem with Blow's personality and attitudes towards other programmers, and I find a lot of what he says in the videos (and elsewhere) distasteful. To me this just compounds the problem of trying to learn more about the actual project. In the end, I think it's easier to just leave it all alone.
  9. Fixed update in game loop

    It has nothing to do with how much time rendering takes versus updating. It's a basic problem of arithmetic. If your budget is 0.5ms to finish a frame, you're going to get bad results with any code that takes 4ms instead. I agree that writing down a sequence of events with timestamps would benefit everyone :-)
  10. D is not a functional language by any stretch of the imagination. It is much more procedural/OO in the vein of C++. R, maybe. Julia I could argue about, but Perl and Erlang are both perfectly capable for general purpose development. But just because a language doesn't do "everything" doesn't make it less valuable to learn. Domain-Specific Languages are everywhere and any good architect should be comfortable pulling the DSL tool from the toolbox when it makes sense to do so. I don't particularly feel that there is a magic set of languages that will make you a better programmer. I think it's more the case that you should learn many different tools for solving problems - and sometimes new languages are a good way to learn those tools. A programming style is like any algorithm or data structure: it will be well suited to some types of problems, and ill suited to others. Learning when to use certain tools is the biggest part of being a great programmer IMO. That said, if there's one major language family to learn to blow your mind, it's Lisp. The sheer elegance of erasing the code-and-data distinction is revelatory and valuable even if you never write a line of Lisp once you've learned it.
  11. Fixed update in game loop

    Maybe I'm reading too fast, but how would any game loop be able to behave gracefully if you give it an 8th of the budget it requires to do meaningful work for a tick?
  12. OOP RPG programming principals

    I would personally do something like this: Basic things that can be combined each have an Ingredient member object (compose, don't inherit) Combining two things invokes a Combination object ("service" in some parlance) which looks at the set of available Ingredients Using a data-driven model, the Combination finds the best "result" for a given set of Ingredients Combinations then execute any logic necessary to resolve the Ingredient Combination into a new game state So for example: Table has a Flammable ingredient Fire is an ingredient of, say, a Flamethrower object USE Flamethrower ON Table results in a data lookup which notices that Fire and Flammables can be combined A Combination object is called upon to run the logic, again data driven as far as possible The Table is destroyed Ashes are created at the Table's former location Flamethrower ammunition (or "uses count") gets decremented The Combination is now finished Note that there is no requirement for a Combination to be a stateful object. Assuming a language which permits it, you can just use a free function like bool CombineStuff (const std::vector<Ingredient>& firstObject, const std::vector<Ingredient>& secondObject);
  13. Awesome, glad you managed to get it fixed!
  14. Look into priority inversion - it sounds like you have stumbled across a classic case of it :-) What happens if you do things a little more lazily, and only re-trigger caching when your position moves, say, 150 units? (Or some other number that makes sense in your coordinate space.)
  15. How does your caching thread know when to stop doing work and idle?