Page 1 of 1

Box2D Integration

Posted: Fri Jul 01, 2022 10:12 am
by tperry2x
I was just wondering, did Box2D ever make it into Livecode Community?
https://www.mail-archive.com/use-liveco ... 02253.html

I was just wondering how far it ever got.
Especially when you consider they raised £417,000
https://www.kickstarter.com/projects/17 ... sts/415346

Not only would it make game creation far easier if we had a physics engine, but it may actually make in-roads into decent 30fps / 60fps card redraw rates.

As mentioned elsewhere in this forum, what I would love to see one day is a command such as:

Code: Select all

set MaxCardRefresh to 60
and then...

Code: Select all

put MaxCardRefresh
max screen refresh achievable: 30.4 fps
Hopefully this means that anyone doing animation, game creation, or simulating physics with Box2D integration, had a consistent experience across older and newer hardware.

On slower machines, to achieve this, other tricks could be used such as loading the entire stack into RAM and warning if a GPU is unavailable:

Code: Select all

set MaxCardRefresh to 30
error: Refresh rate specified is not possible, no compatible GPU hardware detected.

Re: Box2D Integration

Posted: Sun Jul 03, 2022 9:14 pm
by overclockedmind
Don't forget locking the screen until the until the entire screen update is actually done, if it's still there. Literally:

Code: Select all

	lock screen
	-- Do several operations to update screen,
	-- and all of them are going to pop at once
	unlock screen

Re: Box2D Integration

Posted: Thu Jul 07, 2022 9:32 pm
by OpenXTalkPaul
tperry2x wrote: Fri Jul 01, 2022 10:12 am I was just wondering, did Box2D ever make it into Livecode Community?
https://www.mail-archive.com/use-liveco ... 02253.html

I was just wondering how far it ever got.
Especially when you consider they raised £417,000
https://www.kickstarter.com/projects/17 ... sts/415346

Not only would it make game creation far easier if we had a physics engine, but it may actually make in-roads into decent 30fps / 60fps card redraw rates.

As mentioned elsewhere in this forum, what I would love to see one day is a command such as:

Code: Select all

set MaxCardRefresh to 60
and then...

Code: Select all

put MaxCardRefresh
max screen refresh achievable: 30.4 fps
Hopefully this means that anyone doing animation, game creation, or simulating physics with Box2D integration, had a consistent experience across older and newer hardware.

On slower machines, to achieve this, other tricks could be used such as loading the entire stack into RAM and warning if a GPU is unavailable:

Code: Select all

set MaxCardRefresh to 30
error: Refresh rate specified is not possible, no compatible GPU hardware detected.
The only thing I saw relevant to that 'stretch goal' funding campaign item was Monte posted a GIF of geometric objects bouncing off of each other on GitHub's chat thing Gitter.im but that was years ago when Extension Builder was first starting to get interesting. He never posted any code or anything like that.

I would certainly like to get to wrapping some more libraries like Box2D (https://box2d.org) or Love (https://love2d.org/wiki/love) or even all of the SDL framework into builder extensions.
Maybe after an initial public release (SOON!) we can organize some sort of plans for moving far beyond the legacy LiveCode Community Edition base, as collaborative team.

It's a lot of work just wrapping anything beyond a very basic foreign code library. I could REALLY use some help! I'm willing to teach Extension Builder xTalk-ish 'dialect' to people if need be. For Foreign Code Libraries it's mostly all about creating these FFI 'binding strings' for the libraries exported (public) symbols (commands/functions). Once you get the hang of creating those for the target (there's different binding string format depending on if the Foreign lib is JAVA,JS,C or ObjectiveC based). I've been adding more and more binding strings and type conversions for Objective C / Foundation/NS* frameworks, a bunch of that NS* stuff (NS = NeXTStep) some of which might be usable for cross-platform if we wrapped the GNUStep binaries. Lots of very useful functionality available there. The NSURL protocol alone could be really nice, doing async background downloads (also we could then we can remove the outdated embedded OpenSSL) for example.

It would be nice to wrap Box2D as a gesture (a certain hand gesture ;-) ), completing unfulfilled promises of the various funding campaign goals reached by the community.
I consider the state that the IDE's UI was left in as another unfulfilled promise for a 'sleek and modern' IDE UI. That's one goal that I've been slowing working on in between other things.

Still not sure about adding refresher rate syntax in that context. I mean what you're talking about is the 'Frames Per Second of graphic rendering, vs. a screen refresher rates which are frequency attributes of display monitors.

There is already a 'frameRate' property for 'VideoClips'

Code: Select all

set the frameRate of videoClip to timeDelay
There's also:

Code: Select all

set the syncRate to number
-- Specifies how often the display is updated during visual effect, drag, and move commands. Default is 20 
If we are adding any new widget or library objects that need a property similar to something else already in the engine, we should make the property name the same for consistency (Note: I've had problems 'Shadowing' certain built-in properties with my own widget properties)

Re: Box2D Integration

Posted: Sun Jul 10, 2022 1:42 pm
by tperry2x
Okay, makes sense.
I'm all for wrapping Box2D in. 80% of me wants to see it as a huge plus to OpenXT, and the other 20% as a certain :evil: censored :evil: hand gesture too!

Re: Box2D Integration

Posted: Sun Aug 14, 2022 2:00 pm
by tperry2x
Having said that, I realise I'm probably reinventing the wheel and asking OpenXT to be transformed into Godot.
OpenXT and Godot are two different entities, so I guess it's fair not to ask too much of the framerate / animation aspects of OpenXT.

It might be what I'd consider a prerequisite, but it's probably best to limit the multimedia aspects of OpenXT as it's not what everyone else would expect.

So, what is OpenXT in essence? Is it a RAD application prototyping tool, a multimedia creation and presentation utility, a vehicle solely for the xTalk programming language, some kind of web-application builder, a game creation utility.... or is it all of the above?

Essentially, if it's all of the above, trying to wrap all of these elements in to one pre-compiled binary is a huge task. Although I'm a huge advocate for having a binary available for all platforms, even putting out a beta with a roadmap - with a progress / planned features dialog - along the lines of "sound implementation planned for OpenXT vx.x" and "Emscripten engine support in progress"... I'm conscious of perhaps there's loads of different directions that development could take, but trying to persue all of these possible directions at once may lead to going nowhere.

A clearly defined order-of-events and progress roadmap may be beneficial perhaps?

Image