OpenEuphoria

1. The Start Of A Physics Engine For Euphoria

• Posted by Andy May 09, 2009
• 1347 views
• Last edited May 10, 2009

Hello All,

I was wondering if anyone was interested in helping develop a physic library for Euphoria. I'd figure this would be great for game developers as well as being useful for other things in programming. My plans for the physics libray to have collision detection, velocity, friction, car physics, have support for various geomertric types(ie box, sphere, triangle, etc). Rigid body and rag-doll physics. So is anyone interested in this? I think this will be a really cool project, and it could help Euphoria get out there, even more.

3. Re: The Start Of A Physics Engine For Euphoria

• Posted by Andy May 10, 2009
• 1298 views

Thanks, I think this project would be really useful.

5. Re: The Start Of A Physics Engine For Euphoria

• Posted by achury May 20, 2009
• 1223 views

Great!

I like hidraulics and fluid physics...

How to begin?

7. Re: The Start Of A Physics Engine For Euphoria

• Posted by DerekParnell (admin) May 20, 2009
• 1290 views

I've started a project called "physiceul" on the "assembla" open source development site.

https://www.assembla.com/spaces/physiceul/team

You will need to register yourself at Assembla and let me know if you want to be on the team etc ... its free of course.

I have some code files to kickstart the project.

9. Re: The Start Of A Physics Engine For Euphoria

• Posted by Andy May 23, 2009
• 1199 views

I do have to admit, assembla is a bit confusing to use. I made an account, but how come I can't see any of the files, only the folders?

11. Re: The Start Of A Physics Engine For Euphoria

• Posted by euphoric (admin) May 23, 2009
• 1179 views

My experience is different. Assembla is a cheetah for me. Sourceforge is a sloth.

13. Re: The Start Of A Physics Engine For Euphoria

• Posted by ne1uno May 24, 2009
• 1140 views

its web is slower than sourceforge for me, but svn was ok. except, all the directories were empty.
maybe permissions were not set of the original files or directories?

I see 2 commit messages from the svn web page, but no file list.

15. Re: The Start Of A Physics Engine For Euphoria

• Posted by DerekParnell (admin) May 24, 2009
• 1157 views

I've uploaded some files now, just so you get a flavor of the stuff I've done.

http://my-svn.assembla.com/svn/physiceul/trunk/source/

17. Re: The Start Of A Physics Engine For Euphoria

• Posted by achury May 24, 2009
• 1175 views

You have a made a very complex definition for point. And we are not sure will be final. Some other funcions are specific for so definition, if change in the future all will become useless. Many of those functions fit better as geometrics.e, more than physics.

I propose a more Euphoria-like aproach, for example:

Calculate distance between 2 points with

function distance(sequence a, sequence b)

a and b may be {x}, {x,y}, {x,y,z}, {x,y,z,t} (4D space-time) but allways the sequences must to have the same length

If you define a point with a complex structure you can pass to the function with something like:

print(1, distance(PointA[1..3], PointB[1..3]))

The distance of the X proyections:

print(1, distance(PointA[1], PointB[1]))

The distance for Y proyections:

print(1, distance(PointA[2], PointB[2]))

19. Re: The Start Of A Physics Engine For Euphoria

• Posted by DerekParnell (admin) May 24, 2009
• 1197 views

Rather than messing up the EuForum, can we take these discussions over to the project site in future?

In what way is it complex? Is it the provision for OOP access that concerns you? This is optional - you can choose to use an OOP style or Procedural style of coding.

Any complexity is embedded in the library and not the way a person uses it - that is still very simple.

point2D A = p2d:new(X, Y) -- Define a point in 2d space 

The v3 style would have been more like ...

sequence A = new_p2d(X, Y) -- Define a point in 2d space 

which is not a whole lot different.

Change what? The internal definition of a point? In fact, the way I've organised things is so that we are free to change the internals as needed without having to change the API and thus force coders to update their programs.

Small include files are better than large one, so rather than have one huge "geometrics.e" I thought it better to break them into component pieces - points, lines, planes, triangle, rectangle, circle, sphere, etc ...

Yes, I know that the files there relate to geometry rather than physics, but they will be needed anyway. There will also be modules dealing with vectors and matrix math as well as energy, momentum, velocity, acceleration, friction, etc ...

These are building blocks to be used as required. Large library files were almost required for v3 Euphoria but v4 frees us from many of the restrictions so we can better organize libraries now.

function distance(sequence a, sequence b)

print(1, distance(PointA[1..3], PointB[1..3]))

print(1, distance(PointA[1], PointB[1]))

print(1, distance(PointA[2], PointB[2]))

Instead of ...

function p2d:distance(point2D a, point2D b)

print(1, p2d:distance(PointA, PointB)) 
 
print(1, p2d:distanceX(PointA, PointB)) 
 
print(1, p2d:distanceY(PointA, PointB)) 

The current setup is safer to use because it is harder to pass the wrong data to a function and is more self-documenting. If we have a single 'distance' function, errors such as

print(1, distance(PointA[1], PointB[2]))

can occur.

And by the way, using the sequence method you described above, how can the library distinguish between a point in 3D space and a 2D point with a time element?

{x,y,z} vs {x,y,t}