Quote:
Originally Posted by Emithith
Interesting. I've always liked learning the quirks of engines. Re-coding would be well worth the time and effort, but it's not even really important. I mean, if you are gonna even think about starting on it you're pretty much gonna have to drop all your current projects for it, because anything you start now will be probably way easier once you get it all finished and polished up.
The one thing that stands in the way is brainstorming the proper approach to this new "engine". I.e. What is wrong with the current way the game reads and sends arrows, and what can you do to destroy that problem.
|
Surprisingly enough, the projects have been in development for a long time. R^2 was started back in September, and the complete site recode even before that.
So dropping all projects really isn't necessary, we're just pacing ourselves so things are done right the first time. It's the amount of work to get everything redone is the worse part.
How the game loads notes into play along with spawning hasn't changed much at all. KBO uses an SM file encoded into an xml file. The engine itself converters ti to both frames, and MS timings. The engine spawns the notes according to the frame number and judges compared to the ms timing. Thirdstyle and even the old R2 from awhile ago did the same thing in essence.
It's really about optimizing all the code that runs during the level, more code/graphic update = more lag.
A small thing I forgot to mention about how the old graphic engine rendered things. Instead of picking the top layer and rendering that, flash renders every layer even ones that can't be seen. Movieclips have a option call "Bitmap Cache" that caches the image into memory instead of rendering the movieclip each time even when it hasn't changed. In order for the bitmap cache to be updated, it has to pass a tolerance level of how many pixels have changed from my understanding. If it passes this point, it updates.
Things that are constantly moving are slower is bitmap cache are used since it has to render it, then cache it. while things that are layered but don't move gain from it. Which means in terms of FFR which has few layers and many moving things, using the bitmap cache is slower then not using it.