The standard approach to this, at least on Windows, is to build the debug symbols into a separate database (PDB file), and reconnect the addresses to the symbol names on the back end. Microsoft makes tons of symbols available for their own code via a symbol server which debuggers can query by the combination of a module hash and a relative virtual address.
It’s true that you really, really want to avoid making changes to the engine. Even for AAA studio source licensees in prior UE generations this was widely agreed upon. The good news is, you really shouldn’t have to.
In my mind, the big win from having the Unreal source code is understandability. But also, in contrast to Unity, if you should for some reason need to—say a critical bug that’s stopping your game from shipping at the last hour—you at least have the option.
Every AAA source licensee that I worked at made large changes to the engine source. There are many AAA titles both shipped and in development that change fundamental things about how the engine works. Look at the GDC presentation about Mortal Kombat rollback network, or its predecessor about running UE3 at 60 fps on console for some good examples. Completely avoiding engine changed isn't the reality for AAA, and I imagine it's only true for small indies. Good news is it's pretty easy to merge small engine changes.
I haven’t been through the process recently, but I believe the i1 Display Pro I have includes optional workflow steps which ask you what controls are available on your display, and gives you a chance to make those kinds of coarse adjustments before building the LUT. For some monitors it can also automate that process via DDC/CI, but I think that’s an extreme minority.
This is neat, but it seems strange to call it a "port" of a closed source proprietary commercial product. It doesn't actually seem to be related beyond also being a firewall with a UI that kinda imitates Little Snitch.
>Some excerpts from many years ago did defend the alleged liberty of children to have sex – even with adults – “if the child accepted it”. For example, in 2003 Stallman wrote
>>"I think that everyone age 14 or above ought to take part in sex, though not indiscriminately. (Some people are ready earlier.)"
>In 2006 he was skeptical of the claim that “voluntary” pedophilia harmed children. He wrote something similar in January 2013, but within limits.
>This author opposes such an opinion! However, Stallman later changed his mind and, on 14 September 2019, (belatedly) retracted it.
YIKES. I hadn't even heard that part. Convenient timing to suddenly change his views on the subject.
Very impressive, and I'm also seriously tempted to look into a pipeline to take these into Unreal Engine as an alternative to SpeedTree.
There's something I've been curious about, though, which is that since Blender is licensed under the GPL, aren't all these add-ons also forced to release under a GPL license? Which means the first person to pay the ~$500 is legally within their rights to reupload this product for the rest of the world to download freely?
Not trying to troll, though I worry it may come across that way. It's just that I've actually had a friend try to convince me to work on Blender add-ons for supplemental income, and it seemed like a bad idea for that reason... so I'd like to make sure I'm not missing something.
(I guess you can make the case that all the comparable non-GPL software gets pirated too, but this seemed somehow more demoralizing to me.)
Hmm, I swear this must be new since last time I checked the Blender site, but it seems to address my concerns very succinctly, and apparently that's not relevant:
> Sharing or selling Blender add-ons (Python scripts)
> Blender’s Python API is an integral part of Blender, used to define the UI or develop tools for example. The GNU GPL license therefore requires that such scripts (if published) are being shared under a GPL GPL compatible license. You are free to sell such scripts, but the sales then is restricted to the download service itself. Your customers will receive the script under the same license, with the same free conditions as everyone has for Blender. Sharing Blender or its scripts is always OK and not piracy.
This one looks like standalone application, that has integration plugin into Blender. Otherwise, you can export into other 3D packages and not use Blender at all.
By the same token, anybody who distributed a fork of the said script is free to charge for it as well, as long as the source code (or patches thereto) is/are distributed under the GNU GPL or compatible license.
> Which means the first person to pay the ~$500 is legally within their rights to reupload this product for the rest of the world to download freely?
I'm not a lawyer, but I'm pretty sure that's not how the GPL works. If some company were violating the GPL with their product, the owners of the GPL work could sue them to stop them from shipping their product. Nothing in the GPL causes infringing works to automatically become GPL (though it would be one way for the infringing company to resolve the issue, if they so choose).
I don't know how or if the GPL applies in this particular situation, I'm just referring to how the GPL works in cases where actual infringement is happening.
Add-ons licensing are often debated and the answer to it is sadly the subjective answer to a very specific question: Would a judge see it as part of a single work or two works that operate independently and simply interacts with each other.
The common understanding is that in a single static linked software the different source files are just components that makes for a single work. They are not independent. Dynamic linked software could be argued as two works but FSF has a clear opinion that a judge will see the combination as a single work and has publicly stated they will bring it to the court if challenged, and so far no one has challenged them on that view.
Blender core is written in C and Blender engine is in c++. As such I would say the consensus is that all contributions to either of those must be under GPL.
But you are asking about blender add-ons and those are connected via the blender API that is written in python. Python is an interpreted language so what happens here? The answer goes back to the original question, what will a judge think, and the answer is that people don't know. Some say that it changes nothing and the code parts are just as dependent as if it had been dynamically linked, in which case the add-ons need to be GPL. Other disagree, through I do not know any case law here either so it mostly just people with different view about what the judge will say.
The API aspect is also an important part of the question. If the Blender API is closely connected to the internals of Blender then the distinction between an component and an independent work is blurred.
Last there is two more bits I would like to add. First, just like the other comment say, GPL can not force anything to be released as GPL. Copyright law create by default a law against distribution. A copyright license like GPL is a document that describe when you have permission. The only thing that happens when someone breaks the condition of gpl is that you loose that permission. As a side effect, if you loose permission and distributed the work at the same time you can get sued under the crime of copyright infringement.
The second additional bit is that interaction with non-code assets and code is itself a grey area of copyright law, but I think there is a small consensus that it would be seen by a judge as separate independent work.
>I’ve heard of developers that don’t use debuggers because they have a mental model in their head.
Having heard these claims myself, I firmly believe that developers who eschew debuggers are either severely handicapping themselves out of misguided bravado, or at best are too lazy to invest minimal learning time to establish basic proficiency for huge reward. There's no reason not to avail yourself of extremely powerful tools like that.
That said, maybe don't start with text-mode debuggers...
I think it very much depends on the work you’re doing. My co-workers depend on debuggers which are a crutch that allow them to _feel_ like they have control over our spaghetti code — “it’s fine, I can step through!” — but the code I produce (without a debugger but through TDD) is much more resilient. There’s certainly engineering problems that benefit from a debugger but I think for most modern work they’re not essential — and often a crutch.
While I don't think they are only ever used as a crutch, I'm starting to see more and more how they definitely are an enabler of spaghetti code.
It's not even just spaghetti but things that are very obtuse too. I often need a debugger whenever I see things in the code like if(variant.sourceId == null) and then below is the large unnamed block of code that also doesn't give any indication of what it implies. Because I have no idea what it implies, I have no idea how the data got into that state, so it's like... What case triggers this code?
I often wind up refactoring that stuff after computing an understanding of it. It usually comes out significanty easier to read and not likely you require a debugger to understand it.
So I that regard I think debuggers enable unnecessarily difficult to understand code to hang around.
I respectfully disagree. Debuggers are essential while you are debugging. Say you inherit some code and you are not sure where to make the necessary changes. Nothing beats stepping through until you find the place that does the thing and add your change.
I think this is the crux of it and there’s a balance.
Debugging by printing the state of variables too frequently and resorting to line-by-line debugging of every function can be inefficient if it becomes a crutch for the developer. This could be due to a lack of confidence or a lack of understanding — or just habitual.
>> I happen to believe that not having a kernel debugger forces people to
think about their problem on a different level than with a debugger. I
think that without a debugger, you don't get into that mindset where you
know how it behaves, and then you fix it from there. Without a debugger,
you tend to think about problems another way. You want to understand
things on a different _level_.
One of the best moves I made the first 10 years of my career was stepping through every single line of C++ I ever wrote just to observe it working as I thought (and a lot of times it wasn't). MSVC++/Visual Studio made this a very natural thing to do without breaking the flow.
Today, I use a variety of tools and languages and ... hmmm... I don't actually remember the last time I used a debugger on my own code.
Well, when debugging in C/C++ (and I have used lot of debuggers) you may find they don't help you to find the hard to spot problems.
Sometimes a bug just doesn't pop when debugging due to differences in the memory management of the debug mode or race conditions in multi-threaded due to different timings...
So, "text-debugging" (like printf("I'm here") debugging) sometimes is the only way to find precious bugs.
Back in the day most of my colleagues only relied in printf debugging. But we were just a bunch of linux geeks developing kernel modules, linux apps and QT apps (QT brought a nice IDE for debugging, truth to be told)...
https://www.forrestthewoods.com/blog/memory-bandwidth-napkin...