it really depends on if I can find a way to optimize the raycasting algorithm. I used caching so that sprite loading/drawing has no impact on FPS, but the simple math behind raycasting, seems to be too much. I think if I find some changes to optimize it I could potentially have graphics just as crisp as that, running at 50 FPS. That games has a resolution of 1 pixel/ray, which requires 512 rays to be cast, each one checking maybe 20-40 collisions in a worst case (empty field of view) scenario. One reason that game might run particularly fine is because it appears the collision grid for walls is HUGE; it looks like your vision range is never more than 6 or 7 squares total. I'm intending to write my code for doom or at least wolfenstein level graphics. Push the boundaries of MMF
The real difficulty of Klik is that nobody really knows what the limiting factors in any engine will be. If it were in C++, I could google my issues and find 100 articles about optimization. But in MMF, you have to experiment and do trial/error studies to discover why something is running slowly. For example, with my text based one, I initially found that as soon as I made it strings instead of textures, the game collapsed. This as it turned out, is because strings are immutable in MMF, and thus when you append them, you are making and requiring memory for a 3rd string, instead of altering the existing one. So appending 1560 characters at runtime took out memory for Σ1560 strings. Youch. Next I found that the overlay objects "Load image from file" turned out to be a limiting factor; running this inside of a loop will significantly lower the frame rate. Answer? Create extra overlay objects to serve as buffers, as pasting from an overlay to overlay takes no time at all compared to loading from a file.
Now my issue is with raycasting itself. Drawing the sprites & walls on screen is taking no processing time, instead the actual raycasting algorithm, which follows this: http://www.permadi.com/tutorial/raycast/rayc1.html very closely, is an issue. Projecting 600 rays per frame, each of which checks 40 array-collisions, seems to be too much for MMF. Now its back to the blocks of experimenting, and finding out what piece of code is the limiting factor. Is it the "Find distance to object" on the advanced math object? Is it the "Check array @ XY"? is it the very act of running 600 * 50 loops? Who the heck knows.
moral is, I'll probably post the darned thing open source later today.
Advertisement
Post Reply
I love that game!
