News for hackers. Stuff that matters.

karmadog

Re:Tim Berners-Lee Officially Supports DRM in HTML on Thursday July 13, 2017 @09:21AM (#14760971)
YouTube probably won't force this, but even if they do, nobody forces you to use YouTube.
Re:Tim Berners-Lee Officially Supports DRM in HTML on Thursday July 13, 2017 @09:18AM (#14760957)
If that's what content creators want, isn't it in their right?

You're technically not allowed to download YouTube videos anyway, there just isn't a convenient measure against it. You're not paying, you're probably blocking ads and now you want to download stuff for free? You're worthless to creators.

Also, you're not getting to see all the videos that aren't on Youtube exactly because there is no DRM.

Re:Create your own Game Engine but don't use it on Wednesday July 12, 2017 @06:54PM (#14757382)
If <whatever language> makes certain assumptions and guarantees on behavior, then no, belief is not enough. It has to be plausible. GC alone really is a big issue and all the research (of which there is a lot) has not solved fundamental issues.

There are of course languages (like Rust) that have the fundamentals to match C/C++, but then it's still a matter of adoption. C++ also still develops.

Re:Create your own Game Engine but don't use it on Wednesday July 12, 2017 @05:32PM (#14756894)
Maybe on a Hotspot VM with JIT, while using frivolous amounts of memory for good GC performance.

You're not allowed to do JIT on consoles or mobile and you're memory constrained. A PC-only game engine is going to be a tough sell these days.

Also, unless you're bundling a JVM (not sure about the legals here) you have to make your Windows (i.e. primary) customers install the obnoxious Oracle Java runtime.

Re:Create your own Game Engine but don't use it on Wednesday July 12, 2017 @05:25PM (#14756829)
SDKs never forced anybody to move to C or C++, but the opposite is true: C/C++ compilers were either unavailable or limited.

"I have seen these words written against C, Turbo Pascal, Modula-2, C++."

So what? Those words probably had a good argument behind them, at the time.

In the MS-DOS days, compilers weren't as good as today, so handwritten ASM paid off.

Re:Create your own Game Engine but don't use it on Wednesday July 12, 2017 @05:14PM (#14756746)
A dropped frame is always noticable. What you can do is keep a budget for GC and then force-collect every frame.
Re:Create your own Game Engine but don't use it on Wednesday July 12, 2017 @02:05PM (#14754936)
First of all, I'm talking about game engines, not games. Both Unity and the earlier Unreal Engine (afaik) used GC-ed languages for scripting.

However, if you want to make a quality game, you can not afford long GC pauses. I know that lots of people make games with GC pauses in them anyway. It is a value judgement, for sure.

It's certainly possible to work around GC pauses, but that effectively means you are manually managing your memory manager (instead of the memory), which can be surprisingly difficult.

It's also possible that whatever you do is so "small" that GC pauses never affect you. Enjoy your free lunch then.

Re:Create your own Game Engine but don't use it on Wednesday July 12, 2017 @01:58PM (#14754851)
Game developers used Assembly to write games when it was the best tool for the job. They then moved to C when it was feasible and then to C++ when that was feasible. For their engines, they never moved on to anything else, because there still is no better tool for the job, all things (tooling, SDKs, platform support) considered.

Unity, Unreal Engine and CryEngine are all written in C/C++. They have sometimes elaborate script bindings, but the engine remains in C/C++.

There's a lot of people leaving college that have never learned how to use C/C++ and immediately they want something they're comfortable with, which is Java/C# or Javascript or maybe even Python. These languages are not good choices for a game engine, for the reasons I mentioned. Will there never be a better language? I did not say that, but it would be an uphill battle.

Re:Create your own Game Engine but don't use it on Wednesday July 12, 2017 @11:05AM (#14753131)
There's two big hindrances for success right off the bat:

1. Refusing to just use C/C++

2. Attempting to support most of the platforms

Both problems compound each other.

All platforms (even Android at this point) have C APIs for everything you need. Creating another layer of abstraction here causes more work and overhead.

Trying to get Java running on iOS with 3D APIs is a huge task in and of itself. The same goes for C# (a task which Unity does for you). Languages that require JIT for performance don't work on mobile (unless supplied by the OS, e.g. JavaScriptCore). Debugging becomes extra-difficult.

C/C++ are not convenient to use, but not hard to use either. It causes discomfort at first, but you get used to it. Being forced to do memory management manually also helps with learning how to structure programs, with a bonus of not having to wrestle GC pauses.

Having said all that, using a commercial engine is totally fine, of course.