Attached Objects & Collisions Misfunctional
-
@Thecheater887 I've made a couple of posts about spring and rope joints being completely wonky. Damping isn't set up right. I get a sense that some of the physics never got finished, and certainly hasn't been tested.
I'm doing all sorts of workarounds ontop of workarounds to get pin joints to work happily, which shouldn't be necessary. They should just work. But they don't.
It's necessary to remove all mass and friction from your attached objects, which means they have none of the benefits of being physics objects, and I'm (quite literally) simply using pins and welds as "parenting".
I went through quite a lot of trial and error to find that the physics in hyperPad is good for simple things, impossibly broken for anything like a rigged object, and there's no boolean shaping, or snapping of shapes, so I stuck with simple. VERY SIMPLE.
Which is a great shame, because the blend of cocos2D and Chipmunk is the very best of both worlds, and should/could be the shining light of hyperPad.
-
@Deeeds I think hyperPad just needs scrapped an started fresh from zero.
Unfortunately, I also have an idea of just how impossible that is with the current status of the team.
They can't fix all these bugs, contain the nuclear reactors, keep the cores cool, add new features, and have a working product with a team so small.
No idea what their resources are, but my money is on an indie budget, nothing like a developer should have at their disposal.
-
@Thecheater887 said in Attached Objects & Collisions Misfunctional:
@Deeeds I think hyperPad just needs scrapped an started fresh from zero.
Or you know... We could like not.
The last time we rewrote hyperPad we focused on laying out the ground work. We're now focusing on fixing existing functionality, dealing with education users (our largest user base), and then adding new functionality.Every update we fix issues that we're able to reproduce. And add a a few "tent pole" features which lay ground work for major functionality. (eg adding arrays)
In your example case, you're trying to use a physics attachment for a solution to a missing feature. When we add hierarchies and grouped objects that is the correct way to do this.
Object grouping is another tentpole feature that will allow us to do really cool things. Especially with physics. -
@Deeeds said in Attached Objects & Collisions Misfunctional:
@Thecheater887 I've made a couple of posts about spring and rope joints being completely wonky. Damping isn't set up right. I get a sense that some of the physics never got finished, and certainly hasn't been tested.
I'm doing all sorts of workarounds ontop of workarounds to get pin joints to work happily, which shouldn't be necessary. They should just work. But they don't.
It's necessary to remove all mass and friction from your attached objects, which means they have none of the benefits of being physics objects, and I'm (quite literally) simply using pins and welds as "parenting".
I went through quite a lot of trial and error to find that the physics in hyperPad is good for simple things, impossibly broken for anything like a rigged object, and there's no boolean shaping, or snapping of shapes, so I stuck with simple. VERY SIMPLE.
Which is a great shame, because the blend of cocos2D and Chipmunk is the very best of both worlds, and should/could be the shining light of hyperPad.
By rigged object, you mean for example a truck with suspension and turning wheels?
-
@Murtaza said in Attached Objects & Collisions Misfunctional:
@Thecheater887 said in Attached Objects & Collisions Misfunctional:
@Deeeds I think hyperPad just needs scrapped an started fresh from zero.
Or you know... We could like not.
The last time we rewrote hyperPad we focused on laying out the ground work. We're now focusing on fixing existing functionality, dealing with education users (our largest user base), and then adding new functionality.Every update we fix issues that we're able to reproduce. And add a a few "tent pole" features which lay ground work for major functionality. (eg adding arrays)
In your example case, you're trying to use a physics attachment for a solution to a missing feature. When we add hierarchies and grouped objects that is the correct way to do this.
Object grouping is another tentpole feature that will allow us to do really cool things. Especially with physics.
I think you're conflating posts here.
Let me make one thing very clear. I am not suggesting you rewrite the codebase.
But there are a few key things to look at, low hanging fruit, to unleashing far better (and infinitely more reliable) performance from cocos2D.
I make it quite clear, in my post, that I consider cocos2D and Chipmunk to be the ideal basis for hyperPad.
I'll go a bit further on this, I think it should be said. Swift isn't ready, and there's no alternative engine choice that's valid or better than cocos2D-iPhone at this point in time, nor foreseeable.
cocos2D-X is a build system nightmare requiring admin-like monitoring and maintenance of the building processes and dependencies and who knows what else, all the time, full-time. The people that use cocos2D-X in production usually have these kinds of teams. I've been involved with a team of 160 using it. Fully 7 of their very best programmers were simply taking care of cocos2D-X so the game logic programmers could work on game logic without constantly struggling with the engine's maintenance, setup and processes.
SDL is a good option if you like dealing with C++ and have a huge passion for modularity and plugins. There is a project heading in this direction from the guy that was central to Corona. It might be that his experience means he makes a viable and well designed and architected game engine. He's bright, thoughtful and experienced. A very rare breed in iOS game engine thinking and design/development.
ARKit might have a benefit for SpriteKit, in that Apple might begin to take it seriously. It's been a mistreated step-child from its beginnings, and saw nothing but the addition of ARKit in this years iOS update. It's an enormous, unwieldy, mess, too, as they've added on "tentpole" features without any core consideration of its user-friendliness. And it's always got showstopper bugs of some sort or another that remain unfixed (and unfixable because it's closed source) and even unacknowledged for anywhere from 3 months to multiple iOS releases. It's anybody's guess when they'll ever get to any bugs in it, so it's difficult to rely on it.
Box2D is at a bit of a disadvantage on iOS hardware compared to the multicores of Android, much of which is clawed back by the optimisations and approaches of Chipmunk2D. Further gains could be made by utilising Metal, as is the case with the rendering core of cocos2D system, but that's probably not something to consider until iOS 12 stabilises development of Metal. cocos2D is already using some of Metal's advantages and not struggling for rendering performance.
cocos2D's main issues are time management.
There are two inherent problems with cocos2D, one of which I've already shown you in another post, that details how you can stall rendering updates when there's no activity.
The other problem is deeper ingrained, and requires an understanding of the clock mechanisms of iOS and of game loops. cocos2D-iPhone never had a proper game loop largely because it was designed to be an action based engine (abstracted above this need of its users), one that doesn't need the full exposure of a real game loop. As it grew they tacked on ever more game-loop like functionality, but never built a proper time management loop at the core of the update processes interacting with iOS.
And they relied on CADisplayLink, which simply isn't reliable. Over the years it has become more unreliable, too.
I was one of the first to really see how this impacts performance and isolate it as being a problem in cocos2D (rather than a limitation of iOS) because I was working on designing and building a music/rhythm game/tool with a very good programmer. That game required some degree of dedication to mach time, great big bursts of graphics for very short periods of time and concurrent dedication and adherence to MIDI's disciplined timing and C.
We found that cocos2D doesn't recover from those bursts of activity gracefully, or at all. It gets stuck behind what it idealises as "right time" imagined by its adherence to the ever unreliable and limited CADisplayLink. In this way it creates a backlog of events for itself, that it can never catch up on, and balks all of iOS in the process, only getting released from this mess of its own creation when iOS interrupts in a massive way.
When you see hyperPad stammering and stuttering, this is what is happening. Pull down the notifications panel from the top of your screen to release cocos2D from this self inflicted nightmare its gotten itself into.
Coincidentally, @Murtaza @Hamed, once you understand this problem you can actually solve the creation of a non-drawing "update" state in a simpler way, too, which will massively save energy/battery during Behaviour and Scene Editing.
@Thecheater887 There is no need to rewrite hyperPad. A couple of little fixes to cocos2D will make a world of difference... then they can march on with regards everything else they want to do. Without those fixes, cocos2D is always a bugbear because you can't see (without profiling all the time) when you're actually taxing the system and when cocos2D has gotten behind itself and simply choking on itself.
This has probably been driving them mad for a very long time, and been one of the causes of their frustrations. It's a stumbling block that hyperPad is hitting all the time... and it's not because of the way they're doing incremental saves (although this can be massively optimised, too), it's cocos2D that's struggling with its loop getting out of sync with the iOS world and not being able to get back on track.
On the physics, no. I really do mean that it's pretty broken. Rigging up relationships is flawed in some serious ways that I haven't bothered to yet examine and identify, so I haven't commented much other than to say that it's broken. This is most obviously noticeable, instantly, with damping of spring joints. Which doesn't work as it should.
My uses I've restricted to pinning in an absolute way because I can't get pins to reliably work as they should. I actually wanted more from them, but have resorted to only using them for a solid pin, much like a weld with a little rotation freeplay when I need it, because that's all I can get them to reliably do, but even that requires workarounds to ensure stability that should innately be there. This is directly related to the problems @Thecheater887 has noticed. I've seen exactly what he's talking about, and it shouldn't be happening when it does, the way it does.
I'm using a weird blend of monitoring and adjusting velocities and position updates to correct for these problems, along with a peculiar usage of exponential and cubic timings to create a "lerping" camera that I should be able to do with rigging spring and rope joints, but cannot because of their inherent problems and lack of real/correct damping.
-
@Deeeds here are some pivot joints and springs working fine.
http://bit.ly/2icIQ1K -
@iTap-Development Given your past comments, you're going to need to define "fine".
-
@iTap-Development Let me explain, so you can feel the urge to be serious instead of flippant.
Try to use words to define "fine" and what you know of how damping works, and what it is. At this stage, I'm pretty much convinced you have no idea how it works or what it is.
-
So, when we made the migration from Box2D to Chipmunk, we kind of fudged the numbers of some stuff to get it as close as possible so that old games were still supported. Eg. we add a force for air resistance on every time step because chipmunk2d doesn't have the idea of air resistance.
From what I understand, you want us to get rid of these complexities... me too! However, in the mean time, you can go into world settings and set friction, air resistance etc to 0, and it should give you the raw effect.
As for the joints, we can deprecate our old behaviours (ie, old behaviours will still work but just not visible) and give you direct access to the different joints that is currently accessible. We're combining a bunch of joints to get that old Box2d feature set, but it sounds like its more of a hassle to work with for you guys.
All this being said, theres a bunch of stuff broken but we want to make our release cycles "fast". In the coming weeks, we will make a thread with all the broken items linked to our public road map, and you guys can vote on which items are higher priority.
P.S It takes me a really long time to read your guys' long posts... if you could keep feature requests and bug reports short and sweet in their own threads that would be a HUUUUGE help to me. You don't need to include details teaching me the history of computer science... just tell me the problem and I'll fix it. I'm also not ignoring you guys, I'm fixing things. I'll ask questions if needed.
P.P.S @Deeeds nice find on that CADisplayLink bug, I saw that before, but haven't gotten around to fixing it yet.
-
@Hamed With all due respect, I've had to explain the foibles of CADisplayLink to about a dozen different programmers over the years. Not one of them has taken me at my word. I've had to give them detailed explanations and provide insights into how and why it's not what they want, or need, for game loops.
As Apple geared up for variable rate display technology, throughout 2013 through 2106, it became much more noticeably variable in its output.
That cocos2D uses date instead of mach time is also bizarre. But that's for another day.
-
@Deeeds by “fine” I meant working normal.
-
@iTap-Development I'm now absolutely convinced you have no idea how damping works, or what it is.
Read here:
https://blurrrsdk.com/documentation/Chipmunk2D/interface_chipmunk_damped_spring.html
Then ride a bike with suspension.
Then press down on the bonnet of a car and let it spring back. Notice what happens.
-
@Deeeds damping effectively reduces the speed/force of a decompressing spring, right?
-
@iTap-Development I want the attached object to work as if it's "screwed" onto the roof of the vehicle.
Like a light bar on a police car, or an antenna on a motorcycle.
I want to be able to swap out these parts interchangeably, or remove them altogether.
If they are there, they need to act as if they are one with the vehicle, like they do in real life.
The fact that weld attach is described to do this and doesn't is what my complaint was about.
I do believe no one has addressed the collisions complaint, but I could very well just be blind, too.
-
@Thecheater887 I think weld works, except it might kinda wobble, but I haven’t used it in a long time.
-
@iTap-Development False.
This is something you might see in a frictionless magical dimension, not a realistic one.
It's even worse when you try to precisely control the vehicles movements.
Move to objects don't help, set velocity and rotate is always off, and then there's this.
-
@iTap-Development said in Attached Objects & Collisions Misfunctional:
I think weld works, except it might kinda wobble,
This is the exact definition of a weld that doesn't work.
-
@iTap-Development said in Attached Objects & Collisions Misfunctional:
damping effectively reduces the speed/force of a decompressing spring, right?
keep googling and reading. You'll get there...
-
@Deeeds I just tried a weld...I thought they had a very slight wobble, but it actually works perfect.
-
@Deeeds maybe you could define/explain damping then?
