Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 02 Nov 2012
Offline Last Active Yesterday, 04:44 PM

#5316033 GLSL, Blending with Framebuffer Fragments via Shader?

Posted by on 21 October 2016 - 12:40 AM

"Programmable blending" is the magic keyword for what you want. It's available via extensions on some hardware but you won't be able to do it in the general case.


In portable code, it's common to render to an offscreen target (a render-to-texture), then sample from that texture to implement whatever fancy blending equation you need. In some cases this might involve 'ping-ponging' between two offscreen targets as you apply multiple layers of custom blended stuff.

#5315305 CPU + GPU rendering with OpenGL

Posted by on 15 October 2016 - 05:18 AM

Is there a memory trick that I can use in OpenGL to avoid stalling on sampling an uploaded texture? Right now I just upload the software rasterized result to an existing texture ID using glTexImage2D.


Maybe try triple buffering, so that you round-robin rotate between 3 different texture IDs on different frames. It's possible that the current usage is creating a sync point where the GPU has to wait for it to finish with the previous texture before it can upload the new contents.

#5314941 texture still show line between vertices

Posted by on 13 October 2016 - 12:09 AM

The trick might be to stop using "points that sit in the same position" and start using indexed rendering so that there is a single shared vertex instead of a bunch of vertices that happen to be in the same spot. That said, it might be hard to do that for an entire huge mesh, e.g. if you have multiple height map textures.


Using vertices that sit in the same spot can work, but only if you're very careful to eliminate the possibility of floating point error. e.g. If your patches have different world matrices to one another, or they sample different height-map textures, or they calculate their UVs differently, then you're going to see artifacts like this.


Maybe if you post the whole vertex shader and provide detail about any differences in position calculations between patches, then that'd be useful.

#5314285 Billboard Particle Sorting

Posted by on 07 October 2016 - 02:28 PM

I'd have thought whichever one you align your particles perpendicular to. I'd imagine it's B.

#5312315 Sharpen shader performance

Posted by on 24 September 2016 - 08:30 AM

If you were targeting mobile GPUs, I'd say you could expect another huge performance gain by calculating the UV coordinates on the vertex shader and passing them through as vec2 varyings (well, 7 vec2 and 1 vec4 because you only get 8 varyings on some mobile GPUs). There'd be 2 big gains, firstly, you'd be skipping a bunch of per fragment calculations and secondly you'd be minimizing dependent texture reads.


As you're targeting desktop, I'm not so confident it'll have any measurable effect, but it's a simple enough experiment, so if I were in your shoes I'd give it a go.

#5298653 how to differentiate performance on android devices

Posted by on 30 June 2016 - 11:40 AM

This is a hard problem, and one of the reasons that more people make their games free on the Play Store than on Apple's app store. There's just so many devices out there it is effectively impossible to avoid selling your game to a customer who won't be able to play it.


One tool in the manifest to add to Nanoha's suggestion is the screen size: <supports-screens android:smallScreens="false" /> ditches tiny phones which are probably underpowered. But in general it's hard to do much in the manifest beyond OS version, screen size and GLES version.


At runtime, I assess device's graphics capabilities mainly by proxy, I look at information like:


* Number of CPU cores

* Amount of RAM

* Whether highp is supported in fragment shaders

* Whether GLES3 is supported

* Whether depth textures are supported


And I choose a graphics option based on that - I let the user override my choice.

#5297176 Generating Provinces From A Map

Posted by on 18 June 2016 - 11:24 PM

Is it possible to flip it around and create the land map from provinces instead of trying to break-down a pre-existing land map?


That's what I ended up doing in my title to avoid having to solve this problem. My landmass generation looks something like:


for (number of provinces that I want)

1. Pick a single sea cell as a start point (after rolling a dice to decide whether to start attached to existing land, or start a new island)

2. Grow the new province, adding one extra sea cell at a time until its a suitable size

3. If we managed to grow large enough, then accept it, otherwise back to #1 to pick a new start point.

#5296060 how to solve z-fighting

Posted by on 11 June 2016 - 05:31 AM

I always avoid depth bias style approaches because they're never very portable across different rendering APIs. I prefer to use a different projection matrix with an ever-so-slightly reduced field-of-view for decal rendering.

#5293970 New Cryengine/Unity/Unreal 3rd/2nd/1st person shooter

Posted by on 28 May 2016 - 03:28 PM

Possibly the most relevant piece of research you could do for your project:

I think this is the more appropriate link: https://en.wikipedia.org/wiki/Poe's_law

#5292216 Vulkan and mipmap generation

Posted by on 17 May 2016 - 11:19 PM

I think vkCmdBlitImage is likely to be a superior option for mipmap generation than using a render pass per mipmap level. Not sure how vkCmdBlitImage stacks up against a compute shader though.

#5291459 Android development best tool

Posted by on 13 May 2016 - 04:04 PM

If you're setting up a new project, I'd definitely skip Eclipse and go for Android Studio, otherwise every tutorial or set of guidelines you come across will be for the wrong tool.


From google's developer blog on the launch of Android Studio 2.0



If you are developing for Android, you should be using Android Studio 2.0.




Edit: FWIW, I currently use https://developer.nvidia.com/codeworks-android which integrates with Visual Studio and builds are Ant based, I want to switch over to Android Studio, haven't got around to it yet.

#5289743 Pixel Shader Uniform Cannot be Found

Posted by on 02 May 2016 - 08:56 AM

Are you using the uniform? If not, then possibly it has been stripped out (not 100% sure DX9 will do this, but it's a quick thing to check)

#5288903 Generating command buffers each frame issue

Posted by on 27 April 2016 - 06:30 AM

I don't think there's an alternative to recording command lists per frame. Ideally, you want to use pre-recorded ones as much as possible, but too much stuff changes per frame in a real-world app to avoid recording some stuff on the fly.

The only time I saw a similar accumulating frame-rate drop was when my memory manager was leaking like crazy. I'd look into whether you are leaking anything.

Also, from what you've posted, it looks like you're re-recording ALL your command lists every frame. Surely you only want to be recording one command list per frame  as the others might still be being consumed by the GPU.

#5288039 KitKat 4.4 writing to external SD etc.

Posted by on 21 April 2016 - 02:02 PM

I dont use any fancy android local storage things, i need a clear way to write, read into internal/external memory as user chooses on which he wants to install it. Problem is kiktak (android 4.4) doesnt allow third party apps to write to external sd cards (and maybe to internal too) so what opportunities do i have?


Are you talking about your app reading/writing files in external storage?

Or are you talking about your users wanting to move your app to external storage in order to save space?


I think people think you're talking about the first one, in which case WRITE_EXTERNAL_STORAGE should do it as they have said.


But I think maybe you're asking for the latter. If so, then it's a simple change to the manifest.

<manifest xmlns:android="blah" 

Adding the android:installLocation="auto" allows users to move your app install to their SD card.

#5280854 Reducing Compile/Link Times

Posted by on 12 March 2016 - 03:24 AM

Andy Firth wrote a series of blogs about his experiences in optimising the compile and link times at Bungie. Unfortunately, they were originally published on AltDevBlogADay, so they are very hard to track down: