It would be interesting to add an emscripten version, ie. slight modifications to the original C++/OpenGL code to make it compile with emscripten and run in the browser. After some fooling around I got that to work, however nothing shows up because the shaders need to be rewritten for WebGL. Looks like this was already done for the JS/WebGL version, but the shaders are less fancy and clearly don't map 1-to-1 to those in the C++/OpenGL version, so the code will need to be modified a bit either way.
You do have to decide if you want to restructure you code to be event based or if you want it leave it as is and set emscripten to generate really slow code for your main loop
It can display other languages but uses a static font glpyh texture instead of using a font cache (there are too many characters to use a static texture).
It can't take input from an IME so no CJK input or other IME languages.
The Metal version in particular looks terrible, but then again low level APIs like Metal, Vulkan and whatever subset of Direct X are all meant for vendors, not individual developers.
Actually, if continue under this world with unlimited developer resources, the Cycles version should look the most realistic. It's markedly different than any of the other renderers included in this list because it's an offline path tracer whereas Unity and friends are for real-time rendering. We rely on a lot of hacks (Phong shading, FXAA, normal mapping) to produce an interactive 3D scene at 30+ FPS, but once you remove the real-time constraint, we can apply a lot of very fancy algorithms to more realistically render your scene. Cycles might take minutes or even hours to render a single frame, but it spends this time on a whole host of involved computation (physically-based BSDFs, Monte Carlo integration, Metropolis light transport, etc) that more accurately model how light interacts with materials.
The OpenGL version looks really aggressively bump mapped. The Cycle's version doesn't appear to have any bump mapping enabled.
Edit: The depth of field in the Cycle's version also looks a bit weird, and blurs away most of the terrain's detail.
The cycles version, on the other hand, is actually using the depth map to displace a high-res mesh -- a more general technique that should yield results as good or better than parallax mapping. I'd chalk up any perceived differences to lighting and material parameters.
I would say the later, either unfamiliarity with the hardware/software or time constraints because the PS2 is capable of much better than what is shown here.
"This repository contains multiple implementations of the same 3D scene, using different APIs and frameworks on various platforms. The goal is to provide a comparison between multiple rendering methods. This is inherently biased due to the variety of algorithms used and available CPU/GPU configurations, but can hopefully still provide interesting insights on 3D rendering."
It's a mixed bag of APIs, software, hardware and tools, approaching the rendering in very different ways. There's even an offline renderer (Blender Cycles) and a software real time renderer in the repo.
Well, isn't usability the most important criteria to compare it on?
(lazy they didnt have a gallery already ready... lazy that (we) the readers dont ant to click through to each pic..
In particular, resource binding is very different between Metal and Vulkan. Metal's resource binding is more simple/traditional. Vulkans is... sensible, but substantially more complex.
Caveat: haven't used either professionally, read the code in the repo, or had my morning coffee. I've also never touched Dx12, but I've heard it basically works the same as Vulkan here.
So, in practice, if they are noticeably different in the dynamic case, you'll see those differences in the "as if it were dynamic" case, which is most graphics demos of this sort.
Would be intriguing to see how far older architectures like ps2dev can be pushed on modern hardware.
For the DS, note that he seems to be targeting the original DS (e.g. not DSi OR 3DS). I remember there being some slightly better stuff but not significantly better than what he made.
The GBA version also looks pretty good on my DS lite (compared to games on the system). You can't rotate the camera though, so the dragon doesn't rotate. The monkey-head rotates on it's own though and looks pretty good. You're right that there are a few games that do 3D on the GBA, but I can't imagine it's fun coding wise since it the hardware support is basically zero in that regard. But there are some weird ones out there - Banjo Pilot comes to mind, which is a weird mode-7 3Dish flying game. Not exactly a great game, but pretty cool to see. Even with that game though, they have to sacrifice basically all terrain to be able to render the other characters at a decent speed IIRC, so the entire game is just flat.
And if you want to get really obscure, there is Faceball 2000 on the GB, which is a "FPS" and is 3D (And runs at like 15 FPS IIRC). There's no way you could render this scene on it though besides just pre-rendered sprites like was done with the GBA.
part of this album http://imgur.com/a/XQCEJ
Of course it might be that I have missed it or it is hidden somewhere. I hope it really exists somewhere in the repository, but I didn't find it. I might be too tired to find it and someone else has better luck.
Unity is there, I imagine, because it's interesting to see how it translates code that expresses high level concepts like "meshes" and "materials" into code for to the backend, compared to the hand-written OpenGL or DX or Metal or whatever calls.
Edit: ok if I understand correctly, you need to visit the linked web site, visit each linked repo, and pull each one down? Could you provide a web page with previews, or would the resolution lose all visual differences?
I must be getting into my nostalgic period - I love the GBA version.
That was when I learned I didn't want to be in a career field that would have me using DirectX.
Of course, I can't speak for how hairy OpenGL might get at doing more advanced features, and of course, in a lot of cases games are built on established game engines which do most of the DirectX and/or OpenGL coding for them.
OpenGL has so much implicit state and "defaults" set for you that you can get a "hello world" -style app done really quickly, but then it all falls apart.
And if I'm guessing correctly, you probably used legacy, fixed function OpenGL (ie. no shaders) with immediate mode rendering (glBegin/glEnd). Because you can't do anything in 10 lines with modern OpenGL.
As soon as you start doing something practical, you start fighting OpenGL all the time. It's a badly designed, very error prone API that requires much more developer effort than any of the competing APIs.
If you apply best practices to OpenGL code (don't rely on global, implicit state, use shaders/buffers/etc) , it's about on par with the "lower level" APIs.
My OpenGL boilerplate code and my Vulkan boilerplate code have about the same number of lines of code in them while they do about the same things (create rendertarget, framebuffer, clear the screen, draw some text, draw a triangle, blit to screen, measure performance counters). OpenGL is a bit less by a small margin, but the difference is only in the verbosity of Vulkan code (ie. you have to explicitly type every single pipeline state, even if it doesn't matter, e.g. depth test mode when depth test is disabled).
In my opinion the bottom line is this: Vulkan is verbose but OpenGL is complex. I'll take verbosity over hidden complexity any time.