Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


HimanshuGoel97

Member Since 09 Jul 2013
Offline Last Active Yesterday, 10:36 PM

#5226869 Using the 'latest' extensions for a game

Posted by HimanshuGoel97 on 02 May 2015 - 01:16 PM

Sorry for the late reply. I thought about those things after reading your post and reached the conclusion that you were right, I shouldn't mess around with GL4 features since I can't expect everyone to have it. The reason I'm using a custom engine is because I prefer to do everything myself. I ended up switching back to the normal GL 3 backend for my engine and am just focusing on making a game and optimizing the engine accordingly.




#5225140 Using the 'latest' extensions for a game

Posted by HimanshuGoel97 on 23 April 2015 - 05:11 PM

@Hodgman, Thanks for the links, they'll be a nice resource so bookmarked.
 
@vlj I did read it needed hardware support although I hadn't thought about the fact that it would introduce an overhead.
@cozzie, Yeah, I've been trying ot make sure I don't end up just going for the latest extensions. Bindless textures seemed to be the easiest way to do what I needed, the next most viable option being texture arrays + a lot of management code, which is what I ended up going with. I'm still working on it though.
 
Basically, I specify a maximum resolution a texture can have (the dimensions of a single texture on a texture array) and then assign it an ID based off of the layer, this, along with offsets and size information is all written into a uniform buffer and accessed in the shader, which has the same effect as bindless textures.
 
Currently I was upgrading my shading language library to handle uniform buffers and while the GLSL output looks valid, but I guess passing a flat shader variable from the vertex shader doesn't count as a dynamically uniform expression? How else can I get the per draw index over to the fragment shader then in such a way that it's still considered dynamically uniform?



#5221376 When you realize how dumb a bug is...

Posted by HimanshuGoel97 on 04 April 2015 - 01:10 PM

 

Yesterday I'm setting up a new Opengl/SDL/Linux app.  Step one: draw xyz axis lines and rotate them with the mouse.  Easy.  So I copied a lazy-foo example, stuck in my own stuff, and segfault.  What???

 

The code isn't even doing anything.  Hours later, after unsuccessful attempts to read logs, get error callbacks, step through the code, and at least an hour trying and failing to install a visual opengl debugger, a coworker looks over the code.

 

"Shouldn't you call glDrawArrays() instead of glDrawElements() when you don't have an index array?"

 

Facepalm.

lol, I had something very similar happen to me, only it was between glMultiDrawArraysIndirect and glMultiDrawElementsIndirect and there wasn't a segfault because C#

 

I kind of feel dumb for never forgetting how my code works. Maybe I forget the details, but if I take a quick look I remember everything immediately =/

 

 


Other times people copy/paste with minor modifications rather than turning the functionality into a reusable function.

By general rule, the moment you decide to copy and paste is probably the moment to take the code and isolate it into its own function because that is most likely the point when you can tell that a piece of code is worth to be made reusable. If you haven't needed to repeat the code yet then it's probably better to not waste the time doing it though.

 

Of course, easier said than done. If you're the only person touching the code then it's not really a problem since you'll most likely consistently remember that rule, the problem is trusting other programmers to be doing the same.

 

I don't forget how my code works, I just forget which code I have, when I look at the code, I instantly remember how it works and all the quirks about it, the problem is remembering that I had the code. I usually look over my engine's file tree quickly before I start working.

As for copy pasting bits of code, usually I would separate it into a separate function, but it didn't feel reasonable here since it was just a single loop that filled an array with data extracted from Assimp's representation.

 


There was a discussion about that kind of constant just last week. When things should be numbers, or constants in code, or values in data, is a question debated by everyone, even professionals, and it all comes down to implementation details.

I create a const variable (since C# doesn't have #define style values) for when I think a number might be too specific to remember why it was there later, or else I place a comment. But something like i+=3 in my opinion didn't need it because it'd always be obvious why the 3 was there.




#5221134 When you realize how dumb a bug is...

Posted by HimanshuGoel97 on 03 April 2015 - 10:25 AM

Once when I was working on a 3d model loader for my game engine, I kept getting messed up normals on anything but a sphere or plane. I looked through everything, began suspecting that they were getting messed up when exporting from Blender, then I looked it up and turned out there had been a bug like that once. Tried another format (since the loader was just Assimp.NET), but nothing changed.

Then after 3-4 days of trying different things and fixing possible issues, I noticed:

 

for(int i = 0; i < Normals.Count * 2; i+=2){

....

}

 

:|  It felt so stupid that I suspected sabotage from my roommates lol. Now that I think about it, I probably forgot to change the values if I copied the loop for the UVs. (and yes, later I did realize how horrible the idea of looping over everything like that was, and so I've written a proper custom model loader)

 

Also, a few days ago I was having trouble getting MultiDrawIndirect working. I spent an entire day on it and finally gave up and went to sleep. Then, as soon as I woke up, it hit me,
I was using
Model q = new Quad(0,0,1,1); to test the drawing, but with the way everything was setup, it wouldn't necessarily be the first thing I saw when I launched the game. I remembered that I had a fullscreenquad class (which was what I intended all this time), so I changed it to

Model q = new FullScreenQuad();

and suddenly, it works! It made me get worked up about my skill as a programmer though, not even remembering parts of my own game engine. 

 

Another time, I was having issues with the buffer object memory manager, I came up with all sorts of complicated ways I could get around the issue, then I noticed that I could just remove one check to get the same effect, that was yet another wasted day.




#5216056 RenderQueue + Multithreading in OpenGL?

Posted by HimanshuGoel97 on 12 March 2015 - 08:30 AM

Sorry for the late reply.

Thanks for your advice L.Spiro.

I did mean to talk about Command Buffers, I just suck at terminology :P

I understand that there isn't much to be gained on the OpenGL side, but I think this should help speed up my resource loading since that data will have more time to get loaded before it's needed (then again, since I recently learned how designing the model format so it could be put straight on to the GPU without much parsing would help load times, not sure how much this will matter with that in place as well).




#5104706 Real-time Global illumination for games discussion

Posted by HimanshuGoel97 on 26 October 2013 - 10:22 PM

1. Definitely worth looking at, there are so many techniques out there, each one with some advantages and disadvantages plus it gets you thinking about how you could improve the algorithms (because of how painfully slow many GI methods are)

2. Trig, basic understanding of rays, ray propogation, matrices, vectors, sometimes the very basics of calculus and that should get you through most algorithms

3. theres ray tracing, path tracing, voxel cone tracing, metropolis light transport, ambient occlussion, photon mapping 




PARTNERS