Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

308 Neutral

About Darragh

  • Rank

Personal Information

  • Interests
  1. Darragh

    suitable rendering algorithm ?

    Quote:Original post by Simon_Roth 10000 tris is nothing on modern hardware! Forget about space partitioning. Dump them in a VBO. Use frustum culling if you must. Seconded. I've used 20K+ triangles per mesh before without barely taxing the GPU. Mind you I didn't have too many meshes on the go at once, but still- 10K is nothing. The only optimisation I'd recommend you to do beforehand is to sort the triangles by texture so that you can render all triangles of the same texture in one batch. State changes in the graphics driver can be very expensive. Other than that, unless this starts becoming a performance problem I'd suggest not to bother optimising at all. That goes for everything else too. 'Premature optimisation is the root of all evil...' [wink]
  2. Darragh

    MD2 Loader

    Quote:Original post by VitaliBR as to create its own model. How should begin to study? I'm not 100% sure what you mean by that question. Are you talking about how to do 3D modelling (to create MD2 model assets) or how to use the MD2Mesh class? If you are talking about the MD2Mesh class then all you need do is create a new MD2Mesh object with the path to the .md2 file and the path to the texture file used for the model's skin (I don't use the skin names inside the MD2). Example: my_mesh = new MD2Mesh("model.md2", "skin.tga"); The MD2Mesh class may include other headers etc. as well so you might have to figure out which headers and .cpp files are needed for your project in order to use it. This is old code that I haven't looked at in long time, so I can't vouch for what exactly the requirements are. In terms of rendering, the base class (Mesh) has a 'draw()' function that will render the model for you given a position and a 3x3 rotation matrix (for the model's orientation). This might only be of use to you however if it fits into your own rendering pipeline, which it probably will not. This is OpenGL code, so if you're doing DirectX for instance you're going to have to reimplement it.
  3. Quote:Original post by Steve132 What about linux support? Nvidia has almost always been FAR superior to ATI in that regard...has that changed at all? I think ATI have probably improved in that regard, with more regular driver releases etc., but I'm not a regular Linux user so I couldn't say for certain. The last time I tried ATI's driver on Linux (about 2 years ago) it wasn't a happy experience to say the least... Nvidia also support other *nix platforms such as FreeBSD which ATI do not, so I guess they are still ahead in this area.
  4. Darragh

    MD2 Loader

    I've got some MD2 loading code if you want it, wrapped up in a C++ class. One caveat though: it only loads 1 animation frame in the mesh (the 1st) since that all I needed for the game were static models. It's not a huge job however to extend it to load the other frames- just add a for loop and read one frame at a time. Download the source code for 'Rogue Trader' and check out the 'MD2Mesh' class and 'MD2Mesh.h': http://www.darraghcoy.com Let me know if you have any questions about it.
  5. Quote:Original post by bdmstyle so I made a video you came to watch him The purpose of the video was to see if I'm doing the correct configuration for the example is the pattern of the book should be correct, so i think the problem is the development environment I do not post any code because all of the book are with the problem so I think it is the environment If it compiles and links OK (as it did in your video) then it's not likely to be a configuration problem. That said however there are certain things that CAN go wrong at compile/link time which will produce no errors yet which will cause severe problems at run time. For example, say if we have the following: -- types.h -- #ifdef COMPILE_64_BIT typedef __int64 NUMBER; #else typedef __int32 NUMBER; #endif -- mylibrary.h -- void somefunction( NUMBER * number ); If mylibrary.h defines a function that is held in a separate library file (.lib) and the .lib is compiled for 64-bit architectures (COMPILE_64_BIT defined), then if we forget to #define COMPILE_64_BIT in the program using that library all hell will break loose... Why? Because the function in the compiled .lib expects a pointer to a 64-bit number to be passed to the function, yet our preprocessor magic in the program depending on it defines NUMBER as being 32-bit- so it thinks that function wants a 32-bit number instead. The result will almost certainly be stack corruption and a crash thereafter. This problem only happened to me last week with a Unix build [smile]. It's possible your problem is something like this (maybe due to the aliasing of certain windows functions to specific ANSI / Unicode implementations - MessageBox to MessageBoxA and MessageBoxW for example) but I'd hedge my bet elsewhere TBH. More information can help us solve the problem. Can you debug to the line where the crash occurs for example?
  6. Quote:Original post by bdmstyle I tried but could not solve more you saw the video? but these are the examples from the book default should be ok? Golden rule of programming (and possibly life in general): Assume nothing. [smile] It's more or less impossible for any of us to help you without any code, or without more specific information- the problem could be anything. If you could upload the project to somewhere then we could perhaps help.
  7. Quote:Original post by Darragh Quote:Original post by Mybowlcut Sorry to completely ignore your topic, but Exile looks interesting - why is there no download option? :D Hasn't gotten the 'seal of approval' yet. [smile] Nah I just have to fix up some bugs before putting it up, in case it crashes when potential employers are looking at it. The Torque engine can be quite buggy so it's just screens for now [wink] Give me a little while and i'll provide a link on-site to it... There we go: [smile] http://www.darraghcoy.com/storage/GameVS.7z There's no manual for the game yet so this quick list of controls will have to do: wasd - move e - jump space - interact with objects left mouse - attack (melee) middle mouse - cast equipped spell right mouse - block (for combat) tab - open equipment / spells menu (for equipping swords, spells etc.) shift - sprint caps - put on/off autosprint
  8. Quote:Original post by Mybowlcut Sorry to completely ignore your topic, but Exile looks interesting - why is there no download option? :D Hasn't gotten the 'seal of approval' yet. [smile] Nah I just have to fix up some bugs before putting it up, in case it crashes when potential employers are looking at it. The Torque engine can be quite buggy so it's just screens for now [wink] Give me a little while and i'll provide a link on-site to it...
  9. Oh yes, two more things: Press F1 to get an 'in-car' / first person view. I find it's much easier to control the car when in this mode. Also, a screen-shot for those just having a quick glance:
  10. Darragh

    No love for Java?

    Personally I hate Java, I'm not sure why precisely but I think it's mainly down to a culmination of lots of little things like lack of unsigned data types, structs, writing lots of boilerplate code for getters/setters, no const correctness, a style of coding that seems to encourage 'abstraction hell', lack of built-in RAII mechanisms to manage operating system resources (GDI objects, File handles etc.) and so forth. Even the Java coding conventions and style of formatting seems to irritate me for some reason- I just don't like them.. [smile] C++ for me is still the daddy, though I'm considering giving D a shot soon once the next GDB release incorporates support for the language. At the moment the toolchain for D is very poor (IDE's, debuggers etc...) but it still looks very promising as a language. Versatile like C++, with both the highest level features (garbage collection) and lowest level features (inline assembler) when you want them. The compile time code generation in particular looks pretty damm powerful. I'm hoping it will alleviate some of the evils of C++ while keeping the stuff that makes C++ great (and expanding upon them). Plus it's designed by programmers for programmers, not as an exercise in academia or design by committee- always a good thing in my mind. But having that said... I'll reserve final judgement until I've gotten a finished project out it. Anyone else looking into D for future projects rather than .NET/Java or C++? I know I am.
  11. Darragh

    Like Quake? You'll love this (almost as much as pie)!

    Quote:Original post by Antheus Quote:Original post by owl This is the future of gaming. Q2 had sub-par graphics when it came out originally. You know, over a decade ago. Q1 was cool back in the day when people were amazed at real-time pseudo-3D scenes made out of 25 triangles. And today, in the age of multi-GPU configurations which can do bazillion phong-shaded, bump mapped, SSAO shaded triangles people get excited over the fact that Q1 and Q2 barely work... In other news, I have made a wheel. It's not really round, but it's a start. I expect it to be usable in real world in some 5-10 years. I wouldn't be so dismissive. For a certain niche of games HTML 5 is very very promising indeed. It surely won't be doing Crysis anytime soon but it's well positioned to stick it to Flash when it comes to quick-fix advertising based games. Plus we can do really really cool websites with it. Dunno about you guys but I'm definitely looking forward to ditching flash for my own site and going WebGL instead.
  12. Hi everyone, I've been beavering away for the past few months on this with whatever time I've had to spare. The game's name is 'Terminal Velocity' - click on the car thumbnail, and then the 'download' button: http://www.darraghcoy.com Or alternatively a direct link: http://www.darraghcoy.com/downloads/Terminal%20Velocity%20Setup.exe This was originally written as a college project using C# and XNA, and interfacing to Phys-X through a .NET wrapper. Unfortunately however something changed in .NET (possibly- I don't know for certain) that more or less completely broke the game beyond repair; I kept getting serious CLR errors when some of the Phys-X functions were called through the wrapper. No matter which machine I ran the game on it wouldn't run, whereas it had worked fine just a year before. I think something funky was happening in the interface to the native code, and perhaps .NET had tightened up on its validation... A classic case of code rot perhaps? [smile] Anyhow, I didn't want the project to go to waste so I decided to resurrect it by rewriting the entire thing in native C++ rather than face the same scenario again. It now uses Havok instead of Phys-X and the physics code was more or less rewritten from scratch with some improvements along the way (suspension being implemented for instance). Feel free anyways to offer feedback or reports of any bugs that you might find; hopefully however there won't be much [wink] Source code is also available if you'd like to take a peek. Cheers, Darragh.
  13. Quote:Original post by taliesinnz Are you not calculating the friction twice, once on the angular velocity, and one on the linear. since: linear velocity = anglear velocity * radius I will be just dealing with the angular velocity, and when friction reduces that velocity the cylinder slows down as a result. Also by looking at the point C on you diagram. This point has no linear velocity in relation to the ground. When it is in contact with the ground, it does not move, the tube just rolls around it; making v=0. No, in this case 'ordinary' linear friction is not being calculated twice. A point on a rotating body not only has the linear velocity of the body but velocity due to rotation also. When dealing with a body that is both rotating and moving you need to take both these things into account when calculating how fast a point on a body is moving. The linear velocity never changes no matter which point on the moving body you sample (at snapshot in time) but velocity due to rotation changes in both magnitude and direction depending on where you are sampling the rotational velocity at; in three dimensions it will be the cross product of a vector to the center of mass with the angular velocity. This is the reason why many physics libraries include a 'velocity at point' style function to compute this for you, because it is a fairly common calculation. But there is also 'rolling' friction to take into account with rotating bodies (a force caused by deformation) as Rattenhirn mentioned- this was what I was missing. This is not the same as regular linear friction (which is a function of velocity) however... This is a different type of friction. As for the point not moving, that is not true. Although (in this diagram) we always sample at the same point on the body (in local coordinates) the point is still moving- the diagram just shows a snapshot in time. The next time we sample the point 'C' it will not be the same point, as the previous 'C' will have rolled on- provided of course that the body is rotating.
  14. Quote:Original post by Geometrian Quote:Original post by Darragh Now the velocity of the contact point 'C' will be a combination of both linear and rotational velocityWrong. Think about it--"C" is directly under the center of mass, which moves only according to the linear velocity. -G I probably should be clearer on that. 'C' is not at the center of mass in this case, it is beneath it (as in the diagram). If it were precisely at the center of mass then that would be true, however since it is not 'C' is also moving at a certain velocity due to rotation. Quote:Original post by Rattenhirn The answer is rolling resistance. You can observe the change from slide friction to roll friction very nicely when playing billiards. When the ball is struck, first if accelerates quickly, then it decelerates quickly due to friction. Then there's a point where it suddenly stops decelerating quickly and starts to roll gently. Ah... I knew there had to be something missing here. Thanks for the pointer!
  15. Hi everybody, Lately I've been trying to understand some of the forces acting on rotating cylinder shaped objects in order to better understand how wheels work. I've considered the following scenario and it's left me puzzled, because it does not seem to make sense. I know this sort of situation could never happen in the real world (because things are not perfect) but let me explain anyhow... Consider the following idealized situation: We have perfect cylinder travelling along a perfectly flat surface, lets say an infinite plane. The cylinder has a radius 'R', a linear velocity 'U' and an angular velocity 'W'. It makes contact with the ground at a point called 'C', which is directly underneath it's center of mass. Now consider for a moment that the only external force (or impulse in this case) acting on the Cylinder is friction (no aerodynamic drag forces). Lets say our simulation uses the following simple equation (per frame) to calculate a velocity loss for friction: F=KV Where F = Loss of velocity due to friction Where K = Coefficient of dynamic friction (i.e amount of friction) Where V = The velocity of the contact point 'C' on the sphere This is a velocity loss, but we could get to an impulse or force easily if we wanted to. Now the velocity of the contact point 'C' will be a combination of both linear and rotational velocity, and we will need to calculate this in order to calculate friction at that particular point. If a positive angular velocity means a clockwise rotation, and positive linear velocity means movement to the right, then to get the velocity of the contact point we would do the following: (note we are completly ignoring the Y/Z axis for this problem, 1 degree of freedom) V = U - R*W Where V = Velocity of contact point (for the x-axis) Where U = Linear velocity of object along x-axis Where R = Radius of the cylinder Where W = Angular velocity of the cylinder Simple enough? The velocity of the contact point is just a combination of rotational and linear velocity. Clockwise rotation will also produce a velocity in the opposite direction of the X axis at the contact point (because it is tangental to the rotating object). So consider if we plug in the following numbers: R = 10 (radius) W = 10 (angular velocity) U = 100 (linear velocity) If we calculate the velocity of the contact point using these numbers, we get a velocity of 0! V = 100 - (10*10) So in this case we get absolutely no friction, because the velocity of the contact point is said to be 0. Even if we calculated friction due to rotational and linear velocity separately, we would still end up with a net friction of 0- and torques would also balance. So in essence we have a situation where the two friction forces, due to rotation and linear movement cancel each other out- resulting in no friction. In a system with no other forces this would cause perpetual motion! Is this correct? Or am I missing something? It does not seem to make sense that an object could experience no friction even though it is moving and rotating at the same time. Here's a (crappy) diagram if that wasn't quite clear:
  • 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!