• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

jpmcmu

Members
  • Content count

    23
  • Joined

  • Last visited

Community Reputation

184 Neutral

About jpmcmu

  • Rank
    Member
  1. Andreas,   I have a reference counting class that mixes weak and strong references without having to track references to all objects. I use a form of intrusive reference counting so it may not apply directly to your needs. struct ref_count_struct { _int strongCount; _int weakCount; }; class reference { private: ref_count_struct* _ref_count; public: reference() { _ref_count = new ref_count_struct; _ref_count->strongCount = 0; _ref_count->weakCount = 0; } virtual ~reference() { _ref_count->strongCount = 0; if( _ref_count->weakCount == 0) { delete _ref_count; _ref_count = 0; } } inline void ref() { _ref_count->strongCount++; } inline void unref() { // KEEP IT THIS WAY BUG FIX if(_ref_count->strongCount == 1) { delete this; } else { _ref_count->strongCount--; } } inline void weakRef() { _ref_count->weakCount++; } inline void weakUnref() { _ref_count->weakCount--; } inline _int getRefCount() {return _ref_count->strongCount;} inline _int getWeakRefCount() { return _ref_count->weakCount; } inline ref_count_struct* getRefCountStruct(){return _ref_count;} };   Anyway, the basic idea is to hold the reference counting info in a separate object that sticks around after the object is deleted if and only if the object still has weak references associated with it. Weak_ptrs hold a pointer to the reference counting object so they can check to see if the object has been deleted when access to the object is attempted.     template<class type> class ref_ptr { private: type* _ptr; public: ref_ptr() { _ptr = 0; } ref_ptr(type* ptr) { if(ptr != 0) { _ptr = ptr; _ptr->ref(); } else { _ptr = 0; } } ref_ptr(const ref_ptr &ptr) { if(ptr._ptr != 0) { _ptr = ptr._ptr; _ptr->ref(); } else { _ptr = 0; } } ~ref_ptr() { if(_ptr) { _ptr->unref(); _ptr = 0; } } inline type* get() { return _ptr; } inline type* get() const { return _ptr; } inline type* operator->() { return _ptr; } inline type* operator->() const { return _ptr; } inline type& operator*() { return *_ptr; } inline type& operator*() const { return *_ptr; } }; emplate <class type> class weak_ptr { private: type* _ptr; ref_count_struct* _ref_count; public: weak_ptr() { _ptr = 0; _ref_count = 0; } weak_ptr(type* ptr) { if(ptr != 0) { _ptr = ptr; _ref_count = ptr->getRefCountStruct(); _ptr->weakRef(); } else { _ptr = 0; _ref_count = 0; } } weak_ptr(const weak_ptr &ptr) { if(ptr != 0) { _ptr = ptr._ptr; _ref_count = ptr._ptr->getRefCountStruct(); _ptr->weakRef(); } else { _ptr = 0; _ref_count = 0; } } ~weak_ptr() { if(_ref_count != 0) { // If the referenced object is dead if(_ref_count->strongCount == 0) { // If we aren't the last weak reference if( _ref_count->weakCount > 1) { _ref_count->weakCount--; _ref_count = 0; _ptr = 0; } else { delete _ref_count; _ref_count = 0; _ptr = 0; } } else { _ptr->weakUnref(); _ptr = 0; _ref_count = 0; } } } inline type* get() { if(_ref_count != 0) { // If the refenced object is dead if(_ref_count->strongCount == 0) { // If we aren't the last weak reference if( _ref_count->weakCount > 1) { _ref_count->weakCount--; _ref_count = 0; _ptr = 0; } else { assert(_ref_count->strongCount == 0 && _ref_count->weakCount <= 1); delete _ref_count; _ref_count = 0; _ptr = 0; } } } return _ptr; } inline type* get() const { if(_ref_count != 0) { // If the refenced object is dead if(_ref_count->strongCount == 0) { // If we aren't the last weak reference if( _ref_count->weakCount > 1) { _ref_count->weakCount--; _ref_count = 0; _ptr = 0; } else { assert(_ref_count->strongCount == 0 && _ref_count->weakCount <= 1); delete _ref_count; _ref_count = 0; _ptr = 0; } } } return _ptr; } inline type* operator->() { if(_ref_count != 0) { // If the refenced object is dead if(_ref_count->strongCount == 0) { // If we aren't the last weak reference if( _ref_count->weakCount > 1) { _ref_count->weakCount--; _ref_count = 0; _ptr = 0; } else { assert(_ref_count->strongCount == 0 && _ref_count->weakCount <= 1); delete _ref_count; _ref_count = 0; _ptr = 0; } } } return _ptr; } inline type* operator->() const { if(_ref_count != 0) { // If the refenced object is dead if(_ref_count->strongCount == 0) { // If we aren't the last weak reference if( _ref_count->weakCount > 1) { _ref_count->weakCount--; _ref_count = 0; _ptr = 0; } else { assert(_ref_count->strongCount == 0 && _ref_count->weakCount <= 1); delete _ref_count; _ref_count = 0; _ptr = 0; } } } return _ptr; } inline type operator*() { if(_ref_count != 0) { // If the refenced object is dead if(_ref_count->strongCount == 0) { // If we aren't the last weak reference if( _ref_count->weakCount > 1) { _ref_count->weakCount--; _ref_count = 0; _ptr = 0; } else { assert(_ref_count->strongCount == 0 && _ref_count->weakCount <= 1); delete _ref_count; _ref_count = 0; _ptr = 0; } } } return *_ptr; } inline weak_ptr& operator=(type* ptr) { if(_ptr == ptr) return *this; // Handle the old observed object if(_ref_count != 0) { // If the refenced object is dead if(_ref_count->strongCount == 0) { // If we aren't the last weak reference if( _ref_count->weakCount > 1) { _ref_count->weakCount--; } else { assert(_ref_count->strongCount == 0 && _ref_count->weakCount <= 1); delete _ref_count; } } else { _ptr->weakUnref(); } } if(ptr != 0) { _ptr = ptr; _ref_count = ptr->getRefCountStruct(); _ptr->weakRef(); } else { _ptr = 0; _ref_count = 0; } return *this; } };   I ripped part of my ref_ptr and weak_ptr class implementations out as examples. These are not complete. I don't know if this will help but I would love to see weak references in AngelScript.   - James
  2. Lets see first of lets take coulombs equation: E = k*q/r^2 * (r-hat) q = P * dx, Where P is the linear charge density and dx is along the line of charge Therefore, E = k*P*dx/r^2. In your coord system r = sqrt( h^2 + x^2) (r-hat) = ( x*(x-hat) + h*(h-hat) ) / sqrt( h^2 + x^2 ) E = K*P( x*(x-hat) + h(*h-hat) ) / (h^2 + x^2) ^ (3/2) This is getting a little nastier to type than I thought. Basically instead of going into cosines and sines let r hat = <x,h> and divide it by its length ie: sqrt(h^2 + x^2). That should help out a bit, after this its just integration. If you have an integration table handy that would be the easiest route. This link Integral 41a) [url="http://integral-table.com/."]http://integral-table.com/.[/url] Don't do the hard work unless you have to =) Let me know if you need any help I could work it on paper and send it to you. Oh and for the 3D -> 2D coords you could use 3D coords by using (r hat) = <x,y,z>/sqrt(x^2 + y^2 + z^2) but this will become a double integration.
  3. Option 2. I have been using a large c++ codebase in a few projects for a while and I haven't run into any issues. In general my setup is almost identical to what you mention except I also use UIKit for my GUI so I have more than just a single view/view controller. My c++ code is simply included. All you have to do is make sure any objective-c to c++ boiler plate code is placed in source files with .mm extension so they compile into objective-c++.
  4. NSV = modified velocity-verlet integrator It simply makes assumptions about what is being integrated, in this case a constant accelerated body. While I would not discourage anyone from learning Lagrangian and Hamiltonian mechanics, I think you can get a good bit of understanding by taking a look at the kinematic equation for a body under constant acceleration: x = x' + v*t + 0.5 * a * t * t When you combine the NSV integrator you get: x = x' + v * t + a * t * t They are the exact same except for a dropped constant. So the reason NSV is better than Euler because it takes the effect of acceleration over a single time step into account. As for his version of the NSV I don't think it is better. NSV-His: x = x' + v + a * t * t Try testing his with large velocities. I would bet it is far from "better".
  5. I have not read the article but I would not be too excited about this. Using lasers to cause fusion has been an idea for a pretty long time. The general idea is you use magnetic/electric fields to hold the deuterium in place while you bombard it with photons. If the material gets hot enough it will begin to fuse. This is great in practice and has given rise to fusion. The problem is that the likely hood of fusion is extremely small, even in the intense temperatures and pressures of the sun. Fusion actually requires that one nucleus quantum mechanically tunnels into another nucleus. The probability of this tunneling increases with energy, but it is still extremely small. This is why using fusion as an energy source is so difficult. The energy required to keep enough deuterium plasma in one spot is extremely high, and out weighs the energy released from the reaction. We still have a long way to making fusion reactors efficient enough to use. As a matter of fact I know a few nuclear physicist who think it is practically impossible.
  6. The only thing I can find is that the distance calculation is incorrect. You should not normalize before the dot product.
  7. I think the question you are asking a little more complex than you realize, and I need some more information. Is there are specific radius of the circle that you would like? If you don't care than you can place a circle with a radius of half the semi-major axis of the ellipse at the center foci of the ellipse. The circle at this point would only intersect the ellipse twice. If you wanted more intersection with the ellipse or wanted it a different foci, you could use the polar equation for the ellipse and set it equal to the equation for a circle. This is assuming you know where you want the center of the circle to be. Oh and a foci is kind of like the "centers" for an ellipse. There are three of them, one in the dead center and the other two are close to the ends of the ellipse, but their exact location depends on the shape of the ellipse desired.
  8. Is the starting elevation the same as the ending elevation? Assuming that you don't care about air resistance or the rotation of the earth you can use the range equation. I probably wont get it right of the top of my head so I am not going to try, a quick google search should find it. If you want air resistance or need differing final and initial elevations, I can derive the equations for you and email them to you.
  9. I am using the ganymede version of eclipse at the moment as well, but the latest version has driven me over the edge with it. I was ok with it being a little slow but the most recent version does not register mouse clicks in certain menus. In other words some menus I have to click a button only once, in others if I click it twice for it to work( once never works), others mouse clicks never work and I have to tab to the button and hit enter. As far as using a non-gui(I dont want to get into a VI vs. Emacs debate =) ) based text editor your right they have huge advantages in terms of speed, but a very steep learning curve. I am ok with them but I would like to get better if I am going to start using one as my sole editor again.
  10. I have used kDevelop, Anjuta, Eclipse-CDT and just plain old vim/g++ for extended periods of time. I haven't been completely satisfied and its to the point where I have stopped working on code in search for a better setup. kDevelop - Version 3, good features but in my experience very buggy. Version 4, unusable Anjuta - Ok, not as buggy as kDevelop Eclipse-CDT - Fairly stable but often slow and recent versions have had GUI problems Vim/g++ - fast and stable, I need to get better with vim's commands I am currently using Eclipse but going back to vim looks better everyday. However its nice to have some of a GUI's function, I am stuck. What do you use for an IDE as a linux dev?
  11. I am typing this on my phone, sorry in advance for typos. It is very possible to get to this planet. I would throw up the math behind it but my phone isn't good with eqautions. The only problem with getting there is creating a vehicle that can get us there. This seems like a huge leap in technology would be required to build this ship but it's within our grasp. The vacuum of space is not a true vacuum there is a single proton per cubic meter. A spaceship could accelerate at G the acceleration due to gravity, by attracting the positively charged protons in space and shooting them out the back of the ship. A ship as I described above could explore the known universe in a lifetime. It is impossible to break the speed of light. however, if you were to travel faster than the speed of light you would continue accelerating and would be unable to slow down. However these physical laws only exist in the known demensions, it could be possible to break into other dimensions without these restrictions.
  12. Trefall, very interesting implementation. I haven't read every reply in this thread only the main post, so this may have been asked, but how do you manage update order of the components? For instance, say you have a physics component and a graphic component. How would you insure the graphic component updated the visual representations position after the physics component updated the objects position? Your post here has definitely given me something to think about for my implementation.
  13. Thanks for all the responses. Swiftcoder: I know that you can just rip apart objects into their components and then stick the components in the root of the scenegraph. However, I think this is a very poor solution. I think it is worth trying to find a way to keep the scenegraph structure for dynamic objects. Not only because scenegraphs are meant for dynamic objects, but because there are many other systems that could benefit from it, for instance skeletal animation. Obhi: Your right a scenegraph does not have to be used for dynamic objects. These can simply be connected by joints in the physics engine. But what is a joint? Its a transformation with constraints and limited degrees of freedom. From my viewpoint the transformations in the scenegraph are joints. All the physics engine has to do to treat these as joints is apply conditions to them. I am building my own physics engine so I can easily integrate this idea. Dave: Thanks for your response. I am very interested in your implementation. Is this available in one of your books?
  14. dudeman21, thanks for your response. I guess I didn't explain the problem well. I am not trying to use the scenegraph hierarchy as the physics structure, I want to keep the nice scenegraph I am using and allow physics to control it. For example how do you control the components of the space ship? If you use a normal setup each physically modeled part has to be ripped out of the scenegraph tree and placed into the root of the scenegraph. IE. you have this nice scenegraph with two turrets a hull and an engine all in the root node as completely seperate objects. So if you have to do this for every dynamic object in a game you get this array of objects to render instead of a tree. So the question is how can you allow the physics engine to control the scenegraph representation without having to break it?
  15. I don't see a nice clean method for integrating the scenegraph transformation hierarchy with the physics engine. I found a previous discussion( http://www.gamedev.net/community/forums/topic.asp?topic_id=479621 ) on this. However, in my opinion the problem wasn't resolved with a nice clean solution. This must be a fairly common problem so I would just like to brainstorm and see what solutions have been used to overcome this problem. The Problem: Lets say we have a scenegraph that represents a spaceship. The spaceship has multiple components. Lets assume the scenegraph looks something like this: Root | + World Transformation-- Spaceship's location and orientation in the world. | + Space Ships Hull Graphic Representation | + Left Turret Transformation | | | + Left Turret Graphic Representation | + Right Turrent Transformation | | | + Right Turrent Graphic Representation | + Engine Transformation | + Engine Graphic Representation Lets say I want the turret to recoil when it fires a projectile and I want the physics engine to calculate this for me. This is a pretty easy thing to calculate but how do we hook up the physics engine in a way so that it effectively uses the scenegraph transformation hierarchy of the spaceship? I think the best answer is that the physics representation of the ship has to mirror that of the scenegraph. So how would you go about ensuring that these are effectively mirrored? The physics engine should be able to control any number of mirrored representations. For instance what if you want to create an audiograph that mimicks the scenegraph? This would have to be controlled as well. The only solution that I see to this problem is to have each game entity store a "transformation skeleton" then the graphic representation makes a copy of this skeleton sticks the materials/textures/meshes etc into the leafs that it wants and then sticks this into the scenegraph. This skeleton would be automatically linked to the "controlling skeleton" that the physics engine owns and updates. I am sure someone reading the above "solution" sees some blaring problem that I don't see, I definitely would like to hear it. I would also really like to hear any other possible solutions.