Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

  1. serumas

    Multilevel Grid Spacial Partition

    I mean   (slower) for each object     mgsp.getCollisions(object, collidingNeighbors);   vs   (faster) broadphase.getAllPossibleColisionPairs(pairs); for each pair     doCollision(pair.a, pair.b);
  2. serumas

    Multilevel Grid Spacial Partition

    for each object     mgsp.getCollisions(object, collidingNeighbors);     // do what you want with this collisions   Note that this way we will only check the cells where the object belongs (very fast)   I dont agreee with this. Yeah its the worst scenario to find collisions. Ill suggest to change a grid concept a little bit and you can get much better performance becouse such implementation is doomed for poor performance. Good luck
  3. serumas

    Multilevel Grid Spacial Partition

    "The main objective of this data structure is to optimize the performance and memory usage in comparison with the normal grid space partitions."   I think the main objective of article is wrong. Lats say we have 30x30 cells , so we must to visit 900 cells and as author says half of tham are empty, so its perhaps max 0.010 ms job for pc. So we are trying to save this tiny time?   "The main problem with this data structure is that it's good only when the elements are uniformly distributed in space."   Its a problem for maybe all broadphase algorithms.   After lots of months spent on broadphase algorithms, mainly quadtree and grid, I would say that most memory and performance penalty goes to objects data structure. For example in my grid 10k circle objects (very tiny data structure) broadphase tooks ~0.6 ms, in more complicated data structure it tooks twice time. So you cant compare your results with oter peaple implementation results, until you recreate exact physical scene. So I can compare just my implementations, my optimized grid 5 times faster than my not fully optimized quadtree, but I dont believe that even optimized quadtree can beat grid becouse of multilayering, reqursion, harder insertion, harder iteration...
  4. serumas

    Introduction to Octrees

    Im not a fan of quadtree or octree, but must admit that article its one of the best...
  5. serumas

    Implementing Component-Entity-Systems

    I think you miisunderstood me, we are talking about curient implementation   Less memory accessing and processing poteanialy leads to less caching and cash missings, ofcouse its highly dependant on data processing algorithms.  And becouse mask, velocity, displacement are still accessed in every loop , that would be better to marge thouse arrays in to a single array, that goes as a single block in cache. They are processed together so would be better to bring them spatial locality...   This article shows me not benefits of entity systems but weakness. Velocity and displacement is too much connected to be used as sepatrate components of entity (thanks you corected in therminology). I would make instead more mobile physics and rendering components (more clear for novice), will make some simple mechanism of comunicating between those components. And will show INDEPENDANT systems operate with one component: hysics system that dont know anything about object rendering, and component rendering which access physics component only than its must to... Does this article shows that?  Still wrong?
  6. serumas

    Implementing Component-Entity-Systems

    Some time ago , I was lurking info about entity systems and come up to facts (maybe I understood wrongly ):   1. entities can be made from vorious components and that components for each entity are individual, some objects could have 20 different components others just 2. That minimizes memory usage and the same components are in the same block of memory.   2.  One type components can be processed independantly from other components. Its can speed up things... becouse of maybe smaller array of one type component and memory block cache...   So imagine I am very dissapointed with this article.    1. All entites still has all components even if they are not used. So if I have 1000 entities and just 10 of them have velocity, that means there are still unused 990 velocities in memory. That shows    int mask[ENTITY_COUNT]; Displacement displacement[ENTITY_COUNT]; Velocity velocity[ENTITY_COUNT];   2. There are no independant components  processing systems in article.   And you are talking about better memory cache. where you see better cache in your code? Better cache means - less memory usage and sequential memory access. In your code I think would be better even not to have entity system at all (becouse no less memory usage), but entity class has all components inside. As I mentioned there are no component independent processing and all objects still processing every component stored in 4 different arrays(its not sequential memory access)...   Am I wrong or what?   Thanks I corected therminology
  7. I have made the same approach recentlry and found that this technique can be good only on old video cards or perhaps java or html5 (not tested). On directx and mediocre video card that would be even slower. For example in my case dividing sprite to peaces algorithm tooks me about 0.250 ms for whole scene and there was only 0.050 ms improvement comparing without algorithm... so 0.200 ms worse... and that qould be great for just some parts of scene (for ex background), but not for whole scene (background units, bullets, interier).
  8. serumas

    How to Structure a Game

    I think its a bad article for novice like me, becouse there is no explanaton why use static list inside each object rather than use simple std::list<Foo> list; what is real benefits of it?... ghtCreature83 is right, there is big chance to dissopoint novices with this unsafe and creashy design.Dont you think? why std::list, not std::vector? Im shure its very possible to revalidate iterator after concrete deletion inside update loop.So why instead use deleteques?   So thats my questions....
  • 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!