Will you support Stencyl if it will start kickstarter company?

gurigraphics

  • Posts: 688
Quote
I just looked up Cocos physics. It uses something called Chipmunk.

He can use the both.

Quote
If you look through the various tutorial instructions, it has you using spatial relationships and queries.... guess what... that is the same as customizing your math in Stencyl. I did not see anything that happens automatically simply because of Chipmunk being there. If you are saying that Cocos should be integrated into Stencyl, that means ALL of the Chipmunk calculations would also have to be programmed in. You would still need to customize everything for performance because those calculations would be happening everywhere at the same time (even when not needed or desired).  Using any predefined physics engine is going to sap game performance. Physics engines are there to make it easy for beginners and include every calculation that a beginner might need to use - meaning they run many calculations that are not used. It has already been stated, every engine or language out there requires users to create their own calculations for advanced functions and improving performance.

The argument is good. However, you can just put actors on the screen, without using any mathematics and the performance is better in these engines.

gurigraphics

  • Posts: 688
Quote
I agree with Liberado that the Box2D implementation in Stencyl could be better and that physics games with high actor counts are not really doable in Stencyl.  Creating a custom collision system with the complexity of Box2D is not a reasonable solution.

That's what I thought. Box2D is just a library that not run functions without need.

Mathematical calculations blablabla it was a good guess. But, of who should not really understand the question.

The conclusion: is more easier learn to use an engine that hundreds of people together resolved this - because this any beginner can - than, try implement these mathematical calculations - because same who is of area no knows or can.

« Last Edit: March 29, 2016, 12:51:17 pm by gurigraphics »

tigerteeth

  • Posts: 734
I have to say: when I didn't like the 4 way joystick extension that was provided by a 3rd party, I built my own using maths. It was pretty difficult, but the complicated bit was the coding blocks, and Stencyl did a pretty good job of teaching me that.

Although it would be pretty difficult to recreate Box 2D physics entirely within stencyl, the fact is that recreating certain parts of it (whatever part is necessary for your specific situation) doesn't have to be.  Next time I'm going to consider it.

It is a shame that Box 2D in general doesn't have as good a performance as it might be able to. I'm interested to see if the anti-jittering patch makes a big difference to my performance or not. I'll try tonight.


merrak

  • *
  • Posts: 2263
Although it would be pretty difficult to recreate Box 2D physics entirely within stencyl, the fact is that recreating certain parts of it (whatever part is necessary for your specific situation) doesn't have to be.  Next time I'm going to consider it.

Gravity is simple. I'm in the process of implementing it in 3D. Collision handling is much more complicated. A program that is optimized for your specific purposes should perform much better than one using a "one size fits all" type tool.

But I do think there's room for improvement in Box2D. I did manage to get Legend of Fordham Forest to the point that it can handle large structures (like found in Angry Birds), but it has been a real fight the entire time.

Tepastelija

  • Posts: 51
You can enable html5 today (and have been able to for some months now) by modifying a text file in Stencyl's settings. It will very likely be enabled by default in the coming months as we iron out any remaining kinks.

In [workspace]/prefs/boot.txt:
Code: [Select]
html5.enabled=true
We will hopefully move to Openfl Next soon as well. There may be one or two features that haven't been rewritten in Next yet, but I believe the vast majority of what we need is there now. Unfortunately it's not like flipping a switch, there will be some work required to upgrade to Next. Off the top of my head, for example, our gamepads code will likely need to be rewritten (but hey, we can make it better the second time around).

By the way, if you want to experiment, you can also enable openfl next, but it is by no means official or supported.
Code: [Select]
openfl.next.enabled=true

Thanks for answering all my questions Justin! I'm really happy to know that Next is on horizon, and you guys are working hard to get html5 as polished as possible. Keep up the good work!

ceosol

  • *
  • Posts: 2225
Gravity is simple. I'm in the process of implementing it in 3D. Collision handling is much more complicated. A program that is optimized for your specific purposes should perform much better than one using a "one size fits all" type tool.

I agree. I created a platformer in February that used my own custom velocity/speed system. It did not have the jittering problems that everybody complains about.

I am in the middle of created my own collision system for a soccer game. So far it is working out quite well.
EDIT: In case you are wondering, I have the collision boxes as sensors and use custom reactions to the collisions. I could just as easily create my own "x + width < x" type of pseudo boxes and it would work just as well.

SadiQ

  • Posts: 1771
EDIT: In case you are wondering, I have the collision boxes as sensors and use custom reactions to the collisions. I could just as easily create my own "x + width < x" type of pseudo boxes and it would work just as well.

Do remember that, even if you use the actors as sensors, you're still relying on box2d to tell you when and where the collision  happen. If you use regions or terrain regions it's still the same thing. (a region is also an actor).

In the boxing game I posted earlier I used minimal actors with my own collision detection. (not because of performance issues, but because I wanted to learn how to do it and see if it's harder...and it wasn't in that case).
Proud member of the League of Idiotic Stencylers! Doing things in Stencyl that probably shouldn't be done.

tigerteeth

  • Posts: 734
I gotta say: right now I'm about to spend at least an hour changing 12 collision polygons because stencyl doesn't let me copy and paste them (and because I have to avoid clipping, I can't just use the default squares) and this is when I start to wonder if Stencyl could perhaps be a bit more user friendly sometimes.

letmethink

  • *
  • Posts: 2547
If you have multiple animations you want the same polygon for, I believe you can edit the collision string data in resources/data.xml. (make sure you close Stencyl first).
~Letmethink

ceosol

  • *
  • Posts: 2225
I gotta say: right now I'm about to spend at least an hour changing 12 collision polygons because stencyl doesn't let me copy and paste them (and because I have to avoid clipping, I can't just use the default squares) and this is when I start to wonder if Stencyl could perhaps be a bit more user friendly sometimes.

If you duplicate animations, the collision box gets transferred over. So set your first animation's collision, duplicate 11 times and then drop your new animations into them.

tigerteeth

  • Posts: 734
I gotta say: right now I'm about to spend at least an hour changing 12 collision polygons because stencyl doesn't let me copy and paste them (and because I have to avoid clipping, I can't just use the default squares) and this is when I start to wonder if Stencyl could perhaps be a bit more user friendly sometimes.

If you duplicate animations, the collision box gets transferred over. So set your first animation's collision, duplicate 11 times and then drop your new animations into them.

I figured that out right after I posted. So instead of an hour, it's gonna be about 15 minutes of copying and pasting each frame of the animations, individually, and then individually changing their custom origin points, and then their names,  and then copying over the duration of each frame. VICTORY!

« Last Edit: March 31, 2016, 07:46:51 am by tigerteeth »

UnusualCadence

  • *
  • Posts: 139


By the way, if you want to experiment, you can also enable openfl next, but it is by no means official or supported.
Code: [Select]
openfl.next.enabled=true

I actually had a little play around with this a few months ago. I had to rip out all the Shader and Gamepad code to get it to compile, but with a bit of hacking it built! Sadly though, it seemed that it didn't render any tiles, so I didn't actually SEE very much in the end :)

letmethink

  • *
  • Posts: 2547


By the way, if you want to experiment, you can also enable openfl next, but it is by no means official or supported.
Code: [Select]
openfl.next.enabled=true

I actually had a little play around with this a few months ago. I had to rip out all the Shader and Gamepad code to get it to compile, but with a bit of hacking it built! Sadly though, it seemed that it didn't render any tiles, so I didn't actually SEE very much in the end :)
You can pop in this file for tiles to render using openfl next: https://github.com/iamletmethink/stencyl-engine/blob/master/com/stencyl/models/scene/TileLayer.hx
~Letmethink

yoplalala

  • *
  • Posts: 1491
Quote
You can pop in this file for tiles to render using openfl next: https://github.com/iamletmethink/stencyl-engine/blob/master/com/stencyl/models/scene/TileLayer.hx

Maybe you could push the modifications and use #if (openfl_legacy) conditional compiling so that people could use or or not openfl next :)