What are you working on? v66 - February 2017 - Developers

[QUOTE=DoctorSalt;51789476][...] On another note, in c# how would you write a regex to split "10+20" into tokens/string arrays?[/QUOTE] Something like [code](\d+)(\D)(\d+)[/code] should work, but note that you can't use (a plain) Regex to tokenise arbitrarily long composite expressions. [editline]7th February 2017[/editline] You can use [code]d+|\D+[/code] to get them one at a time, or [code](?<!\d)\d+|(?<!\D)\D+[/code] to find all tokens at once with [URL="https://msdn.microsoft.com/de-de/library/b9712a7w(v=vs.110).aspx"][I]Regex.Matches(input, pattern)[/I][/URL], unless Microsoft uses some weird Regex flavour. If you don't need/want multi-character operators, just use [code](?<!\d)\d+|\D[/code] instead.

[QUOTE=WTF Nuke;51787965]Any C++ magicians remember/know why std::future::then had so many issues with sequencing/order of evaluation? I always see it as an argument for the strengthened sequencing spec introduced in C++11.[/QUOTE] I'm no magician, but from what I remember this was exactly because the order of evaluation of chain expressions like this idiomatic one [code] std::string s = “but I have heard it works even if you don’t believe in it” s.replace(0, 4, “”).replace(s.find(“even”), 4, “only”).replace(s.find(“ don’t”), 6, “”); [/code] is undefined in C++11/14, but is perfectly determined in 17.

I'm starting to suspect that any sufficiently advanced C++ program will, given enough time, contain a complete implementation of the STL that is just slightly less garbage. [editline]8th February 2017[/editline] So far I'm up to std::future, std::promise, std::aligned_storage, std::aligned_union, std::variant, std::any, std::make_signed and std::make_unsigned

[QUOTE=Tobba;51791463]I'm starting to suspect that any sufficiently advanced C++ program will, given enough time, contain a complete implementation of the STL that is just slightly less garbage. [editline]8th February 2017[/editline] So far I'm up to std::future, std::promise, std::aligned_storage, std::aligned_union, std::variant, std::any, std::make_signed and std::make_unsigned[/QUOTE] Could you use boost for these components? Pretty sure they have the various aligned elements, and it might be less terrible. fyi make sure to build the tool "bcp" too (although this applies to anyone using boost, I had no idea this existed and it seems a lot of people don't), if you go this route. Turns out it lets you install only certain modules to a directory, and only copies the relevant build items + includes. The build items have the proper jam/make files setup, so you can just use b2 to build only what you need. Unfortunately for me, "boost::log" still requires several thousand (!!!!!!) headers but hey I cut my file count down from 7k to 4k and intellisense hates me a lot less now

[QUOTE=antianan;51791279]I'm no magician, but from what I remember this was exactly because the order of evaluation of chain expressions like this idiomatic one [code] std::string s = “but I have heard it works even if you don’t believe in it” s.replace(0, 4, “”).replace(s.find(“even”), 4, “only”).replace(s.find(“ don’t”), 6, “”); [/code] is undefined in C++11/14, but is perfectly determined in 17.[/QUOTE] Right but I thought the whole point of future::then was that it took a callable as an argument which would be unevaluated until invoked, meaning that it isn't affected. [editline]7th February 2017[/editline] [QUOTE=Tobba;51791463]I'm starting to suspect that any sufficiently advanced C++ program will, given enough time, contain a complete implementation of the STL that is just slightly less garbage. [editline]8th February 2017[/editline] So far I'm up to std::future, std::promise, std::aligned_storage, std::aligned_union, std::variant, std::any, std::make_signed and std::make_unsigned[/QUOTE] Wait why/how/what?

[QUOTE=WTF Nuke;51792136]Wait why/how/what?[/QUOTE] * std::future and std::promise are practically unusable since .then() was removed from the standard. * std::aligned_storage and std::aligned_union are broken for alignments over sizeof(double) on MSVC, asked STL about it and he said it was intentionally broken since larger sizes would break the compiler (but none of my code hit that bug anyways) * std::variant and std::any specified in C++17 and I don't have the compiler for that (plus my implementation is a bit stricter). Doesn't help that MSVC 2017's C++17 mode is (subtly) broken beyond belief. * std::make_(un)signed has an unforutnate wording in the standard and turns out to be SFINAE unsafe, need a wrapper to fix it up Just alternate implementations shoved in my oversized base library.

Starting up an aimless OpenGL project to use/test my ECS and I gotta say reworking everything and using newer tools, which I am very GLAD to do (seriously, that lib has debugging built in) is nice. I finally reworked my RAII managed OpenGL resources to work in a nice and extensible way and am gonna add assimp support for that juicy model loading. Just nice to be working on a small clean code base, unlike at work which has millions of lines of code.

[QUOTE=cam64DD;51788990]still working on my shitty mspaint-based forum simulator [video=youtube;ttEyCNPOyL4]https://www.youtube.com/watch?v=ttEyCNPOyL4[/video][/QUOTE] this is slick as fuck. with a good story this could be a fantastic game.

I got annoyed about the fact that I always forget to draw. So I wrote a service that kills any process I launch if it's from inside my steamapps folders if I haven't launched an art program yet in the current PC session :v: [IMG]http://i.imgur.com/N85i6YN.png[/IMG]

[QUOTE=WTF Nuke;51792136]Right but I thought the whole point of future::then was that it took a callable as an argument which would be unevaluated until invoked, meaning that it isn't affected.[/QUOTE] As far as I understand, the problem is that after the first future is ready and can be moved as a parameter to the next [I]then[/I]'s callable, there's no guarantee that exactly that next [I]then[/I] will be called.

[img]http://files.facepunch.com/ziks/2017/February/08/chrome_2017-02-08_13-29-57.png[/img] Displacements! Although my code for finding normals across seams is pretty fucky

[QUOTE=Ziks;51793918]http://files.facepunch.com/ziks/2017/February/08/chrome_2017-02-08_13-29-57.png Displacements! Although my code for finding normals across seams is pretty fucky[/QUOTE] What's the problem with seams? Can't you linearly interpolate using the 2 nearest normals?

[QUOTE=cam64DD;51788990]still working on my shitty mspaint-based forum simulator [video=youtube;ttEyCNPOyL4]https://www.youtube.com/watch?v=ttEyCNPOyL4[/video][/QUOTE] Yo, this looks fun! [editline]8th February 2017[/editline] [QUOTE=Ziks;51793918][img]http://files.facepunch.com/ziks/2017/February/08/chrome_2017-02-08_13-29-57.png[/img] Displacements! Although my code for finding normals across seams is pretty fucky[/QUOTE] FYI, it's good to add triangle area into mix. I mean, if you calculate vertex normals, you should also calculate nearest triangles areas, sum it and then calculate each triangle weight. This weight is then used for calculating weighted normal.

[QUOTE=DrDevil;51794140]What's the problem with seams? Can't you linearly interpolate using the 2 nearest normals?[/QUOTE] That's what I'm doing, the gross part is how I'm finding the orientation of neighbouring displacements. The BSP contains a field describing that orientation, but my interpretation of it doesn't seem to be right. Instead I'm brute forcing it by testing each of the 4 orientations to find the one that is the best fit. [editline]8th February 2017[/editline] [QUOTE=Fourier;51794150]Yo, this looks fun! [editline]8th February 2017[/editline] FYI, it's good to add triangle area into mix. I mean, if you calculate vertex normals, you should also calculate nearest triangles areas, sum it and then calculate each triangle weight. This weight is then used for calculating weighted normal.[/QUOTE] Ah yeah I've been seeing some dodgy normals near small faces, so I'll try that. Thanks!

[QUOTE=Ziks;51794166] Ah yeah I've been seeing some dodgy normals near small faces, so I'll try that. Thanks![/QUOTE] Here, I found this specific homework that might help you greatly! (and everyone else dealing with normals) [url]http://brickisland.net/cs177fa12/?p=285[/url] ...scrolled through this article again, it's lots of math mumbo-jumbo, but more down you will see what I was talking about :).

Someone absolutely ages ago ( Maybe > 1 year ) was working on some UDK project of a music festival stage, and had programmed lights and such into it. I'm 90% sure it was posted in one iteration of this thread. Is anyone here the person who made that?

[QUOTE=Ziks;51794166]That's what I'm doing, the gross part is how I'm finding the orientation of neighbouring displacements. The BSP contains a field describing that orientation, but my interpretation of it doesn't seem to be right. Instead I'm brute forcing it by testing each of the 4 orientations to find the one that is the best fit. [editline]8th February 2017[/editline] Ah yeah I've been seeing some dodgy normals near small faces, so I'll try that. Thanks![/QUOTE] Find the vertex on the brush face closest to the start position and rotate the vertex list accordingly.

[QUOTE=Instant Mix;51794521]Someone absolutely ages ago ( Maybe > 1 year ) was working on some UDK project of a music festival stage, and had programmed lights and such into it. I'm 90% sure it was posted in one iteration of this thread. Is anyone here the person who made that?[/QUOTE] Could be Tower Unite. Did it involve minigolf?

[QUOTE=Tobba;51794723]Find the vertex on the brush face closest to the start position and rotate the vertex list accordingly.[/QUOTE] -snip- Figured it out, I'd made a mistake elsewhere. Seems like the orientation matches now. [editline]8th February 2017[/editline] [QUOTE=Fourier;51794477]Here, I found this specific homework that might help you greatly! (and everyone else dealing with normals) [url]http://brickisland.net/cs177fa12/?p=285[/url] ...scrolled through this article again, it's lots of math mumbo-jumbo, but more down you will see what I was talking about :).[/QUOTE] Thanks, yeah I revised it to add up ABxAC for each triangle that meets at a vertex, then normalize the result. Seems smoother now.

Speaking of normals, is there a way to lock normals in 3ds max so that splitting a smooth object doesn't make cracks?

Trying to implement shadow mapping, reworked some of the lighting code. However, you are looking at the shadow mapping in effect in the picture. Yeah... [img]http://i.imgur.com/5PNNbef.png[/img] Figured out the issue I had with the depth buffer earlier, and it should be properly read into the shader. Just doesn't want to do anything. Maybe sleeping on the issue again will help me figure out a solution.

Do you ever feel like "this works but oh god the code is horrible and is nearing the point of unmaintainability", and you want to re-make it from scratch, except the old code accounts for a hundred edge cases and there isn't any pretty way to repeat the same behavior in a simpler system? Excuse my sleepy rambling. I'm writing a compiler and the way I decided to structure it long ago turned out a bad choice (duplicates bugs and makes it hard to add new things) that I am now stuck with because thousands of lines of code rely on that structure.

[QUOTE=Nikita;51796679]Do you ever feel like "this works but oh god the code is horrible and is nearing the point of unmaintainability", and you want to re-make it from scratch, except the old code accounts for a hundred edge cases and there isn't any pretty way to repeat the same behavior in a simpler system? Excuse my sleepy rambling. I'm writing a compiler and the way I decided to structure it long ago turned out a bad choice (duplicates bugs and makes it hard to add new things) that I am now stuck with because thousands of lines of code rely on that structure.[/QUOTE] When it comes to compilers, I tend to try to isolate all these edge cases, write them up as test cases and have them be auto-tested for correctness, then when I want to rewrite this part of the compiler, start rewriting the component in parallel to the rest of the program, checking against your compiler tests on the way :v: Then when everything looks green, just slot in the new component instead of the old one! Of course, if there's no way to replace the part you intend to rewrite in this manner, then it's probably a good way to rewrite it either way :v: Either way, regression testing = aw yiss On a random, but slightly unrelated note, here is a project I've been plonking at for a while: [url]https://github.com/profan/meia-lua[/url] A language design project (well, right now just a lexer, parser, CST, CST to AST transformer and Lua AST) Intended to be a project where I can explore building a superset of Lua (so it should parse all Lua code and be compatible with all Lua code, it parses *most* Lua code, spits out equivalent Lua code at the moment, excluding multiline strings and not handling multiline-comments exactly to spec :v:) Right now.. It's just a slow Lua compiler, but with this I can build ontop of it, first step intended is to build in pattern matching (as in ML languages) into meia-lua, cause it's something I've wanted to have in Lua for a long time! Currently for "real testing", ingests this awful lua code: [url]https://github.com/profan/meia-lua/blob/master/examples/timecop.lua[/url] ... And it spits out something like this: [t]http://i.imgur.com/E7PQiWt.png[/t] Properly pretty-printing code with indentation and all is to be done (as you can see parsing is EXTREMELY SLOW RIGHT NOW, need to replace with a yacc-based parser) But basically it's intended to spit out understandable Lua code as end-output, not super-optimization, just language construct experimentation. Will post again later when it actually does something more interesting, like translate pattern matching constructs into Lua code :v:

[QUOTE=Ziks;51794856] Thanks, yeah I revised it to add up ABxAC for each triangle that meets at a vertex, then normalize the result. Seems smoother now.[/QUOTE] Cool :).

Found one problem...I'm really bad at keeping variable names consistent between the shader and the program. [img]http://i.imgur.com/ok6UD77.png[/img] Got a feeling that's not how shadows work, barring the bias I haven't accounted for yet. Ah, I see why the shadows could possibly look a bit funky. (view is where the light's staring at) [img]http://i.imgur.com/vxvIxVS.png[/img] The depth buffer looks pretty wonky and I'm not sure if it's because my scale is off for the light

[QUOTE=The Inzuki;51797178] *wonky shadow stuff* The depth buffer looks pretty wonky and I'm not sure if it's because my scale is off for the light[/QUOTE] Ehhhhh that's an interesting depth buffer. Are you maybe doing projection weirdly?

[QUOTE=Radical_ed;51778328]Fuck everything about SDK interfaces that call asynchronous methods that don't have event completion listeners and won't let you attach your own. On another note, OpenFire, my firebase analytics + database plugin for unity is coming out soon, and i'm pretty excited to release my first "professional" unity asset. [img]http://i.imgur.com/O0rmtY7.png?1[/img] Unity thread on it [URL="https://forum.unity3d.com/threads/coming-soon-openfire-firebase-powered-unity-analytics-authentication.454421/"]here[/URL].[/QUOTE] Just integrated the database, and it looks like it's fast enough to do networked gaming [img]http://i.imgur.com/OkjZ9S2.gif[/img] The top sliders sets the value in the database, and the bottom one gets from the database. The back-end hardware's all handled by google, and getting and setting data from the DB is really, really easy.

[QUOTE=antianan;51793733]As far as I understand, the problem is that after the first future is ready and can be moved as a parameter to the next [I]then[/I]'s callable, there's no guarantee that exactly that next [I]then[/I] will be called.[/QUOTE] I don't really understand this, or how it relates to evaluation order. Mind elaborating more?

[QUOTE=Nikita;51796679]Do you ever feel like "this works but oh god the code is horrible and is nearing the point of unmaintainability", and you want to re-make it from scratch, except the old code accounts for a hundred edge cases and there isn't any pretty way to repeat the same behavior in a simpler system? Excuse my sleepy rambling. I'm writing a compiler and the way I decided to structure it long ago turned out a bad choice (duplicates bugs and makes it hard to add new things) that I am now stuck with because thousands of lines of code rely on that structure.[/QUOTE] Yes. Similar to what Profanwolf said I've got some code I started writing in late 2009. I've learned a lot about programming since then and I've started adding a bunch of regression tests to make sure I don't break anything in my incremental tidy-ups. Also, someone once told me that there are stages of a large system - the first is the one that turns into an unmaintainable mess, the second is the hugely over-engineered mess and the third is when it's done right.

[QUOTE=Ott;51794803]Could be Tower Unite. Did it involve minigolf?[/QUOTE] No, don't think it had any connection to Tower Unite. I can't remember whether it was controlled through FFT's; however it didn't look like it was to be used as part of an existing game. Just remember the light effects being particularly good.