Antriel

Members
  • Content Count

    232
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Antriel

  1. I skimmed through it and yes, what's there makes sense. But it talks about websites, games are different. By sending a request you activate the radio for some period of time, which doesn't really matter if you are already using it and loading other stuff. With websites, sure, if you weren't using the radio, this extra request could drain battery a bit. This is still not much compared to what CPU/GPU and display takes thought (or at least I believe so, I'm no expert). Also these days most people have countless stuff on background loading things anyway.
  2. It does affect speed of course. You need to send request and wait for response. But it has very little to do with battery.
  3. I don't think this is true. Firstly why would a 'call' be bad for battery? Actual transition sure, but that's also negligible to what CPU/GPU and display is eating up. Secondly, you can't "keepalive" the same connection if you are loading stuff through http, that's just not how it works, http sends request for each and every item. Also even if you kept connection alive, you still need to do some kind of request, all you would save is TCP handshake which is iirc 1 small packet sent, 2 received - negligible.
  4. You can also download background music only after game is loaded and running.
  5. Right, well since I know very little javascript I can't judge that, but I could read the haxe output just fine. Of course it wasn't pretty but I could find my way around pretty easily. You can quickly test it here http://try.haxe.org/.
  6. Not sure what exactly means readable javascript, but it's not like you can't read what Haxe outputs.
  7. I personally didn't like createJS too much. It tries to mimic flash API (quite successfully tbh), but there were some weird bugs and things I didnt like as no AABB hittests. Now I'm trying Flambe and so far it looks better for a dev like me who doesn't want to hassle around with lower level stuff. From what I said above, it's apparent I would choose Haxe. Especially if you don't have much experience with javascript. My first project was Haxe + createjs and I didn't have any problems with that.
  8. I didnt read all of what you wrote, just want to say that even though TCP isnt the best, it can still be used for real time games. If I remeber correctly even some older mmorpgs like Lineage 2 used purely TCP.
  9. You can of course run your simulation with smaller timestep You can have 30 fps game with 200 Hz physics. Every person is different but for example I see difference between lamp connected to 50Hz and ones using special hardware to go at higher rates. I can even see difference between 50 fps and 100 fps on my monitor in certain situations. Eyes do not have pooling frequency but higher frame rate is a good thing. That said, with web games I wouldn't bother, unless it's webgl.
  10. I told them the same thing but apparently they know nothing and keep telling us it's our problem. I cannot imagine how they don't have this solved by now.
  11. I agree with all that except that Nagle's isn't the only real issue. Dropped packets are still a real issue even if they can be solved by extrapolation like Ezalia suggested, but it won't be as good as using UDP in the first place. So again, I'm not saying TCP is unusable (iirc even big mmo like Lineage 2 used TCP), just that it's not suited for real-time games.
  12. I respectfully disagree. TCP has more problems for real-time things than just Nagle's. For example a dropped packet can mean waiting for useless data for a long time. Not to talk about actual packet size and how fast those packets go through routers. I'm not saying that it can't be done though. Just that Nagle's isn't all there is to it.
  13. Yeah I'm also coming from flash. What I did is create a small preloader.js that loads all my assets and after that's done it loads my game.js. I suspect my game.js will be around half a megabyte even after minimizing so it just made sense not to include it into data that needs to be loaded before preloader shows. My preloader looks similar to what Rich posted, except I generate most of it via macro where I also process some other data.
  14. Would it be a big problem if I divide my code into say preloader.js and game.js? If game code is too big I don't really want players looking at empty screen for half a minute. Although I read in Rich's article that publishers want 1 file. Any reason behind it?
  15. Antriel

    What to do?

    I beg to differ, I cannot draw. Not saying it's impossible to learn, but as of now I simply can't draw even stickman
  16. So you are registering all the entities that some system wants as they are added? Traditional ES have much more functional approach where each update they query all the entities for the right ones. I didn't like this approach and used something similar to what you do... it has its problems but works quite well as long as I take care to keep it clean.