After over a weeks worth of debugging, I finally the issue.  I missed a bracket...

The whole compiler basically died giving me all sorts of nonsensical errors.  Would eventually compile and then fail on the linkage stage saying functions that existed didn't.  Moving code around (but not changing it) would cause parts to work but others to fail.  Intellistupid completely failed crashing repeatedly.  All because I missed a bracket???

Come on MS... this is unacceptable.

If that's all you want, why not write a C parser?  You can download the grammar pretty much anywhere, add simple operator overloading, and voila the perfect language?

https://www.lysator.liu.se/c/ANSI-C-grammar-l.html
https://www.lysator.liu.se/c/ANSI-C-grammar-y.html

I agree that C++ is very not-orthonormal.  And I do agree with the sentiment that optional features are often poorly thought out/integrated with the excuse of 'don't use em if you don't need them' (perfect forwarding, universal initializer syntax, and noexcept being perfect examples); which I think it a poor excuse.  But I would'nt go so far as to call C++, D, or Rust failures.

I'm not sure as to why the fixation on operator overloading.  Its a nice feature but in the end its really only 'syntactic sugar'; and there's almost no use for operator overloading without some form of RAII.  Not to be argumentative but you're choice of features you dislike vs the ones you like, seem to be contradictory IMHO.

D is very much like C++, classes, RAII, all the bells and whistles and then some.  It just doesn't have all the backwards compatibility nonsense, and generally just makes more sense.  So if you don't like C++, D is not going to interest you either.

TBH from the sounds of it QMopey likes C and only C and nothing else.  Which is fine, but I don't think you'll ever see a language that'll out-C C, since its been around for so long, and is pretty much ubiquitous.

And this mess is the official spec, it's not just Microsoft rolling their own thing with VS before it's properly out? ):

Its preliminary spec stuff, I didn't even get to the MS specific stuff.  I got through the standard nonsense and said 'f-this I'm out!'...  They keep making the same mistakes over and over again, at some point I'm left wondering if its intentional or if the committee is just dysfunctional.

The "You Don't Know JS" series is good for this. I have read the first two and they do a great job of illuminating some of JavaScript's dark corners. If I used JS more often, I'd definitely read the rest. They're available at the github repo below.

https://github.com/getify/You-Dont-Know-JS

Thank-you   I'm reading it already!

Sounds like we need a new language.

LOL yeah...  I've been working on my own over the years; but it'll still be a while before its at the point where I would want to use it in place of C++ or something else.  I don't think most people would like it though.  I find when discussing things on forums, few people (even fellow programmers) approach problems the way I do.  The arguments for or against languages seem to center are silly/nonsensical issues, nullptrs, object vs data orientate design, compilation speed.  We should be focusing (IMHO) on issues like dependency analysis and handling, object and systems relationships, state management, and usability.

As far as alternatives to C++, the D programming language is pretty good, most of what is good about C++ without much of the nonsense.  I'm also impressed with Rust, its more like a true successor to C.

There's a few main issues (AFAIK... I didn't pull out the standard and triple check everything, but I did read a number of sites that I felt were quite reliable and knowledgeable).

1st is no proper namespace 'renaming'.  The biggest issue right now with headers (at least IMO) is that everything gets dumped in the global namespace whether you want it to or not (Win32 API, for example, being a massive headache because of its header).  So its up to the library author to decide how to set up a namespace (usually just 1 large one for a library and forget about it).  The exporting of a public interface is nice, but still doesn't stop namespace clashes.  A proper module system would allow you to import all the names of a module into a new namespace.  For example something like:

Code:

import my_lib as my_lib_namespace;        // one example of a syntax they could use
import std.iostream using namespace std;  // another example of a syntax they could use, it really doesn't matter the syntax
import Vulkan.Graphics using gfx;         // yet another possibility

This feature just seems like a no-brainer and without it IMO there seems to be little reason to use them.  I mean sure we avoid macros polluting the macro 'namespace' but that leads to issue number 2...

2nd there is no way to pass compile information 'up' to modules.  Many libraries use macros to add/remove/alter features at compilation time.  The use of non-standard extensions, intrinsics, assembly, instruction sets, etc... can no longer easily be controlled by a library user.  Now macros were a mess, fragile and error prone, but we need a way to pass constant arguments through an import to a library 'instance' in such a way as to allow conditional compilation.  This, admittedly, isn't as easy as issue #1 to solve, but if we want modules to replace headers and we want macros to go away for the most part (which I do), we need a way to replace this functionality.

3rd is that sub modules are difficult from a maintenance point of view.  Headers were often seen as annoying to maintain (I personally never felt this way but many other programmers apparently do) with the need to ensure that header contents are consistent with the library contents.  This 'ease of maintenance' was touted as an important feature of modules over headers.  And yet sub modules are a mess and require (at least IMHO) even more effort to ensure consistency.

4th the addition of even more convoluted lawyer-esque concepts that affect all corners of the language with the addition of 'visable' and 'reachable'.  Like in good-old C++ fashion these two concepts are defined by a whole list of caveat's and 'quid pro quos' requiring far too much time scouring the deep corners of the standard to properly grok.

5th... apparently as they are specified they'll actually lead to longer compilation times under many scenarios (https://vector-of-bool.github.io/2019/01/27/modules-doa.html).

 

Download vs2019 is hopes of trying out modules and unless I'm completely mistaken... they suck.

At this point I'm certain the C++ committee's sole purpose is to ensure the language dies a slow and painful death.

[I love javascript.]

I love javascript.

I've been a C++ programmer for over 20 years. It was my favorite language up until a month ago. The ease and speed I can develop small games in javascript is far beyond what I could do in C++, UE4, or anything else I've used. The speed of iteration is just incredible. The amount of features available in vanilla javascript is astounding and the architecture is easy to grasp. It feels like a whole new world has opened up to me.

My advice for any programmer is make a small game in Javascript. Don't use any additional libraries, don't use any additional assets, keep it all in one html file. Use source control though. (Always practice safe coding.) You will have the time of your life. Check out this year's js1k games if you want some inspiration. Also I have been using Brackets to develop in, I would recommend using that if you need an editor. Have fun!

Any good resources for learning it at a low level?  Everything I can find is either high level/geared towards web pages, tied to some particular companies tech, or the latest 'buzz word of the week' nonsense.

It's close to that:
https://computergraphics.stackexchange.com/questions/4094/is-there-a-method-to-do-ray-marching-style-modulus-repeat-with-raytracing
https://www.shadertoy.com/view/lly3Rc
https://www.shadertoy.com/view/MlK3zt

That is kinda what I pictured you were trying to do.  The thing I don't understand is how that will translate to anything resembling hair.

I think you're also getting a bit confused, or at least I am by your explanation.  The modulo (or similar like bitwise AND on a fixed point/integer) is required to avoid having to repeatedly step through the intervals.

I don't understand then... what is depth going to get you?  Just knowing how far an infinitely thin single ray would penetrate wouldn't give you anything that of use.  I don't understand how that would make convincing hair.

What your describing (if I understand it correctly) sounds like Volumetric Appearance Modelling.  Here's some articles that might help: http://www.cs.cornell.edu/projects/ctcloth/

Maybe I'm misunderstanding you, but I don't think that sort of algorithm would work.

Tracing hair is difficult (like grass) because at most scales many strands contribute to the color of a given pixel.  It isn't which strand is hit, its how many, how much coverage, at what angles, and how does the inter-reflection of light affect the final color.

Ray tracing is only an approximation, decent for large surfaces but it breaks down on micro surfaces (hence the use of BRDF and similar).  Cone tracing is really what you want, but its prohibitively expensive.

Using a texture-space/UV space trace, or straight forward rendering, you're still going to have to model the surface of the hair.  I'd just as soon use a BRDF and not worry about the trace.  I imagine you'll get better results and performance that way.

Even if you managed to create a function that analytically performs cone tracing over a UV/texture space projection, summing/calculating the resulting coverage, angle, etc... for a given hair type/thickness/color/texture it would look very similar in the end (I imagine) to a BRDF.

I guess what you could do is use a cone tracing over hairs given a hair thickness/color/texture/etc... and create a BRDF 'offline' which could then be used render convincing hair.  But I just can't see any sense in doing that in real time.

Yeah, they forced Java on me in university.  I hate the thing with a passion.

Soon I'll be looking at creating my own UI (C++/Vulkan), so I've been watching this thread with great interest.

If you could write the API for an immediate mode UI, what would it look like (obviously very simple overview)?  How do you envision it being used?  How do you handle user input?  Manage state?

I've looked at immediate mode UI APIs before, but I felt I lacked the experience to really see the forest for the trees, how things meshed together, and why it would be better.

I guess the thing is I am used to it from my experiences with functional languages but functional languages are usually pure so void return functions are extremely rare and pointless and in some languages impossible.

I can adapt

I'm having flashbacks of Miranda form uni... I hate functional languages (not trying to imply your language is bad in any way ProgramGamer).

I started work on a small programming language as a side project. It's nothing fancy, and isn't even functional yet, but it has been a pretty good exercise in how to make my own lexer, parser, and visitor. Next up is going to be the interpreter so I can actually make it do stuff :D

Here's a github link of course: https://github.com/MiguelArseneault/ndl

ndl stands for "Non-Descript Language", which I think illustrates my infinite wisdom and latent intelligence quite well.

Cool stuff

I like the little stick men running around.  I'm guessing its some sort of puzzle game where they have to make it to the spaceship before the fire burns it all down?

All the casts in your code pretty much scream the opposite to me. And more looks like you can make the shoe fit the hoof of the horse, but it wasn't intended for it at all.

Static casts aren't bad.  I could see if they were reinterpret or otherwise, but static's are the 'safe' ones

Only sad part is that "Designated initializers" are not part of the standard yet, which makes bit flags a bit harder to use as nice inline function parameters.

Completely agree.  That and I REALLY want to be able to overload on constexpr, but I don't think that's ever happening.  I just need to finish my own language but I just don't have the time...

This effect is call "pcg echo" and there was a talk somewhere i can't find back where it was discussed as happening fairly often despite what the number would suggest. Player aren't "collision", they actually spread through the possibility space, it's the same mistake the dev of no man's sky got into when they said meeting another player will be rare, but they did it the first day. I think it's because random is not uniform and tend to exhibit clump, and the player "spread" increase the range likelihood of "collision", couple with that we are very very good at spotting pattern.

That wasn't because of the birthday paradox (https://en.wikipedia.org/wiki/Birthday_problem)?