Welcome to Phrogram Sign in | Join | Help
in Search


Functionality/Feature Request - Postition(s) Relative to a 3D Object

Last post 03-06-2008, 7:42 AM by ZMan. 20 replies.
Page 2 of 2 (21 items)   < Previous 1 2
Sort Posts: Previous Next
  •  03-02-2008, 10:52 AM 6282 in reply to 3384

    Re: Functionality/Feature Request - Postition(s) Relative to a 3D Object

    here, use this for momentum:

    (attachment)

    By the way, it actually works as if its really real, and if make speed2 -speed2, it makes an excact, excact excact, (etc...) ZERO.



    (\ _/)
    (- . -) This is bunneh. Copy and paste him to
    (")-(") your signature, so that he may gain popularity and eventually rule the world
  •  03-02-2008, 12:37 PM 6283 in reply to 3384

    Re: Functionality/Feature Request - Postition(s) Relative to a 3D Object

    for the proper gravity, you will need a physics engine.

    (\ _/)
    (- . -) This is bunneh. Copy and paste him to
    (")-(") your signature, so that he may gain popularity and eventually rule the world
  •  03-02-2008, 3:55 PM 6284 in reply to 6283

    Re: Functionality/Feature Request - Postition(s) Relative to a 3D Object

    I like to not rely on "engines" so much because when you do that you don't understand the concept.

    I know the concept of gravity so I think it would be cool to make a small physics module with in phrogram for my own uses.


     

  •  03-05-2008, 4:27 PM 6292 in reply to 6284

    Re: Functionality/Feature Request - Postition(s) Relative to a 3D Object

    Gravity and basic speed/acceleration is definitely something that most people with some simple math knowledge should be able to handle. I'm not sure how the US education system is set up but I remember doing enough math by the age of 16.

    Most physics engines get complex wen dealing with collisions and the correct response to those collisions. At that point you need to be using university level concepts and to be honest its when using an engine is the right thing to do unless that's what you choose to do with your life.

    Saying that you don't like to rely on engines so you understand concepts is a tough thing to justify though... you are relying on phrograms 3d engine to draw, phrogram is relying on managed directx, directx is relying on the driver from the manufacturer. Phrogram is also relying on windows forms which relies on win32 API... these days there is always another 'engine' (or level of abstraction) hiding details from you that you probably dont understand concepts of. But saying that I totally know what you mean... just dont resist engines for the sake of them. Most top games now use graphics, physics and AI engines because otherwise they would never get finished.


    Managed DirectX and XNA ? Check out http://www.thezbuffer.com
  •  03-06-2008, 6:48 AM 6294 in reply to 6292

    Re: Functionality/Feature Request - Postition(s) Relative to a 3D Object

    It's not that I don't like to rely on engines, If you you are planning on make a game it is far more effiecient to use and engine to make the game.  Instead of spending years making your own engine and then more time making the game you can just start making the game by using a game engine.  Most game companies do that, they implement havok physics engine, they use third party graphics engines, game engines, animation engines and everyting in between.  So I understand I should not reinvent the wheel when it comes to that.  That being said I feel that it is important to know how the engine works in case you want to add you own libraries to engines.  I have been studying opengl breifly to try and understand how .draw methods and other graphics work.  I also believe that just using methods from other peoples libraries is good when you start learning but is also a plateau, eventually you need to be able to create classes, add libraries, etc. 

    About using a physics engine:  If phrogram dosen't have a physics engine and dosen't have a way of implementing a third party physics engine then the only way of using physics methods is to do it yourself, that is what I was saying I would like to try.  I could rely on phrograms collision detection.  But as far as momentum or gravity is concerned there are no methods that handle them.  So after taking an introductory college level physics class I have learned the basics about gravity, acceleration, mass, force, etc.  So with my knowledge of that material I thought It would be interesting to try and implement those concepts in phrogram.  I have already begun work on the momentum/acceleration/mass class.  The gravity class is on the back burner, because gravity is relative.  I know that earths gravity is 9.8 m/s^2 but how does that relate to a game world.  Would it be better to create an arbitrary gravity that made everthing fall as expected within the game?  I have also been looking out how particle engines are done in other engines.  I realize that it would be more difficult to do a particle engine in phrogram because I would have to use objects instead of sprites( this is also on the back burner). 

  •  03-06-2008, 7:42 AM 6295 in reply to 6294

    Re: Functionality/Feature Request - Postition(s) Relative to a 3D Object

    I totally understand the desire to know how things work - and the younger you are the better since you have more time than us old fogeys. The trick is finding the balance. I see so many beginner XNA/DirectX programmers fail to finish even their 1st game because they have convinced themselves to learn everything from scratch not realising that writing an engine will take them years to complete..

    As for gravity - you can use all of the equations that you have learned in class. But you are correct in worrying about the 9.8 number. Unless you have mentally defined how much a unit is in your world then that jut won't work. You could decide that each phrogram unit is 1m. This means your human figures need to be modelled to approx 2 units high etc. Then the formula will work just fine as long as you assign an appropriate mass to your game objects. The problem you will find now is that it seems far too fast. Drop something on the floor in real life and it goes down very fast. For some reason people don't like that in games so gravity is often slowed down for gameplay purposes. So your idea of having a number that you can tweak is actually a very good one. This also give you the opportunity to have gravity play a part of your game. Decrease it for space scenes. Increase for planet scenes. Revers is after you go through the 'gravity portal' etc. Bottom line pick a number that works for your game and don't worry about correctness unless you are actually writing an application that models the real world rather than a video game.


    Managed DirectX and XNA ? Check out http://www.thezbuffer.com
Page 2 of 2 (21 items)   < Previous 1 2
View as RSS news feed in XML