Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat | DONATE
Request: Export sprite as an image file — Gideros Forum

Request: Export sprite as an image file

ndossndoss Guru
edited February 2012 in Suggestions & requests

I'd like to be able to export a sprite (and all it's children) to an image file (e.g., png, jpg, gif,...?). Is that possible?

+1 -1 (+3 / -0 )Share on Facebook

Comments

  • You might be able on IOS to hook into the OpenGL view via a plugin and collect the image data from there. The problem here could be that the plugin is called between clearing the view and a new render of it. The Gideros team knows that for sure.
  • atilimatilim Maintainer
    @MikeHart's solution can be totally possible. But you'll see your sprite on screen once.

    I wonder if "render to texture" solves your problem? I mean you'll create an empty texture, draw on it as you wish and use it (without saving).
  • I wonder if "render to texture" solves your problem? I mean you'll create an empty texture, draw on it as you wish and use it (without saving).
    i like this one :)

    Likes: atilim

    +1 -1 (+1 / -0 )Share on Facebook
  • Having "render to texture" would actually be very useful not only for saving images but also for loads of special effects (feedback loops, procedural textures etc)
    +1 from me for the feature!
    :)

    Likes: atilim

    WhiteTree Games - Home, home on the web, where the bits and bytes they do play!
    #MakeABetterGame! "Never give up, Never NEVER give up!" - Winston Churchill
    +1 -1 (+1 / -0 )Share on Facebook
  • Amazon's free app of the day was a whiteboard app. It has the ability to save drawings ... made me realize I want to be able to do that too.

    I wonder if "render to texture" solves your problem? I mean you'll create an empty texture, draw on it as you wish and use it (without saving).
    Not quite sure what you mean by this (especially the "without saving" part).
  • gorkemgorkem Maintainer
    We could implement this feature if a few more people need it in their current project.
  • Whilst I don't need it in my current project, this thread did make me realise that it would have put Gideros out of the picture for the app I already have in the app store - Create & Play - as it relies upon rendering textures as a core feature. cocos2d had a nice way of doing this. Basically you setup a rendering target and added sprites etc. as needed to this. Think of the rendering target as nothing more than a different version of the stage in Gideros. By doing it this way, anything you can output to the stage, you can also output to the rendering target.

    Of course, the other problem I'd have come across in that app, is the lack of image masking in Gideros as well ;)
  • atilimatilim Maintainer
    @ndoss I understand now. I've added this to the feature list.

    @moopf Yes, render to texture (or render targets) and clipping is the most two important features that'll be added to the graphics engine.
  • Hi @atilim, I'm actually more thinking about using masks. For instance in my Create & Play app I used a rounded rectangle image to mask the images when I was rendering the texture so the faces have rounded corners. Ignoring rendering to texture, this part wouldn't be possible either at the moment would it? Or have I missed something?
  • atilimatilim Maintainer
    Hi @moopf,

    I see. Can you explain a bit about the cocos2d way of doing this?
  • Hi @atilim, it's not really about the way cocos2d does it in particular. They treat a RenderTexture element in the same way as any rendering target (such as the screen), so as long as you had the ability to add a mask to a sprite (if I remember rightly Corona, for example, allows this) then presuming that you're using the same render flow regardless of the actual target it should work. One thing is that adding a mask to a sprite should also mask any child elements as well, in much the same way that clipping should ideally work. This I don't think works in Corona, which kind of limits the usefulness when compositing images - I could be wrong here though.

    Of course, thinking about it there's a couple of other things that would be needed if I'd wanted to do Create & Play in Gideros:

    1. Saving rendered textures to file storage (as already mentioned by @ndoss)
    2. Resizing rendered textures (maybe that could be achieved by scaling on the target?)

    So there's really a few things needed in Gideros to make the function set complete when rendering textures to give enough flexibility to do lots of different things. I simply wouldn't have been able to do the app without these features, due to the sheer amount of texture memory I'd need to consume when using the faces in the games - that's why I went the route of compositing and rendering completed faces.

    Hope that helps but if not, just tell me to shut up :D
  • atilimatilim Maintainer
    edited February 2012
    :) Thanks @moopf,

    This information helped me a lot. I just wonder one more thing: Why did you decide to use render targets instead of creating the faces by adding eyes, hair etc as a child. I mean a hierarchy of sprites should work as well. (most probably I'm missing a point but what? :) )
  • Hi @atilim. Right, here goes on how I structured it. This will probably be difficult to understand, never had to explain it before :)

    In the face creator there are 9 different sections, e,g. skin, hair, eyes etc. Within these there are an average of around 25 different options, e.g. different eyes etc. For each different option there can be up to 3 layers, to allow different parts of each options to be coloured differently. So, the frames on a pair of glasses could be coloured differently to the lenses for example.

    What I did was create 4 different sized versions of each layer texture - 256x256, 128x128, 100x100 and 50x50. The app supports retina and non-retina, hence the need for the number of sizes. The 256 and 128 versions are used to show the big face in the face creator so you can see what you're making. The 100 and 50 versions were treated a little differently as they're used in the face creator to pick the option you want. All the layers for all the options for a given section, e.g. eyes, are packed into a single texture. When you touch the 'Eyes' button this loads the texture and displays the scrollable area with the available options for you to select, coloured on the fly.

    On the main "big" face in the face creator I'm using children to composite the face from the individual 256 or 128 versions of the layers, colouring them as I go.

    It's all made a little more complex by having variable ordering built into the engine so, for instance, if you had a hair option that had a long fringe, you'd want that to come over the top of eyes or glasses, rather than behind unlike a shorter hair cut that you'd want to go behind. Beards and moustaches were the most awkward in this regard :D

    What I'm then doing, when you save the face, is rendering that to a texture and saving several resized versions of this finished face, 100 x 100, 50 x 50, 80 x 80 and 40 x 40 - these are the different face sizes required for the games for both retina and non-retina.

    The reason I did it this way is that these sizes are obviously not ideal for texture memory usage and there are 25 faces in total. I can live with wasting some texture memory on that, it's not a problem. If I'd instead created them on the fly from all the layers, each face could have up to 27 layers and you'd quickly see that I'd have some potential issues with texture memory. I'd also need to have saved the 100 x 100 and 50 x 50 versions of all the layers individually as well, rather than having to load all the packed textures in.

    Finally I wanted to ensure that I included every iOS device, so wanted to make sure that playing the games was as smooth as possible. Compositing on the fly would definitely have made that more awkward for earlier devices but, as it ended up, the app runs very smoothly even on my old, battered, first gen iPhone.

    So, hope that helps to explain why I did it this way. It just seemed the most logical, memory efficient way of doing it at the time. It worked well (at least I think so!) I could have gone down the route of dynamically creating a packed texture instead, either of the finished pieces in one texture or the layers required for the faces, but didn't think it was necessary as there was no requirement to alter the created faces in the games

    And the app took 4 months to develop which was much longer than I'd originally planned for anyway :D It was supposed to be a quick intro to the characters but I ended up just running with it so it became something much more.
  • atilimatilim Maintainer
    Thank you for this great explanation :) I think 4 months is very normal (even short) for such a good development.
  • @Atilim, having the facility to save will be a very big gain. It can be used for many things, like some suggested to take a snapshot of what one has created in a make a face type of app or a whiteboard, to take a snapshot and then email it to someone and so on.

    Any time frames on that?
    twitter: @ozapps | http://www.oz-apps.com | http://howto.oz-apps.com | http://reviewme.oz-apps.com
    Author of Learn Lua for iOS Game Development from Apress ( http://www.apress.com/9781430246626 )
    Cool Vizify Profile at https://www.vizify.com/oz-apps
  • hnimhnim Member
    it's better if we can choose layer to capture, sometimes, we dont want to capture share/menu buttons on snapshot. Maybe, you can add HUD object which any sprite on this will never been captured.
  • FWIW, I also need this feature (to be able to save a created image as a file) in the game I'm planning. So +1 from me.
  • Render to target is exactly what I need to create a fog of war effect. I suppose this is still in the works?
  • atilimatilim Maintainer
    @ondesic absolutely but not for the next version
  • So what is the status on saving a render to texture object to an image file? When can we expect to see this? I know it has been talked about for a long time, years... I remember a post describing that it would not be possible without opengl 2.0. Any insight on this would be great, I have 2 games that desperately need this feature.
  • I'm currently developing Media class, handling lots of media managing functions, and one of possible features could be saving RT, but I haven't check yet how it could be integrated with Gideros to retrieve the RT texture, for now it is just an idea and I'm working on making Media plugin more usable and stable.
    But I will check soon and try to provide an estimate if that is possible ;)
Sign In or Register to comment.