Gideros Forums

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.

atilim said:

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 :)

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.

atilim said:

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).

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 ;)

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?

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

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.

@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?

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.

@ondesic absolutely but not for the next version