Jump to content
  • Advertisement

Oxford_Oliver

Member
  • Content Count

    11
  • Joined

  • Last visited

Community Reputation

100 Neutral

About Oxford_Oliver

  • Rank
    Member
  1. Oxford_Oliver

    Writing a game engine

    The only thing I didn't like about you is giving someone a lecture when really you don't understand the point of the argument. The code I wrote is just an example for the OP, I wrote it fast so It is not complete. Of course the OP have to delete the newly created object. The Release function could also be called Reset, its really personal. It was only an idea so lets go back and help the OP and give more ideas because I want to stay on the subject of the OP's question. Sorry for any anything wrong I said to you. I read couple of pages about you and you seem to know really well in C++. I have been working on directx for 1 year but I do know much in C and C++. I wasn’t rude; I am very sure everyone will agree with that. I spoke directly and honestly. The things you have said indicate that you might be on a very tangential learning path. I mentioned stack speed as one of the reasons the stack is preferred over the heap; I don’t see a logical connection to your defensive reply implying that I should only have mentioned that had you specifically said the stack was slower. What you did or did not say about the speed of the stack is irrelevant. I have been handling lost devices in DirectX for many years, and while the learning process is never complete I find it unlikely that reading up on it again at this time could be of any benefit. Instead, it seems that you have misunderstood the concept of Release() employed by DirectX. Release() is the only function you have to call in DirectX because DirectX created the resource for you and it can destroy it for you. In your system, however, you have manually created the object via new. Your release() function may be able to release all of the resources that object itself created and maintains, but it cannot delete the object itself. You have called new, therefore you must call delete. Regardless of whether or not you also have a function for the manual “destruction” of the object. Your idea to make objects destructable and then reused is not a problem. The problem is in your implementation. Reset() would be a better function name than Release(), but either way the goal of the function is to completely reset the object back to its original state so that Init() or what-have-you can be called again. This part isn’t much of a problem, but- #1: You are forcing the user to release the object manually. You are not taking advantage of what C++ offers in the way of automatic clean-up. By not putting a call to Release() or Reset() in your destructor, you are both making it a pain in the ass to use your code and leaving yourself (and others) plenty of room for leakage. Just because you put a call to Release() in your destructor it does not mean the user cannot call Release() manually and still reuse the object. Release() will still be a public function that anyone can call at any time, but putting it in the destructor means they don’t have to call it at all if they don’t want. #2: You seem to have gotten confused by DirectX into believing that Release() is the only clean-up code needed. You have forgotten to delete your object because you see a call to Release() and associate that with the absolute deletion of the object. This is where your learning path is taking tangents. You look at the way Leadwerks works via pointers and overall engine design, and you look at how DirectX uses Release() as an absolute deleter, and without thinking critically about why they do that and how it works internally you just blindly copy their styles thinking, “Well, the professionals do it this way, so I will become more professional by doing it this way.” Under these circumstances, there is nothing rude about someone suggesting that you reevaluate your learning process. It is not an insult. It is a real suggestion. I have to suggest it even more now, because instead of thinking about my post and growing from it, you decided instead to argue. A bruised ego should not prevent one from continually growing. Here is an example of someone who was proud about something that person wanted to share, and then got shot down on the very first reply. Instead of compensating for a bruised ego by arguing and whining, that person instead graciously accepted the advice and continued working more on that person’s project, ultimately making huge improvements as a result, and walked away with a better end result. I suggest you adopt such an attitude, because whether you like it or not, many people here are more experienced than you and you could learn a lot. Or you could ignore it all and wonder why you can’t get a job 10 years later. Your choice. L. Spiro [/quote]
  2. Oxford_Oliver

    Writing a game engine

    Actually you should go study , This code I wrote as an example not my actual engine, however, you are wrong about me using casts. I don't even cast anything. I am only giving the OP an idea. As of the releasing, there is a reason for being done like this, you should read more about directx lost device and that best way to handle it. I never said stack is slower, so you don't need to tell me how fast is the stack. I don't use the destructor to release the memory because I need to release it when I want and reinitialize it if I want. Just don't be rude to people. You have just illustrated exactly why the heap is preferred when possible. You are missing a certain delete graphics; graphics->release(); does not release memory back to the heap (as far as the actual Graphics instance is concerned). And this is not more object oriented. Objects being on the heap or stack is not related in any way. #include "engine.h" int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { Graphics graphics(hInstance, nCmdShow); // parameters are title, width, height, fullscreen if(!graphics.initialize("Game", 1920, 1200, true)) { return 0; } // Main game loop while(graphics.GameLoop()) { graphics.BeginRender(); // Render Sprite/Mesh/View etc graphics.EndRender(); } graphics.release(); return 0; } This is far better and you have even avoided your previous memory leak. Plus you don’t need to call release() anymore since that should obviously be moved to the destructor (which should be the case even if you did use pointers and new/delete). Some systems give the stack the fastest memory access, such as the Nintendo DS. In other systems, stack access is often faster simply due to it likely being in cache. And then of course there is RAII. The stack is always preferred as long as it can be used, and can be used safely. That is when you aren’t dealing with dynamic arrays and are not dealing with static arrays or objects of a huge size. You need to reevaluate the source from which you are learning to program. If you seem to think this is the more professional or object-oriented way due to having used Leadwerks, you are wrong, and you need have some studying to do. Leadwerks returns pointers because it wants to manage the objects it gives to your client internally within its DLL. It doesn’t want you to make them on the stack because it can’t manage and update those objects for you. Not because “professionals use pointers” or because “it is more object-oriented”. Additionally, if you wanted to get out of C and be more C++, stop using C-casts. You didn’t show any code doing that, but I have a gut feeling you have C casts in your engine. L. Spiro [/quote]
  3. Oxford_Oliver

    Writing a game engine

    This way is more OOP (Object Oriented) and it is much easier for the programmer to create new functions and call them from this object.[/quote] It's really not, and no it isn't. 'More OOP' is a nebulous claim at best, and because you are constructing the instance right there, there isn't any advantage to holding it by pointer (if you were allocating a concrete subclass of an abstract baseclass using a factory, it might be a different matter). This is the kind of performance question you shouldn't care about at your stage of learning. Any difference is negligible. [/quote] What you said is true but he want to do it in C++ not C. What I mean is I could just create a structure and do this Graphics graphics; graphics.initialize() ... That would really look more like C not C++ I would rather use this for variables like int x; ... Not a class
  4. Oxford_Oliver

    Writing a game engine

    I really don't recommend using the stack because it is some what limited. I have seen people create objects on the stack but it causes them so many problems like a program crash or exit unexpectedly. Using the heap also might cause memory leaks if the programmer doesn't free the memory. I would only use a stack for primitive types..
  5. Oxford_Oliver

    Writing a game engine

    This way is more OOP (Object Oriented) and it is much easier for the programmer to create new functions and call them from this object. Some times you want to have two instances of the Graphics class so it would give you more control
  6. Oxford_Oliver

    Writing a game engine

    Here is how I start a game in my engine. Might give you some ideas #include "engine.h" int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { Graphics * graphics = new Graphics(hInstance, nCmdShow); // parameters are title, width, height, fullscreen if(!graphics->initialize("Game", 1920, 1200, true)) return 0; // Main game loop while(graphics->GameLoop()) { graphics->BeginRender(); // Render Sprite/Mesh/View etc graphics->EndRender(); } graphics->release(); return 0; } By the way many professional engines use a similar approach, an example would be leadwerks engine
  7. Oxford_Oliver

    [PROBLEM] Game crashes outside VS 2010

    You might have a memory leak. Try enabling memory leak detection, also enable all exceptions in Vistual Studio, go to Debug Menu -> Exceptions then check everything Thrown and User unhandled then click Ok then enable the memory leak detection using MSDN Method http://msdn.microsoft.com/en-us/library/e5ewb1h3%28v=vs.80%29.aspx Make sure your program is Using Debug not Release and then run the program and then close it, it should display the leaks if you have Hope it helps
  8. Oxford_Oliver

    Absolute Mouse Position (C++/DirectX)

    Alright, I posted in the attachment the application I created. Now the mouse in this picture is not at the menu but above it. It is not alighning perfectly because I resized the window from 800x600 to the new width and height What I want is, if I resize the application, the width and the height would stay at 800x600 so the coordinates will not change unless the user selects options then change the resolution of the application.
  9. Oxford_Oliver

    Absolute Mouse Position (C++/DirectX)

    I tried that, it does show the position starting from 0, 0 but if I resize the application the coordinates of the sprite menu change so the mouse would press on it
  10. Oxford_Oliver

    Absolute Mouse Position (C++/DirectX)

    I just read the whole Input Class but there is no where it says how to handle this issue, any one else found a way?
  11. Hello, I am trying to get the absolute mouse position using C++ and DirectInput I know that DirectInput gives the relative mouse position but I tried every possible thing and searched all the internet and read so many books and I still can't find an explanation of how to get the exact absolute mouse position X and Y for my 2D Game. Here is an example of what I have now witch doesn't give the exact position and when I resize the Window the position change void GetMouseState() { dimouse->Acquire(); dimouse->GetDeviceState(sizeof(dimState),(LPVOID)&dimState); mousex += dimState.lX; mousey += dimState.lY; } Then I just return mousex and mousey. Here is why I want the position, I am making a menu that when the mouse is over the selected menu item, the user will be able to select it but when I change the size of the window the coordinates change
  • 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!