in c++ you can go off and create your own shader's and graphic libraries, operating systems, etc. because you have speed and closer communication between software and the hardware.
C++ doesnt allow you to write shaders. You are thinking of open GL or direct X.
Shaders really have nothing to do with what language you choose to code you game logic.
Game maker allows you to write shaders in GLSL or HLSL.
You can get creative with Game maker all you want, but at the end of the day, you are going to be dealing with issues regarding speed. It has nothing to do with understanding computer science. It is simply the limitation of the software. Hope you now understand.
Hahaha, it has everything to do with computer science knowledge!
Lets assume GML compiled with YYC is around 20% slower (quite accurate according to some tests), however you look a at it, if your game doesn't quite reach 60 fps in GML, it will only barely be at 60 fps in C++. Hardly a good solution.
That is unless you multi thread your logic but we already established you don't know what that is.
Now let's assume you have a custom collision system that checks all your objects. That's O(N^2) relationship.
Say you study a bit of comp science and choose to implemented t BVH or sort and sweep: you can get down to O(n log(n)) relationship.
That means that if you have 10 items, your game will run about 3 times faster.
Have 10,000 items? Game will run about 10,000 times faster.
As you can see, algorithms are everything.
if you wanted to get close to the hardware you would use assembly or binary?
Assembly, yes.
Have a look at any major engines source code. Quite a few ASM files.
The truth is that you can do a lot of funky stuff in ASM, if you know what you are doing, you can outsmart even C optimizers.
But, most of us here are probably better off sticking to C or C++
Incidentally, did you know that managed/interpreted languages like C# or Java can outperform c++ in some situations?Whilst performing rather similarly to C++ in common workloads? I'll let you think that one over. (That is not true for games due to their kinds of workloads)
- I was just stating this because the guy above made it sound like language of choice has nothing to do with whether your apps or fast or slow. He called my lack of being able to "optimize my app" lack of computer science knowledge
Yes, yes that's probably it!
There is a reason why DLLs are mostly used to wrap libraries or methods GM doesn't make available. But I have not seen it being used to provide logic since GM8, where DLLs for data structures where quite popular. (We got YYC and better arrays since).
obviously he cant see that game maker was made to be a lower level language, and therefor its limits, like draw calls can be reached alot faster and easier if you are not careful.
You can reach the draw call limit faster in GM not because it uses GML, but because it is not a custom engine. You will get the same issues when using other engines too.
Draw calls are ultimately bottlenecked by the rendering engine, not the language that made the call.
And is why GML has a multitude of lower level graphical stuff like vertex buffers.
Another did you know:
YYC will compile your GML to C++ (though, early in UYG talked a lot obput llvm?) Meaning if you know how to take advantage of GML you can get very good performance.
It is my understanding that instance variables end up slower to manipulate than local variables. Though we would need confirmation from one of the devs.
I don't mean to be mean, but it does sound like you are trying to go a little too fast. From what we have heard, c++ is clearly not for you at the moment. But go ahead and figure it out for yourself