Thread: All of our games

  1. #16
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    I'm not stuck on the engine...I've been reading about different VSDs both mid-level and high-level. Also I've been reading a lot about the mathematics and linear algebra behind the engine. A better understanding of the math will eventually lead to a better implementation in code - IMO.

    So far I've only purchased 2 books on actual math and one of them incorporates code into it. My next book will be simply about the math and perhaps physics - actually will probably be two books.

    I've found some very good ways to do trees and other foliage w/o using billboarding and without storing tons of vertexes. Actually bushes will still be simple planes but trees will be stacked triangle fans with the 'point' of each fan having a positive y vector (with postive y being down in my arrangement of axes).

    As for visibility determination I've decided to implement a combination of techniques. For outdoor scenes it will simpy be quadtrees and/or sectorization. For indoor scenes it will be portals and perhaps BSPs...if I can find a very good algo to populate the BSP w/o it breaking down to a linear search - I'm still working on this - part of it has to do with level design. As to how the engine knows if you are in an open area or an indoor area I will use portals...but in a different way. Essentially if the player has passed through one portal from outdoors to indoors then the VSD algo will be switched...althought the quadtree must still be used in case there are windows - aka more portals in the building.

    The quadtree algo is extremely fast and the terrain algo that I'm still sketching out should allow for some very long distances to be rendered. I've looked at ROAM and another variation of it and I'm probably going to combine the best of both worlds. Combine this with some frustrum culling as well as object culling (determining if an object lies completely inside of, completely outside of or partially inside of the view frustrum.

    I'm still hashing out the portal system but I like its advantages as opposed to a BSP. A good BSP would simply take me ages to compute - basically I must use each line or edge as the root and create a tree from it. Then I recurse the tree and track the amount of time it would theoretically take to render it. If it takes more time than previous ones...I discard that option and start over. This has to be repeated for every edge or wall in the scene or level. Eventually it will come up with the optimal BSP and write it to disk....but the design process is extremely slow. This is one way I've found to get an optimal BSP....but its very slow.

    So I'm not stuck...I'm just researching so that I don't code myself into a corner later.

    And on a side note I think that having each one of use code a portion of a much larger engine would be a better idea. For the actual game design and graphics we would defer that to artists and designers. I for one suck at game design but I love to code the engine portion. In any one game engine there are several sub-engines at work. Here are just some I can think of and each of these probably have sub-categories in them.

    3D Graphics
    Storyline and/or flow (movies..cutscenes...etc)
    Storage (memory management)
    Compression (if any)

    You might think a storage engine sounds stupid but its not. The storage portion will manage the memory. Most APIs try to place everything in hardware...but there is not enough onboard RAM on sound or video cards to do that.

    Another idea is to actually create COM interfaces for the engine. This would require programming the engine and its counterparts as COM objects. This would be the ideal case...but certainly not the easiest. There are books out there on COM and how to create COM objects.
    Last edited by VirtualAce; 05-09-2004 at 01:20 AM.

  2. #17
    I'm not stuck on the engine
    Yeah but you're old(er)

    Keep in mind most of us are really just kids. I'm only a senior in high school, davidp is a college freshmen, jverkoey is a junior in high school, and I am guessing hunter is young as well. It really does get to the point where building the engine exhausts all of our knowledge, and implementing things becomes a pain. My physics code is finally getting to the point that I am continually reading up on new topics just so I can understand what in the heck to implement. The accurate Runge-Kutta method of integration based on velocity is something that we haven't yet covered in my high school calculus class, subsequently I have to read up on that just to understand why my Euler method of integrating positions doesn't work properly.
    Last edited by Shadow12345; 05-09-2004 at 07:12 AM.

  3. #18
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Unfortunately I've never taken calculus. However you should be able to solve the problem using vector notation for your objects and solving the equation using simple linear algebra.

    Updating positions based on pure physics code is in my opinion major overkill since you could simulate the same with less than half of the variables.

    The important parts...and the parts that most developers ignore is that objects have mass and inertia. Many of the physics can be implemented using a high school physics book. For the others there are very good articles on the internet.

    I came across one some time ago that dealt with angular momentum and had a demo of boxes bouncing off of walls - they bounced off of the wall according to the angle they hit and according to how they hit. If a box edge hit the wall then the object reacted correctly...and if a box face hit the wall it simply glanced off with nearly no rotation at all.

    The glancing procedure is simple vector mathematics:

    v dot n where v is the vector and n is the normal to the plane being hit.

    Here is the relationship.

    theta=acos(v dot n)

    I'm working on a linear interpolation that hopefully will be able to find the arccos of theta given a displacement t as t varies from 0 to 1. However, I',m not sure it will work since theoretically you can have out of range values which must be normalized and/or clipped.

    Let me know your problem and perhaps we can find a simpler solution. If the solution is too realistic it will probably be too slow for real time. You gotta break the problem down because you are also trying to render thousands of triangles...rotate hundreds of objects..track projectiles...respond to input....etc. etc. Spending 90% of your time in the 10% that no one will notice seems out of balance to me.

  4. #19
    However you should be able to solve the problem using vector notation for your objects and solving the equation using simple linear algebra.
    No, you can't. You absolutely need to know calculus for this particular type of problem. And it isn't just 'knowing how to position objects'. You need to choose a fixed timestep for the physics, but you want your rendering to run ideally at the highest possible speed. The number of timesteps you run for the physics depends on the amount of time that passed. There were even problems in quake3 arena: people with higher framerates could jump slightly higher than people with lower framerates, getting into places they were not supposed to be able to. Even the doom3 engine is stopping its framerate at 60fps because of the fixed physics timestep (if it rendered more than 60 frames you would be seeing the same frames over and over again).

    I asked a guy who almost has a phd in aerospace engineering, and he told me the same thing about the timestep issue:
    Now, on to the more badish news. That timefrac, the time per frame, is a non-fixed time step, which leads to difficulties. So, unfortunately, you're subject to the problems that others have somewhat solved using Verlet integration and fixed time steps. So, I hope you're not too crushed, .
    at this thread on gamedev:

    and if you follow the rabbit hole to see how deep the problem goes you will find implementing 'fourth degree runge kutta', and this is the topic covered in the next chapter of my high school calculus text book

    let me give you a particularly nasty example of something to implement. A constant force produces constant acceleration. In a spring, the amount of force is a function of the amount it deviates from its resting position (Hooke's law).
    So you've got two 'weights' on each end, their accelerations towards the center can be solved by the 'force' of the connecting spring. They accelerate towards the center, however the *instant* their positions change, so does the force connecting the two, and subsequently their accelerations also change, and their positions become the value of an integral. Now, this is easy to do if you program a *very* specific case and keep track of time that the springs act on the objects, but you have to have code that says 'this is a spring, act like a spring, etc'. But this is very very difficult to do in an arbitrary way with an arbitrary timestep.

    (and technically, gravity is similar because it is inversely proportional to the square of the objects distances, i.e the force changes as you get close).

    Engines should be programmed in a generalized way so you can setup almost any case, instead of saying 'this is a spring' you need to say 'this is a system of constraints, pivot points, and arbitrary forces, so let's come up with a method that can accurately estimate the positions of the objects that are acted upon by this system in such a way that even if there *is* an inaccuracy, this inaccuracy is the same on all systems and doesn't hurt anything'
    Last edited by Shadow12345; 05-10-2004 at 10:00 AM.

  5. #20
    S Sang-drax's Avatar
    Join Date
    May 2002
    Göteborg, Sweden
    That seems overly complicated, in my eyes.
    I've always used this method and it works very well:
    //Game loop
    while (true)
    int64 startTime = getTime(); //Use processor counter
    //Render everything
    //Update objects' positions
    obj.xpos += obj.xvel * secondsPerFrame;
    //Calculate seconds per frame
    secondsPerFrame = (getTime()-startTime) / ticksPerSecond;
    While not advanced, it works and performs well. For simple games, advanced techniques aren't neccessary.

    Quote Originally Posted by Shadow12345
    The accurate Runge-Kutta method of integration based on velocity is something that we haven't yet covered in my high school calculus class, subsequently I have to read up on that just to understand why my Euler method of integrating positions doesn't work properly.
    I see no need to use the Runge-Kutta method in simple game programming. I think you should concentrate on different aspects of game design. Because you are using very many steps (frames), any integration method should be sufficient.
    Last edited by Sang-drax; 05-10-2004 at 10:53 AM.
    Last edited by Sang-drax : Tomorrow at 02:21 AM. Reason: Time travelling

  6. #21
    I'm not talking about simple game programming, I'm talking about 3D games that use real physics, which is precisely the level that Bubba, david, jverkoey, myself and probably some other people on these boards are talking about. Again, your method fails for most realistic situations. That's just the way it is. Of course, you can cheat like a mofo just as long as it looks okay. I'm not saying everyone has to use all of this crap all of the time (like you said, for simple games). But if you ever want to get away from re-writing tetris you're going to have to learn it to represent physics.

    //Update objects' positions
    obj.xpos += obj.xvel * secondsPerFrame;

    //Calculate seconds per frame
    secondsPerFrame = (getTime()-startTime) / ticksPerSecond;
    Again, how do you represent this for something like a spring? You can either use calculus or runge kutta or a simple euler integrator. And another thing, that 'secondsperframe' variable must be fixed for any robust physics simulation. Like I said, the physics timestep and rendering timestep can be different, like in doom3 (which is capped at 60hz for the rendering because that's the cap for physics).
    and you are again correct that not everybody needs to know how to do this stuff. I'm talking in the realm of how real professional games are made.
    Last edited by Shadow12345; 05-10-2004 at 12:22 PM.

  7. #22
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Somewhere on my hard drive I have a program that implements springs and attached objects via springs. It works very well and the math behind it is not that hard.

    Let me look around and see if I can find it.

    I find so many things on google that its nearly impossible to keep track of everything.

  8. #23
    Join Date
    Jan 2003
    It is that 'works very well' part that I have been told to be weary of. On one hand, you could be integrating the positions by keeping track of time, in which case, like I said above, it'd work perfectly for that particular scenario with no instability. If you're doing it on the fly without your program necessarily saying 'this is a spring, treat it as such', then that's when you'd have to implement something like runge kutta or euler integrator (the latter being simpler and hwat I am using in writing this hovertank game).

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. When done right, PC games are amazing
    By VirtualAce in forum A Brief History of
    Replies: 6
    Last Post: 08-13-2008, 05:32 PM
  2. Violent video games?
    By VirtualAce in forum A Brief History of
    Replies: 58
    Last Post: 04-26-2006, 01:43 PM
  3. c++ games comparable to psx games?
    By anarchyhollow in forum Game Programming
    Replies: 17
    Last Post: 01-08-2003, 08:49 PM
  4. Video Games Industry. 5 years left.
    By Cheeze-It in forum A Brief History of
    Replies: 26
    Last Post: 12-10-2002, 10:52 PM