Stop Being Afraid of Lag

Page: 1 2 3 4 5 6 7
Aug 15 2012, 3:51 pm
In response to Tobba
Tobba wrote:
Forum_accounts lighting library causes BYOND to flip out if you're moving too fast due to all the extra objects, even if playing locally

If it flickers or anything when you're doing this locally, that means it's a CPU bottleneck; the result would have been no different if there had been client side processing or not.

Again, lighting is something that should be done on the client, doing it on the server is limiting, slow and makes me puke
Sadly this is currently not possible

Even though this is true, BYOND's performance is good enough to run with lighting being computed by the server.

You can actually get an effect like Forum_accounts lighting library using overlays on turfs instead, but it breaks the entire game because you cant set mouse_opacity on overlays, so unless you set mouse_opacity on every tile and compensate for that it will block clicking on anything

Oh. I wasn't aware Forum_account used /obj to display his shadows.
My system uses /area, so it doesn't affect turf opacity or anything.
Aug 15 2012, 3:53 pm
In response to D4RK3 54B3R
D4RK3 54B3R wrote:
Tobba wrote:
Forum_accounts lighting library causes BYOND to flip out if you're moving too fast due to all the extra objects, even if playing locally

Again, lighting is something that should be done on the client, doing it on the server is limiting, slow and makes me puke
Sadly this is currently not possible

You can actually get an effect like Forum_accounts lighting library using overlays on turfs instead, but it breaks the entire game because you cant set mouse_opacity on overlays, so unless you set mouse_opacity on every tile and compensate for that it will block clicking on anything

Oh. I wasn't aware forum_account used /obj to display his shadows.
My system uses /area, so it doesn't affect turf opacity or anything.

Which is why you two should chat and formulate a smooth and powerful softcoded lighting system.
Aug 15 2012, 3:57 pm
In response to D4RK3 54B3R
It creates a layer of /shading objs to cover the map when you call lighting.init(). They're not overlays, Toddab was bringing up another option. Hazordhu at one point used turf overlays for lighting, and that caused plenty of problems with clicking. In the end, GPU (or lack thereof?) lag actually turned some players off to it.
Aug 15 2012, 3:59 pm
mouse_opacity=0
Aug 15 2012, 4:02 pm
In response to Bravo1
With Hazordhu, some turfs actually had click interactions. That's beside the point, though.
Aug 15 2012, 4:07 pm
Here...

shading_stuff_that_is_layered_above_everything_else
   mouse_opacity=0
Aug 15 2012, 4:09 pm
In response to Bravo1
Yes, Forum_account's library, as well as every other library that uses objects (/areas, /shading objs, etc.) layered above everything else, uses mouse_opacity=0. It doesn't play nice, though, when the shading stuff is an overlay placed on a turf.
Aug 15 2012, 4:30 pm
Did you try mouse_opacity=2 for the turf?
Aug 15 2012, 4:42 pm
In response to Bravo1
That would make the turf cover up everything that is also clickable. Can we get back on topic? This isn't a lighting system discussion, and you're not even hitting "Reply" to internally link our conversation together (in case they feel like implementing my collapse/expand feature).
Aug 15 2012, 4:46 pm
In response to Bravo1
Forum_account mentioned that the most popular 2D games can't be properly recreated with BYOND. I want to know, what kind of popular game is BYOND even capable of making? Just building games and NES-style RPGs? I wonder if anyone realizes; if BYOND were to implement Forum_account's 3D idea (not 3D models, but simple boxes with icons slapped on the faces), even a Minecraft clone without mouse-look or dynamic lighting made with BYOND would not be hard to make at all.

Tom mentioned that you could probably recreate FarmVille and be as popular on Facebook when the Flash port comes. FarmVille's client-sided, though.
Aug 15 2012, 5:10 pm
In response to Kaiochao
Kaiochao wrote:
That would make the turf cover up everything that is also clickable. Can we get back on topic? This isn't a lighting system discussion, and you're not even hitting "Reply" to internally link our conversation together (in case they feel like implementing my collapse/expand feature).

I broke the rules. Call he internet police, for I dun goofed.

It would only make everything unclickable if you made the mistake of throwing an overlay onto a turf with a higher layer than a mob, essentially trapping the mobs and objs in a turf layer sandwhich. I can see now why you stopped using that >_>

I'm making a Metroidvania style game right now. So far it's moving along VERY well. So, there's not a lot of popular 2d games that can't be remade in Byond, there just aren't enough users with the drive to.
Aug 15 2012, 11:51 pm
haha Forum_account isn't talking about encryption here.

I'm not talking about encryption. If the server wants to tell the client "this mob moved to this location and its icon_state changed", what does the message that's sent from the server to the client look like?
When he said encoding I thought about encryption because this part is extremely trivial.
Just gotta define packet's ID, send along mob's ID and new location (coordinates or turf's ID).
Changing icon_state is identical, just different packet ID, but instead of location gotta send new icon_state.

It's actually not as simple as you make it. This data generally only comes in once every 0.1 to 0.3 seconds, depending on your server and such and such.
Data is sent much faster than that. TCP definitely delays it, but it's way less than 0.3 second, most likely less than 0.1 as well, it just waits for more data to build bigger packet, if it's big enough it'll be sent right away.

you need to be able to resolve de-synchronization between client and server
TCP won't have any desynchronization, all data comes in order and it's comes all the time. The only desynch that can happen is lag, but nothing can be done about it.

You also have to keep track of flicked animations.
That does add extra troubles, but in the end it's not too hard. Just gotta define own rules what happens when you flick several different animations at once and problem solves itself: use vector to store animation that need to be flicked, or simple boolean whether anything is being flicked.



P.S. Forum_account, please get my name right next time.
Aug 16 2012, 12:42 am
Zaoshi: It seems a wonder that everything is so amazingly trivial. If only the rest of the world knew that.

Its like creating a new programming language - Extremely trivial. All you need to do is provide a language grammar, figure out precedences, how you want the AST to look, and whether you want to compile to assembly or maybe JVM byte-code or what have you. And then do that.

See what I did there? Its the equivalent of going, 'It is trivial to see that X=Y', and then not providing any proof. As it so happens, quite a few of us are experienced software engineers who've done a great deal of these things before in one shape or another. It may do you some measure of good to consider the wisdom of the crowd, and whether you're stepping into something you really don't happen to know a lot about.

Your posts also seem to add absolutely nothing to the discussion at hand, except to try and highlight how others are stupid and you are not. Thats an unfortunate way to approach things, and it'd be great if you'd consider whether thats the way to approach posting here.
Aug 16 2012, 12:53 am
Alathon, it depends on perspective. What I was trying to say in my previous replies seems trivial to me because I've already done all that.

Creating new programming language? Well in my perspective it's hard, but it's because I had to do assembly programming in the university and I know that it's somewhat complicated and limited, also I don't quite imagine how to parse code. But for someone who done it before code parsing might be easy/trivial.

By no means I'm trying to insult anyone, most likely they just haven't tried it. Once you try you'll see it's really easy.

You say I talk without any proof, but what about hundreds of books about programming styles, game development, good practices or just algorithms? There's no proof either, yet you trust that source, but not this.

I could write little code, but I doubt it'll be any proof to you or anyone else, you're just being ignorant because I'm random person on the internet, yet you know nothing about me, I could be a troll, or author of one of those books.
Aug 16 2012, 1:08 am (Edited on Aug 16 2012, 1:13 am)
In response to Zaoshi
Saying that its 'easy' to write protocols, and 'easy' to do animations, and 'easy' to do X and Y, have absolutely no meaning. You're not defining the context within which it is easy. Its basically an empty statement. Those things can be very easy, or they can be really difficult.

That leads me to believe that you don't have much experience doing those things; because more often than not, people trivialize things they don't truly understand.
Aug 16 2012, 1:31 am
Are you saying I should put equal weight into a published, acclaimed book, as I should random forum posts?
No, but so far everyone completely ignored what I said. Similar to what some religious people do: "It's not in the Bible, you're wrong!". Here, on the forums, I'll be wrong even if I copy/paste text from a book, unless I specifically tell that it was from a book.

Basic protocols and animation aren't hard. There's no interpolation/extrapolation to deal with the latency, no frame blending to smooth out animations.

So you want example of code? Sure. Wrote it in notepad so there might be mistakes
/* contains pointer to texture and coords & size of
single icon/state/frame/whatever you want to call it. */
struct Icon {
    Texture *texture;
    uint32 x, y, w, h;
};

/* all icons are contained here, almost constant search time
could be an array as well,
but would have to make sure IDs are in order or at least not too extreme */
unordered_map<uint32 ID, Icon> icons;

struct Frame {
    uint32 iconID;
    float length;
};

struct Animation {
    vector<Frame> frames;

    Icon& GetIconAt(float time) {
        for(auto &frame : frames) {
            if(frame.length >= time)
                return icons[frame.iconID];
            else
                time -= frame.length;
        }
        assert(0); // shouldn't happen, just crash if it does
        return Icon(); // prevents compiler error
    }
};


That should be enough to figure which frame to draw, now just gotta make sure time value that's passed isn't bigger than animation length, but it should be part of other function.
Aug 16 2012, 1:54 am
In response to Zaoshi
Zaoshi wrote:
Here, on the forums, I'll be wrong even if I copy/paste text from a book, unless I specifically tell that it was from a book.

I'm sorry you feel that way. I think the more likely case is, you'll be wrong when you're wrong. I also didn't say you were wrong, I said you were making statements which are vague enough that they mean very little. And had you stated them in a book, as an acclaimed author praised by the whole world, I would've still said the same thing.

Basic protocols and animation aren't hard. There's no interpolation/extrapolation to deal with the latency, no frame blending to smooth out animations.
That should be enough to figure which frame to draw, now just gotta make sure time value that's passed isn't bigger than animation length, but it should be part of other function.

Now you just need textures, dealing with resource-loading in general, a/multiple protocols to manage what the client needs to know about its surroundings, probably some logic dealing with missing updates, socket/connection handling in general, wrappers to make drawing stuff easier in general, dealing with different screen-resolutions, the game loop itself, logic scaling display resolution / update frequency according to what is nice for the client, trapping mouse/keyboard input, customizable keybindings, and about 600 other things. Or maybe you don't need half of that for your game. That'll depend on the game.

Individually, those things might be relatively easy to deal with. BYOND happens to solve quite a lot of them for you. Could you do that on your own? Sure. Would it be easy? Sure, maybe, depends on the game. Does that make 2d game creation 'trivial'? No, not necessarily. A 20-line code snippet functioning as a primitive, half-finished way of looping through numbers, is not 'animations'.
Aug 16 2012, 2:07 am
Now you just need textures
In the code I posted replace Texture with ID3D11Texture2D and you're done (if you're using DirectX).

dealing with resource-loading in general
DirectX SDK provides function to load textures, if I'm not mistaken it's able to load dds, tga, png, bmp, jpg formats. Without SDK gotta load them manually; dds, tga, bmp are easiest choices in that case.
Audio files depend on library you'll be using, library I use only requires to pass pointer to memory location which contains whole file.

A 20-line code snippet functioning as a primitive, half-finished way of looping through numbers, is not 'animations'.
That's all what's required to figure which frame to draw. Of course filling animation with frames will be annoying without a tool and it cannot flick() animations like BYOND, but that's just part of further progress.

I never talked about 2D games in general. Terraria has a lot logic going on to make sure not to run out of memory or overload processor with unnecessary updates, but most BYOND games won't be hard.
Aug 16 2012, 3:44 am
Terraria could be replicated in BYOND if it weren't for the fact that you can't display that many tiles without extreme slowdown from Dreamseeker. Even at somewhere around 15x15 there's noticeable lag. Since each block seems to be it's own entity then you're looking at easily 5-10 times the "tiles" on screen.
Aug 16 2012, 6:33 am
In response to Bravo1
You might be able to replicate it with sub-tiles. That is, give each tile a grid of values that influence collision and appearance. Lighting might be really complicated, and world generation would probably take hours to get a small Terraria world.
Page: 1 2 3 4 5 6 7