BBC BASIC
Programming >> Libraries >> BOX2D library for BBCSDL?
http://bbcbasic.conforums.com/index.cgi?board=libraries&action=display&num=1506080589
BOX2D library for BBCSDL?
Post by Richard Russell on Sep 22nd, 2017, 11:43am

If I were to port the BOX2D library to BBCSDL (which wouldn't be easy, given that the DLL was built in Visual Studio) would anybody use it?

Richard.
Re: BOX2D library for BBCSDL?
Post by michael on Sep 23rd, 2017, 12:41am

After looking at the videos on BOX2D, I would be very interested in a tool that helps with the laws of physics.

I will have my next improvement to the 3Deditor on Monday night and look forward to adding some physics to certain types of games, like 3D pinball, which I really would like to work on once the editor is ready for small object designs.

Re: BOX2D library for BBCSDL?
Post by Richard Russell on Sep 23rd, 2017, 09:27am

on Sep 23rd, 2017, 12:41am, michael wrote:
look forward to adding some physics to certain types of games, like 3D pinball

I hope you realise that BOX2D is strictly 2D (the clue is in the name)! You could only apply it to a 3D scenario in very limited and specific circumstances, when the 'physics' somehow only applies in 2 dimensions! If by 3D pinball you mean that the only use of the 'third' dimension is in having a frictionless sloping surface, then yes you could possibly simulate that by scaling the gravity term.

Anyway, as I hope was clear, my question was specifically about porting the BOX2D library to BBCSDL. The support (albeit for a fairly old version) in BB4W remains excellent, using BOX2DLIB.BBC, BOX2DGFX.BBC and BOX2DDBG.BBC. Build your pinball simulation in BB4W first and then, if you are still keen to port it to BBCSDL, we can discuss what the possibilities might be.

Richard.
Re: BOX2D library for BBCSDL?
Post by michael on Sep 23rd, 2017, 1:54pm

Quote:
I hope you realise that BOX2D is strictly 2D


Yes. The renderer, regardless of the coordinate system, doesn't effect the x,y coordinates of the graphics screen.

( I checked that when working the mouse presence for each screen)

The only aspects that I would make 3D would be the spinning ball and the rotating paddles.

If BOX2D physics coordinate system is only applicable to predefined draw controls, then I guess it would be not applicable because I am aware of the shared graphics subject.

(which I am working on a remedy for 3D button controls that would have mouse interactivity. So when the mouse moves over the 3D button, a button of different texture would move slightly ahead of the main button and reverse when the mouse was away from it.)

From what I have determined, adjustment in the 3D world can be 0.01 and -0.01 to the limits of the view (on the horizontal and verticle coordinates.

So it would be a matter of working out the conversion of coordinates for mouse control, as well as location of the 3D image in a 2D location relative conversion.

Re: BOX2D library for BBCSDL?
Post by Richard Russell on Sep 23rd, 2017, 3:34pm

on Sep 23rd, 2017, 1:54pm, michael wrote:
The only aspects that I would make 3D would be the spinning ball and the rotating paddles.

Ah, OK. I don't think anybody has yet used BBC BASIC to combine the Box2D physics engine with 3D-rendered graphics and that would be an extremely interesting project. There are no technical hurdles that I am aware of, and the result could be visually exciting.

If you don't attempt it I probably will!

Richard.
Re: BOX2D library for BBCSDL?
Post by michael on Sep 23rd, 2017, 4:11pm

Quote:
If you don't attempt it I probably will!


I have already tested the button idea. It will work. Ill have an demo ready on Monday.

That would be cool if you did work on an physics engine for 3D. I will try my hand at it regardless.

OH by the way! You may want to talk to DDRM, as he just made a shapes library for 3D (he did it lightning fast in response to my endeavours. He is interested in this also.


Re: BOX2D library for BBCSDL?
Post by Richard Russell on Sep 23rd, 2017, 6:46pm

on Sep 23rd, 2017, 4:11pm, michael wrote:
That would be cool if you did work on an physics engine for 3D. I will try my hand at it regardless.

I wasn't suggesting that I would do any work on the 'physics engine' itself - none is necessary really since Box2D already works with floating-point coordinates that are compatible with 3D rendering.

Quote:
You may want to talk to DDRM, as he just made a shapes library for 3D

He's a member of this forum (at least, he was) so if he wants to contribute he can. There is a FNshape() function, written by me, in opengl.bbc (in the examples/graphics folder of BBCSDL) which can create vertex arrays for spheres, cones and cylinders (in fact any shape that can be described by rotating a 2D function around the Z-axis).

Richard.
Re: BOX2D library for BBCSDL?
Post by DDRM on Sep 24th, 2017, 6:33pm

Hi Richard et al,

I've posted my current version of "Make3DLib" in the libraries section of the files section of the groups.io discussion group.

https://groups.io/g/bb4w/files/Libraries/Make3dLib.bbc

Richard, if you don't think it's finished enough to leave there, feel free to move it to the temp folder (but let us know!). It does one naughty thing - it uses a global variable to facilitate "overloading" of the routines.

You may need to be logged in as a member to get it. It's slightly updated from the version I posted on the BB4W conforum - most significantly with much better texture mapping to some shapes.

It has fairly copious notes at the beginning about what routines are included, and how to use them, and I've got some sort examples which give an idea. It can make spheres, cones,cylinders, truncated cones (and, indirectly prisms) prisms and write them either singly or en masses to an FVF file. You can include coordinates, normals, texture coordinates, and ambient and specular colours, depending on the vertex format code you specify. There are also routines to modify the shapes (shear/stretch/rotate/translate), so you can align them to make more complex shapes.

I'm interested to read about Richard's routine: that may well be better than mine, though my routines do allow you to make PART of a shape. I will add some more primitives (torus and "cove" are on my list - the latter once I work out how to calculate the external centre of curvature!

Best wishes,

D

Here's a program to generate a model somewhat like the Starship Enterprise:

Code:
      INSTALL "Make3dLib.BBC"      capped%=TRUE   :REM Include ends on the cylinder      nf%=20       :REM Number of faces      startface%=1   :REM Include the whole cylinder, or only part of it?      endface%=10      REM Coordinates to map a texture to the shape. You might want to use only a small part of a texture      texminu=0      texmaxu=1      texminv=0      texmaxv=1      maxnv%=FNGetNumVerts("sphere",nf%,1,nf%,TRUE)      DIM v(maxnv%,2),vn(maxnv%,2),t(maxnv%,1)  :REM hold vertex, normal, and texture data      DIM vr(maxnv%,2),vnr(maxnv%,2)         :REM These are only needed for the display routine      nf%=10      REM We need to count up all the vertices that will be used in all the sections, so that we can put it at the beginning of the file      tnv%=4*FNGetNumVerts("trunccone",nf%,1,nf%,TRUE)+1*FNGetNumVerts("sphere",nf%,1,nf%,FALSE)+4*FNGetNumVerts("sphere",nf%,6,nf%,FALSE)+4*FNGetNumVerts("prism",5,1,5,FALSE)      vform%=&152       :REM Here I'm making a file with vertex, normal, and colour data      fh%=FNOpenFVF("Enterprise",tnv%,vform%)      nv%=FNGetNumVerts("trunccone",nf%,1,nf%,TRUE)      PROCMake3D_TruncCone(1.0,0.5,nf%,v(),vn(),t(),1,nf%,TRUE,texminu,texmaxu,texminv,texmaxv)      PROCStretch(nv%,v(),-0.5,1,1)      REM Normals for smooth shapes are initially generated as their endpoints, so that can be scaled etc,      REM So we need to carry out any transformations on them in parallel      PROCStretch(nv%,vn(),-0.5,1,1)      REM Now we need to convert the normals to normalised vectors      vn()=vn()-v()      PROCNormalise(nv%,vn())      PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FF808080,&FFFFFFFF)      nv%=FNGetNumVerts("trunccone",nf%,1,nf%,TRUE)      PROCMake3D_TruncCone(1.0,0.5,nf%,v(),vn(),t(),1,nf%,TRUE,texminu,texmaxu,texminv,texmaxv)      PROCStretch(nv%,v(),4,1,1)      PROCStretch(nv%,vn(),4,1,1)      vn()=vn()-v()                  :REM "Normals" are initially generated as their endpoints, so that can be scaled etc, but now need to be converted to vectors      PROCNormalise(nv%,vn())      PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FF808080,&FFFFFFFF)      nv%=FNGetNumVerts("trunccone",nf%,1,nf%,TRUE)      PROCMake3D_TruncCone(0.5,0.4,nf%,v(),vn(),t(),1,nf%,TRUE,texminu,texmaxu,texminv,texmaxv)      PROCStretch(nv%,v(),4,1,1)      PROCStretch(nv%,vn(),4,1,1)      PROCShift(v(),2,2.5,2.5,nv%)      PROCShift(vn(),2,2.5,2.5,nv%)      vn()=vn()-v()                  :REM "Normals" are initially generated as their endpoints, so that can be scaled etc, but now need to be converted to vectors      PROCNormalise(nv%,vn())      PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FF808080,&FFFFFFFF)      nv%=FNGetNumVerts("trunccone",nf%,1,nf%,TRUE)      PROCMake3D_TruncCone(0.5,0.4,nf%,v(),vn(),t(),1,nf%,TRUE,texminu,texmaxu,texminv,texmaxv)      PROCStretch(nv%,v(),4,1,1)      PROCStretch(nv%,vn(),4,1,1)      PROCShift(v(),2,2.5,-2.5,nv%)      PROCShift(vn(),2,2.5,-2.5,nv%)      vn()=vn()-v()                  :REM "Normals" are initially generated as their endpoints, so that can be scaled etc, but now need to be converted to vectors      PROCNormalise(nv%,vn())      PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FF808080,&FFFFFFFF)      nv%=FNGetNumVerts("sphere",nf%,1,nf%,TRUE)      PROCMake3D_Sphere(nf%,v(),vn(),t(),1,nf%,texminu,texmaxu,texminv,texmaxv)      PROCStretch(nv%,v(),3,0.2,3)      PROCStretch(nv%,vn(),3,0.2,3)      PROCShift(v(),-2.1,1.5,0,nv%)      PROCShift(vn(),-2.1,1.5,0,nv%)      vn()=vn()-v()                  :REM "Normals" are initially generated as their endpoints, so that can be scaled etc, but now need to be converted to vectors      PROCNormalise(nv%,vn())      PROCFindNormals(nv%,v(),vn())  :REM Cheat: something is going wrong with normals of sphere by flattening it so much: cheat by using triangles directly - OK when this flat      PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FF808080,&FFFFFFFF)      nf%=4      nv%=FNGetNumVerts("prism",nf%,1,nf%,FALSE)      PROCMake3D_Prism(nf%,v(),t(),1,nf%,FALSE,texminu,texmaxu,texminv,texmaxv)      PROCRotate(v(),PI/4,0,0)      PROCStretch(nv%,v(),3.5,0.5,0.2)      PROCRotate(v(),0,0,-PI/2)      PROCRotate(v(),-PI/4,0,0)      PROCShift(v(),2.5,0,0,nv%)      PROCFindNormals(nv%,v(),vn())  :REM With facetted shapes we can simply calculate the normals after all the messing around      PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FF808080,&FFFFFFFF)      nv%=FNGetNumVerts("prism",nf%,1,nf%,FALSE)      PROCMake3D_Prism(nf%,v(),t(),1,nf%,FALSE,texminu,texmaxu,texminv,texmaxv)      PROCRotate(v(),PI/4,0,0)      PROCStretch(nv%,v(),3.5,0.5,0.2)      PROCRotate(v(),0,0,-PI/2)      PROCRotate(v(),PI/4,0,0)      PROCShift(v(),2.5,0,0,nv%)      PROCFindNormals(nv%,v(),vn())      PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FF808080,&FFFFFFFF)      nv%=FNGetNumVerts("prism",nf%,1,nf%,FALSE)      PROCMake3D_Prism(nf%,v(),t(),1,nf%,FALSE,texminu,texmaxu,texminv,texmaxv)      PROCRotate(v(),PI/4,0,0)      PROCStretch(nv%,v(),1.5,1,0.3)      PROCShear(nv%,v(),2,0,1)      PROCRotate(v(),0,0,-PI/2)      PROCShift(v(),1.8,0,0,nv%)      PROCFindNormals(nv%,v(),vn())      PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FF808080,&FFFFFFFF)      nv%=FNGetNumVerts("prism",nf%,1,nf%,FALSE)      PROCMake3D_Prism(nf%,v(),t(),1,nf%,FALSE,texminu,texmaxu,texminv,texmaxv)      PROCRotate(v(),PI/4,0,0)      PROCStretch(nv%,v(),0.5,0.1,0.1)      PROCShift(v(),-1,0,0,nv%)      PROCFindNormals(nv%,v(),vn())      PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FF804040,&FFFFFFFF)      nf%=10      nv%=FNGetNumVerts("sphere",nf%,6,nf%,TRUE)      PROCMake3D_Sphere(nf%,v(),vn(),t(),6,nf%,texminu,texmaxu,texminv,texmaxv)      PROCStretch(nv%,v(),0.2,0.5,0.5)      PROCStretch(nv%,vn(),0.2,0.5,0.5)      PROCShift(v(),-0.8,0,0,nv%)      PROCShift(vn(),-0.8,0,0,nv%)      vn()=vn()-v()      PROCNormalise(nv%,vn())      PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FF804040,&FFFFFFFF)      nv%=FNGetNumVerts("sphere",nf%,1,5,TRUE)      PROCMake3D_Sphere(nf%,v(),vn(),t(),1,5,texminu,texmaxu,texminv,texmaxv)      PROCStretch(nv%,v(),0.4,0.4,0.4)      PROCStretch(nv%,vn(),0.4,0.4,0.4)      PROCShift(v(),2,2.5,-2.5,nv%)      PROCShift(vn(),2,2.5,-2.5,nv%)      vn()=vn()-v()      PROCNormalise(nv%,vn())      PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FFF04040,&FFFFFFFF)      nv%=FNGetNumVerts("sphere",nf%,1,5,TRUE)      PROCMake3D_Sphere(nf%,v(),vn(),t(),1,5,texminu,texmaxu,texminv,texmaxv)      PROCStretch(nv%,v(),0.4,0.4,0.4)      PROCStretch(nv%,vn(),0.4,0.4,0.4)      PROCShift(v(),2,2.5,2.5,nv%)      PROCShift(vn(),2,2.5,2.5,nv%)      vn()=vn()-v()      PROCNormalise(nv%,vn())      PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FFF04040,&FFFFFFFF)      nv%=FNGetNumVerts("sphere",nf%,6,nf%,TRUE)      PROCMake3D_Sphere(nf%,v(),vn(),t(),6,nf%,texminu,texmaxu,texminv,texmaxv)      PROCRotate(v(),0,0,-PI/2)      PROCRotate(vn(),0,0,-PI/2)      PROCStretch(nv%,v(),1,0.3,0.5)      PROCStretch(nv%,vn(),1,0.3,0.5)      PROCShear(nv%,v(),-0.3,1,0)      PROCShift(v(),-1.7,1.7,0,nv%)      PROCShift(vn(),-1.7,1.7,0,nv%)      vn()=vn()-v()      PROCNormalise(nv%,vn())      PROCExtendFVF(fh%,vform%,nv%,v(),vn(),t(),&FF808080,&FFFFFFFF)      PROCCloseFVF(fh%)      PRINT "Success!"      END
Re: BOX2D library for BBCSDL?
Post by Richard Russell on Sep 24th, 2017, 9:21pm

on Sep 24th, 2017, 6:33pm, DDRM wrote:
It does one naughty thing - it uses a global variable to facilitate "overloading" of the routines.

I don't think that's too awful so long as you use a 'unique' name for the global. Two approaches that effectively guarantee that are to include the name of the library in the name of the global, e.g. myGlobal@myLibrary, or to use a UUID as the name, which by definition is unique. I use the first of these in ogllib.bbc:

Code:
      SYS "SDL_GL_GetCurrentContext", @memhdc% TO origContext@ogllib%

Something to bear in mind is that the library may fail if the user's program, from which it is called, executes a CLEAR statement. That's not as unlikely as you may think, for example most of the 3D programs supplied with BBCSDL contain code similar to this to cope with resizing the window or rotating an Android device from portrait to landscape orientation or vice-versa:

Code:
      ON MOVE IF @msg% <> 5 RETURN ELSE PROCcleanup : CLEAR

Richard.