Jump to content
  • Advertisement

ZMaster

Member
  • Content Count

    275
  • Joined

  • Last visited

Community Reputation

240 Neutral

About ZMaster

  • Rank
    Member
  1. ZMaster

    Custom Memory Allocation

    Thank you, Hodgman, for sharing your idea. I have read about this approach and while it certainly deserves its existance (fast and efficient, no fragmentation, dynamic allocation sizes, etc). It does come with a couple of drawbacks, specifically being comparatively hard to use (not very forgiving if you make an error) and not allowing for deallocation, hence memory might go wasted if it is used only once, but never thereafter. Depending on whether one can live with these drawbacks, its certainly an approach to consider. In my case, I want to be able to pseudo-allocate and deallocate memory at any time during the game (think dynamically spawning particles, for example), even on a per frame basis. Of course, I will not be actually allocating the memory, but just retrieving a pointer to whatever memory chunk is currently free. The actual allocation however, would happen at startup or level-load. Are there any other approaches out there, that might be worth considering?
  2. Hi Guys. I was wondering if you could share some of your ideas on memory allocation in games. Specifically, I was thinking about using the Doug Lea Malloc. For my memory allocations, I have the following requirements: 1) Zero to no memory fragmentation. I am working on embedded devices. 2) Fast allocations and deallocations. 3) Moving memory allocations from the kernel space to the user space on embedded devices. 4) Minimizing memory consumption, although the other points are by far more important than this one. Previously, I have been using pools of various sizes for memory allocation. I am, however, also looking at other ideas and came across Doug Lea malloc, which would be a little more flexible. I am also willing to combine several approaches and use them individually, when appropriate. What other ideas are out there? Thanks! Florian
  3. ZMaster

    C++ Memory Manager

    Thanks tivolo. That helped a lot. I will look into all of these...
  4. ZMaster

    C++ Memory Manager

    Yep, you are right, but I would like to have it in a custom allocator, so I can have different types of objects use different heaps or deallocate all the objects stored on one of these heaps at once. Plus, the problem with the built in allocator is that it is very slow when allocating chunks of memory and still relatively slow when releasing them.
  5. Hi there. I am looking for a speedy and proven-to-work implementation of a memory manager. Specifically, something like a custom heap would be great, where I can allocate a chunk of memory from the operating system beforehand and then redistribute that memory to quickly instantiate custom objects in my code. I am using a solid implementation of a small object allocator, but I would like something more flexible, which lets me allocate objects of different sizes, without knowing their exact byte size beforehand. Do you guys know of anything that would come close to my specifications? I would rather adopt / base on some well-tested code than re-invent the wheel myself. Thanks! Florian
  6. ZMaster

    Collada C/C++ Library

    Thank you for the quick reply. I will look into these libraries to decide which one fits me. I have read about assimp before and I am very impressed by it, however, for this particular project I am looking for a COLLADA only importer. Assimp would come with too much overhead for my specific needs...
  7. Hi there. Quick question: What are my options of free (commercially useable) Collada import libraries (C/C++) out there? I think I have read about one, only a few weeks ago, here on gamedev.net, but even after spending hours searching, I can not find the news article anymore. Thank you for your help! Florian
  8. ZMaster

    c++ STD::vectormyclass problem.

    Correct me if I'm wrong, but in your code snippet newdata appears to be some data on the stack. By pushing it onto your vector you are effectively producing a copy of the variable. Once newdata goes out of scope, the destructor is going to be called on it. I don't know why exactly you would want to prevent the destructor from being called, but one of my guesses would be that you are allocating some data on the heap in your constructor and that you are deallocating that data in the destructor. This might be dangerous if you don't override the copy constructor and are not using some sort of smart/scoped pointer or garbage collector. You might want to make your copy constructor produce a deep copy (copy the data on the heap, not just the pointer to the data) of your class - if that is the case...
  9. ZMaster

    Game interface

    You can set up your ortho mode to have whatever dimensions you want it to have, and that also includes your screen size, which would make sense for a gui system. The only difference in ortho mode is that objects further away from the camera do not appear smaller, as in perspective projection. You can think of perspective projection as of looking down a pyramid or frustum, while you would probably look down a box in orthographic projection. You can also still use your z-Axis and depth buffer by the way to control which windows / widgets overlap others.
  10. ZMaster

    How difficult is Asembly to learn?

    It's generally advisable to have a basic understanding of the underlaying hardware architecture you're programming for. Most programmers today rely on their compilers to do the optimizations but those tend to simply use the more 'general' and 'functional' translation of the high level language. With a few things in mind you will have a better understanding for where your performance goes and you can use C++ (or whatever high level language you use) more effectively. However, x86 assembly is a pain! You should start on some platform that has a vanilla RISC cpu, for example. Although most modern CPUs are similiar to RISC architectures anyway, the implement the more complicated CISC x86 through some sort of 'microcode'. I heard that the ARM or MIPS platforms are quite good for a start, but if you want to have really fast (visual) results you should try to code for the older C64 or Atari platforms...
  11. Your are fine as long as you don't build circular references. To avoid them, boost implements the boost::weak_ptr. Also note, that it's not always a preferable situation if you can't predict when exactly an object is deleted from the heap, since memory allocations / deallocations are extremely expensive, especially on embedded platforms. So they might undermine the one or another design concept. However, as so often, safety comes first, so it's generally a good idea to use them. Understand when and where to use them (depends on the situation you have) and you're perfect! Good luck!
  12. ZMaster

    memory allocation - DS

    Quote:Original post by PaoloStoppa Okey, i now use an existing allocation code. I run the programm, and at pmonster=new CMonster, I go an ensata error message : Stopped due to abort or undefined instruction in ARM9. Whz is this error ? Paolo Unfortunately, this is the only error message of ensata that I've ever run into and it can mean everything that has to do with memory: eg. Double freeing memory blocks, writing to / reading from freed memory, writing to / reading from memory that has not been allocated, writing / reading out of array bounds, etc. Regarding your the error message you posted earlier, you probably did not initialize the heap arena at the correct point in your program. Apart from the main application entry point you do have a start-up function, where memory initializations go! I won't post any more details, because of the NDAs I wrote about earlier! By the way, you shouldn't post any Nitro SDK specific code on this board! Nintendo will get to your balls, if they hear about that. You are violating contracts. However, I do appreciate that you hold the opinion of people on this board in such high esteem, but the official newsgroup is read (and replied to) by many Nintendo officials and people from other, well experienced, development teams with Nitro licenses, you would have probably had a solution to your problem in fewer time, too! Cheers!
  13. ZMaster

    memory allocation - DS

    You need to use the SDKs own functions to allocate memory on the HEAP. See the Nitro SDK function reference for more information (subsection memory). You can then write your own custom allocator to use the new and delete operators. You can also go to www.warioworld.com and register for the newsgroup. Post there to retrieve more information, because things are covered by an NDA, so you won't get any more information from here...
  14. You may experience longer compile / linker times, because boost massively relies on metaprogramming / templates, especially the boost function implementation. Depending on how extensively you are using boost and what the size of your team / project is, this possible drawback might be of great or no importance for you.
  15. Quote:Original post by jpetrie Okay. A factory system has no need for RTTI or type-switching at all... I've read your draft of a Factory implementation. In fact, I agree with you that such an implementation does have a massive amount of advantages over type-switching... However, I wanted to ask for your opinion on some changes to your design: One thing I'm not quite happy with is, that you have to implement a producer which creates an instance of a produce able object and needs to be registered with the factory class. In this particular example where certain objects are created by deserializing a file, wouldn't it be also possible to skip the implementation of a producer and have an interface IFactoryProduceable, inherited by the object itself, which directly implements the ProduceInstance() method. Then you could register the objects, which should be created, together with their key with the factory class, instead of taking the way over a Producer class. What do you think about this? Of course, implementing a separate producer makes a lot of sense in some other cases, for example if you would implement a platform-independent GUI Factory, which produces GUIWidgets for Windows and OSX. Then the producer, registered with the factory would decide whether to produce a ButtonOSX or ButtonWIN instance...
  • 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!