• Content count

  • Joined

  • Last visited

Community Reputation

98 Neutral

About DominikSeifert

  • Rank
  1. Looking for the best C++ Game Library

    There are tons of professional grade frameworks out there, just to name a few: Unreal Development Kit: [url=""][/url] CryEngine: [url=""][/url] (the one used for Crysis 2) Unity (not for free though): [url=""][/url] Ogre: [url=""][/url] Of course there is the classic open source quake 3: [url=""][/url] All these are complete packages that allow you to easily put together an entire game, using an existing engine. If you want to stick to a non-framework solution... SDL is certainly a good choice: [url=""][/url] Here is a list of libraries for OpenGL: [url=""][/url] DirectX comes itself with a lot of basic things, such as vector, matrix etc classes and even texture processing tools and more, but is of course not portable at all.
  2. You did not specify your problem quite well. What is the exact input and output of the algorithm? Whatever you really want, it boils down to an intersection problem. Check this out: [url=""][/url]
  3. MMO Networking

    [quote] Lost packets end up meaning lag, no matter whether you use TCP or UDP. If a packet is dropped, TCP doesn't magically get the message to the destination any faster than UDP. The only defense against "lost items" is proper game design and rules implementation. [/quote] Of course, but a lot of development overhead is required to make sure that packets are not randomly lost and the game still can function correctly. As I said, [quote] you still want to have certain ensurances by your protocol that you end up implementing yourself. [/quote] If you don't have very similar safety features as TCP, you get intolerable error probability and if you don't have a solid background in networking, you always end up having to cope with bugs that arise from the fact that you did not properly consider uncertainty, packet loss, invalid ordering and some such. As was said above, WoW uses TCP only and even single-threaded private servers (plus one thread for I/O) have acceptable performance and no TCP-related lags with hundreds of players online. Don't forget, it's an MMO and not an FPS - 10 ms faster response time is not worth getting people upset over losing their precious bits and bytes that represent their online life. Of course, for one-shot streaming data, such as voice chat, you can use UDP without having to overthink things.
  4. Move on from C++? Learn something else? Opinions?

    Maple/Mathematica, that kind of stuff, is what you want to learn. Basically, if you want to seriously work on game developing/computer graphics, you will want to get behind all the math that is involved. Professional-grade mathematical tools make visualization of a lot of graphical features very simple - Be it computational geometry, physics or computing of lighting and energy. Once you verified that your concept works you can start investing all the time it takes to convert a few lines for visualization inside a math tool into hundreds or thousands of lines of C++ code. Eventually, you will have familiarized yourself with one or two languages up to a level that you can easily use it as a tool to implement your algorithms. At that point, latest, you will realize that the algorithms actually are what carries weight when trying to produce some really decent (and good-looking) results. Alternatively, look for interesting open source projects, look through their code, toy around with them and start changing little things to learn from what others did and to improve your understanding of coding, framework architecture and algorithms.
  5. How to do Collision Checking in SDL?

    First of all: Make sure that (x, y) of a rectangle is always it's lowest point. Secondly: I am not even quite sure what the function is supposed to return - It returns true if there is no collision? Thirdly: Draw a picture! You somehow need to approach your problem analytically. Whenever you do geometrical problems like this, you can easily verify your algorithm if you draw the different cases on a piece of paper. Now to your code: If you follow suggestion number #3, you will very quickly find out that you cannot make any decision after only looking at a single side. The earliest you can place any return is after you checked against all cases in one dimension. For example, your code says: "If the bottom of A is beneath top B, we have (or we don't have, I don't know what you are looking for) a collision". But I can think of two different cases where in one case, they collide (topA > bottomB) and another where they don't (topA < bottomB). Draw the picture and consider all the cases, and you will quickly be able to fix the code by reordering/merging the four checks.
  6. MMO Networking

    UDP is a very bad idea for an MMORPG, since people are gonna be pissed, if loss of packets is gonna cost them an item. Plus you still want to have certain ensurances by your protocol that you end up implementing yourself. Never optimize early! I also recommend a single server architecture to start with. I come from run-dead projects that never made it off the ramp and I'm telling you: You want to keep it as simple as possible, so you get something to show for, as early as possible. That keeps motivation up and starts producing a user-base. Don't do it quick and dirty, keep encapsulation and modulation on high levels, but don't get into the dirty details that can easily be added at a later point in time. As was said before, the basic server framework just has to serve clients fast enough. Make sure, you have a smart threading model that can very well facilitate multi-threading and never does I/O on any world thread. If your threading model works and you have no hard-core bottlenecks, you'll be able to easily support hundreds of players. You might want to check out and use Erlang's threading model as an example. Finer-than-fine-grained levels of concurrency without synchronization issues, at the cost of delayed remote code invocation adds a bit of complexity but makes for fast execution without stalls or starvation which is the key in any server architecture.
  7. The uniform grid is also a space partitioning method, and, given it's resolution does not give you trouble with memory or overly populated cells, it should be just fine. It is also the most simple approach to partitioning space. If you have bad performance, even with a uniform grid, there might be a bug in your code. Maybe you might want to profile it and find out what is making it so slow. I remember the first time I touched OpenGL, I started watching the (sadly never updated) video tutorials at [url=""][/url]. You might want to check out this particular bid: [url=""][/url] Also, I recommend you to always first look online for data structure implementations before investing all the time of doing it yourself, saves you time and enables you to focus on the important parts PS: Bounding rectangle? Usually you look for bounding spheres/circles, since the region of influence and perception of an entity usually has no corners.
  8. I recommend you tanking up on motivation. Without motivation you can't do the research necessary. Either way, the key to success is reading, reading and more reading. If you can't decide on something yet, just read through light-weight stuff. Once you got your mind set on something, start dwelling through all the papers and possible parts of books, that you can find. Once you have a solid understanding of a topic, you can start working on your own addition to it. If you have no background in AI, you definitely want to shape up on the basics. For that you can check out and similar. Tons of online resources that cover the basics - Use them wisely ;)
  9. Yes, you need some sort of space partitioning. Depending on the use-case, the best choice would be an octree, a quadtree, Bounding Volume Hierarchy (BVH), KD tree, Bounding Interval Hierarchy (BIH) or a BSP tree. Generally speaking, either is fine, just go for the one you can get your hands on the fastest. If you can ignore one dimension (i.e. most of your world is flat and not a lot of people flying around), a quadtree will do the trick, else the octree or any of the other 3D space partitioning trees is a fine choice.
  10. Keep same speed on straight segments and slopes.

    Just use the surface normal (which is precomputed, or can be fast bilinearly interpolated, for a triangle mesh) and dot it with your character's "up vector" to find the angle of inclination. Then use that to split your velocity correctly into vertical and horizontal components. In fact, usually you have velocity in vector form anyway. You find your new position by simply computing old_pos + t * velocity, where t is determined by speed and time step.
  11. I agree with Zao. Also, your last version even has an if in it... A very bad idea.
  12. Open source 3D SPH solver

    I also played around with Fluids v.2 (formerly known as Fluids v.1), and looked into the source, and I found that it is mostly a simpler version of the OpenTissue implementation (e.g. it does not have Surface Tension) with similar flaws in the API (it does not even have a concept of Material, and instead defines all material-dependent variables via a configuration per fluid "system" which in the end yields the same effect as the OpenTissue implementation). On the plus side, it has a fully working cuda implementation of the solver. However, I was unable to test that, since my current computer does not have an NVidia card.
  13. Open source 3D SPH solver

    I don't know if you realized it yet, but just to share my experiences: 1. The OpenTissue SPH solver (and probably any other default implementation) is way too slow for a game. Any game would require a much faster, incremental and adaptive solution. 2. The simulation of the particles is slow, but the implicit surface creation is even much much slower and will kill performance even for small amounts of fluid. 3. The API is not really great but I guess it works, as long as... 3a) You are not planning to mix fluids. For some reason the default implementation requires you to initialize the system with a single material even though the formulas are all valid even for different types of particles, if you compare them to those mentioned in papers discussing fluid-fluid interaction in SPH, such as "Particle-Based Fluid-Fluid Interactions" et al. The formulas for different materials are there but commented out. Once you change the integrators to use the particle material, rather than the initially set material, it is just a matter of commenting out some lines and uncommenting some others to support mixed fluids. 3b) You don't need incompressibility. At any reasonable time step, the gas constant cannot be set high enough to reduce pressure fluctuations to a level where heavier fluids, i.e. most liquids, under influence of gravitation do not pulse up and down. 3c) You are able to estimate how many particles you need up front. The system is quite static and wants to allocate space for all particles that will ever be in the system to be allocated right away. That is a certain optimization measure that was not well wrapped into the API, so you need to tell it how many particles you will produce when initializing the system. For more information on SPH and, specifically, the OpenTissue implementation, I recommend you to read the very comprehensive implementation document: "Lagrangian Fluid Dynamics Using Smoothed Particle Hydrodynamics" It would be interesting to find out what "From Dust" does for it's fluid simulations! Either way, I am sure, they use different levels of detail (consider the most of the ocean in From Dust lays still anyway, and the overall appearance of the moving water seems much simpler than that of any general solver/simulator). One idea might be to pre-evaluate certain scenarios (like the Tsunami, or "sucking up" liquid or amassing sand in one place in From Dust) on a static geometry and then just scale and "replay" them on top of a much simpler representation of fluid, but that's just a thought.... Sorry for responding so late...