Advertisement Jump to content
  • Advertisement

mrcheesewheel

Member
  • Content Count

    142
  • Joined

  • Last visited

Community Reputation

325 Neutral

About mrcheesewheel

  • Rank
    Member
  1. mrcheesewheel

    Multiple collisions per frame

    1. a) This is determined by the situation. Stepping to the nearest collision in a "hard" physics model is the optimal choice of time step. The situations in which this can be perfectly implemented are however rather limited (gas dynamics of circular particles in a rectangular box). Clearly there are never multiple collisions in this scheme. b) If you are using an explicit integrator you may handle collisions with a simple spring inserted between objects that have almost come into contact with oneanother, or ones that are already interpenetrating. You can also apply impluse directly (similar to method a). The problem with both schemes is the potential for very large forces to be generated causing non physical behaviour. To that end you typically implement a force limit. One can apply both schemes at the same time, so as impulse is used to cause hard stopping forces, but with a limited maximum force being applied meaning hard impacts result in penetration which is counteracted by the spring force. Multiple collisions are dealt with by the multiple spring/impulse contact forces that are generated. c) If you are using an implicit form of integrator (eg verlet) then you handle collisions by pushing the objects out of intersections in an appropriate direction in a process called relaxation. Applying multiple relaxation steps per frame is guaranteed to approach the correct solution. One could for example apply a fixed number of relaxation steps per frame, or apply them iteratively until the "error" reached an acceptable limit (or use both... an error limit and a maximum possible). Clearly this scheme deals with multiple collisions through the relaxation step. 2. a) This method guarantees no interpenetration as the step is chosen so they don't interpenetrate... the collisions never occur at precisely the same time so each one is dealt with perfectly so they never interpenetrate. The following two methods may work in different ways depending exactly on the collision approach chosen. I base what I say on a simple method rather than an "extruded volume" type approach. b) Typically in low enegry systems these methods work fine. Depending on the nature of the multiple collisions and the springs the system can become unstable so it is usually desirable to add some artificial damping to stabalise things (or preferably justify some physical damping effect and add that). c) These methods tend to work quite well in general situations. It can be harder to trivially control the nature of the contact interactions when compared to the other two methods, but it tends to be easy/fast 3. Essentially any solver correctly implemented will work with framerates varying. A first order integrator (eg euler) is a low order and "simple" integrator, but it's appropriate for quite a range of situations... especially where precision is not necessarily vital (eg games). Such an integrator will have varying accuracy but require not special mathematical treatment in terms of using it with a varying framerate. A higher order solver will need special mathematical treatment to implement with varying frame rates as some of the differencing implied in their formulation will need to be altered. This is something like the interpolation you mentioned. One problem with permitting varying physics time steps is reproducability. Two runs of the same code will produce different results depending on the time taken between each frame pair. This may or may not be acceptable to you. If the physics is suitably cheap a simple approach can be to pick a small fixed time step and carry out an appropriate number of such steps per frame, you'll probably need to setup a frame rate limit corresponding to the physics steps per game second, and put a cap on the number of physics steps that can be taken per frame. As long as this maximum limit takes considerably less time than the implied minimum frame rate, then your simulation will never "freeze", though when the framerate drops too much it'll go into slow motion... but if the framerate is unplayably slow, then there is no need to deal with the physics accurately any longer in any case. Hope this clears it up, Dan PS: If you are really interested in this look up some info on scientific ODE/PDE solvers and physics simulations. They'll give you some insight into more accurate methods (though often these are not implementable in realtime systems).
  2. Again, I've not read your code entirely but you are doing 1+rand()%9... this produces a number in [1,9] when I guess you just meant rand()%9 producing numbers in [0,8] (the usual array indices? Hope I guessed right! Dan
  3. mrcheesewheel

    mass-spring model for cloth

    The blanket sliding off the table is an ideal example... if the edge of the blanket is off the table, then the downward force will be "expressed" by a downward motion of those particles off the edge of the table which will hence pull the remainder of the blanket. Basically if you implement a particle system that could drop numerous particles onto said table and have them bounce or stick/slide... then the method of a spring mesh is directly usable with that engine. Since your mesh is described as vertices and edges... each vertex has a force accumulator which is initially clear. You go about applying all the appropriate forces, the case in point being the spring forces that all edges it's attached to exert (remember it's a "mutual" force, both attached particles feel it). You simply add in gravity and if you wish collision prevention forces (depending on the nature of your collision method). You could for example consider each particle to be a sphere of some radius that packs appropriately and potentially collidable in the normal way. This would ensure your cloth couldn't self intersect and would have some finite "thickness". You could also make it out of triangular prisms or any of various other primitives (these are for collisional purposes). Hope this helps, Dan EDIT: I didn't really mention, but this all implies you are using a typical explicit integrator. If you are using an implicit integrator then the constraints don't have to be "soft", they can be implemented by iterative relaxation to the true system state. [Edited by - mrcheesewheel on November 17, 2007 1:16:44 PM]
  4. mrcheesewheel

    Virtual "pet" program - help?

    If it's very basic as you say... like a typical physical "tamagotchi" type affair then you don't need to look further than the Windows API's GDI. If you want portability then you'll need to go for a portable graphics back end (ie certainly not DirectX)... but remember that the system tray is not a standard thing for desktops so how to actually get it working on differing platforms will be different. As for sprites and windows... SDL is a nice choice. Easy, fast and ported to a wide range of targets. You could also look at using one of the cross platform GUI toolkits... FLTK, GTK+, QT, WxWindows, Ultimate++... whatever takes your fancy. This would make it easy to get it looking more like a "normal" application rather than having a special custom drawn interface (unless that's what you want). If you need more Windows API specific help then I'm afraid I'll have to leave that for someone else. Good luck, Dan
  5. I didn't look in much detail, but it looks reasonable... I'm not sure about your choice of having vectors of free and used nodes when the board is of fixed size you could easily read those direct (but it's not a problem per se). The main thing I'd say missing is what's missing in most people who are starting OOP... If your system is only one object then the use of classes is just a layout difference... it's no different conceptually to a functions+globals approach. The key to effective OOP in large projects is slicing the problem into seperate behaviours. In a simple game like this it's perfectly reasonable to do it as you have... but if you'd like to practise for larger projects, see where you can cut it (just to experiment). Try avoiding gratuitously deep object heirachys, but think about potential for changes in future. Try to think about how you play the real game... what objects are there... pen, paper, players. They *could* have parallels, pen is what draws the board... paper is the boards representation... players interact with the board (which is drawn as appropriate). If you design carefully you could easily switch to a board drawn in a graphical program instead of to the console... and you could switch your two 'local' human players for other player types, a network player? an AI player? It'd be cool if you could just drop functionality like that in while maintaining the core functionality. The way I like to look at it is that the main function should virtually read like pseudo code... expressing the interactions of the system objects and conveying the algorithm at the highest level. Those objects themselves have a similar arrangement to main.... but slightly lower level and more "fine grained". This structure terminates at the lowest level components which are potentially swappable without recompiling (even at runtime). The watchword is orthogonal functionality. Anyway, good work so far. I hope this guides you in the right direction, Dan
  6. mrcheesewheel

    mass-spring model for cloth

    A mass spring cloth is nothing more than a typical particle system with a special force field. The forces accumulated are simply those generated by the attached springs (following hooks law usually). For more complex cloth you can add various other effects and extra springs, but in the simplest case it's as I described. Other than the spring forces, treat it like any other particle system (in terms of how you integrate... damp movements for stability etc). Hope you get it, Dan
  7. mrcheesewheel

    Calling Commands using system()

    Well the question I guess is why do you want the command's name to start with a '"' anyway? I mean if it has spaces then escape the spaces in the usual way "like\ this". As for the quotes being stripped, I wasn't aware of it, but if it's happening... then I guess it's the case. Hope it works, Dan
  8. mrcheesewheel

    Creating libs for use in a project

    Well, presumably the shared code will be trivial and maybe even inlined, so does it really even need a header in its own right? Also as for versioning... Why not use a versioning system. Subversion is very good and there is a nice easy windows client called tortioseSVN I beleive. My typical development workflow is in a *nix environment so SVN, Makefile, gcc and an IDE/editor for code editting. Presumably the 5 programmers in your group are allowed to see eachothers code? If that's the case then you can either password protect the SVN server, or if you are more paranoid... run an SSH server and tunnel the (passworded) SVN traffic through that. This way everyone can work on their own parts of the program and get all the usual versioning advantages... branching, tagging, reverting code, merging changings, keeping everyones code up to date etc. If you really want to use libs, then I'm not sure how you go about it in windows/VS. If it was me and I really wanted it, I'd probably just make a static library and link it into the executable (rather than making a batch of dynamic linking libraries when it's not really necessary). Hope you get it sorted out to your liking, Dan
  9. mrcheesewheel

    Programming with Patterns

    That's all patterns ever were... solutions to common programming problems. Knowning of them can come in handy... especially if you sketch in UML. You can look at your diagram and "spot" patterns within your structures that can help you clarify the structure and interaction of certain objects. I don't think anyone ever thought patterns were a new special OOP device, they are a linguistic basic set by which we can talk about certain OOP principles in a uniform language. This does however (in much the same was as UML) require that we all know the language before we use it (which a lot of people don't). On occasions I've sketched designs (in UML) and recognised a standard pattern (or nearly standard) which has given me a different point of view and insight into the relationships present (ie the pattern flowed naturally from a different set of requirements, but in itself implied certain relationships that I hadn't considered). In short... patterns as more of a language than a tool... what's easier to say: "I used the composite pattern" or "I made a base class which had a container of pointers of base type then I made a number of blah blah blah." The use of the composite pattern is an abstraction in itself too in that the implementation may be carried out in various ways. Basically I agree with you :P. Dan
  10. mrcheesewheel

    Keyboard Control + "Jumping"

    Well you've clearly not understood how jumping might be implemented. Clearly you are just moving the character upwards by a fixed amount every time the key is pressed. I presume you are relying on keyboard repeat to move him left/right too? What you need to do is firstly keep a "state" of the arrow keys, so if the user presses right (for example) the right state is set... and the character moves right until that key is released. In practise you don't want your character to move simply with a fixed increment, but rather with some velocity. Ideally this should be done with a simple physics system, but you can do it in a fairly simple way... like then right is pressed, increment the x_velocity by 1 and limit it to some maximum value, then left is pressed decrement the x_velocity by 1 and limit it to some minimal value... and when neither is pressed increment/decrement the x_velocity towards 0... then after the velocity changes... move the character by that amount. In fact the actual distance moved should be determined by the time taken since the last frame (otherwise the game will go faster/slower on a faster/slower computer). Equally when you push up, you probably want the velocity to increase to a fixed value (when clicked... not when held), then that value to decrement until it hits some negative minimal value (this is his terminal velocity). You then move the character vertically according to this rule and if he's embedded in a platform, move him up until he isn't any more. In essence this is a simple approximation to newtonian physics of a particle, the difference being that jumping is an "impulse" and moving is a continuous force, as is gravity. Clearly the collision method I suggested is very limiting, so you'll have to make your own (more refined) collision handling (eg for hitting the edge of a platform... or the bottom of one (you could simply push him out in the direction that moves him the least, so if his velocity is low enough he'll never "tunnel" through a platform). Basically I advise you get a pencil and paper and think carefully about what you'd like from your game in the end before making a man jump up and down on a flat plane as you can end up hacking your game design together horribly if you start with the wrong representation of the environment, characters and their interaction. Good luck, Dan
  11. mrcheesewheel

    Octree for dynamic objects

    Well the best behaviour depends on the typical speed of objects vs octree nodes, number of dynamic objects in the scene, density of objects in the scene, the size of the scene and various other factors. Firstly if you know the objects will not move that much, you don't actually have to place them back in the tree from the root, you can potentially reinsert it from the parent node of wherever it currently is (this can save time when the tree is very deep). It's quite possible to have a suboptimal octree for dynamic objects integrated with an optimal octree for static parts of the scene, that's to say the dynamic objects always sit at a certain depth in the tree that is considered minimal... eg every branch of the tree has a depth of 4 and those depth 4 elements are the only place that dynamic objects are placed (like a fixed grid) but static scene elements may be placed much deeper in the structure to provide more optimal culling. Basically you can't say generically which will be best, you just have to decide. If you have more specific info about the nature of the application, then maybe you can get some more specific advice. Dan
  12. Having read your question I'm not entirely sure where your problem lies... is it reading the mouse clicks themselves? is it converting the coordinates to match the display? is it putting them in the array? is it because the line could be of various different lengths? The relevance of these questions and your answers also may or may not depend on your intentions and the API. If you could say in very specific terms what your problem is, ie the program domain, the expected user interaction and the required behaviour of the function... then I'm sure someone will give you a much more specific and helpful answer. Dan
  13. mrcheesewheel

    box collision detection

    If the boxes are both in the same orientation, then in their local frame or reference it's a simple axis aligned box collision test, ie do what you suggested and it's reduced to the previous case. If they are not in the same orientation, then you'll need a different method... You could probably be clever and rotate both so as one was axis aligned, then check for vertices penetrating, then edges, then faces (you must cover all of these to cover all possible collision cases, eg a box in a box). If you know more about the possible states the boxes can be in you can try less options. You can also do this in the unrotated frame of reference which may or may not be advantageous. I suggest checking vertices then edges then faces as that reflects the computational cost of each and if you simply want a boolean result... you'll most likely get it faster. If you need more specific details skip straight to face/face collision checks. Hope this helps, Dan
  14. mrcheesewheel

    Understanding torque and horsepower

    Well... the engine produces a torque which is modified by the gear box, passed down the drive train and applied to the road. Engines have an associated torque curve indicating how much power they produce for a given RPM... typically an electric motor produces torque proportional to rev rate (up to it's maximum rev rate). Without a gear box the motor's shaft will rotate at a rate that is typically too high to drive wheels (unless they are tiny, eg the shaft of an electric motor itself). In putting the motors drive through a gear box we effectively scale down the RPM, but the total power output is fixed (appart from mechanical losses which can be ignored for these purposes), so the torque proportionally increases. The drive train transfers this drive to the wheels (with further loss which we can ignore) and given the radius of the wheels we can calculate the effective linear force experienced by the tyres where they contact the road. From this you can calculate the acceleration (assuming no slip on the road and you know the weight of the vehicle). Note that the engine produces no torque at no revs... Hence the engine must be turned in order to start it and must rest at some "idle" rev rate when you aren't moving (the clutch is disengaged). I didn't really mention the clutch... but in practise you can consider it to disengage the motor from the gearbox... that's to say when the clutch is down, there is no load on the engine (or rather only load due to the motor itself). In an electric motor when it's not powered the magnets/coils sit in a low energy position... so when the coils are charged they move out of that state and "rev up" hence electric motors not requiring starting (though if you make one yourself, you'll probably find you need to give it a spin by hand to get it started). As for how this all translates into a game... it all depends what you want to happen in game. You could for example ignore the fact that it's a motor altogether and simply apply a constant torque in the appropriate direction corresponding the the users requirements to the wheels. If you are going to add some sort of engine/gear/wheel relationship then the user should be able to pick the gear as otherwise it'll be (from the user's point of view) no more useful than the "simple method". If you are going for one of these monster truck/dirt bike/whatever games that seem to be quite popular nowadays, then allowing the user to select gears could add an extra dimension that they don't typically have, but equally... more complex play mechanics can detract from the simple and direct fun of the game. In an even simpler case you could effectively just have the wheels free to rotate as appropriate and simply apply a linear force to the vehicle (in the forward direction tangent to the ground the vehicle is touching). Depending on the level type this may be sufficient. Good luck with it, Dan
  15. mrcheesewheel

    HUD programming

    Well... A HUD is basically just a 2D overlay... If you look up opengl tutorials for displaying text... and for 2D placement then you should be able to figure it out. If you like you can draw on the near plane... but this can have an amusing side effect... messiah did this, but it didn't have a near plane clip... this meant that on occasion, if an object was heading for the camera when you brought up the in game menu, the object would appear to pass right through the menu. An obvious way around this is to disable depth testing for the HUD drawing. Hope you get it working, Dan
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!