Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 13 Sep 2012
Online Last Active Today, 05:46 PM

#5316229 Moving from plain "ascii" to XML?

Posted by on 22 October 2016 - 09:25 AM

I'll go for my own format where I can 'learn' from other formats.
*sigh* There are tons of libs that you can literally call 'load(path)' and it returns a key-value structure. YAML/JSON/XML schemas are as complex or simple as you want them to be, they're very flexible. You already spent more time in coding that piece of code than in what it takes to download one and link it to your project, "I shouldn't make it complex" is the opposite of rolling your own. 

#5316149 Moving from plain "ascii" to XML?

Posted by on 21 October 2016 - 05:07 PM

Lets see, verbose XML:


If you're doing XML you should probably do it like:

 windowed="true" />

ie, use attributes.


If you're doing JSON:

"d3d11_settings": {
  "xresolution": 1280,
  "yresolution": 720,
  "windowed": true

ie, nicer.


If you're doing YAML:

  xresolution: 1280
  yresolution: 720
  windowed: true

ie, "look ma! no double quotes!".


I'd use something else than XML, YAML is nice. JSON is not as nice, but its much more widely used (thus more info on it, more libs, etc). 


EDIT: Fixed the JSON as fastcall mentions below.


Anyway, this is my YAML window stuff as an example:

width: 1280
height: 720
fullscreen: false
vsync: yes
softsync: false
vfov: 75
renderdist: 256
resizable: yes

Basically using it as a normal key-value thingy, except i can just call "load" and I get a Map<String,Object> out of it. My renderer pipeline is also made in YAML, using the compact notation, here is a render pass:

dirlight_pass: &dirlight_pass
  name: dirlight_pass
  program: df_dir_light
    name: gbuffer
    targets: [light_acc]
    name: gbuffer
    targets: [albedo, normal, misc, depth]
    - [default, default, default, default]
  batch: LIGHT_DIR
  updaters: [DIRLIGHT]
    writing: COLOR_ONLY
      func: GREATER
      range: [1.0, 1.0]
      testing: YES
      clamping: NO
    scissor: DEFAULT
    viewport: DEFAULT
    stencil: NO
    triangle: DEFAULT
    blending: NO
    clearing: COLOR_ONLY

#5316144 Estimating the performance of my application a priori?

Posted by on 21 October 2016 - 04:56 PM

This is taking premature optimization to a whole new level.


I dunno. Explain what you want to do and see if it requires any traveling-salesman solution kind.

#5315360 Shader Permutations

Posted by on 15 October 2016 - 03:00 PM

Yup, no idea where you got from UBOs are a 4.5 feature.

In GL 3.3 you got UBOs and glBindBufferRange, you got TBOs also. Unless you're messing with draw indirect, you wont be missing anything from GL 4+ when dealing with this stuff.

#5314768 Minimizing draw calls and passing transform/material data to a shader in Open...

Posted by on 11 October 2016 - 06:48 PM

64kB UBO is the standard for nVidia (Intel varies from 16kB to 64kB, chances are you dont care about the Intel GPUs with 16kB UBOs). GCN supports 2Gb UBOs if you want them for some reason. As I mentioned, you could just simply use texture buffer objects (TBOs), which are megabyte sized in most cases (they're often used for skeletal animation data for example, which is a lot of matrices, more than whatever material data you might have).


Also have in mind this: 64kB (or whatever) is the maximum range you can bind of a buffer to an UBO slot, that doesnt prevents you from creating a megabyte sized buffer (which I do), and updating it entirely in a single call. Then you just rebind ranges incrementally and draw as you go (drawcalls themselves aren't the real issue here but the stuff you have to touch to get to that drawcall).


At least in my profiling, the time is spent updating the buffers rather than issuing the drawcalls. So that's what gets minimized.

#5314431 Minimizing draw calls and passing transform/material data to a shader in Open...

Posted by on 09 October 2016 - 12:11 PM

Ah if I could point you to some older thread that was about this kind of thing. Sadly I cant seem to be able to search keywords in my own posts only, so I can't find it.


Anyway, ARB_shader_draw_parameters seems to not be supported in any GL 3 hardware (and I've read for some reason it has a non-negligible performance impact). So the idea is to work around that using this beautifully named draw call:




Which comes in the extension arb_base_instance, made core in 4.2, which also is supported by all the GL 3 hardware you should care about.


Now this gives you a couple of things:


A way to specify a vertex offset to start drawing from in a vertex buffer.

A way to specify an index offset to start drawing from in an index buffer.

A way to specify the instance you're starting to draw from in instanced rendering.


With this you can have a single VAO, with all your meshes, and a way to combine instanced rendering with normal rendering in a single draw call (like Vulkan!).


You need a way to bind these single/multiple mesh instances to their respective transform/material data right? And uploading a single uniform per draw call wont cut it, since you might have instanced calls with more than one instance. So you need a way to upload data for several different instances, preferably without caring if they're of the same mesh or not, so you can issue a single upload then make draw calls as needed that operate with that uploaded data.


Now the issue here is that instance ID still works as usual, that is, its zero based. So if you're drawing 5 instances of mesh 10 in your draw list, you need it to fetch transform data at index 10, 11, 12, 13 and 14, so you need a way to communicate to the shader that it should start from index 10. So, with a normal instanced draw call, if you tell it to draw 5 instances, it will start at zero.


A way to get around this is to specify a separate instanced attribute buffer, that contains the indices. From 0 to whatever maximum instances you can draw in a single uniform buffer upload (usually 4096 with a 64Kb UBO limit).


Now the trick here is to tell the instanced draw call to start at instance 10, which will fetch the instanced attribute at index 10, which will be the real index you want (ten!). gl_InstanceID will still be zero, but you dont care about that, because you got the index you want automatically fetched from the instanced attribute buffer.


So your render loop becomes something like:


for ( allPassedShaderPrograms) {


  do {

    // Fill the UBOs as much as you can with the render tasks data.

    for (allUniformBufferInThisBatch)


    // Draw all the render tasks that had their data uploaded. 

    for (allTasksThatCouldBeUpdated)


  // And repeate while there are tasks to draw.

  } while (thereAreMoreTasksToDraw);



You can find a more detailed explanation here if you read the PDF: http://www.gamedev.net/blog/2042/entry-2261259-from-yaml-to-renderer-in-50ms/


Have in mind that my renderer is pretty basic, no multi layered materials or anything, so your mileage may vary. But those are the basics to get more draw calls per buffer upload.


EDIT: Also, these kinds of approaches were described in nVidia's advanced OpenGL scene rendering presentations from GTC, they did one and updated it each year with different methodologies and benchmarks. You can google those. The idea is more or less the same, how to minimize buffer uploads, how to get the most out of your drawcalls, and how to efficiently upload instance IDs for indexed resources (whether they're UBOs, TBOs, SSBOs, etc).

#5313782 Why C# all of a sudden?

Posted by on 03 October 2016 - 04:01 PM

For independent development C# had a lot to offer in terms of increased productivity while minimizing the performance sacrificed for it (this is what Java got wrong; it did things in essentially the most wasteful way possible instead of the least.)

Java's philosophy is to make stuff in the obvious way, then throw engineering time at the VM until the obvious way was fast enough.


This is why escape analysis exists in HotSpot for example. You werent supposed to care if you were new'ing tiny objects inside a for loop, or if you were allocating a temporary ArrayList to grab intermediary results and then throw it away, the VM was meant to make it run fast for you anyway (and it does, it can "desugar" that ArrayList into a plain array in some cases). You werent supposed to care about the performance impact of deep hierarchies and virtual calls, the VM is supposed to think instead of you if you really needed virtual dispatch or not at a particular call site.


I'd say that objective has been quite successfully met, its just that it isnt the ideal case for video game programming. I dont want the VM to guess the allocations for me, I want it to let me make a contiguous array of stuff and let me manage it.


Then again, Java is being successfully being used in high frequency trading software, which has similar "real time'ish" requirements as videogames (albeit making use of your usual workarounds: Primitive collections, off-heap buffers, etc).

#5313657 How to implement a object manager class?

Posted by on 02 October 2016 - 09:00 PM

Seeing that so many intermediate programmers get snared on CES, either by overabstracting and over-engineering, or simply not understanding it, I'd suggest the OP holds off on exploring that avenue.
There are many libs implementing those parts already. Its no different from trying to implement your own hierarchies, or your own renderer. There is the dirt road or the high way, you pick. 


If anyone wants to go the ECS way they should download something like this: https://github.com/alecthomas/entityx And gets started.


In my opinion, hierarchies get too complex really fast so it is time well invested, even if you dont end up using an ECS in the end. Just to get a hang of the different approaches you can take.

#5313593 game programming on multiple platforms with javafx

Posted by on 02 October 2016 - 11:22 AM

JavaFX doesn't works on any mobile platform as it is (iOS, Windows Phone, and Android). Unless you buy something like Gluon Mobile (dunno if you can use their JavaFX port individually).


Also Java as it is, right now, since Xamarin bought RoboVM, and Microsoft bought Xamarin, which in turn canned RoboVM, has some rough patches when trying to run it in iOS.


There is BugVM, which is a fork of RoboVM. That might work. Not with JavaFX though, desktop UI libs weren't ported.


There is also Intel's Multi OS Engine, which it seems it will allow you to run stuff on iOS, but no JavaFX.


So all you're left with is libGDX probably, they have some iOS targeting strategy that I'm not knowledgeable about. Then again, no JavaFX, you'll be using whatever libGDX has to do everything.


TL;DR: No JavaFX on mobile, you need to target the UI libs of each platform individually or target the compatibility layer whatever means you end up using to run your app in iOS.


.. As for Windows Phone, you're out of luck I guess.

#5313135 Sharpen shader performance

Posted by on 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? 

#5312175 Why C# all of a sudden?

Posted by on 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).

#5312172 Gui Libraries?

Posted by on 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.

#5311310 Engine works fine on Ubuntu but has issues on Windows

Posted by on 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.

#5311131 Data-Driven Renderer - how to modify the pipeline on-the-fly?

Posted by on 16 September 2016 - 03:42 PM

1) What is the cleanest way to allow on-the-fly modification of the rendering pipeline in a data-driven graphics engine?
 Reload everything?


 2) How should render targets be described in a flexible rendering pipeline? How to specify that a render target should be taken from a render target pool?
I put a "shared" flag in each render target. If they're shared, they go to a name->target map. All targets first look into that map to see if there is a target with the same id, or create it otherwise. If a target is created and it has the shared flag, I add it to the pool, otherwise I just leave it alone in the render pass.

#5309412 (VB) Barcode Reading / Scanning for Inventory?

Posted by on 04 September 2016 - 01:15 PM

You could just google for anything like that. Its a fairly common application to make. I got like 10 different applications from googling "inventory barcode software".