Now, I've done coding in DM, Visual Basic, and C++ (even though I'm still somewhat of a newb in C++), yet after all this time I still couldn't figure out why when you play a graphical 2D game in BYOND, it seems unresponsive and it only goes like 10-30 frames per second. Now if it's made in C++ and the highest it would go is icons, you'd think the speed would be somewhat faster. Can anyone answer this for me? I hope i'm not posting this in the wrong part of the forums, but it's been so long since i've ever used this.
Thank you for your time.
ID:134785
 Sep 14 2005, 4:02 pm
|
|
BitBit, I never heard of that, and I have good memories of using DOS and Windows 3.11. I'm curious though, what if Dream Seeker was Peer-2-Peer (if it isn't already)? As you can see I have no experience with network code.
| |
BYOND's graphical speed is limited to 10 frames per second. It's a design decision made by Dan/Tom.
The reason BYOND games might feel sluggish is twofold. First, there might be network lag like in any other game. Second, BYOND allows for an increadibly vast number of different games, different things that can happen inside a game, etc. Games programming from scratch in C++ know what's going to happen. For example, in a FPS, the client knows that when you press the up arrow, you move forward, and can redraw the screen before even telling the server that the up arrow was pressed. Dream Seeker doesn't know any of this - it can't. Dream Seeker can't predict what's going to happen, since BYOND games are so different. Instead it waits for the server (Dream Daemon) to tell what to do, so network lag is more apparent in BYOND games than in others. However, a low-latency network connection to a fast server helps this a lot. Also, BYOND handles keypresses by queuing them up. This can sometimes cause a game to feel sluggish. One of the reasons for doing this is that in high latency situations (a server is overloaded, has a slow internet connection, or something) a queue of keypresses works much better. Say for example, there's a really bad lag situation and it takes two seconds to update the screen. With a queue, one could press down five times, and right three times, and then end up where they wanted to go in 2 seconds. Without one, a player would only be able to move about 1 space every 2 seconds, in that really bad lag situation. | |
In addition to what I'm sure the others have said, BYOND executables aren't read as pure byte code, like a program you would create in C++. It's something called virtual byte code. You can look it up on the net, if you want, or I think that the DM Guide has a little bit of info on the topic in an Appendix. I don't feel like going into much detail.
Another reason is the many, many built-in variables that everything has, that more often than not, you won't use in your project. These were all included with the intention that BYOND would provide an easier platform for which to create games, with as many accessible variables as deemed necessary to be able to mold into your "net dream." Some variables you may/may not use could include: - desc - see_invisible - infra_luminosity - luminosity - mouse_---_pointer - etc. Because in a C++ program, you generally create only variables that you have intent on using, less RAM must be used. BYOND wasn't created to be the "quickest" language. It was designed to be free a resource for anybody to be able to come in and make the game of their dreams. And more often than not, those people have little-to-no previous programming background. This validates the argument to include so many built-in vars that can shape one's "net dream." Hiead | |
The things you've mentioned aren't usually a problem, and don't usually contribute to a sluggish feeling while playing a game. Very few games use significant amounts of CPU. The only one I know of is SS13, which uses near 100% of CPU due to its air system. It does a lot of CPU-intensive loops.
| |
I noticed you didn't mention the byte code part. :)
Anyways, in an online game, where you're constantly exchanging this data with a "host" who must distribute it to the other players, I'm sure that the extra data can acount for some of the lag. Can't talk more, I gotta get to school! Hiead | |
You can decrease world.tick_lag to speed your game up, but it is optimized for performing at 0.1 seconds per tick.
The reason BYOND games tend to be slower is because the server is responsible for all processing. In large scale online games, the client handles all player input and display, only communicating the important interactions to the server to be interpretted and validated. Let me give you an example. In my Darke Dungeon game when a fireball goes off, The server sends out several individual missile() messages to draw a ring of fire exploding from the center. A client specifically designed for DD would only require a single command to call the client's DisplayExplosion(icon, center, radius) proc. It games like my raytracing demo it's even more apparent how much a complex display system handled server side can bog things down. The demo runs pretty smoothly for a single player, but when you get a few friends in there it slows down tremendously. If the drawing was handled client-side, then everyone would be viewing things at the speed it runs in single player. Each client could handle it's own display and the server would only have to worry about things like whose bullet hit who. | |
Shadowdarke wrote:
If the drawing was handled client-side, then everyone would be viewing things at the speed it runs in single player. Each client could handle it's own display and the server would only have to worry about things like whose bullet hit who. I know most PC multiplayer games do this, but why doesn't BYOND do it? Is it that hard to implement? | |
I did it on BYOND, but there's a problem with network connections that gives it latency. Perhaps things will be better in BYOND 4.
| |
Here's a good little read on BitBLT the rendering byond uses. (I'll agree byond needs a major upgade there, OpenGL so linux can get it's full.)
http://en.wikipedia.org/wiki/BitBLT | |
Justin Knight wrote:
I know most PC multiplayer games do this, but why doesn't BYOND do it? Is it that hard to implement? BYOND programming is (in part) so easy because you only have to program from the server's perspective, and the client "just works". BYOND currently has no client-side processing. It could certainly be implemented, but it would require quite a bit of modification - most of BYOND's code assumes that everything is done server-side. | |
Just a question Crispy, were you referring to client-side game processing, or graphics processing? I was mainly talking about graphics processing, because I knew that game processing would require a big revamp. They both tie in though.. you obviously cant be moving around graphically without some code being executed.
| |
Jon88 wrote:
BYOND's graphical speed is limited to 10 frames per second. It's a design decision made by Dan/Tom. Any particular reason as to why they chose this? | |
Crispy wrote:
Game processing. Graphics are already processed client-side. Isn't the current graphics processing inefficent though? | |
Justin Knight wrote:
Isn't the current graphics processing inefficent though? Yes, it is. But there are other things higher up in the to-do list, though from the optimistic things I've read, Tom is working on the graphics department of BYOND. Hiead | |
I believe BYOND needs a serious upgrade in this department, but it would require a lot of rewriting in BYOND's source i belive.