FB a requirement to get news on torque future? ;)
by Marc Dreamora Schaerer · in iTorque 2D · 05/03/2012 (8:00 am) · 20 replies
I might missinterpret that but thanks to having David Montgomery-Blake on my FB friends list I got the chance to read about http://www.3stepstudio.com/ on his wall.
Is there anything more on that? :)
Is there anything more on that? :)
About the author
#2
If you look at the product that they are working on it looks like T2D in an even simpler version or T2D templates alternatively and the studio itself at least seems to be related to GarageGames as you can see in the footer.
So my question is: why the find out about it on DMBs FB wall instead directly here? ;)
05/03/2012 (9:54 am)
Not sure I get the meaning of the ???If you look at the product that they are working on it looks like T2D in an even simpler version or T2D templates alternatively and the studio itself at least seems to be related to GarageGames as you can see in the footer.
So my question is: why the find out about it on DMBs FB wall instead directly here? ;)
#3
We are approaching it from a "eat your own dogfood" standpoint. The game templates we are making use the features directly, so we can make sure that they work in a logical way. Box2D is only useful if it can actually be used in the engine without serious performance implications, for example. We're trying to avoid adding bullet points for the sake of adding bullet points to product pages and make sure it works and works well.
05/03/2012 (9:59 am)
Not yet. We're finalizing a blog for here, but we're in invite alpha state right now and 3 Step is more tailored to completely green developers who do not know where to start, so the GG crowd is much more seasoned. But the work that has gone into it will roll back into our current engines here, so everyone will benefit from the updates. You may have seen the screens that Mich has posted on performance updates, physics, etc.We are approaching it from a "eat your own dogfood" standpoint. The game templates we are making use the features directly, so we can make sure that they work in a logical way. Box2D is only useful if it can actually be used in the engine without serious performance implications, for example. We're trying to avoid adding bullet points for the sake of adding bullet points to product pages and make sure it works and works well.
#4
I indeed saw the postings by Mich yeah :)
I like that fact that you are returning to the 'eat your own dogs food' approach. It has helped TGEA a lot that GG was forced to use it for Legions after countless threads where various staff members didn't believe that it was utter trash till they were forced to use it ;) This naturally isn't the situation now but its still obvious that the engine was not used heavy enough to realize that various core aspects were already 2 years ago overdue for an update.
Box2D is one of the things as the T2D physics system is just as bad as the TGE+ system has always been.
It never was good at all, it was just good enough for what it originally was created for and under the assumption that cpus remain that absolutely limited as they were back in the 500mhz days which didn't justify more than 'fake pretend physics' for cpu limit reasons.
I though hope that one of the side effects of this though is that GG finally, after years of missing or refusing this trivial optimization especially on iT2D, also accept that you have the collision polygon and its editor and that there is not a single good reason to not use it to generate the sprite mesh to finally stop the overdraw GPU trashing T2D has always done due to its quad sprites. Quad sprites instead of more opted meshes are simply an absolute waste, even more if you have a polygon editor generating valid polygons already present ... ;) I would really love to see how the performance would look alike if this was taken into account too, how much more it could push that way especially with real sprites then that aren't quad and that can not be made opaque just for the sake of getting a theoretically high performance that falls flat the moment it has to work under a real use case. But as you now use the engine I doubt it would remain like that if such a dirty shortcut would have been taken to achieve those metrics :D
05/03/2012 (10:11 am)
Hmm isn't or at least wasn't that the exact target usergroup for which TGB got developed actually? (the only reason why you can use purely through script without a bachelor in dirty hack++ ie C++ as it was required for TGE at the time? ;) )I indeed saw the postings by Mich yeah :)
I like that fact that you are returning to the 'eat your own dogs food' approach. It has helped TGEA a lot that GG was forced to use it for Legions after countless threads where various staff members didn't believe that it was utter trash till they were forced to use it ;) This naturally isn't the situation now but its still obvious that the engine was not used heavy enough to realize that various core aspects were already 2 years ago overdue for an update.
Box2D is one of the things as the T2D physics system is just as bad as the TGE+ system has always been.
It never was good at all, it was just good enough for what it originally was created for and under the assumption that cpus remain that absolutely limited as they were back in the 500mhz days which didn't justify more than 'fake pretend physics' for cpu limit reasons.
I though hope that one of the side effects of this though is that GG finally, after years of missing or refusing this trivial optimization especially on iT2D, also accept that you have the collision polygon and its editor and that there is not a single good reason to not use it to generate the sprite mesh to finally stop the overdraw GPU trashing T2D has always done due to its quad sprites. Quad sprites instead of more opted meshes are simply an absolute waste, even more if you have a polygon editor generating valid polygons already present ... ;) I would really love to see how the performance would look alike if this was taken into account too, how much more it could push that way especially with real sprites then that aren't quad and that can not be made opaque just for the sake of getting a theoretically high performance that falls flat the moment it has to work under a real use case. But as you now use the engine I doubt it would remain like that if such a dirty shortcut would have been taken to achieve those metrics :D
#5
05/03/2012 (10:21 am)
Melv has been doing a ton of backend optimization to get the performance seen in the screenshots. I'm not familiar enough with the work he has done to answer whether that is the path he has taken, though.
#6
05/03/2012 (12:05 pm)
Please don't tell me that this product will get all the new performance improvements before iTorque2D?
#7
05/03/2012 (12:20 pm)
We're doing it this way so that we can do it right rather than having to course correct later because the implementation was not as robust as required by devs in production. We believe with the way that we are approaching this, that the final improvements that move into the 2D codebase will be of high quality and, more importantly, tested in a real world application.
#8
05/03/2012 (12:29 pm)
David, my concern is that all the dev effort will focus on the new project and we'll never see the performance improvements. Do you get source code with the new project?
#9
I definitely understand your concerns. It would be very different if we did not see it as a transitional process that will grow as the developer grows.
05/03/2012 (12:38 pm)
Nope. It is a free product designed for brand new developers. When they hit the ceiling of the beginning product, they can move to the next tier, which is our 2D engines here. So it is important for us to be able to move them to iT2D/T2D, which mean getting those features solid in our engines. We're not killing our current engines to work on this one. But it is providing solid development work to ensure that the features we move into our engines are useful and robust.I definitely understand your concerns. It would be very different if we did not see it as a transitional process that will grow as the developer grows.
#10
05/03/2012 (12:40 pm)
Well, I wish you all the best of luck and sincerely hope that we see the fruits from this project ported back into iT2D within a reasonable timescale.
#11
05/03/2012 (1:04 pm)
I'm going to stomp my feet and shake my tiny fists in the air if it doesn't happen. No one likes to see a grown man throw the equivalent of a Walmart toddler fit in the middle of the dev room.
#12
05/03/2012 (1:16 pm)
:)
#13
05/03/2012 (5:13 pm)
@Scott - I'm sure you don't have to guess who is involved with the product and who will also be trying to schedule time to port improvements to iTorque 2D.
#14
FB picks up old news then, IRC rumbled this months ago - and then proceeded to complain about the name being too "generic".
05/03/2012 (5:57 pm)
Quote:
FB a requirement to get news on torque future?
FB picks up old news then, IRC rumbled this months ago - and then proceeded to complain about the name being too "generic".
#15
05/04/2012 (1:35 am)
I'm confused as heck. What is FB? Is 3 step studio using iT2D?
#17
05/04/2012 (4:58 am)
@Marc - Ha. Yeah, I myself don't use facebook too much, but I do have FB integration in my new game. Thanks for pointing that out.
#18
While I develop integrations for it and happen to have a 3 year ongoing chain of poke-poke with a friend of mine I otherwise don't really care about it :)
05/04/2012 (5:03 am)
aye I'm not all that active there too.While I develop integrations for it and happen to have a 3 year ongoing chain of poke-poke with a friend of mine I otherwise don't really care about it :)
#19
05/04/2012 (5:06 am)
@Marc - you wont be cooking your friends in the next Cannibal Cookout release then ;-)
#20
05/04/2012 (5:09 am)
No fair, my cooking bowl is awaiting their backs ;)
Torque Owner John Vanderbeck
VanderGames