k now this is a really novice question but im not sure, should i be using "always....set counter to...."
or is it a bad idea cause its a continuesly running code? i have this running about 30 times per screen. Will this effect my game on low spec machines?(im running on a really high spec comp so i wont be able to see any problems)
one more question. There is an option in MMF2 to include external files when building the progamme. does this mean that i can inbed INI's etc?
Originally Posted by Antworx one more question. There is an option in MMF2 to include external files when building the progamme. does this mean that i can inbed INI's etc?
I'd like to know this too.
The best way around this is to have an external file with everything compressed inside, and during run it's extracted to the folde
one more question. There is an option in MMF2 to include external files when building the progamme. does this mean that i can inbed INI's etc?
I was looking into that myself a while ago. This is what Yves said at the CT forums:
Include external files
If this option is selected (in the properties of the application), MMF2 automatically includes in the EXE file all the files that are specified either in object properties, or in action/expression/condition filename parameters where you select the file in a file selector (not in a simple text expression).
When the application starts, MMF2 extracts all the files to a temporary directory and updates all the filenames in the application. If you want to access one of these files with a simple expression you can use AppTempPath$ + "name of your file".
Binary files (Data Elements editor)
If you don't want to include all the external files to your application, or if you want to access them directly from the EXE file, you can add files to the Binary Files tab of the Data Elements editor. These files are included in the EXE file and can be read directly from the EXE by objects that support them (all the Clickteam object + a few ones).
When an object that support this feature wants to read a file, it asks MMF2 to open it. MMF2 first checks if the pathname is the one of one of the embedded binary files and if so directly opens the EXE file at the position of the embedded file (otherwise it tries to open the file).
The next build of MMF2 (247) will contain an action that allows to extract an embedded binary file to a temporary file. I guess that's the best solution for you.
This space is for rent
DaVince This fool just HAD to have a custom rating
Registered 04/09/2004
Points 7998
5th November, 2007 at 07:49:33 -
Originally Posted by Antworx k now this is a really novice question but im not sure, should i be using "always....set counter to...."
or is it a bad idea cause its a continuesly running code? i have this running about 30 times per screen. Will this effect my game on low spec machines?(im running on a really high spec comp so i wont be able to see any problems)
Thanks
Edited by the Author.
Games always run at 60 frames per second, anyway. Which means your entire event list is looped through 60 times a second.
Believe me, it doesn't matter much at all, though a tiny optimization is to have as many stuff as possible in that one "always" rather than having 10 "always"es.
thx guys, that sorts that out. Basicly i have never had one of my games run on somone elses comp and the time for this draws ever closer (Dreamweaver.....coming soon!)
Im not the best coder and always find that my games end up eating themselves due to my ineffecient code, but this time i have been ultra carefull, this was my only concern.
As for the include external answer from the mmf boards....i dont get it. lol
TGF/MMF run on a quite different code structure then normal languages;
The event list is run through a read/eval/print loop every single "frame" of gameplay, as predefined in the settings. On default, this occurs 50 times per second (50 FPS). This is the same idea of having *every single* event take place on a 50 fps tick command structure in other languages.
Hence, it will read through every single command in the event editor, and once it reaches the very bottom, it will draw the onscreen actions. This means that an "always" event is an event that will take play every single run through the read/eval/print loop; it is the same as saying "trigger this action every 1/50 of a second", followed by the action.
This should almost never eat up your CPU. A simple action like "set counter to" can easily run 50 times a second without consuming any memory or processor space. In big O notation, its effectively O(1) at all places; its the same as defining a variable.
Advertisement
Post Reply
Edited by the Author.
