Pete Nattress Cheesy Bits img src/uploads/sccheesegif
Registered 23/09/2002
Points 4811
2nd February, 2004 at 10:49:02 -
shab: too much.
the problem with click products is that there's so many ways to code pretty much anything... so finding the most effecient way can be a challenge. espescially if you code 100 lines of stuff as a newbie and go back to it later and realize you could have done it in about 10 (me).
Same here pete. I will think for somtimes hours on how to code a certain thing, even though I can think of tons of easy ways to do it, I always want to do it none or minimum ammount of extra objects to complete the task (Like extra counters or invisable objects).
We are the music makers, we are the dreamers of dreams...
i bet if some of you guys checked how many of the same event ('always'...'start of level', etc) you had, you'd be able to cut at least 10 off to start with
Edited by the Author.
"Say you're hanging from a huge cliff at the top of mt. everest and a guy comes along and says he'll save you, and proceeds to throw religious pamphlets at you while simultaniously giving a sermon." - Dustin G
Nah. I make sure I keep track of that one "Start of Frame" event.
The only times I could think of which I might have duplicate events would be if I had groups of activated and deactivated events of different points of the game.
CRUSH!!
Pete Nattress Cheesy Bits img src/uploads/sccheesegif
Registered 23/09/2002
Points 4811
2nd February, 2004 at 15:37:58 -
kris: yeah, but it's sometimes easier to have one always event per group, just for neatness' sake and easy editing. and obviously sometime you need the always events to just function when the group is active.
does MMF process always events simultaneously? or does it process them as it moves down the list?
It processes them as it goes down the list; so it's necessary sometimes for more than one always event, so the objects are changed in the right order. usw.
I don't use just one always event. If I did that then the code would not be organized. Don't get to obsessed with effeciency guys. You will never be able to tell the difference between using one always event and 10.
Also as Shen said, you can do certain things by using more than one always event that would be hard to do otherwise.
Edited by the Author.
99 percent chance that the above post is 100 percent correct.
Mr Coffee is right, one or ten always events is not going to make any noticable difference.
If you go to the events list editor MMF reads the events like there: Top to bottom. Top action first to last action. It's very useful to check there when running fastloops because often the placing of the loop action can affect how it all works.
95% of Terminal Orbit's code is necessary most of it is getting around the fact you cannot create an object from an expression, so an event is needed for every object created.
If it is a very complex game and alot of stuff is going on, then yes it does matter between 10 undeeded always and 1 needed always. I have a way I organize my events, at the very top I have Start of Frame (Cause its the start! ) and then right under that is ALWAYS. Then after that its groups of events for every thing coded, then after that is the EVERY '10' miliseconds type of events.
Only thing that drives me completly insane is the order of the objects in the event editor, if you have alot of objects and say you want to edit 2 simular ones, well one could be wayyyy freakin on the right side, and the other on the very left. Theres no way to organize these exept to drag them yourself, wich is a pain since it takes forever and you cant drag more then one. It helps to zoom all the way out and then move them, but you still can only get them so far.
We are the music makers, we are the dreamers of dreams...