Small miniB3D extended 2 Video
Community Forums/Showcase/Small miniB3D extended 2 Video
| ||
| Nothing big but it shows miniB3D extended 2 in action with Newton and Shadows enabled. This is a stresstest on my more or less low system. But for these test I think it is a good framerate + it is recorded. http://s2.photobucket.com/albums/y48/klepto2/miniB3D/?action=view¤t=Newtonandminib3dExplosion.flv |
| ||
| Looks very interesting and quite performant for that many objects with realtime shadows on single core Can't wait to get my hands on it. What are the system specs of the test system? |
| ||
| the specs are AMD Athlon 64 3200+ ATI X800Pro (Catalyst 8.2) and 1 GB Ram. We expect to have a big speed inrease as soon as we have integrated back the shadersystem. Then there is an option to create the Volumes via Shader which already worked on the cancelled extended Version. |
| ||
| shadowmapping, nice :) Yupp definitely will speed it up on systems with enough shader units to do it that way :D |
| ||
| no, not shadowmapping ;) well shadowmapping will also be included but it will be stencilshadows with volumes created by GPU instead of CPU. This just needs a one time calculation of neighbor triangles and creating some new as I'm not able to use Geometryshaders but the rest is done by the GPU. |
| ||
| Will you be able to use multicores then? Would be nice to be able to flag certain effects to use the second core if its present (if thats possible) This is a complete rewrite isn't it, not based on the existing minib3d? Maybe you should consider a new name, just so its not confusing. |
| ||
| The multicore system is integrated within the Newton Archimedea Beta version. So main miniB3D will be single threaded but the physics could be multithreaded. The main core of this is the old minib3d 0.452 it is just new organized and optimized in some parts. More optimizations will be done after we have a stable version ready. As you see this is not a complete rewrite, I would it call a reorganization. |
| ||
| AMD Athlon 64 3200+ ATI X800Pro (Catalyst 8.2) and 1 GB Ram Is that a low end system? I should hope not. Not from what i've seen in the shops/online etc etc. Sounds great though! It's the one thing i'd get blitz max for. Had my eye on it for a while :o) |
| ||
| Thats pretty medium/low end for a gaming pc. |
| ||
| The multicore system is integrated within the Newton Archimedea Beta version. So main miniB3D will be single threaded but the physics could be multithreaded. I'd caution against it. In my experience, BlitzMax gets crashy if you link to a multi-threaded library. |
| ||
| Looking good, funny the fps increases around the middle of the video. |
| ||
| not bad ;) cool klepto |
| ||
| I will put a small app together as soon as possible for testing the multithreading. As far as I know the problems with multithreading should only occure if it is BMax which handles the things, but in this case the whole threadthing with GC and other things is completely independent from BMax and is all done via the lib. So (even if I couldn't test it) it should work. |
| ||
| glad this is still being worked on, looks good! |
| ||
| As far as I know the problems with multithreading should only occure if it is BMax which handles the things, but in this case the whole threadthing with GC and other things is completely independent from BMax and is all done via the lib. So (even if I couldn't test it) it should work. Yeah, that's what I thought too. But even the GC is not involved, BMax gets crashy, and it only happens on some systems, and only at some times. It's very unpredictable, and can easily slip by unnoticed. It slipped past me unnoticed anyway, it was only when it went out for testing that I realized something was wrong. Disabled multithreading and sure enough, all was solved. |
| ||
| klepto2, that's very impressive. Considering the hardware of the testing system and the fact that the module will be multiplatform I can't wait to get my hands on it ^^ |
| ||
| The GC only gets crashy on multithreading if you have shared data ... that means: operate on BM data in C or have Callbacks Otherwise its save to use threads. The main point is that all stuff that runs in its own thread in C / C++ must be wrapped into a "manager". that manager is just an interface for BM to call. Like "eventwaiting()" and "retrieveevent" and the like. Those calls must run in the same thread as BM. then you are out of problems. by the way: just ordered a MacBook Pro Peryn based, so soon I'll be able to test that stuff on OSX as well :) (it will replace my old systems which are currently offered on ricardo) |
| ||
| The GC only gets crashy on multithreading if you have shared data ... that means: operate on BM data in C or have Callbacks Yeah, you keep thinking that, and when you start getting random crash reports from people who are using your creations, don't say I didn't warn you. |
| ||
| Well do you have an example where it crashed while using a library that used thread and offered a non threaded interface for BM? The second part is what normally is missing because you must not interact with the threads or functionality / data used by the threads at all. BM is only allowed to access that that exist within the "calling function execution layer", not within the other library threads. Simply said: All data used by the threads and not guaranteed to be not used anymore must be cloned for BM to be used by it. Otherwise you will run into the problem where the GC access data used by the library -> boom So far, all reports I've seen here have been related to Callbacks for threaded libraries (sound libraries seem to be the most common here) used within BM, which logically is a big no no and objects sent to librarys by converting them to byte ptr instead of replicating the data into a memory by using memcopy and sending that one (as memory can be allocated unmanaged and thus beeing untouched by BM) I've never believed that the GC commands (resume suspend etc) actually make a difference on the thread safeness and I don't think they are fully implemented as the "compile to dll feature" never made it into BM officially. Its still an instable feature and so are its base commands. |
   |