• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
blueshogun96

Large textures are really slow...

39 posts in this topic

Alpha testing on mobile devices is generally slower, and should be avoided.  This is what I've read many times while googling iOS optimizations.  Second, I'm using OpenGL ES 2.0, and it doesn't appear that GL_ALPHA_TEST is supported.  Gives me an error when I try to enable it because it's not defined.

Alpha test interferes quite badly with early depth testing on typical hardware - however, you do not need nor benefit from early depth testing anyway (as far as i can see from the picture posted).

Alpha testing, the ancient silly way ("enable(GL_ALPHA_TEST)"), is deprecated (ie. not to be confused with not supported) - it should be done in shader directly (ie. "discard").

It cuts down bandwidth from areas that are hard or impossible to efficiently reach with the geometry approximations - in short, it might be worth experimenting with (although "discard" might be slightly costly [with no depth test] on amazingly-badly-engineered-garbage-hardware ... to be fair, i do not know if mobile devices do qualify for that title or not. So, might be of no use to you, but i thought i clarify the alpha test anyway).
0

Share this post


Link to post
Share on other sites


It cuts down bandwidth from areas that are hard or impossible to efficiently reach with the geometry approximations - in short, it might be worth experimenting with (although "discard" might be slightly costly [with no depth test] on amazingly-badly-engineered-garbage-hardware ... to be fair, i do not know if mobile devices do qualify for that title or not. So, might be of no use to you, but i thought i clarify the alpha test anyway).

 

Discard is indeed a bit expensive on a lot of mobile hardware, but to be fair, you have to cut some corners when you have just about a square inch and a few watts to work with!

0

Share this post


Link to post
Share on other sites

Thread is kind of long for a simple problem. I will leave with this though:

 

 

First you would also need to modify your blending function, and make sure your framebuffer is RGBA.

No.......   If you are blending any 2 images. As you pointed out SRC, and inverse of source.
Green Texture in Framebuffer,  I apply a red sprite on top with .2 alpha,        (0,1,0)*(1.0-.2)    + (1,0,0)*(.2) = (.2, .8,0)

Ok throw the red spirte in the framebuffer and blend the green like the OP is doing:
Red sprite in Framebuffer, I apply the green overlay with .8 alpha over it,     (1,0,0)*(1.0-.8)  +  (0,1,0)*(.8) = (.2,.8,0)

Definitely worth a try. When there are several different sprites drawn at the same location, you may get unintended results, depends on what they look like, and depends on how many sprites you really have layered.

0

Share this post


Link to post
Share on other sites

Sure, but how would the sprite know what alpha to use?

 

That level is defined in the alpha channel of the overlay. If the sprite moves (which sprites usually do), it would need to use another alpha if you want to draw it on top and get the same result as if you drew it below.

 

So you need to use destination alpha instead of source, and can't have an alpha channel in the sprite too.

Edited by Olof Hedman
0

Share this post


Link to post
Share on other sites

Discard is indeed a bit expensive on a lot of mobile hardware, but to be fair, you have to cut some corners when you have just about a square inch and a few watts to work with!

 

 

I did a bit or reading about how mobile devices do things, but did not get any smarter in regards to their "discard" - every time they told that discard can be detrimental to performance they did so in regards to hidden-surface-removal/early-depth testing (which is the obvious disaster-case regardless of hardware - and likely to hit tiny-die devices especially hard).

 

Which keep the question open - does it degrade performance if no depth testing is used? I can not think of any reason why it should/could.

0

Share this post


Link to post
Share on other sites


Which keep the question open - does it degrade performance if no depth testing is used?

Degrade performance as compared to what, exactly? I see a few alternatives to discard: (a) not drawing the pixels in the first place via geometry changes, (b) blending the pixels with zero alpha, (c) rejecting the pixels with the stencil buffer, or (d) rejecting the pixels with the depth test.

 

Option (a) is pretty much always going to win on mobile hardware, followed closely by (d) and then (c). Option (b) is likely to be worse than discard, but I wouldn't expect significant gains.

0

Share this post


Link to post
Share on other sites

Reread OP:

 

"One of my main game features (visually) is the overlay texture I'm using.  This overlay texture is full screen, and covers the entire screen which gives it a nice transparent pattern."

 

And the post following it:
 

"http://shogun3d.net/images2/looptil/04.jpg"

 

Depth test is absolutely useless there - as i mentioned in my original post. I take you did not read any of it.

-1

Share this post


Link to post
Share on other sites

Alpha testing, the ancient silly way ("enable(GL_ALPHA_TEST)"), is deprecated (ie. not to be confused with not supported) - it should be done in shader directly (ie. "discard").

It cuts down bandwidth from areas that are hard or impossible to efficiently reach with the geometry approximations - in short, it might be worth experimenting with (although "discard" might be slightly costly [with no depth test] on amazingly-badly-engineered-garbage-hardware ... to be fair, i do not know if mobile devices do qualify for that title or not. So, might be of no use to you, but i thought i clarify the alpha test anyway).

discard is actually destructive on nearly all current mobile chips and should be avoided at all costs, especially if you are targetting mobile devices that are a few years old. There is always a better way (performance-wise) even if some are slight asset hacks. Also null blends are vastly cheaper than using discard at least on PVR chips.

Edited by joew
2

Share this post


Link to post
Share on other sites


Depth test is absolutely useless there - as i mentioned in my original post. I take you did not read any of it.

You are missing the point of my post: there are many methods to reject pixels, and there is no magic bullet.

 

Asking whether discard degrades performance is a subjective question. What are we comparing it to? The performance of not discarding pixels? The performance of using another pixel rejection path?

0

Share this post


Link to post
Share on other sites
On PowerVR chips simply using discard even once in a single shader will disable a lot of optimizations hence the larger than normal performance hit. For devices using PVR you want to optimize your geometry as much as possible avoiding overdraw, and at the same time remember that alpha blend is nearly free due to the way the TBDR renders, whereas rejection using discard or depth testing is costly.
1

Share this post


Link to post
Share on other sites

Gamedev forum software broke again - cannot use any formatting.

 

--------------------------

joew: "discard is actually destructive on nearly all current mobile chips and should be avoided at all costs, especially if you are targetting mobile devices that are a few years old. There is always a better way (performance-wise) even if some are slight asset hacks. Also null blends are vastly cheaper than using discard at least on PVR chips."

 

Thanks for actually addressing the question. Just to clarify, did you mean that "null blends are vastly cheaper than using discard when depth (and stencil) testing is disabled"? As thous would obviously be hurt quite badly by discard.

 

swiftcoder: "You are missing the point of my post: there are many methods to reject pixels, and there is no magic bullet.

Asking whether discard degrades performance is a subjective question. What are we comparing it to? The performance of not discarding pixels? The performance of using another pixel rejection path?"

 

If you would have read my relevant post then you would have known exactly what the question was meant to compare - and hence know that you do not HAVE a point. _Not relevant to the question anyway_.

 

To recap for your benefit (post #26 onwards): "It might be worth using discard after doing everything else (geometry approximation in particular) given that depth test is unusable. Hm, not sure how much of an impact discard has under thous circumstances - reading around about mobile devices did not clear the question, does anyone know?"

0

Share this post


Link to post
Share on other sites

Sorry what I meant was that it is better to actually alpha blend using 1.0 rather than using discard, but I worded it improperly calling it a null blend. Basically do everything humanly possible before resorting to using discard / depth testing on any PVR chipset, as well as a most other mobile GPUs (I don't have experience with the nVidia chips so I have no idea on those). As soon as the driver cannot rely on every pixel being drawn it is forced to take a more complex and therefore slower render path disabling many key TBDR optimizations.

 

EDIT: also looking at the problem set in this thread I would definitely recommend using tessellated geometry reducing the amount of overdraw as much as possible. I had to do this on a project that supported iPad1 as fill rate was not exactly ideal with that hardware. 

Edited by joew
0

Share this post


Link to post
Share on other sites

I think that tanzanite7 is getting frustrated because he's essentially asking the question:

 

"In a situation where HSR and early-z are not an option, is discard still bad?"

 

And he's getting a lot of answers about HSR and early-z.

 

TBH, I'd have to measure, but one possible reason that discard might be worse than the alpha blend in this scenario is that discard is adding a dynamic branch to the shader (by dynamic, I mean that some fragments within a 2x2 quad might take the discard path and others may not). However, I'd imagine that the relative costs are very hardware and shader dependent, I wouldn't be surprised if you could create a shader where discard clearly improves performance (e.g. if the shader was doing complex per pixel deferred lighting operations). However, I think that where you're just blending a simple texture onto the screen, then the cost of the discard probably outweighs the cost of the alpha blend.

1

Share this post


Link to post
Share on other sites

since you have a texture layed over screen to blend up to target, if I'm not mistaken, I came up with this idea that you could prerender it to the target stencil and blend it upon stencil test, what will allow you for early pre-rejection of pixel. Since stencil buffer is rather yes/no, you would not achive partial transparency, but maybe it would be a benefit, since you would reject totaly transparent parts, and alphablend only those partial ones. Maybe a crazy idea, I know, but you could try it and see, since it demands the texture transparency rendered to stencil only once, if you will not clear the stencil and use it for something else during frame.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0