I use a method that I guess is sort of a hybrid of all three approaches Naitor mentioned - though I suppose mainly the last two. Of course this is not everything, but it's something to think about.
#Clickteam fusion 2.5 ram limit software#
You can use Active Picture object but it can be slower, it works best with software mode for this.Īlternatively you can use TileMap Viewport, that would be a lot more efficient than creating backdrops, with no object limits, but it seems like the DX11 ported version is a bit slower than the DX9 original version. Usually tiles are placed inside a active object, which you can use to create backdrops during runtime from specific frames, so no true backdrops there. Programming it can take a while, has to be well designed and can be difficult if you don't understand the concept.
You can also do dynamic level loading, so it would load either chunks or all tiles/objects that get into the visible area. A lot more flexibility, you can for example design the editor/loader it in a way that you can have instances of the same object with different alt values/strings.
You load only the level you need and reset it before loading another level, so it's it will only load what it will use.
Reordering frames will break "Jump to Frame" actions. Nothing is shared unless you program it, except Global Values/Strings and Global Objects. Loading between frames can be slow sometimes. You can't create from Global Event editor a object that doesn't exist on the frame editor of the specific Frame you are, meaning you'll need to copy objects between frames whenever you add something new. Unless you use Global Event editor or Behaviors, you'll need to copy events between frames, meaning you have to fix and change all frames and might forgot stuff on some. (The trick above can also affect the unintended objects if you don't name your objects making then unique) Global Event Editor let you do some interesting things, for example, events will affect objects with the same name and type, even if it's not global, meaning you can have same objects with different graphics. Easy to organize, edit and replace entirely. I believe there's a limit of 65.000 unique images per Frame as well. Frames are limited to 30.000 objects, seems like a lot but you can easily get to this limit with big tile-based levels if you don't use quick backdrops. Events that will not be used at the moment might affect your performance unless you toggle its state. Significantly higher memory usage and "loading" times (freezed screens). Everything is shared, objects, events, you don't need to store anything since you'll not be switching frames, it will remember it all. Has anyone tried out these approaches and if so which of the 2 were better or worse for you? That's got me thinking since we can do this now, is there even any real advantages anyone has to using frame editors/large frames per stage with this vs just making individual frames that add up to a complete stage? I'm thinking it would be tedious and does get messy quick having tons of frames for stages, but on the other hand i can see having a lot more control on a frame per frame basis, like layers, parallaxing, effects, etc. My main reasoning for doing this was because i was using the 2.5+DLC features like having qualifiers work in the global event editor, letting me make my changes and bug fixes on the fly and having them translate across all frames vs having to go into each frame and find them/fix them. This worked out well but it was a MAJOR pain in the a**. This time around, i was going to try out making each stage in 1 big frame and control the sections with x/y coordinates of the player to transition them. I started back up with it about a month or so ago, got busy (as usual) and put it on back burner. So i'm going to commit and take another REAL attempt at getting my game finished lol.
0 kommentar(er)
