I'm finally able to make a working gravity engine with pixel movement. I finally make it so that its nice, clean, and smooth for people to look at and play. I finally see BYOND's full potential, and I'm hit with something I cannot solve without taking away the things that 4.0 came with in the first place!!
Client...pixel...offset. Server side it works perfectly fine; client side, not so much. I don't see the problem, but everyone else does. With a pixel-driven gravity system, the client pixel offset is changed so much that they see it but the host does not. It flickers about 3 tiles on all sides, so all they see is 3 tiles of actual scenery, but the rest is destroyed by a flickering wall of black space. Is this a problem in my own programming, or is this a problem within BYOND itself?
Should that be the case, is pixel based movement and a client pixel offset reserved only for single player games because BYOND can't handle it?
ID:151683
 Aug 23 2009, 4:21 pm
|
|
|
Aug 23 2009, 4:37 pm
|
|
Kaiochao
  |
Yes. It's BYOND.
|
Yes, it does.
It's why I pretty much don't work on any of my pixel projects any more than the day they were made. There's really no point to it, unless I learn moar maths(like the stuff in Hobnob's post with jt_vectors, which I've been using since a few months before that article appeared) and make the next best single-player BYOND game. Darn you, BYOND lag! | |
Kaiochao wrote:
Yes, it does. You could make a pixel based BYOND multiplayer game, but it would have to employ client side processing, which would in turn have to employ server to server communications. It actually isn't as difficult of a concept as people make it out to be. | |
It's more that BYOND isn't designed to handle it. It's too general-purpose to handle the client-side processing that's really required to make smooth networked real-time games.
| |
It's actually possible to make good multiplayer pixel-based games if you do your calculations minimalistically and do them well. For example, IainPeregrine developed two very functional multiplayer games that I actually enjoy a great deal: hub://iainperegrine.plundergnome and hub://iainperegrine.jeetkunedo.
| |
AJX wrote:
You could make a pixel based BYOND multiplayer game, but it would have to employ client side processing, which would in turn have to employ server to server communications. It wouldn't have to do any of these. hub://IainPeregrine.PlunderGnome works perfectly fine without. | |
I just played a round of that with myself(multikeyed) and the screen flicker probably doesn't happen because the screen is stationary. I've experienced a couple problems with changing client pixel offsets before, including the one mentioned above.
But it was still as choppy for the client window as it is for any of my pixel projects when I multikey-join myself. This probably means it'd be even more choppy for other clients out of my local network(as it is for my other pixel projects). This is the main reason I said BYOND can't handle quick-updating pixel-movement systems. Even with tick_lag at its default 1, players experience lag. Lowering tick_lag causes even more noticeable choppiness as players teleport more ticks at a time. | |
Kaiochao wrote:
But it was still as choppy for the client window as it is for any of my pixel projects when I multikey-join myself. This probably means it'd be even more choppy for other clients out of my local network(as it is for my other pixel projects). This is the main reason I said BYOND can't handle quick-updating pixel-movement systems. Back when I had a bit of money to pay for a SliceHost account, I hosted Plunder Gnome 24/7. When I connected to the server I never noticed any choppiness. | |