Forum_account's Site - Use DirectX quads instead of sprites

#1 Nov 14 2011, 12:37 pm

To be clear, we have never observed display problems with sprites that I'm aware of; any problems sprites have in this area would be shared by quads. We have, however, observed questionable texturing behavior in early trials (IIRC) that required hacky workarounds. One such hacky workaround was to alter the red/green/blue values of completely transparent pixels to match their surroundings, because the texturing engines of some GPUs did overly simplistic averaging. (The only way to correctly calculate an average rgba is to use the alpha as a weight. This is actually an area I think some parts of our own code could improve on.) Seams along tile boundaries were also common in early trials.

I don't know how far the technology has advanced to where any of this is moot or easier to overcome. The early graphical work was done by Shadowdarke, and my interaction with the code since has largely been in the form of reorganization and restructuring how icons are loaded.

#2 Nov 14 2011, 12:49 pm

Forum_account

The problem I was referring to is sluggish performance. The result of the rendering process is correct, I just have a feeling that a DirectX demo that draws 1000 textured quads on the screen will blow DS out of the water for drawing the same amount of objects.

It doesn't sound like any of those hacky workarounds would really hurt performance. If you release a build where DS uses quads and people find performance to be the same as using sprites, you can stick with sprites. If people find that quads perform significantly better, you can then worry about seams and those other issues.

#3 Nov 14 2011, 1:02 pm

Lummox JR

The problem with hacky workarounds is they have had a nasty impact on all sorts of code. But in particular the seam issue I don't think was something Shadowdarke ever figured out how to fully resolve.

I don't know enough to look into this myself, but the bottom line is this: For quads to be a viable alternative, we need the following: 1) We need them to handle orthographic projection. 2) We need them to use an arbitrary number of layers, and to look the same from frame to frame when that number changes and quads move forward or back; i.e. no visual cues that their Z position has changed. 3) We need to be able to draw some quads clipped to the map area, some clipped outside the map. (Right now we actually just don't clip anything outside the map, clear the map area, and redraw that with clipping.) 4) There must be no screwy rounding issues (or, there must be a viable alternative in the way we preload the texture). 5) There must be no visible seams, even accounting for the fact that the quads will not be lining up at the same Z level; they must appear as if they do. As I recall seams appeared intermittently in different kinds of tests.

No-seams ought to be achievable by some means, and if it isn't then it's a complete deal-killer. (That would obviously be harder to do if the view was rotated by an angle not a multiple of 90°, but that's not even on the table.)

#4 Nov 14 2011, 1:17 pm

Forum_account

I can understand not wanting to deal with hacky workarounds but you don't know how detrimental using sprites might be. The first step in switching to quads is to first figure out if it's even worthwhile.

Lummox JR wrote:

For quads to be a viable alternative, we need the following...

Just assume all that stuff is possible and make a demo using quads to see if the performance is any better. If you discover this is an opportunity to get a huge performance boost, *then* you can worry about those other things.

I don't know enough to look into this myself

Don't know enough to get a basic implementation that uses quads? Or don't know enough to figure out solutions to the numbered list of problems?

#5 Nov 14 2011, 1:23 pm
Lummox JR	Forum_account wrote: Don't know enough to get a basic implementation that uses quads? Or don't know enough to figure out solutions to the numbered list of problems? Either. I haven't done much work in DirectX at all. As I said, most of the graphics code was implemented by Shadowdarke and I've only done tweaking since.

#6 Nov 14 2011, 1:45 pm
Forum_account	It's never too late to add a DirectX book to your Christmas list!

#7 Dec 2 2011, 4:02 pm

Tom

Actually Shadowdarke's work was all in the OpenGL port that we moved from due to its own limitations (I have obsoleted all remaining OpenGL support as of 494, not that anyone uses it). I wrote the DX code. If we were to seriously pursue this, we'd first want to do some benchmarks to see if there is in fact a performance issue, by taking our wrapper in a standalone project and seeing if it suffers at 50fps or whatever (since no BYOND game is going to go above that). And I don't think it does. I think this is really a non-issue and 99% of the "lag" people experience is do to inefficiencies in the VM, the DM coding, or both.

#8 Dec 2 2011, 4:38 pm
Falacy	Tom wrote: by taking our wrapper in a standalone project and seeing if it suffers at 50fps or whatever (since no BYOND game is going to go above that). You mean 60?

#9 Dec 2 2011, 5:17 pm
Tom	Well, I don't know what the standard is but I'd imagine 50 or 60 fps is pretty fast. I'd also be shocked if our sprite system couldn't push that. Now the server being able to maintain that pace is another issue altogether. Have you experienced client-side performance issues at higher framerates? I know your games get a lot of users.

#10 Dec 2 2011, 5:25 pm

Falacy

Dot Shot runs at 60 FPS, hundreds of dots seem to update their positions just fine, even over a network. It uses almost no CPU. Monster Kingdom, on the other hand, only runs at 30 FPS, but seems to have some serious CPU issues, even when idle (Uses ~2% per player?). Monster Kingdom has a lot more graphical flair. Battles are handled entirely in client.screen, and seem to lag the worst over a network. Next update, I'm turning it up to 60 FPS and increasing the update speed of certain systems to see if they run any smoother. Movement runs pretty smoothly over a network, and the entire game runs flawlessly when played locally in DS.

#11 Dec 2 2011, 5:30 pm
Tom	So if you are hitting 60fps with a decent number of objects in DS, I don't think we really have a rendering issue (of course this may be machine-dependent). Client.screen improvements seem to be a better area of focus as I've heard a number of complaints that HUDs are slower than images when used for the same purpose, and that shouldn't be the case.

#12 Dec 2 2011, 5:39 pm (Edited on Dec 2 2011, 5:49 pm)

Falacy

Tom wrote:

So if you are hitting 60fps with a decent number of objects in DS, I don't think we really have a rendering issue (of course this may be machine-dependent).

I have had complaints about Monster Kingdom running slowly for certain people locally. Which is why I changed it from 60 to 30 FPS in the first place (which seemed to fix, or at least improve the issue for them). However, I think that may only be an issue for the host, and since there is an official server on a good machine now, it shouldn't be an issue. One of the people that was complaining about movement being slow when they hosted has commented the opposite when playing on the server.

> Client.screen improvements seem to be a better area of focus as I've heard a number of complaints that HUDs are slower than images when used for the same purpose, and that shouldn't be the case.
I haven't used images for anything in this game yet, though I do plan on having client sided objects at some point. I would say that client.screen objects don't update as fast as mapped objects do. Monsters transition into battle in a smooth slide across the screen in single-player, but when connected to the server, the movement is extremely jumpy, and sometimes just completely skips from point A to B.

Initially, I had a system that would use Scale() to dynamically create the width of health bars. This worked seamlessly in single-player. However, on the server, the bar would just completely disappear while resizing every tick or so. I pre-"rendered" the 100 or so bar widths that were necessary, and just update the icon_states now, this is better, but has the same inconsistent update speed that I mentioned above with in-battle Monster "movement".

There are also some serious issues with transparent graphics. It seems that the more transparent colors needed, the worse the FPS gets. This is understandable and acceptable to an extent, but the current issues can almost pause a game. This seems to be on a per client/machine basis, and be completely disconnected from the server.

#13 Dec 2 2011, 5:47 pm
Tom	Ok. The transparency is def. something client-sided; hopefully it's not too platform dependent. We can test that out with your DotShot game to see how it varies (it would help if you could give us benchmarks on opaque vs transparent object performance yourself). We'll look into the screen stuff. I think that can be improved a lot.

#14 Dec 2 2011, 6:00 pm
Tom	Can you provide me the demos (and/or instructions) to test that on my own?

#15 Dec 2 2011, 6:15 pm (Edited on Dec 3 2011, 10:06 am)
Falacy	Nope, I take that back. It seems to slow down after ~20 seconds either way (not sure why). I can't seem to get a simple, reliable test case for the transparency issue. Which is why I haven't filed a bug report about it.

#16 Dec 2 2011, 6:21 pm
Tom	That's kind of interesting on its own. I'll try playing with it and seeing if I get the same results.

#17 Dec 2 2011, 6:29 pm (Edited on Dec 2 2011, 6:46 pm)

Falacy

http://www.angelfire.com/hero/straygames/ByondBugs/ DotShotTest.zip
If you press F3 in that, it will spawn an extra 400 enemies. If you wait 30 seconds or so, the lag should start up, it seems to drop from 60FPS to 20FPS and then stay around 20. If you move, you can kill yourself by bumping an enemy, which will clear them all. Even after they're all gone, it seems to stay slow for a while. You can also just sit in the middle and hold Space to spam kill and spawn however many enemies. 200 enemies doesn't seem to cause any problems, lag starts up around 290 for me.

I'm using Fraps for frame rate display. world.cpu is displayed in the bottom right of the screen (System Stress) and updates every tick.

#18 Dec 2 2011, 6:44 pm
Tom	ok, I'll try it out this weekend. I'd think that once the icons were all loaded the first time, it'd have a consistent frame rate so something funny must be going on.

#19 Dec 2 2011, 6:46 pm
Falacy	Well, they are all moving.