Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 13 Sep 2012
Offline Last Active Yesterday, 06:29 PM

Posts I've Made

In Topic: Sharpen shader performance

28 September 2016 - 06:04 PM

Personally I'd recommend treating GLSL like JavaScript on the modern Web -- never directly write the files that will ship; always have them generated from some build system and potentially have the real source code in a better language altogether. That way you can have clean source code and ship ugly optimized GLSL files, such as with pre-unrolled loops.

Making a shader transpiler and a new shader language is a whole project in itself, Hodg :D When you don't have a tooling team that makes that stuff, the time might be best invested in something else. 


What happens if you declare the kernel/offset arrays as uniforms and use the for loop? 

In Topic: How to get 86KB/frame in a browser?

25 September 2016 - 12:16 PM

You can just send all the animation frames once to the client, then let the client play the animation. Not every pixel has to be a client<->server transaction. You wont get anything fast enough working like that.

In Topic: Why C# all of a sudden?

23 September 2016 - 04:02 PM

Well, yes and no. IIRC, the official implementation was closed indeed, but it was standardized from an early age and all blocking patents were released under some "community promise". So it was an open language with a closed implementation. I think Java was a closed language at the time, not even sure if an open implementation existed. There was some shared source reference implementation of .NET ("SSCLR" or something), but the license was bad.


Originally Microsoft implemented all of Java and then some. Delegates for example appeared first on Microsoft's Java, which was against the licence Sun offered (they wanted a more centralized development where they agree on certain features and get them standardized first). They literally tried to do the embrace-extend part, but Sun's lawsuit came before the third step. Still Sun fucked it up by themselves by stagnating the language for years (although not so much JVM as a platform, thus why tons of alternative languages have sprouted from it).




What changed? Why is C# or JITs (or for whatever reason Java and C# were hated) acceptable, now?

Because it isnt like they coded a VM once back in 1992 and set it in stone. Java wasn't even JIT'd when it started, that came later with HotSpot. VMs have advanced a *lot* in the last 20 years. HotSpot in particular has tons of nifty profile guided optimizations that does on the fly (branch prunning and reordering, "devirtualization" of method calls, escape analysis, etc).


Microsoft's VM isnt as sophisticated, but it was better designed from the get go, so you got less overhead with native interop, easy marshaling between native and managed memory, finer control of the memory layout of your objects via structs and arrays of structs, etc. ie, most of the tools you need to get more performance out of your code.


Google's V8 can get quite nice speed out of JS in record time since its been based on the goal of fast loading websites (afaik JS VMs do cool stuff like optimistic typing to try to get around JS's limited type system).


Not only hardware is faster but VMs are much better at what they do nowadays. Nevermind that the tooling and environment is really great (for both C# and Java you got great IDEs, great libraries, great debugging tools, great profiling tools, etc).

In Topic: Gui Libraries?

23 September 2016 - 03:43 PM

Having your UI lib issuing GL commands mean the user has to track all the state your library modifies, or needs before rendering. OpenGL is a state machine, which means that your lib not only needs the state it sets, but it also implicitly needs all of the state it doesnt touches in certain ways. Its a pain in the ass to work with and a pain in the ass to debug. Just issue commands and let the game's renderer do its thing. You can see nuklear or libRocket's rendering APIs as an example.

In Topic: Engine works fine on Ubuntu but has issues on Windows

18 September 2016 - 12:14 PM

Yeah Intel stuff in Windows didn't get good until the GL 4.2+ GPUs started to come out. If you have no issues with maintaining a D3D pipeline, thats prolly your best option. Otherwise just target core 3.3 on both platforms and scrap older Intel GPUs on Windows.


AMD supported GL3 cards up to GL 4.2, so you get a couple of nice GL4 extensions supported in GL3 hardware (arb_shading_language_420pack, arb_texture_storage, etc). nVidia went a bit further (you can find 4.4 extensions in GL3 cards). Intel just implements what it wants on Windows (sometimes GL 3.1, sometimes GL 4.1, sometimes GL 4.2, its a lottery). Although on Linux they do support some GL4 extensions on GL3 hardware.


Thus why GL 3.3 core is a nice "middle ground" context to target on most places.