Raggar

Members
  • Content count

    82
  • Joined

  • Last visited

About Raggar

  • Rank
    Advanced Member
  • Birthday
  1. For the constraint. I haven't personally toyed with the function, but have you verified that the function itself works by doing something like this: ballM.physicsImpostor.executeNativeFunction(function (world, body) { body.velocity.-y = 10; }); Or maybe just log the output of the world and body, to make sure everything is right?
  2. The name shouldn't really matter as far as I know. They still have ID's to uniquely identify every single mesh. Try zooming out, then it doesn't run as smoothly, but that is something entirely different than this thread. Imagine making a skyscraper you could bring down, that would be cool, but I'm not really sure Javascript is capable of doing that, in a performant way.
  3. Stupid me. For every frame in my network loop (20/sec), I create an array of the positions of every single player connected to the server, and sends it to, again, every player connected to the server. What I did was create said array OUTSIDE of the 'for loop' handling every single player, this resulted in the array containing duplicates of every players state. So instead of an array looking like this (Simplified and made realable): [{playerID: 1, position: 1}, {playerID: 2, position: 0}], the array would be: [{playerID: 1, position: 1}, {playerID: 2, position: 0}, {playerID: 1, position: 1}, {playerID: 2, position: 0}], and of course increasing with the number of connections. This was fixed by initiating the array inside the loop. Now I can have 5 players connected before the speed of the player object starts to get affected. Something else to investigate I guess Right now, I'm sending player inputs every frame, at 60/sec, which I would like to cut down to ~30/sec to save bandwidth, but still keep it as accurate as possible. I will have to change the implementation, so that only inputs that have changed will be sent, but this early I like to assume that every player will be doing everything he can at any time. I tested the server's received packets, and 4 players summed up to just about the right amount of packets(4 * 60/sec).
  4. http://www.babylonjs-playground.com/#15U9CT#42 On line 521/522, I tried using both world.removeConstraint and constraint.disable() without any apparent difference. Try picking the boxes to see it in action. Try running either of those functions natively using the function in the plugin.
  5. I know Cannon has a removeConstraints function, so if that's the plugin you use, maybe you could either try that, or try the executeNativeFunction function.
  6. Ehh. I got server-side hitboxes properly working, using 3 boxes to simplify intersection checking. The problem I'm facing right now is, that after changing from sockets to WebRTC, I have some weird issues I can't really figure out how to fix. When one player joins, everything runs smooth and perfectly as it did with sockets, but as soon as another player joins, the accuracy slowly gets worse. Then, with any additional player, it only gets worse. I tried with big and small packets, but it doesn't make any difference. The functions handling the interpolation of both the local player, as well as the remote players run at about 0-2ms, so this isn't the bottleneck either. I have checked and double-checked my code many times, but everything should simply work as it did before the switch. This is starting to give me quite a headache
  7. I know that a couple of users on this board, myself included, are using Node-Gameloop: http://timetocode.tumblr.com/post/71512510386/an-accurate-nodejs-game-loop-inbetween-settimeout https://www.npmjs.com/package/node-gameloop
  8. 47 - 60 FPS. Mostly around the 55-50, depending on the number of asteroids in the view.
  9. 9-18 FPS using Chrome on my Samsung (Core Prime) running Android 5.1.
  10. Interpolation of the other players now look smooth and right. I'm not too happy with the correction of the clients own player, after applying some 'only send when state has changed' on the server. For now, I'll revert back to the old way of doing it, as I guess this is more important to test, as it will show how many players can actually be active and playing at once. Then, at some point, I can go back and give it a try again. I'm not quite sure where the issue happens, as the functions are pretty much the same, but somehow creates very different results. The first way is very accurate, the second one seems to make it randomly inaccurate some times. As there are some differences between the API of WebRTC and Socket.io, the next step will be to implement the DataChannels, then test and find a suitable solution to the reliable/unreliable problem with either my own implementation or multiple channels. Then comes delta compression, which I have an idea how to implement, based on every player's own acknowledged state, as I'll have to send every state to every single connected player.
  11. I've the multiplayer part working, prediction and correction of server state, some of it based on latency so it looks better and more smooth. Next step is interpolation of the game states from the server. I'm not quite sure how to implement this, but I'm thinking about using delta time to calculate the lerp percentage to make it frame independent. Then when a new state is received from the server, I snap to the previous state, and uses the delta time to calculate the lerp. If I send the state to the clients 20 times each second, and have ~60 fps, I'll use the ~17ms to get a value like .03 or point .05 depending on what looks the best. So far I only send the client's ping once every second, and I'm planning to use this update to send a full state, and then the remaining 19 to only send deltas. Whenever a client sends input, they should send the last acknowledged full state, and deltas are then then based on this state, so packet losses won't mess too much with the accuracy of the states. Right now, I send all clients' states 20 times a second, but I'll have to only send changed states, too. But that shouldn't take more than a few minutes to implement. Same thing goes with input. If neither rotation nor input has changed, no need to send any. The reason I mention packet loss is, that I am planning to use WebRTC. I have a little test with it successfully running on Node.js as well as in the browser. I'll just have to test whether I can, in a stable way, habe 2 dataChannels for each client, one reliable and ordered and one unreliable and unordered. Otherwise I'll have to implement reliability myself, with retransmissions of packets and acknowledgments. I would prefer the first option, though. 2 other issues I have are: First, right now I send 1 state for every client, 20 times a second. With, let's say 10 clients, that's 10 states * 20 frames * 10 players * every second. That sounds like a lot, so I'll have to send updates in arrays, and maybe split these array into smaller arrays, depending on the sizes of the states, as well as the player count, as to not enforce MTU-fragmentation. The other one is, that I'm sending inputs every frame, that's, when everything runs smooth, 60 times a second. I think this sounds like a lot, too. But I'm afraid there is no way around it, as the input applies velocities, and because of that, can't just be applied at any time. It has to be as quickly as possible, to get the most accurate results. I guess I could just send the inputs, at most, 20 or 30 times per second, and suffer a bit from inaccuracy. But as this is the only data that i so far send from the client to the server, I'm not too worried about it, yet. Same goes with deltas. I'm not planning on sending deltas for rotations at this point, but I might have to at some point.
  12. This ended up really shitty, but it shows collisionResponse in action: http://www.babylonjs-playground.com/#29TTKJ#5
  13. With Cannon.js, you can set the collisionResponse to 0, thereby preventing the actual collisiion with the physics body, but still fire the 'collide' event, so you can remove the pellet, increase score etc.
  14. Why don't you use velocities insteaf of moving the camera using units? Are you using Oimo or Cannon? I know Cannon has collisiiongroups and masks, as well as collisionresponse, so you can turn off actual physical collisiions, but still register the event. When you say laggy, does this mean that the framerate drops, or that the camera physics body simply stops, due to colliding with the pellets?
  15. It makes it a lot eassier if you post a Playground example, as otherwise, people will have to blindly guess what the problem 'might' be