SC Physics

[Gan]

Yeah I meant RB. Cause the physics engine is written in C++. Cross platform. If Sc could link to C++ code, the engine could be built in.

[x]

You could always just attach the compiled plugin exe to the end of the sc project exe in binary form. But I guess you would have to parse it all yourself, and create a runtime to execute it separately.

[GMG Mike]

You could always just attach the compiled plugin exe to the end of the sc project exe in binary form. But I guess you would have to parse it all yourself, and create a runtime to execute it separately.

It's too messy to extract an EXE, run it, and then have to throw it away later.

Back when the entire game was held in silvercreator.dat, I had to extract all of the game sounds this way because they were really just QuickTime movies. The temp folder got littered up, and if you had a lot of sounds then your disk would thrash for a second or so when the game loaded. The first thing I did for the OS X bundle compiled games was store the sounds separately. Later I decided to store all the pictures as PNG files so they would be smaller and cross platform (old format was Mac PICT style, or Windows BMP for Win32 and those are huge)

In the future, there will be a new file format called .scbproj which will be SC Bundle Project. This will store everything in lossless PNG files, separate QuickTime movies, and one file for scripts and card data and finally eliminate Mac PICT. Then in theory, SilverCreator it's self could be made for Windows.

Related side note for everyone: If you use a lot of photographs in your game you should make sure to allow JPEG when compiling since this will save a lot of space. The compiler is smart enough to choose the smaller file so line art will still be perfectly clear PNG and only photographic images will be JPEG - and sprite masks are always PNG so you won't get artifacts. You can choose high quality JPEG and it will be unnoticable to the player.

[x]

It's too messy to extract an EXE, run it, and then have to throw it away later.

Back when the entire game was held in silvercreator.dat, I had to extract all of the game sounds this way because they were really just QuickTime movies. The temp folder got littered up, and if you had a lot of sounds then your disk would thrash for a second or so when the game loaded. The first thing I did for the OS X bundle compiled games was store the sounds separately. Later I decided to store all the pictures as PNG files so they would be smaller and cross platform (old format was Mac PICT style, or Windows BMP for Win32 and those are huge)

In the future, there will be a new file format called .scbproj which will be SC Bundle Project. This will store everything in lossless PNG files, separate QuickTime movies, and one file for scripts and card data and finally eliminate Mac PICT. Then in theory, SilverCreator it's self could be made for Windows.

Related side note for everyone: If you use a lot of photographs in your game you should make sure to allow JPEG when compiling since this will save a lot of space. The compiler is smart enough to choose the smaller file so line art will still be perfectly clear PNG and only photographic images will be JPEG - and sprite masks are always PNG so you won't get artifacts. You can choose high quality JPEG and it will be unnoticable to the player.

Yes, extracting ANYTHING thats been appended is always tricky, and ramps up the .exe size. It was just another idea to consider.

Speaking of which, I have another. You could have external functions they way that blitzmax and some other languages do. If you have xcode on the users computer for example, you could compile C++/etc and have a proxy method within SC. When anyone runs that method it executes the compiled function written in C++ that its linked too, and returns the variables/arrays/etc. So, when the user compiles their SC project, it also compiles the .cpp file they added, and links all the functions in it to SC method proxies.

Although to be fair, this will probably be really clunky and hard to implement. But the more options the better eh?

[Zoo]

I can see physics sidescrolling platformers popping up all over the GMG.

[Connors]

I wish I understood more of those 2 posts.

[Gan]

I too was lost.

Anywho I believe there's a C++ RB plugin. Just an idea but it would be 5* easier and even faster to have it built in.

[Connors]

I have made this simple program to visually draw shapes for SCBox2D. It allows for quicker coding and more complex parts, possibly even gears later. I plan to update it and improve a few things later.
https://sites.google.com/site/onronc/ObjectBuilder.zip?attredirects=0&d=1

The problem is it seems that my polygons are making an error that makes the plugin quit after SC draws the polygon, so the physics stop. Any idea why?
https://sites.google.com/site/onronc/Polygon.scproj?attredirects=0&d=1

[Gan]

That object builder is nice! Though there appears to be an error when you're coming back from the instructions screen.

As for the polygon, remember when I flipped the coordinate system? Turns out polygons need to be clockwise.

Here's the working coordinates:
"120,10;120,30;100,50;60,70;0,70;0,10"

I'm going to start looking heavily into fixing polygons.

[Connors]

OOOOHHHHHHHHH I found the problem Matt. When you said "Clockwise", you meant "Counter-Clockwise" or "Left".

[Gan]

Ah hahah yeah... I should probably use regular clocks instead of digital.

[GMG Mike]

Speaking of which, I have another. You could have external functions they way that blitzmax and some other languages do. If you have xcode on the users computer for example, you could compile C++/etc and have a proxy method within SC. When anyone runs that method it executes the compiled function written in C++ that its linked too, and returns the variables/arrays/etc. So, when the user compiles their SC project, it also compiles the .cpp file they added, and links all the functions in it to SC method proxies.

Although to be fair, this will probably be really clunky and hard to implement. But the more options the better eh?

My idea was not too far off. The plugin developer would compile the C++ themselves into a dylib. REALbasic can "weak link" to dylibs. All I would need to do is weak link to generic methods in 50 dylibs all named SCPlugin01, SCPlugin02... all the way to SCPlugin50. When you compile the game in SC, it would take all of the dylibs the game needs and rename them, and then include some information as to which plugin is which dylib.

So, to include the physics dylib with your game, the SilverCreator compiler would take SC Physics.scplugin (which has the dylib and the file describing all the functions), take the dylib and rename it to SCPlugin01.dylib and bundle it in the app. The byte code system works by assigning everything numbers, for example the beep method is method #1. The byte code system would assign numbers to methods from used plugins and would include a table that says methods 123-126 are in plugin 1, etc. When method 123 is called, we then call a function in the weak-linked SCPlugin01.dylib, something like ExecuteMethod which returns nothing. We would also have ExecuteNumberFunction and ExecuteStringFunction if we need data back, and some way to pass the parameters.

The whole point of doing all that is that we need not modify the SC Runtime (RuntimeMac) at all, we just have to include information that says SCPlugin01.dylib is really "such and such plugin, that does all of this nice stuff that we'll be referencing". So they're really truly plugins but without all of that messy actual compiling.

I'm not sure how dylibs work exactly, whether or not they have a persistent memory area as long as the parent app is running - or if they just have temporary memory while a dylib method is running. I *think* they might have persistent memory which would make things easier.

I'm not sure if you can do this Gan - can you write a dylib? Something that just exposes a generic function named "TestBeep", no parameters or return value, all it does is issue a system beep? Make sure it compiles for 10.4+, PPC and Intel. We can use that to test.

[x]

My idea was not too far off. The plugin developer would compile the C++ themselves into a dylib. REALbasic can "weak link" to dylibs. All I would need to do is weak link to generic methods in 50 dylibs all named SCPlugin01, SCPlugin02... all the way to SCPlugin50. When you compile the game in SC, it would take all of the dylibs the game needs and rename them, and then include some information as to which plugin is which dylib.

So, to include the physics dylib with your game, the SilverCreator compiler would take SC Physics.scplugin (which has the dylib and the file describing all the functions), take the dylib and rename it to SCPlugin01.dylib and bundle it in the app. The byte code system works by assigning everything numbers, for example the beep method is method #1. The byte code system would assign numbers to methods from used plugins and would include a table that says methods 123-126 are in plugin 1, etc. When method 123 is called, we then call a function in the weak-linked SCPlugin01.dylib, something like ExecuteMethod which returns nothing. We would also have ExecuteNumberFunction and ExecuteStringFunction if we need data back, and some way to pass the parameters.

The whole point of doing all that is that we need not modify the SC Runtime (RuntimeMac) at all, we just have to include information that says SCPlugin01.dylib is really "such and such plugin, that does all of this nice stuff that we'll be referencing". So they're really truly plugins but without all of that messy actual compiling.

I'm not sure how dylibs work exactly, whether or not they have a persistent memory area as long as the parent app is running - or if they just have temporary memory while a dylib method is running. I *think* they might have persistent memory which would make things easier.

I'm not sure if you can do this Gan - can you write a dylib? Something that just exposes a generic function named "TestBeep", no parameters or return value, all it does is issue a system beep? Make sure it compiles for 10.4+, PPC and Intel. We can use that to test.

To be honest I don't know much about dylibs as most of the C based programming i've done has been windows. But having said that im pretty sure they get their own stack, so it sounds like it would be ideal for creating a reference method, as I was saying before.

By the way, the way you organised compiled SC projects is freaking neat!

Technical details aside, the SC plugin thing sounds awesome and might really open SC up for all sorts of crazy new features. Like a simple 3d plugin if you could give us access to draw directly onto the canvass!

[Gan]

Whoa. That's mind blowing.

Yeah I'll learn how to write a Dylib. I have all weekend.

[Connors]

I know little or nothing about most of this, but, plugins would open up some great opportunities, like if you know what you're doing and you want a new functionality, you needn't wait for it to be added. We could possibly also attract more users that way.