Jump to content

  • Log In with Google      Sign In   
  • Create Account


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

#5275006 Simple Open-Source Projects To Contribute To?

Posted by on 09 February 2016 - 10:53 AM

 I'm wondering if you guys are aware of any simple C# projects that I can contribute to. 
Small open source projects tend to be very personal, like one or two dudes team. You'll have a hard time convincing them they need your contributions.


You could fork something and expand it instead, but without a use case its useless (developing libraries in the void tends to do that).


So I don't think this is a feasible approach.


What you could do is develop your own projects, but read about the libraries you use, see their sources, see how they're developed. Maybe then, after you've used them, understood their development and gained experience, you can start to contribute back.


And as always, bug reports, those are contributions too.

#5272775 Vulkan is Next-Gen OpenGL

Posted by on 26 January 2016 - 06:57 PM

If they did the same thing this time, my bet would be on Valve taking to initiative to finish Mantle/Vulakn/Valven on their own, and form a new comittee making Khronos redundant. So, failure is not an option for them this time.

Or they could just wait another 10 or 15 years then try again! /s

#5272507 How can I implement a GREAT blur?

Posted by on 24 January 2016 - 02:46 PM

Your offsets are too big. Thats why you get those artifacts.


I suggest you read this:



#5271765 View/Projection Matrices for Cascaded Shadow Mapping

Posted by on 18 January 2016 - 06:15 PM

You can see the result in the video. The problem is, that depending on the horizontal angle of the camera a lot of shadow map resolution is wasted, because the shadow map does not "rotate with the camera". How do I achieve that?
I haven't implemented anything close to CSM but I've read (from Crytek's presentations IIRC) that rotating shadowmaps arent actually a good thing. By rotating the shadowmaps you create instability when sampling from frame to frame, which introduces shimmering. They got around that by simply not rotating the shadowmaps, wasted resolution yes but they get stable results.

#5270401 When are Shaders needed ? (wich context vers.)

Posted by on 10 January 2016 - 09:40 AM



There are only a few things that you can't do with shaders on "core" contexts. Like clearing the screen as you discovered, or blitting one framebuffer to the other with glBlitFramebuffer. But thats it, if you want to actually draw anything, you have to use shaders.

#5270379 Question about data and resources protection

Posted by on 10 January 2016 - 06:03 AM

Multiplayer games will end up checking these files as well, as it is trivial to modify these resources to gain a competitive advantage.
Very true. I was thinking more on the lines of an MMORPG. Wouldn't want anyone replacing the smoke grenade sprite with an empty one in a game like CS:GO or CoD.


I believe once heard of a game where the players would lower the graphics setting to a minimum since cloaks/smoke grenades at low quality settings affected visibility less than at higher quality. That sounds like a hard nut to crack : /

#5270322 Question about data and resources protection

Posted by on 09 January 2016 - 06:15 PM

If its a single player game, that stuff will be local and what Josh/Swift/Sean said applies.


If its a multi player game, the important data will be in the server (player progression, stats, characters, etc), so it shouldn't be modifiable by the player, and the unimportant data (models, textures, sounds) will be local resources, for which again, what Josh/Swift/Sean said applies.


Being overly paranoid with the game data is annoying from the POV of the users. More often than not some parameter isn't exposed in the options menu, and people have to dig through the games files to fix it and play their game, typical scenario in older games: Game resolution/refresh rate was set higher than what the monitor supported, so people would edit the config files so they could at least launch the game.


Easy modification is what allowed modders to fix hundreds, if not thousands of big and small bugs in Elder Scrolls series. And being pragmatic, if your users go out of their way to fix something in your game and make said modification available to your users, thats good for you, someone just gave their time to you in a silver plate for no charge.


Let them mod.

#5269710 D3D11 Shadow Mapping with Deferred Rendering

Posted by on 06 January 2016 - 05:52 PM

When exactly is not relevant, it just needs to happen before the light pass.


In the light pass, for the lights that can cast shadows, you sample the shadowmap and compute lighting from there (instead of doing the normal pass without shadows). That result gets added to the light accumulation buffer. You add there all lighting results (shadowed or non-shadowed).

#5269538 How to support multiple rendering paths in my engine?

Posted by on 05 January 2016 - 08:34 PM

The way I see it shaders aren't the hard part but the data flow:


  • With deferred you just collect all opaque objects, draw them, then collect all lights, then draw them (more or less).
  • With forward shading you have to do everything simultaneously, ie, grab an opaque object, collect data from lights that affect it, then draw.


I'm not even sure if its worth it, I'd focus on having one good render path first, since that will take a lot of time anyway...

#5269520 [SOLVED] Uniform buffer actually viable?

Posted by on 05 January 2016 - 06:48 PM

It also does really feel like a "hack", and it really only works with instancing.


You think that is a hack? Well, Unity stores instance ID numbers as part of the texture coords so I'd say its an improvement biggrin.png And I remind you you're using textures to store things that aren't textures what is that if not a hack? tongue.png Providing an instance ID its always been a hack because the API doesn't provides a direct way to do it. Only very recently with gl_DrawID and even that isn't widely supported nor has good performance. Its an issue you need to work around given what you have.


Anyway, here is Mathias explanation about how you can have IDs for whatever you want to draw, thats implemented in Ogre3D:




TL;DR; Setup a fixed attribute from indices to 0 to MAX_INSTANCES once, and just manipulate it with instanced call instance id. Oh and before you mention "I'd have to draw everything with instanced draw calls!", Mantle doesn't even has non-instanced drawing IIRC, probably Vulkan won't have either, so I'd suggest to get used to it.


 so this is technically doable for some shaders where it's clear how much data will be written from the start


Not really necessary. You don't need to know that, you just need to know the size of the data your struct instance contains and how much memory glBindRange can handle in your GPU. Like this:


// Allocate temp buffer up to max bindable ubo range.
Buffer buffer = alloc(MAX_UBO_RANGE);
// Uploaded task counter.
int tasksUploaded = 0;
while(!buffer.full() && !tasks.empty())
  Task t = tasks.next();
  // Pad to vec4 if necessary here.
// Here ring buffer works its magic.
ubo.bindNextRange(TRANSFORM_SLOT, buffer.size());
// Draw what you have uploaded so far.
drawTasks(tasks, tasksUploaded);


There, something like that, its just an iteration, write all the data to a buffer, then glBufferSubData or glMapBuffer it to your UBO. Then repeat until you have drawn everything.


(Here you can find a nice explanation on the internal differences between UBOs and TBOs http://www.yosoygames.com.ar/wp/2015/01/uniform-buffers-vs-texture-buffers-the-2015-edition/ )


Again, this reduces state changes and interaction with the driver dramatically. A similar technique is suggested in a GTC NVIDIA presentation, although they do things slightly differently. Look it up, it was called something like "Advanced OpenGL scene rendering", GTC presentation, various PDFs around that had data on how does the indexing into the shader impacts performance vs the amount of time it saves on the CPU side (overall win even on older hardware from what I read).


Graham Sellers, of AMD/Mantle/Vulkan/Modern OpenGL fame, also mentioned in an Ogre3D thread to store all meshes in as few buffers as possible, separated only by vertex input format. Here, read all the thread, good stuff in it:




In that way you can also reduce all the buffer/vao binding to a minimum.


I don't think I'm able to do that from Java besides hoping that the memcopy function I'm using for unsafe memory access outside the Java heap (= C performance) does that under the hood, which seems unlikely.


Now that you mention it maaaybe HotSpot does something like that. Although probably works just for copies between Java arrays. Maybe Spasi an do something about this in LWJGL... 

#5269326 Questions About Blur Effect

Posted by on 04 January 2016 - 09:02 PM

This Intel article its a good resource, discusses blurring techniques, optimizations and other considerations:



#5269275 Java, still being a good option for game dev in 2016 or there are other optio...

Posted by on 04 January 2016 - 04:41 PM

The single biggest problem you're going to have with Java is version-of-the-week hell.  Write once run anywhere is a joke. 
Have you had an issue where desktop Java applications broken inbetween releases of the same Java version? (ie, from Java 7 u60 to Java u72 or something). Otherwise its an unfounded myth.


I've run my projects in more VM versions of OpenJDK and OracleJDK that I can count, played Minecraft with all the damn updates that came every two weeks or so, never had an actual VM compatibility problem. They do take retro compatibility very seriously (to a fault even), thus why no API was ever actually removed from the runtime.


Hell I've never in years had an issue where Eclipse would crash because some VM was incompatible, and Eclipse its a massive application.


And please, don't even mention applets. They shouldn't exist, its a Good Thing™ most of them stopped to work.


In any case, there wouldn't be any single damn problem if you just provided a link to download the JRE but Oracle is composed top to bottom from a pile of steaming stinky assholes and they bundle crapware with their damn JRE distributions (luckily they dont do it with the JDK). So yeah, bundle a JRE (20Mb to 40Mb, libGDX guys provide a tool  to reduce the size of the VM by removing unwanted crap).


Still this is an issue that you will have in some measure whatever you choose. C# needs the .NET runtime (or Mono depending on the platform, which is a whole other issue altogether), Java needs the JRE, C++ will need whatever MSVC runtime you're using (or some specific glibc version depending on the platform), etc.


The answer to all of those is: Ship the dependencies with your application, and save yourself a headache.

#5269080 [SOLVED] Uniform buffer actually viable?

Posted by on 03 January 2016 - 05:51 PM

Here: http://www.gamedev.net/topic/655969-speed-gluniform-vs-uniform-buffer-objects/ I ended up implementing the idea I had at that time.


There was also a discussion with Mathias that I can't seem to find, he explained the instanceId with more detail.


Anyway, say that we have some per instance data. Like mv and mvp matrices:


Thats a single struct:


struct Transform
  mat4 mvp;
  mat4 mv;
  // Then some padding to respect std140 if necessary. 12 bytes / vec3 at most.


Now, thats 128 bytes per struct right? If you wanted to place them sequentially on a buffer and bind the range for each Transform struct, yeah, you'd need to place 128 bytes, then pad, for every Transform instance.


Lets say we got our typical 64kB UBO and we define it like this

layout (std140, binding = TRANSFORM_SLOT ) uniform TransformsBlock
  Transform[MAX_TRANSFORMS] transforms;


Where MAX_TRANSFORMS its max ubo size divided Transform instance size, given our 64kB UBO, that'd be 512 instances. Tightly packed.


Now the issue here is that while now you don't need to pad, since you're binding a lot of transforms at the same time, you need to index into the array to get the proper one for whatever you're drawing. There are many ways of providing an instance index, like with an additional attribute, with a normal uniform, with the instance ID, with a combination of instance ID and a vertex attribute, etc. I think Mathias talked about the instance indexing in the Vulkan thread, can't remember.


Anyway, once you got the index per instance uploaded its as straightforward as:


mat4 mvp = transforms[instanceId];


There, now you just need to bind the whole range to that TRANSFORM_SLOT, no more padding in between instance data.


Also, have in mind that you shouldn't put everything into a single buffer. Separate them between "globals" (stuff that never changes), per frame parameters, and per instance parameters. And choose appropiate update strategies for each. Probably mapping a global or per frame buffer for a single tiny update is a waste, glBufferSubData would suffice.


The strategy I use right now is to have a sort of ring buffer of a couple MB. I compute the maximum amount of instances I can upload in a single pass, given the kind of buffers that pass needs (say, TransformBlock and MaterialBlock).


Say that the max is 512. First I bind the ring buffer. Then iterate over the transform data, upload those 512 instances, then bind that range to the transform slot. Then iterate over the material data, upload 512 instances, then bind that range to the material slot. Then draw those 512 instances. Rinse and repeat for the rest of the draw tasks. The only padding I have is in between the kind of block I'm updating. Each block itself has its internal array of structs tightly packed.


Since its a ring buffer I just upload to the next available range, until it wraps around and starts again, by the time it wraps around that data will be quite a few frames old if you give it a couple megabytes.


That means that I can draw 10 thousand different things with 20 updates, 20 bind ranges, and only one buffer binding (drawcall count is a different matter, ideally you can also draw each instance batch with a single draw).


You can get smarter and pack UBOs in a way to reduce the calls even further via passing reduced forms of the matrices, packing different kinds of data into the same struct (ie, instead of having separate slots for transforms and material, just put them in the same struct), uploading all of the instance data in one step, and then just do a loop of bindRange-draw for all of them, and so on. That way you can handle batches of thousands with a dozen calls tops.

#5268936 Criticism of C++

Posted by on 02 January 2016 - 09:55 PM

Yup. Language wars are silly because it doesn't make sense to use only one language in the first place. Every language has its weak points and every language except for Java has its strong points.
 biggrin.png I'm above that shit Khat, I'll just upvote you.

#5268767 Benefits from manual function loading.

Posted by on 01 January 2016 - 08:24 PM

. I was wondering if there was any benefit to manually loading functions for OpenGL rather than using a library like GLEW or similar.
If your goal is to waste your time, then that would be one benefit.


Use a lib: GLFW, GLEW, SMFL, SDL, etc. OpenGL is hard enough as it is, you don't need to artificially create more complexity around it.