SC Physics

[Gan]

I loved those games, use to play them all the time.
It'd be awesome if someone made that.

As for terrain, there's something I haven't made yet that'd be perfect. It's called the Edge Shape. Similar to the polygon shape except that it's just lines.



That feature will come in a while though. Meanwhile boxes and circles could be used to make the terrain.

By the way, I'm part way through the next update. Currently hooking up collision detection.

[Connors]

Sweet, I don't mind if collision detection is a priority, that opens up some great possibilities. In the mean time I'll just make some methods that line up shapes for me.

[Gan]

Update!
- Joint drawing fixed.
- Sprite lag believed to be fixed.
- New SetGetVelocity(ShapeNum,True/False) command! Allows you to receive velocities of shapes. Thus you can tell if a shape is moving or is perfectly still. (Think landing game)
- New SetGetCollision(ShapeNum, True/False) command. Allows you to receive collisions of shapes. Which you can detect if one shape is touching another.
- Fixed flickering when first making the world! No more cruddy object teleportation and flashes.
- New Revolute Joint. Basically allows you to put a nail through two shapes and connects them where they can rotate freely of each other but connected. Good if you want to for example make a see saw. A triangle in the middle, a rectangle at the tip with a revolute joint piercing through both.

As always download is in the first post.

[Gan]

Added more demos, check it out:
http://www.youtube.com/watch?v=oEGXl-eDfbc

[Gan]

As a note, I didn't make a velocity demo so...

When making a shape you:

Code: [Select]

SetGetVelocity myShape, TRUE

That makes it so you can access velocity. Now to get the velocity you:

Code: [Select]

PRINT "X Velocity=" + STR$(shapeXVel(myShape))
PRINT "Y Velocity=" + STR$(shapeYVel(myShape))
PRINT "Rotational Velocity=" + STR$(shapeRotationVel(myShape))

I have it set up this way so the game runs fast. You set a shape to get velocity, then you just grab the velocity number from the array.

[Connors]

Hey Gan, if two shapes are touching when you start a physics world then as soon as they aren't there's a glitch in EndCollision. It's easy to re-create, it worked with a circle and a polygon or a circle and a circle.
And what's wrong with this polygon? Maybe I'm just tired but the physics wouldn't start.
I made the points with my brand new Object Builder, which I will upload as soon as I'm sure it works and is not the problem here.

Code: [Select]

LET polygon = CreatePolygon( "40,361;160,361;200,241;0,241", 100, 100, 0.2, 1, 0.1, "Dynamic", 0)

[Gan]

Hmm. It'll look into this bug tomorrow.

The polygon looks fine to me. I'll have to play with it. Hopefully soon I'll have the code to allow you guys to make any kind of polygon without error.

[Connors]

In that case I'll post what I made when I get home, it's pretty useful for seeing what the shape will be and you can tell it to lock to a grid.

[GMG Mike]

I just tried this out for the first time. Amazing shit right here.

I think a proper plugin system would be awesome for v2.1 even if it was Mac only (plugins made in Cocoa). REALbasic supports something called IPC which is more appropriate than regular sockets and I bet Cocoa supports this too.

Instead of having to launch the plugin and do all this other crap, the plugin would be rebundled from a .app into a new .scplugin format that you would add to a Plugins folder. Inside the bundle would be a file that describes all of the methods that the plugin adds to the game, including their parameters and return types so that they can be added to auto-complete.

In addition the game would support getting and setting variables by the plugin, as well as access to almost any method that the game has access to.

If a game uses a plugin it would be bundled into the game automatically, launched when the game starts and exited when the game stops.

In this model the plugin would be persistent and have it's own memory etc like a normal program. There's also another way we could do it that doesn't involve IPC at all but would actually be even cooler and closer to the REALbasic model. Instead of a program you would be writing a dylib. The dylib would expose a number of generic functions that would be identical between all SC plugins. REALbasic can weak link to libraries and I could set it up to weak link to say, 50 different plugins named SCPlugin1.dylib, SCPlugin2.dylib, etc. so up to 50 dylib plugins would be supported. Instead of using IPC Sockets (with a latency of maybe 1 ms) we could just use declares/method calls with a much smaller latency... just an idea I've been throwing around in my head.

Another idea I had for really really easy to make plugins would be SCMethodBundles which would be nothing but a group of methods that you save out of a project into a file, and then drag into the Plugins folder of SC. If you use any of the methods then it would link in the whole bundle. You still have to worry about overlapping variables though, consider this problem which can happen even in a regular game using methods:

Code: [Select]

FOR i = 1 to 10
   SOMEMETHOD
NEXT

SOMEMETHOD Code:

Code: [Select]

FOR i = 1 to 5
   PRINT "Hello"
NEXT

That code will cause infinite loop.

[Gan]

Aha! I was wondering when you'd notice Sc Physics.

Those plugin ideas are fantastic. Certainly be easier than doing direct sockets. There are some issues trying to keep things synced. If I could directly access Sc variables through a plugin that would be amazing.

[GMG Mike]

Aha! I was wondering when you'd notice Sc Physics.

Those plugin ideas are fantastic. Certainly be easier than doing direct sockets. There are some issues trying to keep things synced. If I could directly access Sc variables through a plugin that would be amazing.

There's something else I've looked into as well, there is a way for REALbasic to have a method, and you can pass a ptr for that method to a declare (as a callback), so there must be some way to write the dylib so you can access the REALbasic method. This would allow practically instantaneous access to variables with the least amount of overhead.

In theory somehow we could even use this with non-dylib plugins, I'm just not sure how.

[Gan]

Hmmm. Yeah if I could retrieve pointers of Sc variables that'd be crazy fast.

I'm willing to write up any code you need to get this working.

[GMG Mike]

Hmmm. Yeah if I could retrieve pointers of Sc variables that'd be crazy fast.

I'm willing to write up any code you need to get this working.

I don't think I can get pointers of regular variables.

I can get pointers to memoryblocks of arbitrary length, as well as pointers to functions (REALbasic AddressOf keyword). I don't know if the function can accept parameters or not. I don't know if your Cocoa app running in one memory space can access my memoryblocks running in a different memory space (this isn't OS 9 anymore)

SC game runtime variables are held in two arrays and I can not get pointers to individual array elements (and you probably couldn't edit them anyway if I could because of the memory space issues)

[Gan]

Hmm yeah.

Can Sc run C++ code?

[GMG Mike]

Hmm yeah.

Can Sc run C++ code?

You'll have to clarify that. I assume you mean can RB run C++ code, and the answer is, you can compile a plugin that links into REALbasic and provides classes, methods, etc. but SilverCreator would then need to bundle that plugin with each and every game whether or not it's used. SilverCreator is written in a specific way as to avoid RB plugins being bundled into the game runtime.

If you meant, can the SC script interpreter run C++ code the answer is obviously "no" - but almost all code can be converted, but there are lot of advanced operators, etc. that aren't supported.