Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 7.8K All Categories
- 11 Help with translations
- 4.2K General questions
- 107 Roadmap
- 358 Game & application design
- 317 Plugins
- 70 User experience
- 75 Marketplace
- 291 Code snippets
- 34 Building a team?
- 269 Suggestions & requests
- 352 Announce your apps made with Gideros.
- 90 Step by step tutorials
- 668 Bugs and issues
- 195 Introduce yourself
- 239 Announcements
- 106 Forum talk
- 404 Relax cafe
In this Discussion
render to texture related feature request: create virtual sprite hierarchy to render
keszegh
Member
so atilim said that export to file will be added later. that's cool.
i have another thing, that might be easy to do and seems that it would be quite useful.
what i want to achieve is to put together sets to render to texture more freely than what the sprite child/parent structure allows. basically i want to be able to build a virtual child/parent structure just to render it to texture.
why i need this?
i want to render out lot's of meshes, half of them added to a sprite A visible on screen, other half not visible on screen (let's say it is added to a sprite
. one can forget about the small parts, let's say i have a sprite A added to stage and a sprite B not added to stage. what is the way to render all these to one texture?
if i add A and B to a sprite not on stage than A disappears from screen, if i add A and B to a sprite on screen than B appears on screen, none of these i want.
one solution would be the ability to be able to add a sprite to several parents at the same time. i understand that in general this could lead to complications etc there are probably many reasons why this can't or won't be implemented. on the other hand just to render to texture there could be a possibility to build a virtual sprite hierarchy.
actually while writing this i realized that using tables and multiple draw()-s, one for each element can emulate this, e.g. put the sprites in a table hierarchy (instead of a child/parent hierarchy) and sweep through them, drawing them one-by-one to the rendertarget.
so @atilim, a question about the performance of the latter idea:
is drawing 1000 sprites to a rendertarget in a for loop the same speed as adding the sprites to a common parent and drawing this one parent to the rendertarget?
if yes, still an addon class to make this in a clean way would be useful (emulating the sprite hierarchy to make 'virtual' sprite hierarchies for using in rendertarget draws).
i have another thing, that might be easy to do and seems that it would be quite useful.
what i want to achieve is to put together sets to render to texture more freely than what the sprite child/parent structure allows. basically i want to be able to build a virtual child/parent structure just to render it to texture.
why i need this?
i want to render out lot's of meshes, half of them added to a sprite A visible on screen, other half not visible on screen (let's say it is added to a sprite
. one can forget about the small parts, let's say i have a sprite A added to stage and a sprite B not added to stage. what is the way to render all these to one texture?if i add A and B to a sprite not on stage than A disappears from screen, if i add A and B to a sprite on screen than B appears on screen, none of these i want.
one solution would be the ability to be able to add a sprite to several parents at the same time. i understand that in general this could lead to complications etc there are probably many reasons why this can't or won't be implemented. on the other hand just to render to texture there could be a possibility to build a virtual sprite hierarchy.
actually while writing this i realized that using tables and multiple draw()-s, one for each element can emulate this, e.g. put the sprites in a table hierarchy (instead of a child/parent hierarchy) and sweep through them, drawing them one-by-one to the rendertarget.
so @atilim, a question about the performance of the latter idea:
is drawing 1000 sprites to a rendertarget in a for loop the same speed as adding the sprites to a common parent and drawing this one parent to the rendertarget?
if yes, still an addon class to make this in a clean way would be useful (emulating the sprite hierarchy to make 'virtual' sprite hierarchies for using in rendertarget draws).
Comments
But yes, as you know yourself already adding sprites to multiple hierarchies (even virtual ones) is not quite possible due to design/architecture of Gideros.
and do you know the answer for this perhaps?
"is drawing 10000 sprites to a rendertarget in a for loop the same speed as adding the sprites to a common parent and drawing this one parent to the rendertarget?"
(worst case i can test it)
Likes: dr_max
Fragmenter - animated loop machine and IKONOMIKON - the memory game
https://deluxepixel.com
i still propose the idea to make a class to handle such a virtual hierarchy. i don't have enough time or need for that now.
on the other hand i will test the speed loss of many consecutive draws.
Fragmenter - animated loop machine and IKONOMIKON - the memory game