Aug 10 2015, 1:56 pm
|
|
Lummox JR
  |
I'm way open to hearing of any ways I might be able to improve rendering performance on the webclient. However since it does use StageXL for rendering, I don't know how much of that is really in my hands. (I suspect it'd be easier to talk with the creator of StageXL about that sort of thing, because he might see ways of making that work.)
|
Well, Lummox, the major problem is the fact that OpenGL works heavily with buffers.
The less often you swap materials, the faster rendering is going to happen. What more than likely needs to happen is that you need to build vbuffers for chunks of the map (The sweet spot is going to be somewhere around 16x16 or 32x32 chunks of the map). Chunks should only use ONE texture, which means you are going to have to construct megatextures for each chunk. Objects that are mobile can get away with not being batched. But it just comes down to the problem that BYOND's mapping format is absurdly flexible to the point that any meaningful optimization just really isn't possible. | |
One thing that I wonder about, then, is if something like StageXL could handle a setup where it's passed a list of sprites, assigns a depth to each one, and then groups them by bitmap. The individual icons drawn in the webclient are subsets of each source bitmap (the raw .png data) which is effectively acting like a series of sprite sheets--one for each main icon.
This does raise the question of whether it'd be feasible to maintain a single mega-sheet, at least for most of the icons drawn; that would itself reduce the amount of material swapping by quite a lot. If for instance all the built-in icons sent from the beginning got combined on the webclient end, that'd be a big change. | |
Well, vertex data is inherently 3D, so layer can be used as a Z-coord. Unfortunately, because BYOND supports partial transparency, you can't take advantage of overdraw optimizations through the Z-buffer, so you need to draw bottom to top, ignoring the z-buffer. Which means a sort by layer.
Animations could be handled by passing a property to a vertex shader, which would allow the shader to calculate the UV offset based on the frame. This would avoid per-frame destruction of vertex data. Sorting by texture pass might well be impossible, so mega-texturing is probably the best-case scenario. Unfortunately, owing to a lack of limitations to unique animation frames per DMI, this can wind up pretty ugly. Also owing to a lack of standardized size, of visual data of appearances, calculating UV data on the shader is almost impossible as well. Then there's the step_x/step_y/pixel_x/pixel_y/pixel_z/transformation problem, because these need to be passed into the shader as properties per-vertex. I dunno. I've looked at these problems pretty heavily, and unfortunately the amount of unregulated standards in the way DM structures its atomic entities... Well, it gives you worst-case solutions more often than not. | |
No I am not, just normal DS- version 508.1289. I've been trying everything I can. Is there something else other than the webclient that has caused a problem like this?
| |
Are you in software mode?
| |
Are you using transparency in your interface skin at all? That can cause byond to go into software mode.
| |
Where would you check this? Right click on the title bar of your game's main window, and select client->Preferences. If hardware mode isn't checked, you are in software mode. | |
@AERProductions, I don't have transparency on any interface skin. I don't even think I have any interface skin, just the map in a window. The game is also running on 60 fps, not sure if that could be the problem.
@Ter The hardware mode is checked. | |
Yeah, 60fps is gonna be a problem with large view sizes.
| |
Don't think of it as a console, Exe. You don't need 60fps!
Pondera is currently running at 11fps and it is perfectly smooth. :) | |
11fps ...What the hell are you doing? | |
Nooo, do you know what would be an optimal size for 60fps? It looks so smooth I'd really like to leave it at 60. The current view size is
world soo : 1152x832 I believe. | |
Noooo, do you know what would be an optimal size for 60fps I've got a couple projects that run 60fps, but even at 20x15 it DEVOURS network bandwidth. There isn't really an ideal. But I can say that 36x26 is absurdly oversized. I've found that you want to keep less than 800 tiles in view at any given time if you plan on having a game that supports more than a handful of players. | |
Well this game is single player so maybe we can push it up a bit?
edit: at 28x25 it seems to be working just fine. I'ma clutter the map and see where that goes. | |
Exentriks Gaming wrote:
Well this game is single player so maybe we can push it up a bit? Absolutely, to an extent. You can always push more out of an offline mode than online (as long as it is ran locally, of course). | |
Any faster FPS and my game runs too quickly. There's very few times that I'll actually completely invalidate someone's opinion on a setting for their game without having seen the logic or justification behind it. This is one of those times. Having an FPS setting of 11 means that your TICK_LAG is 0.90909090909090909090909090909090... There's no possible way that you've set your icon states' animation frames to the correct values with this FPS value, which means that your icon animations are going to frameskip. There are a few reasonable values to set FPS to. Here's why: 10 FPS (looks like hot garbage) 100ms per frame 15 FPS (looks like warm garbage) 66.667ms per frame 20 FPS (looks bad) 50ms per frame 25 FPS (not great) 40ms per frame 30 FPS (looks good) 33.333ms per frame 40 FPS (sweet spot) 25ms per frame 60 FPS (you'd better be a genius) 16.667ms per frame The really great FPS values to work with for proper animation are 20, 25, and 40. The really great looking FPS values are 30, 40, and 60. Nobody in the history of ever anywhere has targeted 11FPS deliberately. Not just because it looks bad, but because it is mathematically retarded to use that setting. | |