LWJGL: Lightweight Java Game Library 3
lwjgl.org
lwjgl.org
[1] https://en.wikipedia.org/wiki/Project_Valhalla_(Java_languag...
That said... the potential to exploit security holes via GL library calls is, unfortunately, alive and well even with WebGL.
There are already a few projects doing exactly that.
One could even create a ActiveX compliant library, that via emscripten would be able to target WebAssembly.
Having programmed several 3d engine, I can say it's really simple to program a 3d engine but it's really hard and time consuming to program one that has reasonnable performance.
Minecraft was especially bad because it used very old version of OpenGL (the 1.5 - 2.0 OpenGL with fixed pipeline) which is really not adapted to modern GPU.
Actually Java and the JVM are the heroes here, because the guys that took over after Notch, just wrote shitty code allocating several hundred MB per second on the game loop.
Also the majority of Mincraft plugins are written by kids, whose understanding about how to write game code is nonexistent.
Yes, there are some performance issues regarding lack of value types, but not every single game is going to be the next Crysis.
Yet it appears by some in the game community that if language X cannot be used for doing Crysis than it is not worth it, let alone that most likely they will never finish their game.
Unity's runtime is a fossilized version of Mono, with much more performance issues than OpenJDK, yet indies flock to them.
Only because they are deeply committed "to all or nothing", in what concerns advancing the status of doing game development in .NET. Since they created their own AOT compiler (IL2CPP) they have even started to port sub-components from C++ to C#.
Our internal performance testing is ranking Java on par with the C++ implementations of the same algorithm (performance typically flattens until a bottleneck is reached such as disk read speed) or completing the same tasks faster. In one side this is due to the JVM optimizations done automatically, the other side is having developers that understand how to write efficient code. This does require an experienced developer which understands how his code is impacting performance.
For example, avoiding ArrayLists or String objects and learning to use direct arrays or char objects. I can see LWJGL being useful, most particularly to help keep the infrastructure under the same language so that development and long-term maintenance are not a nightmare.
So do good c/c++ programmers, especially now that it's increasingly rarely taught in university and there is less fresh meat coming into the industry, yet games still get made.
> Yes, there are some performance issues regarding lack of value types, but not every single game is going to be the next Crysis.
It's not just value types, it's reference indirection everywhere. You can't declare an array of objects for example, only an array of references to objects, which isn't cache friendly. There are similar issues if you want to actually use many of the features higher level languages come with. It's why java/c# will never be as fast as c.
As far as unity goes, all the heavy lifting in the game engine is still done in c/c++, c# is only used as a scripting language. As far as I understand LWJGL, it is not analogous to unity, it's not a game engine but a low level library to write a game engine with.
C# has value types, added local references and reference returns on C# 7, and they will be adding more features from System C# (Midori) in the 7.1, 7.2 and 8.0 releases.
https://github.com/dotnet/roslyn/blob/master/docs/Language%2...
Microsoft recently did an interview where they admitted they only cared to make their native code compilers for .NET "good enough" and are now planning on changing that.
https://www.infoq.com/articles/high-performance-dotnet
Also .NET Native actually makes use of the same backend as Visual C++.
Java is not yet there with value types, but in about 5 years time, Java 10 will be here with them. They are also available in prototype form today for anyone that wants to play with them.
I wrote my first games on a Timex 2068, since then I have witness and took part in many variations of this subject.
Started with, no serious game programmer would use anything other than Assembly. C, Pascal, Basic, Modula-2 lack the register control, memory layouts, instruction count, ability to self modifying code that Assembly allows for.
Followed by, no serious game programmer would use anything other than C or Pascal. C++ adds too much bloat to make any game worthwhile playing.
Now he are on, no serious game programmer would use anything other than C or C++. Java, C# and other type safe languages will never perform as good as C and C++.
Fact is that the majority of games I see on the stores aren't really AAA pushing the hardware limit, many of which have graphics and gameplay that could have been done with AMOS on an Amiga 500 and people would hardly notice.
> As far as unity goes, all the heavy lifting in the game engine is still done in c/c++, c# is only used as a scripting language
Since IL2CPP got mature some of that C++ code is actually C# code. If you pay attention to the Unite 2016 and 2017 keynotes they are rewriting the not so performance critical components from C++ to C#.
Finally the programming language compilers that come with the games consoles and OS SDKs also play a big role, and games developers tend to stick with what they get with the SDKs.
Ever play text adventures? Even back then a lot of non-critical code was written in higher level scripting languages. I'll even go out on a limb and assume you know what the AGI engine is.
> Followed by, no serious game programmer would use anything other than C or Pascal. C++ adds too much bloat to make any game worthwhile playing.
We haven't moved beyond this point AFAIK, most games will use either c or the zero cost parts of c++ for the core engine.
> Java, C# and other type safe languages will never perform as good as C and C++.
For 20 years now I've been hearing java will match the speed of c one day, yet I'm still waiting. Fool me once shame on you...
Lots of them, they were quite common on the Iberian peninsula. Many of them used PAWS.
http://www.worldofspectrum.org/infoseekid.cgi?id=0006825
> For 20 years now I've been hearing java will match the speed of c one day, yet I'm still waiting. Fool me once shame on you..
Just like C will never match the speed of Assembly and people are pretty ok with it. Also C compiled without UB optimization tricks isn't that fast.
C had 40 years of compiler optimizations, so Java still has 20 years to catch up, back in the 8 and 16 bit days junior Assembly coders could write better code than C compilers would generate.
For most people being a few ms slower doesn't matter at all, specially if they aren't playing Crysis, Battlefield or any other AAA game.
Microsoft's first decision was to port everything into C++, which they finished doing this year.
It might even be the second most popular way to make indie games, after Unity. Depends on how you count "indie" games.
basically anyone thinking they might want to use Java could use Monogame instead and have a much better time.
Practically, not having value types is not really the kind of problem you'd expect it to be. Cache coherence with something like Mono or the JVM is less of a priority (nice-to-have but let's be real here) and a bunch of arrays of primitives looks uglier than C# structs but it mostly comes out in the wash.
Kotlin, Frege, Clojure, Fantom, Ceylon, JRuby, etc. There's a language for everyone. So building more value into the JVM with projects like that would be really great.
The JVM is probably the most advance VM currently, and hopefully it'll just keep getting better, maybe faster startups with the new module system, hopefully in java 9 they add value types, etc. All to say, I think more people should look into the JVM as a platform for the future.
I would also add as an aside is that most production Java applications are rather large, with several large dependencies.
That said, reified generics I think are a limit of the JVM bytecode. But type erasure has its own advantages over reification. So one is not clearly better then the other, just offers a different set of trade offs.
Won't happen in 9. The way it currently looks like there will be a experimental support on the VM-level in 10 and language level support no earlier than 11.
At least in my experience, I've had a great deal of fun working with LWJGL and it is a pleasure to use. It's very unopinionated and doesn't try to force you into any sort of specific structure. On top of that, Java + LWJGL hide a significant portion of the cross-platform mess that you inherently see in this field. No matter where you stand on the issue, setting up a project to build and run cross platform, and managing its dependencies is a pain point in C/C++. Add a trivial maven configuration once and you're good to go the majority of the time. Having a mature package manager is also something that you shouldn't ignore.
No one should shy away from writing a game if all they're familiar with is Java/some JVM language. It's a gradient between choosing the right tool for the job and premature optimization. Here's a video of what looks to be a dead project, but still serves as a decent tech demo of a nice looking game running on the JVM https://www.youtube.com/watch?v=eM_bABrFERs .
I went from doing general IT to being a professional software developer, and the first thing I ever starting coding was that engine.
A bit simpler and great for getting started is Construct3, which is a HTML5-Game-Editor which runs in the browser. They did a great job with the App. https://www.construct.net/
If you're investing into anything serious, I would strongly recommend going with Unity over this.