Porting Script to Engine

#1 I do not think that porting this to C++ and including it in the engine is the right way. It sounds that something is conecptually wrong. What are you doing exactly? I cannot really imagine why a Match-3 game (even with 140 objects) would be so slow (or even need the onUpdate methode).

#2 I had to do some "magic" in the onUpdate function of the objects in order to get the physics to work properly.
It is not a typical Match-3 Game (every one says that).. ; Things are being stacked and falling using the built in physcis but as everyone knows, Stacking causes objects to start jittering.
I am using the onUpdate to check objects to see if they are "atRest" and if so I disable physics. Then I have to constantly check position of other objects to determine when to re-enable the physics...
That seems to be the only way to stack objects using the built in physcis.
If you want you can look at one of my earlier posts HERE
One thing I can think of is to only let my code run on Every Other OnUpdate by just having a flag for each object. That should lighten the load a little but do not know if it will perform as expected.
Maybe I'll try that.

I was thinking about going to C++ because I still have a lot of gameplay elements to add and figured if it was already slow then It would only get slower as I added things. I only have the Core game mechanics functioning right know.

#3 Most of the console functions of objects map to C++ member functions, although many of console wrappers do processing/checking on the input values. If you want to see which C++ functions are being used, just search for the ConsoleMethod wrapper in the project: "ConsoleMethod(class, function"

#4 I think I have to agree with Christian on this one...

I'm guessing that you can probably rework your algorithms to run much faster. From what I gathered in your other post, you're doing a bunch of for loops and physics fudging and collision tests and whatnot every frame for something that really shouldn't be so conceptually difficult. You can simplify a bunch of this stuff to help speed it up.

For example, you could maintain some kind of 2D array that keeps track of what pieces should be located in what position. Given that info, and the current actual positions of the pieces, you can manually move the objects to where they should actually be on the board. This way you only need to check things when something changes, rather than on every onUpdate() call. It also does away with all the collision and physics overhead.

Anyways, just my 2 cents... best of luck with your project!

Tom

#5 Thanks for the replies. I have let my brain cool off for a few days and am about to get back at this issue.

I will look at my onUpdate code again and try to consolidate and make sure I can't find better/faster ways
to make things work.
I do have a 2D array that holds my objects once they are stacked and "Locked IN" a Grid.
But they can't really be tracked in the array until they stop and I lock them in position.

I oroginally tried doing some things by manually moving them. Depending on what you were talking about,
the .MoveTo method did not work at all for what I am trying to do. If multiple objects are touching/colliding
it just doesn't work out trying to manuallly move them. The other way is to just .setposition but that doesn't work in my application because I do not need that "teleporting" movement..

I do think I will have to keep the Onupdate method and physics fudging as my objects are in constant
motion up and down and side to side. Only when they collide and have stopped via built in physics can I manually track them via my 2D Array...

Just to clarify, I sortof just wanted to start learning the C++ side of the engine and figured that I was
at a good spot to try and work on that.
I will continue to try and get my scripts performance maxed out and maybe dabble in the C++ to start
getting a feel for it..

I appreciate all posts and Kalle's tip on the C++ side of things...
Any other beginners tips on working through the engine are appreciated.

#6 I dont think i really have a grasp of what your game works... but from what i've read from the other folks, i think that dissabling the physics from the very beggining and relyin on the onColission method its the way to go (scrap the onUpdate method, and use it only if REALLY needed... and in as less objects as you can).

with the onColission method, you can check which side of the object colided with what and so do certain things... like say, setAtRest() or somethin like that... and since you have some sort of predefined grid, you can "cheat" some like this:

---> on collision
------> %obj.setAtRest();
------> %obj.setPosition(x, y); //this one its a prefixed position, determined by the surrounding objects or so.

hope it helps.

#7 Dustin, I've had the exact same need as you... In my game, I *need* to call certain object's onTimer() callback very frequently, and this slows down the game with a fair number of objects on the screen, on anything but the latest computer. But by porting a few key script methods to C++, I should be able to fix this.

I've just started this, but I've already got a working C++ console function that I exposed to script. It turned out to be very easy. Here it is:

// ConsoleMethod Parameters:
//
// 1) The class the function belongs to (i.e. t2dSceneObject)
// 2) The function name this function will be in script (usually best to keep this the same as the C++ function's name)
// 3) The return type of the function. Some common types are: F32, bool, const char*, void, etc.
// 4) Minimum number of arguments. Use 2 + number of script arguments, since this includes the function and type.
// 5) The maximum arguments. Often the same as the minimum number.
// 6) Text that describes the function when we do a .dump() on the object.
//
// NOTES: 
// - argv[2] is the first argument from script.
// - Use dAtof() to convert arguments from script into C++ variables. (Decode argument to float, is what I'm guessing this stands for.)

ConsoleMethod(t2dSceneObject, offsetSprite, void, 4, 4, "() Offsets the sprite by xOffset and yOffset\n"
                                                       "@param xOffset The horizontal offset"
                                                       "@param yOffset The vertical offset")
{
    object->setPosition( t2dVector( dAtof(argv[2]) + object->getPosition().mX, dAtof(argv[3]) + object->getPosition().mY ) );
    object->updateSpatialConfig();
}

Example usage from script:

%this.offsetSprite(1, 0);

I did "offsetSprite" simply because I wanted something easy to test with. And lo and behold, it works! Amazingly easy.


How I did it: I looked at similar ConsoleMethod functions t2dSceneObject, such as setPositionX and setPositionY, and was able to figure out, from the code there, how to write my method. I advise looking at these methods to see how I figured it out. Not hard at all. If you want to use other functions, like mSin() or mCos(), find those functions in the C++ script (find the ConsoleMethod for it), and look at how it's used.

I still have yet to figure out how to get access to variables created from script though, such as

%mySprite.aNewVariable = 5;

I don't know how to access that from the C++ code yet...