Some memory questions

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.
  • Is there a benefit to using alt values instead of counters?

    What about Load on Call? The MMF2 help file mentions it for use with big image files, but will it help with ios apps at all?

    What is harder to handle, large objects, or several small objects?

    Xcode is telling me my game is running at around 11mb, which is well under the limits I've seen written about here as well on dev sites, yet it just can't seem to handle what I've put into it. The worst slowdown is occuring with multishot weapons where after a few shots the screen can have 20 or so bullets on it.

    The stage starts off with around 86 objects. I've been hacking away as much as I can but I feel that at this rate I'm going to end up not being able to run anything other than a crappy space invaders clone instead of the project I started with.

    I've read through the 'memory considerations' and other ios walkthroughs about 100 times now, so if anyone has come across anything that's substantially helped their game run that isn't in those, please let me know!

    Here is a screenshot so you know sort of what I'm working on. It's an nes style shooter.

    Please login to see this picture.

  • is it slow when you test on the virtual device? or on the iPhone? what model phone are you testing on? the iOS runtime just plain doesn't work on the early model iPhones.. it doesn't seem like there should be any speed problems with what you've described/shown.

    I think alt values are preferable to using counters, and smaller objects are generally better than larger ones. Keeping them in standard chunk sizes like 16x16 32x32 64x64 etc is more efficient I believe.

    Game looks awesome btw ^^

    Check out my Game on Itch.io
    Please login to see this link.

  • It's only slow on the actual device. The simulator runs fine. I'm using an 8gb ipod touch running os5. Brand new white one, latest build.

    I'm going to switch as much over to alterable values as I can, since counters read as active objects.

    I killed the left/right enemy sensors using a sensor free tutorial I found. That eliminated 24 active objects, but the boost was minor.

    Another question, unrelated to memory, but could end up being major for me. After outputting the xcode file, would it be possible for someone with programming knowledge to go in and modify the code to optimize it in ways that I can't do through mmf2? If I can't sort these issues on my own, it may be my last resort to hire someone if that's possible. I definitely don't have the budget to pay a programmer to build the game from the ground up. . .

  • without seeing the code I can't really tell what the problem might be.. it certainly doesn't sound like you should be having speed issues, have you tested just a really basic game on this device? just a few actives and events.. to see if it still runs slowly?

    one thing to watch out for is fastloops, you have to be very careful with them in iOS.
    edit: also if you must use counters, making them hidden (not number display) may help a little, not sure on that though.

    as for getting a programmer to modify the code... I'd say that's not very likely... it'd take him a very long time to decipher all the runtime code.. he'd probably never be able to make sense of it.

    Check out my Game on Itch.io
    Please login to see this link.

  • I have had results getting things to run pretty well. During first testing of this game it ran smoother, but it was very basic. Only a single bullet weapon, 1 character, very limited amount of background graphics. The thing is, the allocations haven't changed much at all. It's hovered around the 9-11mb mark since the beginning. I'm not pushing the hardware to its limit or anything, they've got Grand Theft Auto 3 running on the same device. I understand that there's different technical aspects going on behind the scenes, but I'm starting to feel like I'm running out of ways to optimize it using the tools I have in mmf.

    I only have a couple fastloops, and they use very few loops, I believe I tried taking them out at one point and it didn't make a big impact, but I'm planning to try it again, and see if I can figure out how to get it running without them if it does help.

    All my counters are set to hidden except the health and weapon ones you see, but those are graphical and not numeric (which seemed to be the problem mentioned in the docs)

    I do imagine it'd be hard for a programmer to make heads or tails of it in a reasonable time frame/cost, but I figured since the runtime is geared towards running games in general, maybe a tailor made fix would be rather simple. I'm not a programmer of course so I have no idea. . .

  • We have impleented a colision detection acceleration recently. It might make your gam faster. It will be published in the iOS user Lounge soon.

    Francois
    PM: Please login to see this link.

  • Looks like a great game! If you sort out your memory problems I can't wait to play it!

    Have you tried setting all of the active objects to be inactive if too far from window? I'm not sure how much that affects the iOS module but in past PC games I've made it's been the difference between 15ps and 50fps. Also are you destroying bullets as soon as they leave the screen?

    You could also potentially split your levels over multiple frames and use transitions, like they did with the iOS version of MegaMan X.

    Maybe add events to test that your enemies etc. are within the frame area before they do anything. Try condensing all 'Always' events into one, I often find that increases the efficiency.

    What fast loops do you use? I try to avoid them altogether on iOS games if I can help it. The one time I tried to port a static platform engine of mine the fast loops pretty much killed the game. Of course that can be difficult with collisions, particularly on platform games where without fast loops the character will land 'in' the floor and it looks clumsy to have to 'push' him out, but I find the Advanced Platform Movement Object to be pretty damn good at doing what I want.

  • Our game runs very badly and crashes on the brand new ipod touch we bought in december, however works flawlessly on the ipad 2 and iphone 4/4s, not sure about ipad1 performance.

    I would be very interested to know what the market share is between these devices. I would suspect the majority of people buying apps *are* using the iphone 4s and ipad 2.

    Personally we are just focussing on targetting the high end apple devices and including a disclaimer that the game will not work on ipod touch.

    Not that we consider ourselves to be in the same league as cave or square enix, i believe they make similar disclaimers.

    ANOTHER thing to consider, is that you can initially release your game JUST for the ipad & ipad 2. If it is well recieved, then spend the time cutting back to release a ipod touch friendly iphone build.

    Game looks awesome, good luck.

  • DistantJ:
    I have several objects set to inactivate, but now that I've eliminated enemy sensors, I will check that those enemies inactivate.
    Bullets are destroyed as soon as they hit the edge. My levels are 'relatively' short already, but that's something I'm considering. I'd like to avoid it if I can though.
    Certain enemies are created based on the players position. i.e, you reach 1000x so enemies between 1500 and 2000 are created.
    I have now eliminated all fastloops. I use a sensor below him to help avoid him sinking into the floor to begin with. That's the way I did it before I discovered fastloops, and while it's not optimal, it works well enough.

    CfullerNY:
    Limiting to ipad/ipad2 is a possibility, but a last resort. Plus, I'd have to go out and spend $500. I've already sunk quite a bit of time and money into development so I'd hate to spend MORE money while at the same time limiting my potential profits.

    Bigfoot, Assuming you're talking to CfullerNY, but mine's 4th gen and I'm building in release mode.

    Thanks for the tips everyone.

  • The demo game Zeb (from back in the Games Factory days, I believe they still supply it with MMF2) had a nice method of avoiding the player falling through the ground without fastloops which you could potentially borrow. The character actually had seven 1-pixel high markers stacked one above the other underneath him, since 7 was the maximum number of pixels he could move vertically (i.e. when his fall was at terminal velocity). It'd test which ones were overlapping the backdrop and which weren't and position him accordingly. I can't see how just the one fastloop to prevent him landing 'in' the ground could harm that much though. There's gotta be something happening which slows it down. Have you got the image compression setting as 'colour reduction'? How many colours is your app using, you could turn it down to the lowest number of colours you're happy with. An old school game like yours might even work with 256 colours, though that might be pushing it. Next one up is probably your best bet. All sprites are using 'transparent colour' rather than an alpha channel, right?

    You using a lot of quick backdrops? I've noticed sometimes it's better to tile backdrops manually than to use quick backdrops. To save the amount of redrawing the device has to do, you could always grab those trees in the background and put them in a static layer underneath, as in having them not scrolling with the level. It might be getting bogged down by the sheer number of pixels it has to draw.

    One quick test - try turning off the scrolling and actually making it re-enter the camera one screen further forward when the player goes off the right hand of the screen. I know it won't suit your game to actually use that method but it'd be a good way to test if it's the scrolling which is the issue, and if it is you want to try and cut down the number of pixels being redrawn each frame.

    One last thing, try temporarily replacing your character's platform engine with the built in one, just to see if his movement is affecting the memory. If you find this speeds up the game a lot you could drop an Advanced Platform Movement object in there to take the place of your static engine.

  • Ok, first things first. Andos suggested the problem was collisions, and that I should eliminate fine detection from everything. And it helped immensely!! One question in regards to that, when the update comes with improved collisions, will that speed up box detection as well (as in would I see an even BIGGER improvement?) or is it just to fix the problems with fine detection?

    The method you mention in zeb is similar to what I've been playing around with. The bottom sensor is set to y of the player + the players current gravity (so player is moving down at a rate of 6 pixels, and sensor is at player y + 6.) I had used something like that in the past. This engine isn't really tweaked for that so I ran into some problems, I'm deciding if I should redo things to work that way or just settle for what I've got, which really isn't bad.

    Now that I've got some of the major slowdown fixed, I might try putting the fastloop back in anyway.

    Color reduction is set. I tested 256 colors in the past but it didn't make much difference. No alpha channels.

    I haven't had the best luck with layers. Although at one point I had the border on a static layer above and it didn't cause much slowdown that I noticed. I may try going back to that now. I only have a few quick backdrops (the trees, the repeating tiles at the very bottom, and a portion with some brown bricks.) I've been planning to do away with the bottom ones.

    Limiting scrolling does help a bit. Even when I was having the worst problems, I noticed if I stood still and just jumped in place, the slowdown went away mostly. (There's no Y scrolling).

    Overall though, my slowdown has been virtually eliminated now, EXCEPT when I'm rapidly firing off the multi-shot weapons. This fills the screen with roughly 20-30 extra shots. I'm planning to make the flamethrower shoot 5 bullets instead of 7, and just have the bullets be larger. I'm also going to decrease how rapidly you can shoot those weapons. I'll also probably adjust the speed at which the bullets move so they get off the screen faster.

  • That's great news about the fine detection thing. To be honest if you're making a classic style game you're probably better to have it disabled anyway.

    Ah yes, that marker technique. I had forgotten about that one! I remember seeing it in an engine once. Good thinking! Certainly better than I could come up with in the time it took me to type the message. :D

    If you put the border on a static layer above you can then lock and hide that layer so it doesn't get in the way while you edit your level. That's what I always do :)

    Good idea about 'economising' with the fire bullets. Sometimes the stuff you have to do to combat limitations can even make your game better. I've discovered that a lot in the past (been using Clickteam products since 1997!). Limitation inspires creativity, that's what I've always believed. :) In fact, Super Mario's entire character design comes from what would be visible on a low-res screen with a handful of colours.

    I noticed you only have left and right buttons, so I'm guessing you can't fire up, down or horizontally. With this in mind, since they're bullets and thus probably moving quite fast, have you considered making them not follow the frame? If they don't scroll with the level, you might find it's not noticeable if they fire fast enough, and that might keep them from slowing it down since it's not having to redraw them in different places every frame... Might not be that plausible though if it requires a lot of accuracy and the bullets don't move all that fast.

    Really looking forward to this game.

  • glad to hear you figured it out, these findings will likely help me too (i was testing on whatever the absolute latest ipod touch is, release not debug)

    is fine detection enabled by default?

    i am away from my machine where MMF is installed so i cant check.

  • Something you might want to consider if your game is old school is to drop the global FPS. You'd have to speed up your platform engine slightly but if the drop in FPS doesn't harm the presentation (I imagine it might look more authentic retro if it runs at a lower framerate) I imagine it'd save a hell of a lot of memory if it's rendering less frames at a time...

    Fine detection is enabled by default yes.

    Oh also, since your game is a retro styled one I'm guessing there are a lot of instances where sprites 'flash'? Either with MMF's 'flash during' feature or by toggling visibility? If so, I noticed that in my game the framerate was dropping when large or multiple sprites were flashing on screen. I removed the flashing and the framerate stopped dipping in the moments it previously did.

    Edited 2 times, last by DistantJ (January 6, 2012 at 11:14 PM).

  • Ok, I'm finally ready to continue work on my game! For the record, here is what I've had to do:

    Eliminate fastloops. I tried putting one back today, but it did cause slowdown. Not major, but noticeable. Avoid fastloops!

    Eliminate Fine Detection! I also changed all backdrops to collision with box. Doing both these things has probably made the biggest difference.

    Eliminated several counters and and spun them into one object's alterable values.

    I cut back on the bullets my flamethrower shot and reduced how often you can shoot. Did similar for the spread gun.

    Made sure there weren't any misc/unused animations in my objects.

    Eliminated sensors from left/right enemies.

    inactive objects if too far from window.

    Changed my border to a new layer. I think using Always - Bring to front was causing some slowdown.

    Today I did a test where I doubled the amount of enemies from 30 to 60. It still ran pretty good (110 total objects at level start) but did slow down when I had a lot of enemies on screen and was shooting. But that's probably a lot more than I'll actually need, so I feel that I won't have to be too careful going forward. I can just focus on building my game!

    Anyone want to play test?

  • I have had a little trouble with 'collision with box' backgrounds, sometimes my character gets 'stuck' in them when he doesn't when they're using the normal collision. I can probably come up with a workaround but it's a strange glitch which doesn't happen on PC. May be an error in the Platform Movement Object which I have used for this game.

    Just a little note, you've probably already thought of this but, since your border is on a new layer, it no longer has to be an active object. You can make it a backdrop object, which uses less memory. Since it's on the top layer it'll be in front of everything anyway.

    I found that after eliminating flashing, rotation and a couple of other features from my platform game, I can make the levels pretty much as big as I want without any real performance hit on iPhone 4 (it runs slow on 3GS no matter what I do, I think it's a lost cause, that one...), which is nice!

    I'd love to test it if you want to PM me the XCode project. I'm stoked for this game! I can test on iPhone 4 and iPad 1.

  • Obviously collision with box isn't great for every backdrop. Due to the 8-bit style and tiled nature, all my graphics fill up the entire dimension that they're in. Obviously ramps and stuff wouldn't work like that. I haven't had any problems though so I'm guessing it has something to do with the pmo.

    I could change it to a backdrop, but I don't know how much space it would save. Right now it is also used as a detector for enemies and objects being on screen or not.

    I will get you the game sometime tonight. Do you have an e-mail I could send it to? It would be great if you could test on ipad since I don't have one. I'm interested to know, not just how it runs technically, but how well the controls work. On iphone/ipod you just hold it like a typical portable console. But that might be too cumbersome with ipad.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!