Jump to content
  • Advertisement

MidoriKid

Member
  • Content Count

    32
  • Joined

  • Last visited

Community Reputation

199 Neutral

About MidoriKid

  • Rank
    Member
  1. MidoriKid

    Quadtree: struct vs. class

    As stated above, structs and classes in C++ are nearly identical. Reading into you question, it could be rephrased to mean something else: Should I implement quadtree nodes as public structs accessed by external functions, or as strictly object oriented classes with most logic as member functions? There isn't a good answer to this question (and it might even start a C, C++ flame war ;), but I would recommend against using higher level OO techniques in such a performance critical area unless you are entirely cognizant of how to avoid the possible disadvantages of using classes in this way. Of course, this might not be what you were asking at all.
  2. MidoriKid

    Toolbar

    More information is needed to answer this. What type of application are you creating? Creating a toolbar in a fullscreen GL game would be very different from creating one as a browser plugin.
  3. MidoriKid

    3d RTS Engines

    Check out the built-in game engine in Blender
  4. MidoriKid

    Database in game engines?

    Like Spoonbender said, it all depends on the application. I'd guess that most games that could benifit from a database would be better off with something lightweight. SQLite is implemented as a small C library, but offers many features of the heavier client/server types.
  5. MidoriKid

    Space strategy

    You should check out Orbiter. The orbital calculators and transfer MFDs taught me a lot about orbital mechanics. I never knew that stuff was so complex! I mean, it's rocket science, not brain surgery. ;) Get the Red Shift mission planner add-on and try to copy the autopilot stuff for your orbital AI.
  6. MidoriKid

    what if microsoft made a handheld?

    MS would make you pay a monthly fee to play wirelessly with the guy sitting next to you. ;)
  7. MidoriKid

    Simple class question

    I would use a linked list to hold the blocks. When the ball hits one simply remove it. Check out stl::list. edit: Untested example #include <list> #include "Block.hpp" #include "Ball.hpp" int main() { stl::list<Block> blocks; Ball myBall(30,50); // add blocks to the list here blocks.push_back(Block(25,25)); blocks.push_back(Block(50,25)); // main loop while (!gameOver) { // check every block to see if it touches the ball for(stl::list<Block>::iterator b = blocks.begin(); b != blocks.end(); b++) { if (myBall.collides(b)) { b = blocks.erase(b); } } } }
  8. Have you considered using your first game (the one that flopped because of piracy) to attract investors? Even if it was a financial failure it would show what your team is capable of. PS Your web site is very professional looking.
  9. MidoriKid

    Couple books for sale, $2 each + s/h

    Isn't $10 a little excessive considering it costs less than $5 to ship 10 pounds of books from California to New York at the media rate? I suppose the other $5 is for gas to drive to the post office. ;)
  10. MidoriKid

    std::map is driving me insane!

    To create an object using a shared_ptr the "proper" way: shared_ptr<myClass> myPointer(new myClass);This creates a reference count outside of the class. Any time the myPointer is copied the reference count is incremented. If the reference count drops to zero the object is deleted. The problem here is more than one reference count can exist if you're not careful. If you try to hand out a shared pointer from within the class you might try to do it like this: return shared_ptr<myClass>(this);This would be very unfortunate because it creates a reference count separate from when new was called to create this object. Now as soon as the pointer you returned goes out of scope (assuming it was not copied) the object will be deleted no matter how many references the original pointer holds. One work around for this is to make the constructor for the object private (and thus inaccessible) and only create objects through a static factory function that returns a shared_ptr. This allows the factory function to store a weak pointer in the object referencing itself. This is a valid option especially if you want to enforce the use of shared_ptr. Of course, you already know all this. The way around the whole mess is to use intrusive_ptr. This type of smart pointer acts just like a shared_ptr but stores the reference count in the object itself preventing the possibility of two separate reference counts existing for the same object. For an object to hand out a pointer to itself it simply creates a new intrusive_ptr: return intrusive_ptr<myClass>(this);The object's reference count is automatically incremented. This type of smart pointer does have at least one disadvantage, however. You must define intrusive_ptr_add_ref and intrusive_ptr_release functions in the host class. See Smart Pointers to boost your code for an example. edit: Removed dereferenced *this. Those constructors take pointers.
  11. Quote:Right now all of the lights in my ray tracer are just simple spotlights with 90 degree cutoff angles that I arrange into a square to form a sort of area light. .... From each light (which I have positioned just below the ceiling) I choose a random vector, if the vector is within the cutoff I trace it through the scene. This is little off topic, but why not chose a random point on the square to emit each photon from instead of using multiple spotlights? On the topic of rendering the actual light: Assuming the light isn't effected by it's own reflected light I think drawing a white polygon after the scene is rendered would be "pixel correct". As long as you took into account the poly's normal to change the brightness for the directional effect. Of course, everything I know about photon mapping I learned from this thread so everything I said could be completely wrong.
  12. MidoriKid

    std::map is driving me insane!

    You should also take a look at boost's invasive smart pointer. This has the same advantages as a shared pointer but allows you to store the reference count in the object itself. This is closer to the system you already have set up. A problem I've had in the past with shared pointers is the difficulty of a class handing out pointers to itself. You can't do something like return shared_ptr<thisClass>(*this); because it creates a separate reference count. Using an invasive pointer alleviates the complexities of storing a weak pointer from the original shared pointer.
  13. std::string * pointer_to_value = & strValue; If you are using this line and strValue goes out of scope (ie. the function returns) pointer_to_value will likely point to garbage. You should use the pointer to the value stored in the vector assuming that the vector is still in scope. Using smart pointers the way you were before is more cumbersom but safer if you're using it for the right reasons. If you hold the shared_ptr somewhere else in your program and the vector is destroyed you are guaranteed that the pointer still points to valid data. Besides those facts, I think it's funny that the first suggestion was to move away from the safer way of doing things. :D Of course, you shouldn't use shared_ptr unless you need it.
  14. MidoriKid

    Priority of boost::thread

    As of 2003 setting the priority of threads was still in the design phase and I haven't seen much about them since then. I assume it's very difficult to make it portable. You might find something being worked on in the dev branch. There are other ways of controlling boost threads manually. For example in my application the thread that generates procedural textures sleeps for a while after all tasks are complete. It wakes up periodically to check the queue for more work effectivly reducing it's priority and overhead. This won't work for all situations, of course, but sleep(time) and yield() can be very useful.
  15. MidoriKid

    Linux Game Distro

    I have a live CD distro of America's Army. Doesn't work on my PC, but it was a nice try. The standard Windows version works, by the way. This might give you some insight on the difficulties of providing drivers for every possible system.
  • 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!