Re: How would you dive into a big codebase
On Wednesday, 22 October 2014 at 02:09:53 UTC, Jonathan M Davis wrote: The usual suggestion that I've heard given (without any particular language in mind) is to start by tracking down and fixing a bug in it This is how I usually do it too, though you don't even need to find a bug in it. Picking any feature and trying to find it in the codebase and understand how it is implemented will usually serve well as an entry point. To understand all of the code, I'd start taking notes though, as they're useful to fall back on later. Either way, I wouldn't try to swallow all of it before starting to work with the code. I've been working on codebases just fine without understanding them in their entirety, as such is the magic of code separation. I'm pretty sure there are real codebases in the wild where nobody understands all of it. X11 comes to mind.
Re: generate unique variable names?
On Wednesday, 8 October 2014 at 02:53:08 UTC, K.K. wrote: On Wednesday, 8 October 2014 at 02:06:28 UTC, Brian Schott wrote: I'm 99% sure you actually want an array or associative array. Something like this maybe? ImageType[string] images; images[format(image%03d, i)] = new ImagefromFile(userDefinedLocation); oooh okay I see what you mean. Yeah that will be wy better. It'll help me get rid of all my extra temp variables and string/int conversions, too. Thanks! :) Since you're actually already using indexes in the name, you might as well use a regular array of the appropriate size
Re: How to detect start of Unicode symbol and count amount of graphemes
Unicode is hard to deal with properly as how you deal with it is very context dependant. One grapheme is a visible character and consists of one or more codepoints. One codepoint is one mapping of a byte sequence to a meaning, and consists of one or more bytes. This you do not want to deal with yourself, as knowing which codepoints form graphemes is hard. Thankfully, std.uni exists. Specifically, look at decodeGrapheme: it pops one grapheme from an input range and returns it. Never write code that deals with unicode on a bytelevel. It will always be wrong.
Re: Trying to get Derelict.opengl3.gl3 and derelict.glfw3.glfw3 to work together
Make sure to call DerelictGL3.reload() to get all the OpenGL calls, if you don't, you only get OpenGL 1.1
Re: Trying to get Derelict.opengl3.gl3 and derelict.glfw3.glfw3 to work together
Whoops, I just saw that my earlier answer was totally inaccurate. I was on my phone at the time, so didn't look at the code in detail. On Wednesday, 24 September 2014 at 13:59:41 UTC, csmith wrote: On Wednesday, 24 September 2014 at 11:07:56 UTC, Mike Parker wrote: You're using deprecated OpenGL calls. The gl3 module only declares and loads modern OpenGL. If you really want to use the deprecated stuff, change the gl3 import to this: import derelict.opengl3.gl; And call load/reload on the DerelictGL instance rather than DerelictGL3. All of the modern stuff will still be available. Thanks for this. Was using GLFW's example trying to troubleshoot it. Wasn't really considering them using the outdated functions. I guess I'll look for a different tutorial elsewhere. Also, thanks for making it in the first place! Yes, ##opengl on freenode has good tutorials and examples in the topic. If you've been reading NeHe, drop it. NeHe is severely out of date and anyone still recommending it probably don't know what they're talking about. Here's some links: http://www.arcsynthesis.org/gltut/ https://github.com/progschj/OpenGL-Examples https://github.com/g-truc/ogl-samples Note that modern OpenGL is a bit more involved to get something on the screen. You'll be writing a lot more boilerplate in the beginning, but a lot of the modern features are definitely worth it.
Re: Trying to get Derelict.opengl3.gl3 and derelict.glfw3.glfw3 to work together
On Wednesday, 24 September 2014 at 16:36:29 UTC, csmith wrote: I came from web development, you're meaning to tell me there's coding outside of writing boilerplate? Jokes aside, figured if I took the time to learn a modern language, I'd be consistent with adding in newer technologies :) In that case, here's some two things on the way that may not be all that intuitive for a web developer when it comes to dealing with OpenGL, as they are quirks stemming mostly from how C works: 1. When you need to pass an array of some sort to an OpenGL function, remember to use foo.ptr, not foo. foo.ptr will get you a pointer to an array that the rest of the world, not just D, understands. 2. The OpenGL spec mandates that empty error logs for shader compilation are to report length 0, but if you ask on an nvidia machine about the length of its empty error log, it will reply with length 1. This is because nvidia just send the length of the string in all cases, which for empty C strings is 1 due to the null-byte. I hope this helps you along, good luck!
