Jump to content
  • Advertisement

PolarWolf

Member
  • Content count

    47
  • Joined

  • Last visited

Community Reputation

179 Neutral

About PolarWolf

  • Rank
    Member

Personal Information

  • Interests
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. ps->~set<int>() ; this works.
  2. fastcall22: Because I have hundred of sets,and these sets tend to be released and reallocted as the program running, so I used a memory pool to allocate set memory. pSet->~set(),are you sure this code is correct? I have tried found no stl::set destructor available. Shaarigan: I only want to allocate stl::set itself using memory pool, not its elements.
  3. I don't want to delete the pointer because I want to reuse it,in fact I used a memory pool to allocate stl::set;
  4. I noticed when constructing std::set using placement new,like this 1 2 std::set<int> *pSet = (std::set<int>*)new char[sizeof(std::set<int>)]; new(pSet) std::set<int>; the placement new in the second line caused memory increased,but there isn't any std::set destructor available,so how to properly clear std::set constructed using placement new,when I don't want to delete the pointer because I want to keep the pointer for future use?
  5. cpumemory.pdf is really useful, as it's title says, every programmer should read it, it's a shame i hadn't found it after programming for so many years. And thanks Satharis ,your summary is concise and comprehensive,it's useful to me and others who read this topic.
  6. What matters is cache, this refreshes my knowledge about stack and heap.The latency in the url is very useful for optimization,thanks a lot.
  7. So stack is faster only in allocations ? I thought stack is faster in both allocations and manipulation(write and read), if it's only faster in allocation, then there is little point in moving calculations from heap into stack,thanks for infromming me this.
  8. We know stack is faster than heap,so if we increase stack size, and move some calculations into stack from heap,will the performance be better? I googled but find no clear answer to what's the max stack size limitation on windows, I set my program's stack size to 50M,all are ok,but when set to 100M,my program runs slowly,and acted weird, such as GetOpenFileNameA has no effect, no open dialog was opened and no error occured. My question is,is it right or good to increase stack size for better performance,what stack size should be set for window programs?
  9. I have read those two urls several times when i googled fbx format,they have nothing useful to me. Obviously AutoDesk want to keep fbx format private, i think that's why the fbx sdk provided as dll, so i choose to tangle with vertices positions and uv coordinates only,and this won't cause any problem, thx.
  10. I have two ASCII fbx files,they have same vertices and faces,the only difference is their face order,and all faces has the same smooth group 1,this is the smooth data in fbx file, LayerElementSmoothing: 0 { Version: 102 Name: "" MappingInformationType: "ByPolygon" ReferenceInformationType: "Direct" Smoothing: *584 { a: 1,1,1,1,1,1,1,1,1,1,1,...... but when imported into 3ds max,one mesh's faces's smooth group all are 1 as expected,while the other's faces's smooth group seems random, such as some are 1,some are 2,Why this happens, i can't see any difference between their smooth data in fbx file,it seams that there is no document about ASCII fbx format,i want to know how 3ds max extract smooth group information from ASCII fbx files.
  11. It seems that many devices don't support glMapBufferRange and glDrawElementsBaseVertex, but vbo is safe to use.
  12. I'am not familar with mobile programing,and never thought of putting all rendering data in video memory without system memory cache,thanks for your information, I will try to load scene data directly into video memor.
  13. I'am currently working on loading scene data(vertexes and faces) for a mobile game,my first thought was to load all data into system memory,and transfer only visible parts into video memory while traveling in scene.But when I learned mobile system memory and video memory share the same memory,I thought it maybe better to load all data into video memory directly,because no transferring is needed when traveling in the scene, Am I right?
  14. Your solution will produce neat code, and i think compile different binarys for different kind of mobiles is common too.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!