Image Optimisation & RAM Usage

battleduckbattleduck Member Posts: 105
Hi guys,
I just watched TShirtBooths video on Art optimisation



where he explains about the 8x8 rule, and how when producing graphics, we should aim to use image sizes 8x8, 16x16,256x256 etc or variations thereof. TSB then explains that an image 30x66 would utilise 32x128 worth of RAM.

My question therefore is does this just apply to images imported into GS or to individual actors?

I'm working on an iPad puzzle game where for example I have a "Wall" actor with an image 64x256px. This actor would therefore use 64x256 worth of RAM, but if I then use multiple instances of this actor which are resized to construct a level, would GS / iPad use 64x256 worth of RAM for every instance of the "Wall" actor, or would an instance resized to say 64x96 use 64x128 RAM, and an instance resized to 64x64 use 64x64 worth of RAM, rather than the full 64x256 for each?

I hope I'm getting my point across, and would greatly appreciate an answer before I go any further with designing the many levels in mind for my game.

Thanks, for all the helpful videos & forum threads.
Battleduck

Comments

  • battleduckbattleduck Member Posts: 105
    edited December 2011
    Hey,
    Maybe i need to clarify slightly exactly what i'm asking.
    What i'd like to know is, in terms of game performance and RAM utilisation, would I be better off with having a "Wall" actor with a single large 256x64px image, and just resizing the multiple instances of the actor to construct my levels, or have multiple prototypes of say 64x64, 128x64, 256x64 etc, each with their own imported image of the correct size?

    Battleduck.
  • ozboybrianozboybrian PRO Posts: 2,102
    I think resizing is better... But that's just me.
  • mynameisacemynameisace Hull, UKMember Posts: 2,484
    It applies just to the artwork, not in actor's size. From an images point of view, if you imported a 64 x 64 image and had that as a 5000 x 5000 actor, the image would use the same amount of RAM.

    Ace
  • battleduckbattleduck Member Posts: 105
    edited December 2011
    cheers guys,
    so just so I'm 100% straight with this Ace:

    horrible pixelated images aside i can see a potential benefit to your example of a 64x64 image, using 64x64 of ram even on a 5000x5000 actor,
    but then in reverse, does having 512x512 image used by 2 actors one sized 512x512, and the second 64x64 use 512x512 + 64x64 of ram or 512x512 *2 worth of ram? thus using more than it really needs to.

    thanks again
  • battleduckbattleduck Member Posts: 105
    Also, if a scene has multiple instances of an actor in it, does it just load the image into the RAM once, and use it for all the instances using just one lot of RAM, or does it load multiple copies of the image for use on each individual actor, therefore using multiple lots of RAM?
  • mynameisacemynameisace Hull, UKMember Posts: 2,484
    As in the same image? If you import a 64 x 64 image and have 30 actors all as different sizes using that one image, the RAM for the images will just be one 64 x 64 image.

    Ace
  • mynameisacemynameisace Hull, UKMember Posts: 2,484
    A lot of different instances does bog your game down a little, but not because of the images, it is treating each instance of the same actor as a different actor.

    Ace
  • battleduckbattleduck Member Posts: 105
    That's great, thanks a lot for the help.
  • mynameisacemynameisace Hull, UKMember Posts: 2,484
    No problem Buddy, any time.

    Ace
  • ozboybrianozboybrian PRO Posts: 2,102
    edited December 2011
    WOW!!???? the one image same sized image on duplicate actors doesn't effect memory at all??????? THAT'S CRAZY!!!

    This gives me so many ides :D

    Edit - Ace: "A lot of different instances does bog your game down a little, but not because of the images, it is treating each instance of the same actor as a different actor.

    Ace"

    Dang.
  • battleduckbattleduck Member Posts: 105
    edited December 2011
    Oh while I'm thinking about loading times and optimising...
    I have a crate actor which has a lot of rules for various different scenarios in it, but not all the scenarios crop up in all levels,
    would i be better off unlocking the instances in each level and deleting the rules that aren't needed for that level so the scene is not unnecessarily loading the extra rules? or would just turning off the rules do anything to help out?
  • mynameisacemynameisace Hull, UKMember Posts: 2,484
    If they are on different levels, it's fine unlocking them and deleting the rules, but without there being absolutely loads of rules, I wouldn't bother, since if you need to tweak things later, it's easier if they are all prototypes and the rules only fire when they are triggered anyway.

    Ace
  • battleduckbattleduck Member Posts: 105
    nice one cheers
  • ozboybrianozboybrian PRO Posts: 2,102
    What do you guys think about this idea?...

    GS working with Vector art, so images resize in accordance. :D
  • mynameisacemynameisace Hull, UKMember Posts: 2,484
    If we had custom fonts we could kinda do vector images.

    Ace
  • ozboybrianozboybrian PRO Posts: 2,102
    Vector is the ones that can resize to any size and not lose quality right?

    Custom fonts without the crazy code would be nice... Adding that to the wish list!
  • mynameisacemynameisace Hull, UKMember Posts: 2,484
    Yeah, it's images based on math instead of pixels. Fonts work like that, too.

    Ace
  • battleduckbattleduck Member Posts: 105
    I agree that would be awesome, custom fonts woulds certainly cut done on the number of images i'd need in some games, and make for a smaller package size!
  • ozboybrianozboybrian PRO Posts: 2,102
    BD, I think ACE means, the option of inserting custom fonts rather then doing the code and lining them up in a tedious process.

    But I could be wrong.
  • battleduckbattleduck Member Posts: 105
    oh right, the only cusomr fonts I've used so far are for game scores, with a custom image imported for each number and a rule changing the image to match the desired number as per the cookbook/ TSB video on gamescoring.
  • ozboybrianozboybrian PRO Posts: 2,102
    Yeah, it's a pain to do lol... But it's definitely a Must to make your game look polished.
  • battleduckbattleduck Member Posts: 105
    oh, absolutely, after all its the graphics / text that users see. I know if i'm browsing the app store and the screenshots show shoddy graphics / text, i'm turned off before tapping 'Purchase'.
  • mynameisacemynameisace Hull, UKMember Posts: 2,484
    I mean that we could make custom vector pictures and save them as a font file and import it in to GS... Hey presto, we have a vector image in GS. Not sure when/if custom fonts are coming though.

    Ace
  • ozboybrianozboybrian PRO Posts: 2,102
    Stop being smart Ace.
    I want to be one of the GS Gods.

    Fantastic idea mate, me calls that a Pluggin!
  • MotherHooseMotherHoose Member Posts: 2,456
    edited December 2011
    I use a transparent.png (4x4) as a place holder in all my images actors

    basically working from generic actors …
    In designPhase, drag image into the actorInstance; set the actorAttributes correctly
    In actorBehavior Editor: 1st element: changeAttribute: [exp]self.image To: imageName/#

    when everything works great in that scene: drag the transparent.png to replace the pix in the actorInstance …
    this does not affect other attributes such as W,H; X,Y; color, etc.

    IMO by doing this, at the start of scene, the device loads 69 bytes of image/actor sequentially.
    the individual actors load their real images simultaneously.

    even more efficient programming: create an attribute in the prototypeActor … either myName (text) or my# (index)
    then 1st element in behaviorEditor: changeAttribute: [exp]self.image To: [exp]self.myName or self.my#
    this will be correctly processed in each instance.

    vector images would use less RAM and be fantastic for scaling … can hardly wait!
    alas, think GS will start with bitmap fonts for custom fonts … when/if ever we get them.

    MH
Sign In or Register to comment.