Denuvo email leaks

VMProtect is another protection suite for general software (common programs). It's one of the best suites to protect stuff (along with Themida). Because of the message I imagine they're saying that VMProtect is suspiciously similar to Denuvo, but I don't think that would be correct since VMProtect has been cracked for long, and Denuvo is, supposedly, much more difficult to crack.

It's a possibility, but quite unlikely due to how painful it would be to maintain. I'd say C++ given how flexible it is.

godspeed future colleague

This isn't even going into the trash, this is going straight to the incinerator.

Has somebody tried logging into that Amazon cloud server?

please do
I'm about to faint of exhaustion

gee i dont know

There's three reasons why we don't program games in Assembly anymore, not even as an optimization.

One: It takes too fucking long. If you think writing your own boiler plate code in C/C++ is annoying, imagine how awful it must be in a language like Assembly where NO ONE HAS WRITTEN GAME CODE IN THE LAST 30 YEARS. There's no Unity in Assembly, there's no Unreal Engine in Assembly. If you want to write an engine like Unreal Engine in Assembly it will take you YEARS even copying the fucking Unreal Engine code.

Two: The compiler nowadays is more efficient at writing Assembly code than you are. This isn't even a fucking joke, the compiler has been optimized like fuck to give you the fastest speed you can obtain to do the things you want to do. This isn't like 1989-1996 where you have to write Assembly hacks to get the game to render to screen fast enough.

Three: Lack of support for all of the big name interfaces (APIs). OpenGL 4.0, DirectX 12, even XNA .. you're not going to get to use any of those in Assembly. The best you hope for is either GDI or OpenGL 1.5, maybe 2.0. So unless you want to write your own code to do the same shit that DX/OGL/etc. then you're shit out of luck up the creek without a paddle.

The reason we don't write Assembly code anymore is because there's no reason to do so. Assembly is as close to metal as you get. As such there's no high-level development kits, you might find a library someone wrote for something, but you're going to be writing your engine yourself.

Not really going to follow this thread but I'm going to weigh in on this.
Every time you increase a layer of abstraction you inevitably introduce some overhead that is difficult to account for.

Yes, pretty much what you said is true…however…You have to consider that modern tools are built on these layers.
Layer after layer after layer.
To the point where they become bloated and inefficient. It seems to follow that the more "user friendly" a programming language gets, the more inefficient it ultimately becomes.
Java is a great example of this and once more because of this it became an industry standard. As such, it dominates and yet it is a piece of shit in all matters of optimization.

It all concludes back to, at a certain point, you have to return to getting to the metal. Otherwise you end up building abstraction on top of abstraction and everything becomes more delicate as a result. You go from building with concrete and steel to eventually stacking a literal house of cards!

You see this problem pronounced in the "multi-platform" considerations of development as of the recent decade. Remember, there were plenty of exclusives that MAY have been eventually ported to other consoles back in the "day" (PS2 era and before) but this was due to wildly different architectures and considerations. as a result…the games on any give platform were wildly different in quality because they were PRODUCED FOR THAT PLATFORM.
And towards the end of a system's lifespan you saw some wonderful things being squeezed out of it.
You won't see that anymore.

Anyway…we may not return to such a thing but sometimes we really have to. We have to dig back into the lower layers every now and then to clean up, remake, and re-purpose.
Really just because we are hitting bottlenecks we need not have.

Hello, fellow Computer Engineer here (B.S. in 2012).

Have you actually had courses in assembly yet?
I made a chat program in assembly. While tight and small and super efficient the writing of it made me want to kill myself and maybe any others around me.

That's some nice nonsense you're saying there. The Unreal Engine, for example, is written not by Software Engineers but by Computer Scientists. The Unreal Engine 4 isn't just Unreal Engine 3 with extra code on top. They overhaul and rewrite significant portions of it to reduce these "bottlenecks." We don't write completely system neutral code. That's just not a thing that we fucking do. The compiler has directives in it that we use for this kind of thing.

#ifdef __WIN32

This directive right here? We use this to poll if the system we're developing on is Windows. Yes even Windows 64-bit returns true when polled to see if it's 32-bit Windows. Because 64-bit Windows is actually x86-64 which means "the x86 architecture with the 64-bit expansion header." The only time you really run into a system that's either 32-bit or 64-bit (and can't be both) is either in Linux where they require your binaries be compiled specifically for one or the other (as stupid as that is), or in ARM which is kind of a dead architecture outside of cell phones.

__WIN32 is used to see if we're on Windows, if we are, then we load the proper libraries. It can be used for OS-dependent code such as code that only works on Windows/only on Linux/ony on ARM. Through the use of directives we don't have to worry about writing 900 different apps, because we've really moved away from middleware that was completely OS dependent. You write one function, you write it as system neutral as you can, and if there's steps that have to be done differently based on OS you can write those ifdefs in the middle of the functions. This has *0* overhead because the compiler IGNORES the code that doesn't correspond to its own directives. Code for Win32 is invisible to Linux. Code for Linux is invisible to ARM.

As an example, threading. Before C++ unified the process across different machines, we used to have to write some ass looking code to use multithreading. But in C++11 Bjorne Stroustrup and the rest of the assembly who is responsible for maintaining C++ decided "hey, you know what we should do? Fix this shit, remove the complication so everyone can easily use it."

There's lots of great headers for this kind of thing. There's chrono for timing, there's thread for threading… And so multithreading is as simple as either declaring a STL thread object OR detaching the threaded functions. Where you used to have to mutex and lock your threads, C++ now does this automatically. With detached threads, you write a thread that no other process is going to work on, and just let it run. And it will, it will run until the program is ready to quit or you set for the function to die (in whatever way you deem to do that).

There's also just calling a thread and the joining it afterward. The join function is your mutex, it will monitor the functions that you set to thread, wait for them to complete, and then synchronize your threads. So your threads won't write data to the same variables at the same time. This is why we don't have a vast ocean of exclusives and very few multiplats these days, is because we have plenty of good tools to work with in our already low-level libraries. But see, these are like a noose. They give you enough rope to tie it all together in one tight little fuckable obedient package or they give you plenty of rope to hang yourself with.

If we want to get to metal, we use C++, because it's already close to the metal as it is. We don't go down to fucking Assembly. No one does, no one SHOULD, and no one will.

That's regressive, it's not helpful at all. There's optimizations to be made, but these are optimizations to be made in the right ways, and the wrong way to do it is to start writing Assembly black magic code in your render function, unless that Assembly code is part of a shader. We write shaders in a variety of languages, so sure that can work to write your shaders in Assembly. If you want to teach the computer how to walk with everything you do, then go for it.

And you know what? Python despite being high-level and interpreted is still far more suitable for games than Assembly is. So quit saying ridiculous shit.