What are you working on? v67 - March 2017 - Developers

[QUOTE=Karmah;51987680]I've been meaning to implement ImGUI in my engine and drop the shitty ui I made. If I use it then I'm going to have at least 3 separate libraries defining vector classes with: GLM, ImGUI, and ASSIMP all defining vec2 vec3 and vec4 :v:[/QUOTE] We use a number of libraries for our software, but isn't it possible to only include what you want from each library? (I truly don't know :P)

[QUOTE=jangalomph;51987724]We use a number of libraries for our software, but isn't it possible to only include what you want from each library? (I truly don't know :P)[/QUOTE] Idk if there's any other way because the assimp model importing library seems to store its data using its own data structures ie using its own vector math library.

[QUOTE=Karmah;51987680]I've been meaning to implement ImGUI in my engine and drop the shitty ui I made. If I use it then I'm going to have at least 3 separate libraries defining vector classes with: GLM, ImGUI, and ASSIMP all defining vec2 vec3 and vec4 :v:[/QUOTE] When you add a physics engine you're going to have 4 probably. Not really something I'd call an issue though, esp. with being able to define conversion operators for them.

[QUOTE=Berkin;51985550]My speech synthesizer can now convert simple words to a phonemic representation, but all it can pronounce right now is vowels (not even diphthongs). It's something special. ~MOUTH SOUNDS~ [/QUOTE] If you add a drum machine and some synth you could create a sequel to that rat man song from portal [media]https://www.youtube.com/watch?v=tzwIzwe9Iq0[/media]

[QUOTE=JWki;51987903]When you add a physics engine you're going to have 4 probably. Not really something I'd call an issue though, esp. with being able to define conversion operators for them.[/QUOTE] Whoops totally forgot about that, so yeah I do currently have 3, plus ImGui = 4

[QUOTE=Dr Magnusson;51987714]I've been following [URL="https://www.youtube.com/playlist?list=PLbgaMIhjbmEnaH_LTkxLI7FMa2HsnawM_"]Bartosz Milewski's videos on Category Theory for Programmers[/URL], and I feel like it's blowing my mind on a regular basis. Furthermore, I am starting to see why Haskell is so well liked by people who "get it". The video series is bridging that gap between rough and tumble programming languages like C++, and the mathematical beauty and purity of what lies beneath all the dirty implementation details. I might give Haskell another shot once I'm done with the series. I read the Learn You A Haskell For Great Good book a while ago, and understood the syntax fine, but it never really explained the "why" of Haskell, the almost philosophical arguments for why Haskell, or category theory in general, is a good thing to know about and use when programming. [B]edit: [/B]I still don't really know what a monad is[/QUOTE] Here's an explanation that I don't often hear when people ask what a monad is. Say you have a value of type Int in a strict, non-pure language. You don't know where it came from because it doesn't matter. Now say you're in a non-strict (as in, lazy), non-pure language. Your Int might not yet be evaluated, and in order to evaluate it you might need to do some IO, perhaps query a database or something. Suddenly you need to start caring if the Int you have is a simple number or if it's actually a side effecting computation waiting to happen. So the way you decide to do that is by differentiating these values at the type level. Ints that can't do anything special remain just Ints, but those that require some side effect evaluate will be decorated with a special IO type. Now you have two incompatible things, Ints and IO Ints, and there's no way to make a mistake. The only problem is that you can't really do anything with the IO variants so you need to define some operations that make sense for these values. Firstly, we should be able to "promote" a normal Int into an IO Int. Nothing bad can happen by assuming some pure value does side effects. So that's our first function, `Int -> IO Int`. Next we might consider the opposite. A function that takes an IO Int, does the side effect and gives you a normal Int back. The problem is that we're still in a lazy language so this side effect again won't happen until we start doing something with our normal Int. This is the same problem we started with. So `IO Int -> Int` is out of the question. There are many candidates for potential functions to include, but it turns out that pretty much all the sensible ones can be implemented with the following function: IO Int -> (Int -> IO Int) -> IO Int. So a function that takes an `IO Int`, and takes another function `Int -> IO Int`. When the side effect finally gets executed we get our normal Int out of it. Then we feed it into the provided function which can also potentially require additional side effects to produce a new number. The final result, an IO Int, represents an Int we'll get when both of those side effects get executed. Notice that we don't have a problem we had with the `IO Int -> Int` function because we never claim to produce normal Ints. We just keep stringing on functions that will eventually get run when the side effecting starts to happen. Now we have a pure, lazy language. It's pure because the side effects never really happen. Our code just constructs this huge plan what to do. Then the runtime takes that plan and actually executes it. If you get this, you get what a monad is in a practical sense. Further insight comes from the realization that many more things, other than just our magical IO, also allow for the same interface. So you call everything that implements this interface a monad. The other generalization is, of course, that talking about Ints here is completely arbitrary since the whole story works for any kind of value. Now as far as theory goes, there is a bit of a disconnect. Monads in Haskell are more "inspired" by category theory than they are derived from it. Actually seeing the parallels between mathematics and code does yield significant insight about what this interface does and doesn't let us do, but understanding that is in no way required to be able to say you "know what a monad is". Common question is "so what's so special about this?". Well, there is a certain minimality to the interface we defined. Because it's so minimal, a HUGE number of ideas and constructs can implement it. On the other hand these two functions are enough to be able to write whole libraries worth of functions, without ever talking about anything more concrete. The whole laziness story above is the actual motivation for introducing this concept into Haskell. I feel that it provides a useful perspective for understanding monads. That being said, the interface itself has nothing to do with laziness. It's just a solution to some of the issues.

One of the long-standing problems I've had with my slicing engine is the simplification of polygons. When imported from an STL mesh especially, the output polygons generated can have an excessive amount of vertices that aren't needed at all. This is a problem both from the standpoint of computational complexity (generating toolpaths and such), and because lots of small details are really rough on 3D printers - you want the smoothest, simplest toolpath required to sufficiently describe a polygon so that you can keep the movements smooth. Right now, the simplification is hopelessly broken and has become a blocker since its so bad at safely simplifying things (either I get way too many points to use for a toolpath, or I lose vital detail). Both of the big slicing engines out there use the [URL="https://en.wikipedia.org/wiki/Ramer%E2%80%93Douglas%E2%80%93Peucker_algorithm"]Douglas–Peucker algorithm[/URL] to simplify Polygons, which is fairly primitive. Its also pretty hard on RAM in most implementations, and requires a lot of recursion. Enter the [URL="https://bost.ocks.org/mike/simplify/"]Visivalignam algorithm[/URL]! I just kinda stumbled into this and a really nice implementation on [URL="https://github.com/shortsleeves/visvalingam_simplify"]github[/URL]. It iterates through all points defining a polyline, considering the area generated by the triangle created by a point and its immediate neighbors. In this way, it's able to weigh the simplification better to avoid over-simplifying and really easily takes care of regions with unnecessarily high detail. It uses less RAM, is generally faster, and adjusting the tolerance to clip/simplify by feels much more intuitive. There's also no need for a new heap class: just define a "<" operator for the Visivalignam node struct you create and then use the standard library's lovely "make_heap", "pop_heap", and "push_heap" to take care of all of the sorting/ordering work for you. In simple tests I've run, its already come out far ahead. I take a square and just add random points all along the lines defined by the initial four vertices, and then simplify this down as far as both algorithms are willing to go. Visivalingam simplifies down to the base square, but Douglas-Puecker can't even handle this fairly simple test and ends up keeping a lot of the extra points around (and they really aren't needed). The Douglas-Puecker version also ends up breaking things, making the output into a really distorted rhombus. Oops :v: [t]http://i.imgur.com/J0zDZn4.png[/t] I've also integrated automated unit testing using the Boost Unit Test Framework, which has helped me loads in verifying functionality as I rewrite a large chunk of my codebase (it was terribly broken and used Cura's wretched code too much). With that complete and this simplification integrated, I should be able to get back to work on tying up the last of the work needed to get this application running on the command line. Also, we just got news of an awarded Phase II contract at work. I'm not going to say what, exactly, as my name is on the paper and I don't want to throw that around too casually, but the tech is something NASA really wants for the Mars missions, and it should be immensely helpful for any long-term stays on the Red planet :science101:

[QUOTE=Tamschi;51987353]In case you used other engines previously, what is most different in Godot in your opinion? [editline]20th March 2017[/editline] They could use some irregularities, but I'm saying this as someone who wears glasses and as such gets pretty crazy patterns from these :v: They seem overall way too strong/large, too.[/QUOTE] Godot's extensiblity, speed, lack of dependencies and low weight makes it my go to choice for 2d, I would use UE4 before, but I switched to Godot in an attempt to get away from UE4's licensing system, plus it uses gdscript which is like python, which is something I like. I feel like Godot is the 2D king, and will become a very competitive 3D engine once 3.0 drops.

[QUOTE=TeamEnternode;51986736]I'm hearing a lot of differing opinions about SDL vs. SFML Now that SFML and SDL have version 2s, which do you think is better for 2d game engine development in C++, and why? Reddit says SDL2 but I've heard a couple of arguments for SFML2. [editline]20th March 2017[/editline] I should state I intend on implimemting Lua and Tiled into what I am making[/QUOTE] For an engine, SDL2 has features that SFML2 simply doesn't have. Raw mouse input, multi monitor stuff, no window maximising without context switch, i'm sure there's a few others. I hit a few snags with SFML2 not supporting features in my 3d game engine SFML is easy as shite to use though. Its super useful because of the whole RAII thing, so you can easily manage object lifetimes and gl stuff with it

[QUOTE=Icedshot;51988702]For an engine, SDL2 has features that SFML2 simply doesn't have. Raw mouse input, multi monitor stuff, no window maximising without context switch, i'm sure there's a few others. I hit a few snags with SFML2 not supporting features in my 3d game engine SFML is easy as shite to use though. Its super useful because of the whole RAII thing, so you can easily manage object lifetimes and gl stuff with it[/QUOTE] Ah really I didn't know SFML was lacking on that front.

I feel honored. [url]https://leakforums.net/thread-861651?pid=24409220#pid24409220[/url]

[QUOTE=phygon;51989056]I feel honored. [url]https://leakforums.net/thread-861651?pid=24409220#pid24409220[/url][/QUOTE] [quote=]Also, in addition to the moral thing, there's a deadlock switch built in to an obfuscated DLL. If you accidentally trigger it, it rm - rf / 's your computer so your mileage may vary if you decide to pirate it.[/quote] seems like a really dodgy and malicious thing to do imo.

[QUOTE=Skipcast;51989106]seems like a really dodgy and malicious thing to do imo.[/QUOTE] Pretty sure he's bluffing [editline]20th March 2017[/editline] Why would a DLL execute bash?

[QUOTE=Ott;51989113]Pretty sure he's bluffing [editline]20th March 2017[/editline] Why would a DLL execute bash?[/QUOTE] I don't think it matters if it actually does or not; as long as those who want to pirate it think it does.

nvm

[QUOTE=Skipcast;51989106]seems like a really dodgy and malicious thing to do imo.[/QUOTE] I'm not being serious All the DLL actually does is turn your computer into a grenade and blow your family to smithereens.

[QUOTE=phygon;51989207]I'm not being serious All the DLL actually does is turn your computer into a grenade and blow your family to smithereens.[/QUOTE] Phew, I was actually worried there for a second.

[QUOTE=phygon;51989207]I'm not being serious All the DLL actually does is turn your computer into a grenade and blow your family to smithereens.[/QUOTE] I think the issue with stuff like that is that a legitimate customer could be turned away by it by doubt alone. Then again, most people should recognise this as a joke or at least ask you about it. I don't really get why anyone would pirate programming assets though. You can't publish anything with that stuff without risking to get sued.

[QUOTE=Tamschi;51989957]I think the issue with stuff like that is that a legitimate customer could be turned away by it by doubt alone. Then again, most people should recognise this as a joke or at least ask you about it. I don't really get why anyone would pirate programming assets though. You can't publish anything with that stuff without risking to get sued.[/QUOTE] I mean, people steal whole games and upload them onto the steam store, some games have audio and art assets stolen from other games etc. It is illegal, but that doesn't seem to stop them given valve's fairly lax moderation policy [editline]poo poo bum willy[/editline] [QUOTE=phygon;51989207]I'm not being serious All the DLL actually does is turn your computer into a grenade and blow your family to smithereens.[/QUOTE] You are a truly talented programmer, grenade.exe is top tier business

[QUOTE=Darwin226;51988350]Here's an explanation that I don't often hear when people ask what a monad is. Say you have a value of type Int in a strict, non-pure language. You don't know where it came from because it doesn't matter. Now say you're in a non-strict (as in, lazy), non-pure language. Your Int might not yet be evaluated, and in order to evaluate it you might need to do some IO, perhaps query a database or something. Suddenly you need to start caring if the Int you have is a simple number or if it's actually a side effecting computation waiting to happen. So the way you decide to do that is by differentiating these values at the type level. Ints that can't do anything special remain just Ints, but those that require some side effect evaluate will be decorated with a special IO type. Now you have two incompatible things, Ints and IO Ints, and there's no way to make a mistake. The only problem is that you can't really do anything with the IO variants so you need to define some operations that make sense for these values. Firstly, we should be able to "promote" a normal Int into an IO Int. Nothing bad can happen by assuming some pure value does side effects. So that's our first function, `Int -> IO Int`. Next we might consider the opposite. A function that takes an IO Int, does the side effect and gives you a normal Int back. The problem is that we're still in a lazy language so this side effect again won't happen until we start doing something with our normal Int. This is the same problem we started with. So `IO Int -> Int` is out of the question. There are many candidates for potential functions to include, but it turns out that pretty much all the sensible ones can be implemented with the following function: IO Int -> (Int -> IO Int) -> IO Int. So a function that takes an `IO Int`, and takes another function `Int -> IO Int`. When the side effect finally gets executed we get our normal Int out of it. Then we feed it into the provided function which can also potentially require additional side effects to produce a new number. The final result, an IO Int, represents an Int we'll get when both of those side effects get executed. Notice that we don't have a problem we had with the `IO Int -> Int` function because we never claim to produce normal Ints. We just keep stringing on functions that will eventually get run when the side effecting starts to happen. Now we have a pure, lazy language. It's pure because the side effects never really happen. Our code just constructs this huge plan what to do. Then the runtime takes that plan and actually executes it. If you get this, you get what a monad is in a practical sense. Further insight comes from the realization that many more things, other than just our magical IO, also allow for the same interface. So you call everything that implements this interface a monad. The other generalization is, of course, that talking about Ints here is completely arbitrary since the whole story works for any kind of value. Now as far as theory goes, there is a bit of a disconnect. Monads in Haskell are more "inspired" by category theory than they are derived from it. Actually seeing the parallels between mathematics and code does yield significant insight about what this interface does and doesn't let us do, but understanding that is in no way required to be able to say you "know what a monad is". Common question is "so what's so special about this?". Well, there is a certain minimality to the interface we defined. Because it's so minimal, a HUGE number of ideas and constructs can implement it. On the other hand these two functions are enough to be able to write whole libraries worth of functions, without ever talking about anything more concrete. The whole laziness story above is the actual motivation for introducing this concept into Haskell. I feel that it provides a useful perspective for understanding monads. That being said, the interface itself has nothing to do with laziness. It's just a solution to some of the issues.[/QUOTE] holy fuck, does that make a promise a type of monad?

[QUOTE=Icedshot;51989992]I mean, people steal whole games and upload them onto the steam store, some games have audio and art assets stolen from other games etc. It is illegal, but that doesn't seem to stop them given valve's fairly lax moderation policy[/QUOTE] They don't moderate actively enough, but as far as I know they crack down pretty hard on any kind of copyright infringement [URL="https://steamcommunity.com/dmca/create/"]once they're notified[/URL]. I'm pretty sure they permanently ban companies and individuals who are caught selling copyrighted material on their platform. [editline]edit[/editline] There's at least one game that didn't get banned permanently, [URL="http://www.shacknews.com/article/95645/activision-invoked-dmca-law-to-remove-steam-game-that-stole-assets-from-call-of-duty"]though that had a freelancer steal assets[/URL]. [QUOTE][editline]poo poo bum willy[/editline] [...][/QUOTE] [editline]:wideeye::ass:[/editline]

[QUOTE=Darwin226;51988350]Here's an explanation that I don't often hear when people ask what a monad is. Say you have a value of type Int in a strict, non-pure language. You don't know where it came from because it doesn't matter. Now say you're in a non-strict (as in, lazy), non-pure language. Your Int might not yet be evaluated, and in order to evaluate it you might need to do some IO, perhaps query a database or something. Suddenly you need to start caring if the Int you have is a simple number or if it's actually a side effecting computation waiting to happen. So the way you decide to do that is by differentiating these values at the type level. Ints that can't do anything special remain just Ints, but those that require some side effect evaluate will be decorated with a special IO type. Now you have two incompatible things, Ints and IO Ints, and there's no way to make a mistake. The only problem is that you can't really do anything with the IO variants so you need to define some operations that make sense for these values. Firstly, we should be able to "promote" a normal Int into an IO Int. Nothing bad can happen by assuming some pure value does side effects. So that's our first function, `Int -> IO Int`. Next we might consider the opposite. A function that takes an IO Int, does the side effect and gives you a normal Int back. The problem is that we're still in a lazy language so this side effect again won't happen until we start doing something with our normal Int. This is the same problem we started with. So `IO Int -> Int` is out of the question. There are many candidates for potential functions to include, but it turns out that pretty much all the sensible ones can be implemented with the following function: IO Int -> (Int -> IO Int) -> IO Int. So a function that takes an `IO Int`, and takes another function `Int -> IO Int`. When the side effect finally gets executed we get our normal Int out of it. Then we feed it into the provided function which can also potentially require additional side effects to produce a new number. The final result, an IO Int, represents an Int we'll get when both of those side effects get executed. Notice that we don't have a problem we had with the `IO Int -> Int` function because we never claim to produce normal Ints. We just keep stringing on functions that will eventually get run when the side effecting starts to happen. Now we have a pure, lazy language. It's pure because the side effects never really happen. Our code just constructs this huge plan what to do. Then the runtime takes that plan and actually executes it. If you get this, you get what a monad is in a practical sense. Further insight comes from the realization that many more things, other than just our magical IO, also allow for the same interface. So you call everything that implements this interface a monad. The other generalization is, of course, that talking about Ints here is completely arbitrary since the whole story works for any kind of value. Now as far as theory goes, there is a bit of a disconnect. Monads in Haskell are more "inspired" by category theory than they are derived from it. Actually seeing the parallels between mathematics and code does yield significant insight about what this interface does and doesn't let us do, but understanding that is in no way required to be able to say you "know what a monad is". Common question is "so what's so special about this?". Well, there is a certain minimality to the interface we defined. Because it's so minimal, a HUGE number of ideas and constructs can implement it. On the other hand these two functions are enough to be able to write whole libraries worth of functions, without ever talking about anything more concrete. The whole laziness story above is the actual motivation for introducing this concept into Haskell. I feel that it provides a useful perspective for understanding monads. That being said, the interface itself has nothing to do with laziness. It's just a solution to some of the issues.[/QUOTE] Thank you for the detailed reply, I can definitely see the use for it, especially now with the insight into why these foundational constructs are useful and necessary, in a programming context. I haven't gotten to the video on monads yet, so my edit was mostly made in jest, but your contextualization will no doubt make it easier for me to understand completely when I get to it. Thank you!

MSVC and GCC were just playing around with their code when suddenly Clang showed up and started yelling error left and right. MSVC tried to ask what was wrong but Clang just yelled "Not standard compliant!". GCC tried to protect MSVC but Clang responded "You're too blind to see what I can with my two phase lookups". What I'm trying to say is that sometimes you have to delay your lookups. Unfortunately remembering all the rules of when something is or isn't a dependent lookup is a pain in the ass.

N I C E [t]https://puu.sh/uSJJG/ecdbb6dcb7.png[/t]

It's not much, but I'm proud of finally being able to piece together something that resembles a game. Still a lot I don't understand but I'm learning! [vid]https://pred.me/videos/2017-03-21_14-08-10.mp4[/vid]

[QUOTE=Ac!dL3ak;51990047]holy fuck, does that make a promise a type of monad?[/QUOTE] It does. So are arrays/lists with the flatmap function. So are basically all collections.

[QUOTE=PredGD;51991198]It's not much, but I'm proud of finally being able to piece together something that resembles a game. Still a lot I don't understand but I'm learning! [vid]https://pred.me/videos/2017-03-21_14-08-10.mp4[/vid][/QUOTE] Now juice it [video]https://youtu.be/Fy0aCDmgnxg[/video]

[QUOTE=PredGD;51991198]It's not much, but I'm proud of finally being able to piece together something that resembles a game. Still a lot I don't understand but I'm learning! [vid]https://pred.me/videos/2017-03-21_14-08-10.mp4[/vid][/QUOTE] video is broken on firefox

I asked really nicely and got myself an actual workstation at work. I've been using my Surface Pro 2 since I started last June, and honestly I'm tremendously impressed with how well the wee little i5-4300U in this has held up. Debugging and compiling my program has become killer though, and intellisense keeps breaking (thanks for 6000 headers, Boost) but doesn't at home on my 6700k. The new workstation is all assembled (7700k, 32GB RAM, 512GB SSD) but needs to have an OS installed along with generally being setup properly. Unfortunately, the guy who will be doing this is in a conference call with the DoD so I'm stuck waiting (but knowing its assembled). Seems like a good [del]time[/del] excuse to finally watch the whole of "C++ Seasonings" though

[QUOTE=paindoc;51991973] Seems like a good [del]time[/del] excuse to finally watch the whole of "C++ Seasonings" though[/QUOTE] Was that Sean Parent's talk at GoingNative '13?