I've been around since KNP days and theres no difference between the MMF2 loop architecture and MMF1.5, and HWA would only speed up built-in graphical systems, not overlays, and the overlays aren't the problem anyway. The problem is specifically something inside this loop, and it would run the exact same speed in either MMF1.5 or MMF2
anyways the main problem is that you have too many loops. Shorten them and it'll be done.
[/thread]
any programmers care to comment? -_-
Sorry about some comments above...
I know that some MMF actions do have a bit of overhead on them, but I don't see any in your events there that really stick out apart from the ones that look up the values in the array - however, I'm not really sure how you could avoid those. It may be worth testing with different array-style objects (depending on the content), though I can imagine that it's a bit of a job switching them over each time.
well yeah the array was the first thing that stuck out to me, too. But simply deleting it, and running he raycast as if there were no collisions at all, yields incredible slowdown. So its definitely not that. It seems to simply be the overhead associated with a loop, rather than the events/actions. That whole loop is called maybe 8 or so time per angle, and a loop runs through 200+ angles each frame. I guess my next course of testing would be to try running side by side loops & unwinding the outer loops, but so far it seems doubtful that would work.
as far as I can tell, the actual complexity of the actions is insignificant, the slowdown being rather entirely dependent on the # of total loops run per frame, wherever they are called. Like in that example I posted, running an empty loop 10000 times will kill your system with its lag, yet running a ridiculously complicated loop 100 times is just fine. its beyond me why fast loops, especially the built in ones, would have such high overhead compared to regular events.
its kind of interesting. I made a counter that kept track of the total number of times a loop ran per frame, combining ALL the loops in the entire game. It seems to be that the FPS is inversely proportional to the # of loops run per frame, regardless of how complex the loops are, what graphics are doing, etc. Its just FPS = k/#loops, pretty much. And right now, its appearing that even with a TON of loop unrolling, like 4x in every single loop, I'm pulling in around ~800-1000 loops per frame, when the FPS starts to suffer. Apparently, exceed this ~700 loops threshold just plain tanks the game.
As a further test, I created a BLANK MMF project, with simple commands: On an always event, it runs "Loop A" 1000 times. Loop A does nothing but set Global Value B to (random(10)). When this loop is not running, the game gets 50 FPS. When the loop is running, it gets ~44 FPS, with spikes down to 40.
Now my program runs ~700 loops, with a decrease down to maybe 38 FPS. The worse effect can be explained as the loss due to the graphical paste to overlay element, which is far from enough to lag the game on its own, but probably exacerbates the already bad lag.
So from what I can tell, MMF simply can't run a large amount of loops per frame. It slows down. Can someone PLEASE explain why it can parse through the ~3000 lines of code that my game gridquest had in TGF, each frame, yet cannot run a simple machine code "JMP" command 1000 times in MMF?
Simple answer its not the same as creating the same project in C or assembly. Its using interpreted commands that MMF understands this is slower because your computer doesn't readily understand these commands. If MMF could create a "pure" executable then things would be zipping around faster and the size of the exe would probably be smaller too.
At the moment there are some things MMF just isn't practical for your raycaster won't deliver the speed you want. You will have to wait for MMF3/3D or a faster processor
You may find another way to overcome this bottleneck by creating an object.
yeah thats just about it summed up. I guess I'll try experimenting with replacing some loops with extenions, like the fast loop object & fast function instead of using MMF built in loops. Perhaps having the work spread out across a variety will speed things up. Perhaps not. Worst case scenario, I just keep the resolution down. But you're right that it might be worth making a raycasting extension of my own just for use in this.
Have you tried it in MMF2? It's worth checking, Clickteam have done a lot of work on it since MMF1.5, even if it doesn't seem like it to you.Originally Posted by Pixelthief
i could try, but I'd need to KCAmath.mfx extension for MMF2, or a LOT of work rewriting code.
Posting Permissions
Reply With Quote