• Content count

  • Joined

  • Last visited

Community Reputation

126 Neutral

About elanthis

  • Rank
  1. 3D collision detection is fairly complicated. 3D collision response (fixing the collision after detected) is very complicated. Doing interesting physics with these events (from bouncing balls to complex constraint-based physics) is insanely complex. There are a number of books on the topic. There are also Open Source libraries to learn from, such as Bullet. If you're looking to use physics without digging into the details and writing it all from scratch yourself, you are far better off using an existing physics library. Bullet is quite serviceable. There are others. If the game is a free/hobby project, I believe you can even use Havok or PhysX freely.
  2. Texture buffer objects exist specifically to solve this problem. They're pretty straight forward to use and easy to look up on the OpenGL wiki.
  3. Bounding Box Calculations

    To transform an AABB the simple way, there's only a few simple steps. First of course generate the untransformed AABB from the model's untransformed vertices by calculating the max/min values for each axis. Then, for any transformation matrix you wish to apply to the model, you will apply that matrix to the eight corners of the AABB, and find the new max/min values for each axis. If you have more constrained transformations you can simplify this somewhat. Constraining rotations can do a lot. If you represent your AABBs as a point and a vector of half lengths, you only need to do 2 matrix multiplications instead of 8, but remember that you still need to decompose the half length vector and calculate a new one after transformation.
  4. SDL or SFML probably do what you want. There are a ton of 2D rendering libraries that can use GL/D3D, but that all have various caveats. Note that "blitting" over modern graphics APIs is not necessarily what you want to be doing. You're much better off with a simple scene graph that can probably batch draw calls and offer an automatic texture atlas. Old-style 2D rendering is simply not the right way to get proper use of modern graphics hardware, and in some cases it's just faster to do that kind of rendering completely on the CPU.
  5. In terms of best use of time, an existing engine is the way to go. For someone who finds C++ to be a little overwhelming or requiring too much boilerplate, I would recommend trying Unity, which is a very popular AAA level game engine that uses C# (as one option) for coding custom game logic (Unity's core is all in C++, of course). Note that I do not believe that a programmer can simply take an engine like that and make the most efficient use of it. If you don't understand how to code 3D animations in C++ yourself then that strongly indicates that you just don't understand 3D animations, and you need to understand them at a decent level to be able to use them in any effective, interesting ways. If you're looking to teach students about game programming, premade engines are not the way to go. Again because a game programmer has to understand the core techniques of an engine to use an engine effectively. Students will be best served by building their own simple engines. Yes, it's a lot of work, but it's worth it. Otherwise you'll be educating the game industry equivalent of script kiddies: a bunch of young clueless people who know how to use a specific tool but are utterly lost as soon as they need to do something new, different, or innovative. Specifically regarding 3D animations, there's not a lot to it. Students should have prior knowledge of GPU shader programming (D3D or GL, doesn't matter which) and a solid understanding of linear algebra (particularly vector spaces, changes of basis, and the usual 3D affine transformations). A primary on quaternions can be useful but given in the same class that animations are taught. With those foundations, writing a complete animation and rendering system is not that difficult at all. It's practically trivial, really, if you start out with key-framed skeletal animations and build up from there.
  6. In general, the rules for use of a smart pointer in a game engine are no different than for any other software. Which kinds of smart pointers you use may change a bit, however. For example, in my engine and a dozen other AAA engines I've worked with, smart pointers to game objects acted a lot like std::weak_ptr. The handles were implemented quite a bit differently (generally via a slot map, but sometimes as object ids and a map of some kind), but the usage is similar. You can call a ptr() method which either returns a pointer to the object or nullptr, depending on whether the object is still alive. For game resources (textures, shaders, sounds, etc.) it can be handy to use a similar system. However, I find it is even easier, safer, and more efficient to use a package system. A particular set of assets all reside in a package, which depends on other packages. Loading a new level will open up any packages the new level requires and unload the packed that it does not (also taking into account the UI packages and such). You can then safely use raw pointers to resources will no worry that the resource will disappear while the logic using the resource is still be executed. You can combine this with smart pointers for extra checking, potentially making those smart pointers just thin wrappers around pointers in a release mode build. For a lot of the miscellaneous stuff, again, the rules are the same for games and other software. Prefer smart pointers for any "owning" pointer, with std::unique_ptr being your primary smart pointer. Only use std::shared_ptr where you truly need shared ownership. Temporary pointers that will outlast owning handles can be raw pointers. Never create any smart pointer from a raw pointer without utmost care (too easy to end up with two different owners of a resource that will both try to free it).
  7. Easily done with a shader. Pass in a uniform or vertex attribute for your display factor. Multiply the alpha component of the sampled texture color by this factor. Write result (possibly discarding fully transparent pixels of you don't want z-writes on transparency) to the fragment color. Sorry for not posting sample code; using my phone to type this and typing code on this thing is not pleasant. However, this is basically a trivial two line change to the simplest textured fragment shader.
  8. Quote:Original post by Win32Coder Huh, I update project site, add more examples/features, also add generated .h/.cpp binding files. Compiler further will distributed only in binary form ( coz it consists about 100.000 LoC and represents solid IP which I didn't want sell or share ), so no GPL, no problems. That makes it immediately uninteresting and useless. I don't care how good you think it is, if I don't have the source to inspect and understand myself, I see no reason to use your library instead of Lua or a custom engine. The claim of "IP" is just ludicrous. There's nothing new or noteworthy in your scripting engine that hasn't been used and fully disclosed somewhere else. You're keeping things locked down for no benefit to yourself and with no benefit to your users, and are just retarding the adoption of your library and/or the intellectual growth of your clients. I'm also relatively worried about a script engine that has 100k LoC. Are you implementing some kind of high-level optimizer? Is there any way to inspect how it works? Oh, no source, so I guess not. :/
  9. Simple Server design

    Quote: And why is this a bad thing? If you were running another heavy process then it would take some of that time. Because running a CPU at 100% when it's not actually accomplishing any useful task with those cycles causes a massive increase in power consumption over what you need. Many data centers charge users based on power consumption. Electrical companies bill households for their power consumption. Laptops have batteries with limited amounts of power. No matter where this game server is going to run, wasting power is going to cost a lot of money that wouldn't need to be wasted if the app didn't throw away CPU cycles for absolutely no good reason because the app was written incompetently. There's a reason that AMD and Intel are competing more on power consumption than performance these days, even in the server space. Power consumption and its cost is starting to break a lot of companies, and in today's economy, a lot of home users as well. Do NOT be lazy and waste cycles you don't need to. You are being actively harmful to your users if your games or servers busy-loop like that. Games have absolutely no need to run faster than the refresh rate (triple buffering solves any concerns about skipped frames) and servers have absolutely no need to run faster than they're receiving actual network events. The OP is totally on track in wanting to get rid of the busy-loop in his code.