Maxpcs - update
BlitzMax Forums/BlitzMax Programming/Maxpcs - update
| ||
Maxpcs - alternative collision system for max2d. Almost there - the above image shows the optional screenspace mapping + the rendering of sprite collision hulls & AABB's.. The hulls for those spritey images above are auto-generated..a handy little feature. [ignore the fps - the rendering of the collision meshes] [is not optimised..its really for debug/testing..] The only stuff really left to do is the editor & import/export routines.. Note: This framework isnt really suited to physics systems - it simply reports wether or not a collision has occurred, and it doesnt use sweeping volumes..etc..its a replacement for the current bitmap collision code..with an emphasis on speedy testing.. anyhoO - back to work ;) |
| ||
| a basic collision thats fast is sorely needed by bmax. |
| ||
| Polygon based collision has its bad part as well -> not as detailed things possible as you actually can do (no pixelperfect). If you have holes, you must manually split the object to several subpolygons. AND: BM does not provide editors, so you would need to write your own collision polygon generator that exports the needed data (0.0 - 1.0 for both dimensions). Without it, its the hell to create them. (See it when I use Torque 2D which only has polygon collision) |
| ||
| yes your right - its not perfect, few things are...the point is that is represents a balance - you get reasonable accuracey with good speed...pure bitmap collision atleast bmax2d's collision is far too slow..i can only manage a few objects before the fps drops to stuped levels... The system im developing is reasonably powerful + very easy to use...of course i havent really started work on the editor yet...but the fact that hulls can be generated from images, to a user defined lod...makes it easy to create the data.. And if your not happy with automatic generation - you can use the editor.. Dreamora - do you always have to be so negative? |
| ||
| small test - nothing amazing... - this demo isnt making use of screen space mapping, there - are some bugs to sort out.. keys - "Enter" - spawn entity.. "1" - switch between bmax collisions & maxpcs collisions "esc" - exit. sillytest |
| ||
| FPS at 100 entities: BMax: 25 MaxPCS: 300 FPS at 200 entities: BMax: 7 MaxPCS: 90 |
| ||
| MaxPCS version says its doing 10x the speed compared to BMAX default. |
| ||
| Thanks for testing it :] on my system the difference isnt as great as that, buts its still 4-5 times faster. One thing thats important to realise is that the mesh generated from sprite in this demo is very simple [8 point convex hull], having said that, its probably a typical point count for most sprite objects. anyway - still some stuff to fix + test, before releasing this. cheers! |
| ||
| Without seeing the source code to your benchmark I am unfortunately in no position to defend the reputation of my collision engine. |
| ||
| Yours is bitmap based, his is polygonal. Speed or accuracy? When it comes to 2D, I don't feel accuracy is absolutely critical in the vast majority of cases, and you probably should have taken that into consideration whilst writing the included collision system. |
| ||
| Pro: In polyon collision you theoretically can add collision normals. One thing that is a must have for physical reaction. This can be done in Pixelbased as well, but only for special shapes (have done it with circles, where it is no problem). On the benchmark: If you compare both systems, then please do it at the same level of accuracy. This means if you use a simplified shape, use a simplified image as well as collision image. I myself use a own type on which I can set the object as collision send and collision receive and before even drawing the collision image, I check if an object of the oposite type is even in range (using radius distance checks using half the diagonal, meassured from the middle of the image). Otherwise drawing collisions is pointless, it only takes time. I'm using a similar approach on my ingame GUI system btw: I only draw the collision rects for buttons etc if their window is the actually "active one", otherwise I don't draw it as a collision can never happen. With this type of optimations, BM collision is by far fast enough. Only the collision normal is missing on pixel perfect collisions. |
| ||
| The only problem i found with my system was that running in debug mode caused 1000% slow down. In release, my exponential growth shootemup disaster seemed to suffer more from fill rate on my 6600 way before any impact was felt from the collision system being overtaxed. Of course actual use may vary but questioning the value of pixel perfect collisions in 2D gaming incurs you 3 x firestorms of wrath from me. And of course it's all my fault because the documentation is still yet to describe acurately the optimal use of layer based collision testing. One hint for Defoc8 is to try and make any temporary arrays global to avoid allocation costs. I remember moving the quadlayer array I use in max2d.bmx from local to global for a significant performance boost (as it's only allocated once instead of every invocation of the function it was local to). |
| ||
| First up - i dont dislike pixel perfect collision, its the best solution...i personaly jst find it too slow on my slightly naff 800mhz system - the fact that it works as well as it does is amazing...so kudos to you. Im jst providing another solution..perhaps one that will be better suited to some projects than the existing system. Sorry if i caused offense - this was never my intention. This project may be terminated...i was going to sell it as a module with tools, and update it as needed. I initially thought that this was something the community really needed...im starting to think i was badly wrong... |
   |