Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by dreta

  1. It makes absolutely no sense to specify requirements for a graphics library other than the minimum API version the graphics card needs to support (in this case it's a WebGL-enabled browser).
  2. Cool Good luck with your future projects!
  3. Looks great, plays horribly. The jump is awkward, the character floats too much and there's no controllable jump height, meaning that you have to stop the character in the air when jumping over short gaps. The game doesn't register jumps when the character is near the edge of a platform, this is awful. There should be a leeway as to when you can perform the jump; it should be possible even a slight amount of time after leaving a platform. This is important in 2D platformers in general, but here it's MUCH more important because everything is 3D and the camera's angled. Additionally the charac
  4. Occasional lag most likely means you're producing too much garbage. If the game runs slower with lower FPS, that means you've tied your game logic to the FPS, what you should do instead is update the game depending on the actual time passed between frames, or better yet, by a fixed amount of time, but only update if the time between frames is at least as big as the fixed time. The size of your level shouldn't matter as long as you implement proper space partitioning structures for physics and rendering.
  5. It's absolutely distinguishable between 30 and 60 FPS. It's always a big deal when a fast paced AAA title drops to 30 FPS. "Juicy" mobile games and infinite runners need high FPS for appeall, though for a lot of titles it probably isn't as important. People that play games often are used to 60 FPS and they can tell the difference. Should be the other way around. Run your physics at 20 FPS and rendering at 60 FPS with interpolation.
  6. http://buildnewgames.com/optimizing-websockets-bandwidth/ Use https://github.com/Worlize/WebSocket-Node instead. It allows you to send binary data and doesn't bloat packages.
  7. To expand on what Deltakosh said, it's common practice to load any assets that aren't Image or Audio by using XMLHttpRequest (or xhr for short). XMLHttpRequest won't work offline, because it doesn't allow cross-origin requests for security reasons. You have to set up a local server (since you're dealing with HTML5 development, you'll need to do that no matter what anyway). I suggest either setting up a static node.js server or using XAMPP.
  8. I enjoyed the few minutes i spend with the game. There are a few immediate issues though. For one the game desperately needs volume control, even if it's just a demo, and secondly you can't move diagonally on the world map, which gets annoying.
  9. Well it should be a basic feature for any physics engine. How do people who use Phaser handle things like explosions or more complex AI without world queries?
  10. Hey, I've downloaded Phaser from GitHub and the only object that's documented is the TimeManager, so i tried building the documentation with yuidoc myself, but not the whole documentation builds, f.e. physics isn't building at all. Which leads to my next question, since i can't look this up in the documentation, can somebody tell me if Phaser has the ability to query the physics world? F.e. retrieve objects or tiles that overlap an AABB or retrieve the first object or tile hit by a ray. I looked at the physics source and i can see that you're using a quad tree and making it publicly accessib
  11. Using socket.io for games is a terrible idea.
  12. You can center content on a page by setting the horizontal margin to auto. For this to work with canvas you have to set display to block first. canvas { display : block; margin : auto;}This is how pages are centered. You either set the margin for the body or a div that holds the page content.
  13. dreta

    WebGL HUD

    You mean HUD as in UI? For every UI element, you build a rectangle out of two triangles and you texture that rectangle with the graphic you want to use for it. If you use pixels to position your UI elements instead of the (-1, 1) range, then you'll have to build an orthogonal matrix that will transform your rectangles from screen space to NDC space. Remember to render the UI after the scene, enable blending and disable depth testing. Text rendering works the same way by rendering individual letters, but you can optimize it by using triangle strips for a text area, by pre-rendering a piece of
  14. Your code structure is kind of a mess (in the same sense that interleaving public and private field definitions in C++ is a mess), especially the Score function and the way you use it, but since you're looking for strictly JavaScript feedback, and since structuring code is a skill you learn with time, i won't comment much on that. The glaring issue is this piece of code: document.addEventListener('keydown', function(event) { if(event.keyCode == 38) { player.Y -= player.speed; } if(event.keyCode == 40) { player.Y += player.speed; } });Y
  15. As i and Ezelia said, client-side prediction is the way to deal with these problems and you need it no matter which protocol you use. The only real issue could be Nagle's because you couldn't work around it if it wasn't disabled, that's why i only mentioned that.
  16. @Quetzacotl TCP/IP is fine, you don't need UDP for Pong, don't be ridiculous. The only problem with TCP/IP is that it can use Nagle's algorithm, which is an issue, since Pong would most likely send lots of small packets, but it's disabled by default in socket.io. Pong is a great place to start because it will require you to implement client-side prediction, which is an essential thing to understand. Writing Draughts, or what ever, is a waste of your time, you won't learn much of anything from doing that except for the socket.io/WebSocket API (which takes 10 minutes on its own).
  17. I'm skeptical about TCP/IP being used for multiplayer games, especially RTS or FPS, though i hope to be proven wrong.
  18. Cute way to shorten the names of WebGL functions. Also clever usage of undefined type conversions in the gl.vertexAttribPointer function. There's an unnecessary calculation in the gl.bufferData function though, my guess is that 34962 was initially assigned to a variable.
  19. My guess is that drawing operations are always transformed, just that the default transformation matrix is an identity matrix. Since canvas drawing is hardware accelerated, it just doesn't make sense that the browser would do some sort of check whether the current transformation matrix is an identity matrix or not, especially that applying a transformation on the GPU costs nothing and it's only done per vertex. IMHO the first approach is the way to go, the second approach potentially has to draw content that isn't going to be displayed on the final canvas, not to mention the copying operation
  20. If somebody gains access to your server, they can do what ever they want to your users, whether you use eval() or not. eval() gets bad reputation because it's used incorrectly. If you want to download a piece of JavaScript code from your server and then run it, then it's alright to use eval(), that's what it's for. The performance implications of eval() versus attaching a <script> may exist, but that's going to be VM dependent, and it certainly won't come into play unless your scripts are huge, on top of that, you're only calling eval() once per script. I don't see the performance ever
  21. It's game dependent. If your game only updates the canvas when something happens, then that's a different story, in most games things update and change constantly, so it makes sense to constantly re-draw as well instead of waiting for something to change. As for, does it makes sense to render even though logic hasn't updated, imagine a platforming game, it's sufficient to update physics at 30FPS, but you want your rendering to be super smooth, because you have fast moving objects, so you'd still update the canvas at 60FPS, but you'd have to implement prediction so that even though physics chan
  22. requestAnimationFrame() is the way to go, but it's not the solution. The reason is that, first of all, you don't need to update your game logic as often as your rendering, and second of all, you want to update your logic with a fixed time step, not with the exact frame time. This improves stability, especially when it comes to physics and ensures that your game always behaves the same. Read at least one of these articles. http://www.koonsolo.com/news/dewitters-gameloop/ http://gafferongames.com/game-physics/fix-your-timestep/ As for OOP in JS (and JS in general), you should read "Profess
  23. If you wrap your HTML5 game with node-webkit, then it's just like any other executable and is a subject to the same piracy issues as any other game. HTML5 games served from a server are a subject to the exact same "you can get this game for free, but it would be neat if you paid us" policy. Most indie games these days don't include any DRM anyway, if somebody wants your game for free, they can get it without any problems, doesn't matter what language or platform you're using. The reason why most browser games are F2P is because they fit into the ideology. Browser games are an instantaneous e
  24. dreta

    To Box2D or not

    Over a month ago i'd vote on Chipmunk-JS as well. The engine was written in C, which means that it translates to JavaScript without all the problems that plague Box2D. The API stays near identical and from the tests i've ran, the performance is quite spectacular, both when it comes to speed and garbage generation. These days however, there's only one physics engine i'd consider using, that is the one that's a part of the Turbulenz engine. You can use the physics engine separately without any problems and the APIs were designed to mirror Box2D's APIs, so the documentation should get you up to
  • Create New...