|
|
Post by silderan on Jan 31, 2015 21:27:40 GMT
Hello Ness. Long time I didn't annoy you!!! XD Time ago I tried your engine with a million tiles. I was impressed with FPS because doesn't care at all with map size. But, when I tried to zoom in/out it takes too long. I thought that as tile tilemap is a renderable, the transformations, such scale, could be "global" and no need for per-tile. But, as zoom is slow, seems that it's applied to all tiles. Maybe I'm wrong and not doing it right. BTW. I'm sad reading that you need to pause this project for a while.  Silderán. |
|
|
|
Post by Admin on Feb 1, 2015 10:18:03 GMT
Hello Silderán! Your posts never annoy me, no worries they are most useful. Some questions: 1. How are you doing the zooming? With set_scale()? 2. whats the size of your tilemap? 3. What do you mean by "slow", the zooming itself or rendering while zoomed in? I think I'll be able to help you with some more info. Meanwhile, if you only need zooming you can hack this by rendering on texture in the size of the screen and scale that texture. Thanks! |
|
|
|
Post by silderan on Feb 1, 2015 11:29:54 GMT
Just take your tile example, increase map size to 1000x1000 and zoom in/out with x/z
After new_scale is changed, in transformable_api.h, transformation_update() is called and applies scale to all tiles and takes some time because there are one million tiles!
Is it possible to override set_scale on tile_map (node_map, etc) and keep the transformation as a absolute_transformation or similar?
Silderán.
|
|
|
|
Post by Admin on Feb 1, 2015 11:53:26 GMT
yes you are absolutely correct about the problem. I don't know about the solution yet but I will figure something up. perhaps what you offered or maybe something more sophisticated (and by more sophisticated I'm talking about a more efficient "need-update" mechanism for all entities, not just tilesmap  . is this a real issue holding you back or just a problem you encountered? thanks! |
|
|
|
Post by silderan on Feb 1, 2015 12:33:39 GMT
Nooo, don't worry. It's something I figure out and tried. Not a real problem. Can I ask you why you don't like to use absolute_transformation for scaling? I saw this variable member in tilemap.h and there is no way to modify it, but you use it when calculating transformations. Another transformations, like blending and color/opacity could benefit with absolute_transformation. I was thinking with a way to change world color to simulate light modulation up to day/night. Maybe there's another way to do that. But this is another question  Silderán. |
|
|
|
Post by Admin on Feb 1, 2015 14:37:14 GMT
absolute_transformation is a struct most entities and nodes have, its just a cache of their current transformations including their parent's transformations. just like the node have it, the tiles have it, and the tiles absolute transformations are actually the tile transformation * the tilesmap transformations (i.e. the tile trans * its parent trans). hope it was clear lol. anyway the problem you raised is relevant to any node containing millions of entities and thus needs to be fixed I already have a general idea I hope I'll come around to implement it soon. if my explanation wasn't clear feel free to ask. thanks again for this report! |
|
|
|
Post by silderan on Feb 3, 2015 13:37:51 GMT
You're perfecly clear But, what about reanimg to cache_transformation instead absolute_transformation!?!?!?!? XDDDDD |
|
|
|
Post by Admin on Feb 3, 2015 17:35:41 GMT
NEVER! huehuehuehuehue
(now seriously - I like the "absolute transformations" because it gives good hint that these transformations are absolute and include all the ancestors).
|
|
|
|
Post by Admin on Feb 4, 2015 0:48:40 GMT
if you take the code from the git its now suitable for large tilemaps and nodesmap, and also fixed the absolute transformation virtual functions.
however, I still discourage you to make maps so big! mostly due to long loading time.
after tests and fixes from dazed I will make a version (that will also include new cameras system)
|
|
|
|
Post by silderan on Feb 4, 2015 13:14:08 GMT
Ok Ness, thanyou very much. As said other times, I'm not in hurry. Just testing diferents engines, APIs, etc. for learning while developing a game. So, don't worry about me. I must say that I don't like and I won't use big map size. I don't like to mix logic with rendering. So, my idea is to use a "enough to fit screen" time_map size that will move it's sprites to new tileID (tileType) and position following camera position. That way, real map size can be as big as I want, can has any shape (not just a square). Well, maybe I'm completly wrong... |
|
.