Problem description: Adding a screen mask to the game makes it really laggy. Especially when moving around other images. I'd like to know if it's something I'm doing and how can I make it work.
Code:
for(var/obj/effect/screenMask/L in specialEffectsDump) | |
|
Aug 8 2015, 11:26 pm
|
|
Lummox JR
  |
A screen mask of the type you're using is not one icon, but many. For each tile of screen_loc space (e.g., your image looks like 25x15) an icon is being drawn.
|
Out of interest, what exactly is the bottleneck with BYOND code?
If this was coded directly in a more low level language it wouldn't be a lot to ask of a computer to do but when you ask BYOND to do it you're really pushing the limit of the software. Why exactly is that? | |
As I said it's more icons; that's part of it. (IMO the whole HUD drawing system could be much improved, but it's something I haven't really touched on yet.) More icons to show means more icons to sort. At some point I intend to try out something like Timsort to see if I can get it to outperform quicksort for this purpose.
If you did this at a lower level you'd likely be doing a mask over the whole display, which would be trivial compared to trying to sort in hundreds of icons because it'd just be one object compared to, say, 375 of them. | |
IMO the whole HUD drawing system could be much improved, but it's something I haven't really touched on yet. Does this refer to core or webclient? Because I could yarn you for decades my headaches with the UI approach DM uses. I'm still performing key optimizations on UILib and a release is pending, but I think what I've done is sensible. I've unfortunately had to make sacrifices to what I consider elegant because initial player logins taking upwards of 0.14 seconds of self CPU time to create ~100 objects, manage their variables, and keep the majority of the code pertaining to UIElements encapsulated within the UIElements, and use polymorphism as intended is just... It's insane. | |
Thanks that explains a lot.
One more thing though. The thread owner is using animate(). Is that the appropriate method to be using here? I'm assuming that his screen effect objects are just black rectangles. He could just take out the animate statement and change the icon_state to a transparent black square to get the same effect? That's how this effect used to be done before animate() and I don't see how animate() is helping the situation. | |
Man, I responded to the wrong thread. Sorry, Lum.
@OP: I don't understand why you are iterating through a list of special effects like that. Since your special effects aren't using explicit coordinates, you can actually get away with using one per world. var/obj/global_lighting/night_effect = new() I think the reason you are lagging out is because you are looping through a list that's probably pretty big. No actual reason to loop through the list at all. Everybody can use the same object. Your loop is also really poorly set up. if(L) is pointless, the break also indicates that you shouldn't be using a for loop at all. This is largely how I handle my day/night cycle in one of my recent experiments. Works just fine for me and I work at 40fps usually at 31x17 or 15x9 view. If this is still a major issue for you, you might consider using transform scaling instead so that the icon doesn't have to be reblitted for every space on the screen. You can just blit a single scaled up icon at the bottom-left corner and scale it to the biggest viewport available given your game's constraints. | |
Thanks I will try to scale it, if not then I guess I'll have to make an icon the size of the screen. Also the list when this runs only has one object in it, it's definitely not the reason why it lags.
| |
Also I have a question that doesn't have anything to do with this problem but something I just noticed and still relevant to the title:
If you use different icon states(by generating the icon_states from the object in the object tree) for a specific area object, each different icon_state is treated as a separate area entity. Is this the desired result? Ideally I would like for all of them to be treated as one uniformed area. here's what I mean:  Edit explanation: The entire roof is an area object: /area/roof The edge of the roof is /area/roof, just using a different icon_state. As you can see in the image, when you pass through the edge of the roof, only the edge changes instead of all the /area/roof tiles. | |
To clarify I meant DS's method of drawing HUD objects. DS's approach to map building is what I would call "strongly tiled". It loops through each possible x,y on the screen and looks up the turf, area, and turf contents to display there. In a separate routine it looks up HUD objects at each x,y and displays them. (This is one of the reasons screen_loc isn't currently animatable.)
The new DSified webclient takes a radically simpler approach: It goes through all the turfs it knows it should display, all the movables (on map or on screen), updates their icons if need be, then shoves everything into a list to be sorted. | |
No, it was clarifying what I'd said earlier.
I don't actually understand what you're asking about the areas. The image doesn't explain anything. | |
The entire roof is an area object: /area/roof
The edge of the roof is /area/roof, just using a different icon_state. As you can see in the image, when you pass through the edge of the roof, only the edge changes instead of all the /area/roof tiles. My question is, if this is the intended behaviour? Because I figured all the tiles should behave the same. | |
It's intended behavior, Exentriks.
See my rooflib for ways to deal with that problem. | |
Exentriks, you can't have the same area show two different icon_states. An area is simply an atom that can exist at more than one turf; it will look the same on every turf where it appears.
| |
What if you could though?
Dual-icon state classes or TwinAtoms or something! :) | |
What if you could though? Again, what you are looking for can be done in softcode quite easily. Rooflib does exactly what you are trying to do:  | |
You have been really helpful so far along with Lummox, I'm just trying to understand this engine as best as possible so thanks in advance and sorry for any dumb questions.
Here's a new problem: When you walk through an area for the first time, everything seems to load fine and render smoothly but the further you walk away from this area once you start heading back the game begins to lag and the screen starts tearing. Almost as if it was trying to load all the tiles that aren't even in your view. Any ideas what could be causing this? There's no large icons in the view or anything like that. Just basic 32x32 tiles. I tried to take a gif of the problem but it's hard to tell the difference with the gif. | |
Are you using the webclient?
I had major issues with screen tearing and lack of hardware utilization owing to a lack of shaders. I talked to Tom about the webclient's rendering schema being doomed from the beginning because the method that it's designed around just isn't OpenGL-friendly. Unfortunately, I'm not sure he wanted to listen. While I respect the shit out of Tom's patience and persistence, his permanent poker-face and evasion of acknowledgement of criticism made me want to choke him about half the time I interacted with him. Lummox on the other hand, has always been amenable to reason. He's really great at putting down invalid criticism and explaining why he can't do something that's suggested instead of just evading it. Too many texture swaps during renderpasses and a dependence on sorting algorithms that just aren't necessary. Further, BYOND's atomic structure is something that can't be easily turned into something that's going to work well with WebGL. If you are using the webclient, my suggestion is to use a smaller view size. I was one of the biggest proponents of the webclient, but after seeing it in action and reverse engineering no small part of the obfuscated source code, I came to the realization that it just plain was never going to be workable for my needs. The idea of every tile being an object and the way BYOND's icons are structured (no tilesets, no firm layering, the expectation of chaos and standards violation at every tile) is just something that makes the webclient borderline unworkable. Thing is, OpenGL expects material swaps to be minimal, and vertex batching to be as aggressive as possible. You can get away with just jamming unsorted, unbatched polygons into the renderbuffer with material swaps all willy nilly when you are on a reasonably powerful machine, but WebGL is so limited that you have to do much more aggressive batching during drawcalls. The way DM is structured makes this impossible. DM is too flexible to allow for significant optimization of drawcalls. | |
