Dec 13 2011, 9:14 pm
|
|
Tom
 |
There may be more than one bug at play here. The one I think will be easiest to resolve is the difference between software & hardware displays in the remote server test. In my test, at least, that was most dramatic and should be easy to isolate.
|
What kind of ticks is it outputting for you in DS vs DD?
Blast: 10 ticks Blast during HUD Updates: 17 ticks That's in DS for me, with DD it always seems to execute in 10 (as I mentioned earlier). That means the game is running 70% slower when updating HUDs, almost half speed. Anyway, I figure it as the same problem on both ends, so if you can take care of the client sided hardware vs software issue; then this will probably clear up as a whole. | |
I think I made a mistake last time I tested because I'm seeing very different results this time, more consistent with what you're reporting. I'll see what I can find...
| |
Ok, I tweaked this a little bit. I made some marginal improvements but I suspect they aren't really relevant to your reports, since they apply primarily to software-mode.
What I found was that DS was doing some unnecessary updates when screen objects were sent, and this was especially pronounced in software mode. In 493, I was basically not getting visible HUD redraws when running in software mode, and I bit of choppyness in hardware mode. In this 494 build, that seems to be working fine in both modes. When I run on a remote server, speeds look fine and your output is showing 10 ticks in both modes. When I run in client-server mode, I am seeing roughly the same thing you are. The non-HUD "blast" test is outputting ~10-14 ticks while the HUD test consistently is around ~17 ticks. This is most likely server-overhead in generating this stuff; since the client-server isn't multithreaded it's being bogged down by whatever the server is doing. I think we can improve this but it will take more work. The latest 494 build is here: http://www.byond.com/download/build/BETA/494.1122_byond.zip If you could give that a try and let me know if it improves anything (or you can confirm what I saw), that'd be good to know. Keep in mind there's a possibility I screwed something unrelated up because I had to clean up a bunch of code to even follow it. I forgot what a joy this project was. | |
Well, things look a bit smoother on the client at least.
| |
Though that seems to have improved the performance of screen objects for remote clients. It seems to have degraded the general performance of server-clients. Firing multiple blasts while moving around will now report execution times as bad as screen objects in the previous version, when they used to always execute in the proper 10 without HUDs going on.
| |
Though we've pretty much confirmed this already. After releasing HU2 with pixel movement, most of the players seem to have the same issue; Screen objects + hardware mode = game freezing lag. Software mode in general seems to provide a generally smoother experience for me.
| |
Hmm, I don't see how this release could have degraded performance as it was just some fixes to cull out unnecessary calls. Are you able to reliably reproduce that case?
It's strange that hardware-mode would be slower in any case, and of course it's very card-dependent. If software mode is consistently better across the board I'd rather use that (it actually renders better on one of my machines, while about the same on the other). However, I thought there were complaints about its speed in many games. If you can give me an example of something that works well in software mode, but not in hardware mode, that'd help a lot. | |
BTW, if you do further testing, use the latest build: http://www.byond.com/download/build/BETA/494.1123_byond.zip
just so we're on the page here. One thing does occur to me and that is that we switched from DX8 to DX9 for these builds because of a font bug in DX8 and some unrelated maptext stuff I've worked in. You should first conduct tests in software-mode to see if there are any server-side problems with 494 (I can't imagine there would be), and then you can see if the hardware-mode is different. From what I can tell, the only changes should be to software-mode and they should speed things up. | |
Tom wrote:
If you can give me an example of something that works well in software mode, but not in hardware mode, that'd help a lot.The demo that I have already provided here seems to do just that. In said demo with version 484.1123: Software mode (Local DS): Any tests I run report 10 ticks (as they should) Note: In 493, HUD tests would slow the processing down in software mode. Hardward mode (Local DS): Single blast: 10 ticks, sometimes 11 Spamming blasts: This seems to get slower the more blasts there are, up to 17 ticks Single blast while moving: 16-17 ticks HUD + Blast: 16-17 ticks Note: In 493, blasts alone don't effect performance, and both hardware and software mode seemed to provide similar execution times (only experiencing a drop in performance when HUDs were updating). This is why I mention the general degradation of performance in hardware mode here. However, there does seem to be an animation slowdown (frames playing for like 10x longer than they should) in software mode, or at least there was in 493. I'm not sure if I've necessarily noticed it in 494, but it could be reliant on overall system stress or something, and I haven't been heavily using 494, nor have I been specifically testing for it in any case. | |
We getting a release for this fix anytime soon? Been several months...
| |
Coming late to the party after looking around the forums for this, but I've got something I'd like to say in reference to this.
When it comes to BYOND, the only things that I note that need a huge overhaul are: multicore capability (which seems a distant dream) and the way the screen is displayed. Leaving OpenGL and heading toward DirectX for displays would give a massive boost in the capability of BYOND. I can see why it's difficult work, but it's best to work hard and get something nice than to let what you currently have sit and stagnate. Some of the best game ideas out there use features that BYOND is just slightly out of reach of, with pixel movement being one of the bigger features that was resolved, I personally believe that getting a more capable display system is the next big step BYOND could take. I've had some amazing game ideas that just simply can't be done with BYOND, even though at first glance it seems entirely possible. Once again, sorry for dragging up an old thread but this one really means something to me and I personally would very much like to see this change come to pass. The addition of pixel movement made BYOND leap in capability, and this would too. | |
They pulled off support of the OpenGL implementation back in 2009 I think, having instead adopted DirectX, and then finally killed OpenGL in 2011. The topic mostly concerns how the drawing is being done and the drawing strategy.
What would be useful, would be to identify what kind of non-BYOND games you're trying to create the effect of, and analyse what BYOND's currently doing for that and understand the bottleneck. The assessment seems to be it's probably not the client draw that's the bottleneck. One question I do have though for the developers, is what is the composition of APIs at work here? I know there's some GDI/GDI+ kicking about for much of the rest of a BYOND skin, but how is the map control handled? Is it also GDI+ (transparency in GDI+ is a bit weird, so I'd assume not) or something like Direct2D/DirectX 2D API? And what versions? How is that integrated into the window as a whole? | |
Examples of things that BYOND should be capable of currently, but for some reason isn't: Fast icon/image rotation, Anti-aliasing (multiple options), map/camera rotation, proper lighting, etc.
Basically, anything DirectX handles on a regular basis. I understand if I'm asking a lot, but I'd at least like to see a "We're working on that" instead of just (seemingly) nothing happening. I mean, I saw a demo of a game where you're in a ship and the world rotates around the ship when you turn. Why isn't that possible in BYOND? So far the best we have it to turn client.dir and it's not very good. Lighting is a big thing that should be built in as well. There's not a single library out there that gives a reasonable lighting solution if you want something that isn't tiled. I just don't understand why these things aren't being addressed, or at least, why no one is saying much about addressing them. | |
Like i've read somewhere. Instead of porting old stuff to 3D (I've also read that lot of BYOND Source Code seems to be disorgnaized) this could move as a separate project. Using modern techniques. (It would be cleaner.)
I think that all of the improvements that have been said on this thread could increase a lot game development and the come of awesome games. (Even more memberships!) We know this isn't easy, like Bravo1 said we'd like a "We're working on that". | |
Its unfortunate, because this is beaten to death with no solution. It is true that they are focused in other directions, not so much graphics. One thing that would be nice would be a detachment from graphics, allowing people to write "front-ends" on their own, and use byond for all the back end. This will start to become "something" when the flash client is released. Because then we'll have some sort of "protocol" to mess around with (maybe not right away).
I think the short answer is, you're not going to see a new graphic API overhaul for the client, they're done with graphics. We can only hope for a detachment of the protocol of DM in the future, so we can just write our own front end. | |
That would be lovely, as we could use pre-made APIs depending on what we need, instead ot the general purpose API that BYOND comes with. I'm all for a detachment of the current system.
| |