Blaze v0.6, a 2D Rigid Body Physics engine, has been released: http://www.dsource.org/projects/blaze

The code has been optimized for D, and all known bugs have been fixed. Enjoy!!!

The next step will be to implement joints.

If anyone is interested in creating cool demos please let me know so I can add them to the downloads section: http://www.dsource.org/projects/blaze/browser/downloads

Also, if you plan on using Blaze in your project please let me know!

Thanks,
Mason

the demo zip seems to be updated, but nothing seems to have changed but the framerate. Is it correct that now all the demos run incredibly slower than in the package befor ?

Mason Green wrote:
> Blaze v0.6, a 2D Rigid Body Physics engine, has been released: http://www.dsource.org/projects/blaze
> 
> The code has been optimized for D, and all known bugs have been fixed. Enjoy!!!
> 
> The next step will be to implement joints.
> 
> If anyone is interested in creating cool demos please let me know so I can add them to the downloads section: http://www.dsource.org/projects/blaze/browser/downloads
> 
> Also, if you plan on using Blaze in your project please let me know! 
> 
> Thanks,
> Mason

For those who don't know, SirAlaran has been maintaining a phobos branch of Blaze that will be updated shortly.

The Blaze 0.5 demo was only running one time step per frame, which is not very accurate in regard to the impulse solver.  The new demo is running at 3 time step per frame, which gives you much more stable stacking. I've also included a 5 millisecond time delay in the mail demo loop to prevent 100% cpu load.  Download the library and demos and you can experiment with various time stepping methods to suit your needs.

That being said, I'm not sure how fast your CPU is, but Blaze 0.6 is lightning fast on my Windows-32 notebook, and even faster on my Linux-64 machine...

The majority of changes for Blaze 0.6 are internal. I've completely rewritten the engine to take advantage of D dynamic and associative arrays, and also cleaned up the code considerably. The next release will include new features such as joints and more advanced collision detection...

Mason

Extrawurst Wrote:

> the demo zip seems to be updated, but nothing seems to have changed but the framerate. Is it correct that now all the demos run incredibly slower than in the package befor ?

Mason Green schrieb:
> Download the library and demos and you can experiment with various time stepping methods to suit your needs.
>   
Yeah i gonna try it as soon as the phobos version gets updated.

> That being said, I'm not sure how fast your CPU is, but Blaze 0.6 is lightning fast on my Windows-32 notebook, and even faster on my Linux-64 machine...
>   
I really like Blaze and its code. i think i will try using it in a little 2D project as soon as i find the time.

Extrawurst wrote:
> the demo zip seems to be updated, but nothing seems to have changed but the framerate. Is it correct that now all the demos run incredibly slower than in the package befor ?

For what its worth, I just updated the demo zip to use release flags.

I know Mason did a lot of code restructuring changes, making the code better structured and more true to the Chipmunk implementation, probably resulting in taking out some functions that were inlined by hand, which may result in a slight speed decrease, in favor of better structure.

However, I think its an exaggeration to say the demos are running incredibly slower.

I think Mason may have changed the timestep or iterations to make the demos look 'smoother', but I'll let him comment on that if that is the case.

~ Clay

Clay Smith wrote:
> Extrawurst wrote:
>> the demo zip seems to be updated, but nothing seems to have changed but the framerate. Is it correct that now all the demos run incredibly slower than in the package befor ?
> 
> For what its worth, I just updated the demo zip to use release flags.
> 
> I know Mason did a lot of code restructuring changes, making the code better structured and more true to the Chipmunk implementation, probably resulting in taking out some functions that were inlined by hand, which may result in a slight speed decrease, in favor of better structure.
> 
> However, I think its an exaggeration to say the demos are running incredibly slower.
> 
> I think Mason may have changed the timestep or iterations to make the demos look 'smoother', but I'll let him comment on that if that is the case.
> 
> ~ Clay
> 

I just took the SDL_Delay out of the posted demo.

What I find interesting, is that without the SDL_Delay it still only uses 50% of the CPU.

Clay Smith wrote:
> Clay Smith wrote:
>> Extrawurst wrote:
>>> the demo zip seems to be updated, but nothing seems to have changed but the framerate. Is it correct that now all the demos run incredibly slower than in the package befor ?
>>
>> For what its worth, I just updated the demo zip to use release flags.
>>
>> I know Mason did a lot of code restructuring changes, making the code better structured and more true to the Chipmunk implementation, probably resulting in taking out some functions that were inlined by hand, which may result in a slight speed decrease, in favor of better structure.
>>
>> However, I think its an exaggeration to say the demos are running incredibly slower.
>>
>> I think Mason may have changed the timestep or iterations to make the demos look 'smoother', but I'll let him comment on that if that is the case.
>>
>> ~ Clay
>>
> 
> I just took the SDL_Delay out of the posted demo.
> 
> What I find interesting, is that without the SDL_Delay it still only uses 50% of the CPU.

If you have a dual core cpu or hyperthreading enabled, then cpu usage is often reported as 50% when one proc is pegged and the other isn't doing anything.  May or may not apply to your case.

--bb

> I really like Blaze and its code. i think i will try using it in a little 2D project as soon as i find the time.

No problem.  If you're looking for raw speed you should lower the number of iterations steps per frame in your main program loop.  However, the lower the number of steps, the less accuracy you're going to have with respect to solving simultaneous collisions, i.e. stacking.  If you have a situation that calls for single collision response, such as collision in zero gravity between dynamic objects with no resting contact, your should be able to get away with only one step per frame just fine...

Mason