Have you noticed any performance issues when
the form (not fixed) is resized?
I have a mainform containing toolstrip container, menu and 2 toolbars.
Then my panel, a splitter and a propertygrid.
When the main form is sized there is some delay
in sizing the rest or is this C# NET?

Yes, Lite-C stores/restores my and you at each wait(). So in my opinion it would make sense if your scheduler did that too. It's no big deal though.

Hm... Couldn't you do something like always having two versions of each property. For example time_step and time_step_as_reference. I think most commonly variables don't get used as references. It would make sense to make the most common case easy and clean from the user perspective. If you want to use a variable in a panel you can add _as_reference.

@pararealist >>> You shouldn't really see a performance decrease because the engine is running on a seperate thread. Are you using the "embedding" sample from the manual? If you want to resize the engine when the form resizes then you will have to use the Resize event handler or you can override WndProc and handle the WM_RESIZE message. Then you will need to use the win32 call "SetWindowPos" to set the size of the engine window.

PM me if you want me to give you a "resizing" demo.

@amy >>> I think the way it uses Vars at the moment is pretty good, if not fine. Having time_step and time_step_as_reference would be overkill i think, and more work on Stromousfall's part. I think it also serves as a helper to use IntValue and FloatValue to stop you eg, passing a float to a function that wants an int, thus preventing errors.

@Stromausfall >>> I looked over the multiplayer functions in the manual and after some consideration decided not to go that way because a number of errors could occur (ip settings etc) and the engine's network functions don't have a reputation as being useful.

I wanted to go a bit more 'low-level' and operate on windows messages, so i decided to create a method of sending custom messages to the exe window. Then the window can handle it and do whatever it wants. It works fine...



...and i can control each instance seperately by passing values to each window.

LMAO, i have learnt more win32 in the past 3 days than ever before. At least we now have multiple instances running.

If anyone wants the code for running more than one instance of the engine, then ask here or PM me.

Thanks.

If he uses code generator scripts anyway it shouldn't be much work to add the _as_reference feature.

In what cases do you need references? Panels? What else? These rare cases where you need a reference shouldn't prevent streamlining the wrapper API in my opinion. Stromausfall did a great job so far but i still find the API a bit ugly. It's not wrist friendly to always have to type that much.

I think lengthy code which isn't easy to read leads to more errors than passing floats to ints. :p

Another question... I have never tried this but if you make a .NET dll out of this wrapper it should be usable from other .NET languages, right?

@DJBMASTER looks great! You're progress is really fast!

@amy I'm sorry but Var will stay the way it is now, as long as i don't find a solution that truly is easier for the user (and of course not too much work for me to implement ^^). The problem with your concept is, how would one pass a reference of a Var that the User created - your concept would only work for EngVar and maybe Vars in Engine Objects and it would also be confusing, as one would have "two" variables that represent the same but are of different types.

Regarding the .net dll, i have to admit that i have actually less to no knowledge about this topic. The only thing i know is that all .net languages compile to the same language.

in my opinion fixed point variables aren't that great. the user of the c# wrapper shouldn't be forced to ever create one himself. they are relics from a time when cpus didn't have floating point units. it shouldn't be necessary to think about vars at all. the issues with panels and other cases where references to vars are needed can be solved differently.

yeh, if you write the wrapper to be CLI compliant then it should be accessible though-out all .NET languages because they all run on the CLR.

If you can get unmanaged code into C#, then getting the C# into VB should be no problem, you don't have to worry about marshalling etc.

I agree that Var shouldn't change and if you really want to use ints and floats implicitly then you can write your own helper method/macro.

I think this would work...

My intention in using float and int is, that the engine uses these with it's var variable.
And thus also the user should use them if he interacts with the engine ^^

Does anyone know how to hide the start-up window completely. When using engine_open() the engine window flashes up. I've got "-nwnd" as the command line.

http://www.galep.com/beta/a-black.htm
according to this page you it's a pro feature, do you have pro ?