Godot 3.3(godotengine.org) |
All I can say is working with Godot is an absolute bliss. Seriously, it's fun, it's "easy" and it gets out of the way. Within a couple of weeks, you can be focusing on making your game, rather than a constantly evolving tech-demo.
There are only two caveats: understand what Godot is not good at, 3D open world / large landscape, and console development.
Godot 4.0 was a total mess the last time I tried it though. The Vulkan stuff was completely half baked and the UI was acting out. Godot 3.2 though, solid fun.
Godot 4.0 still has a long way to go before it's ready for everyday use fortunately, not even in alpha state yet so I wouldn't judge it too prematurely.
Godot just doesn't fight you the way Unity does.
So if you're in space, and you're flying nearby a big ship full of triangles, such as an imperial star destroyer, you run your framerate down to the ground if you render even only 5% of it, as it renders everything else as well.
You can mitigate that to some degree by breaking up objects, but even the shell being plain would still cause massive issues.
For first person, open world, or large environment type game, I'd recommend Unreal. For 3D isometric style games, it's perfectly suitable with knowing the caveats and minimal adjustments from an asset creation perspective.
The 3D it can do is kinda... "shoved" into it. It works but it wasn't designed from the ground up like other native 3D engines are.
Last I checked the editor has no advanced 3D scene editing features, and the engine itself has no basic capabilities that are needed for large open world 3D games, like being able to load tons of stuff on the fly as the player moves in a way the player doesn't notice.
My company cannot afford to wait until Godot 4 to build product. And since we’ve got a big investment in prior work, there is little chance we will switch that work over to a platform that will be brand new in a short period of time.
Don't get me wrong, I'm not saying you have no right to complain. But the way you're going about it is off-putting. Godot's devs are working hard and what you're saying isn't constructive.
I mean, it's MIT licensed. So no, not really. It's designed to make games, and the commercials are left to you.
My advice: don't bother waiting for Godot 4 just because it sounds nice. You'd be surprised at how many of the "limitations" of the 3.x branches are not actually problems at all for most use cases (granted, your company may have a very niche use case...)
Will it be a good choice for FPS shooters taking place primarily in closed spaces like buildings, etc?
If you're keen on this, I recommend using Trenchbroom for level design and the plugin that goes with it in Godot, it's pretty cool! (Qodot)
I was starting to make a 3D game for mobile and was planning on using UE4, but I've heard a lot of good things about Godot. Are there any pain points or blind spots in Godot's feature set?
for 2D I'd definitely go Godot.
I mostly do 3D games with fixed or limited range cameras (not first persons) so Godot works nicely.
Overall you'll need to understand well the engine you choose going forward. They all have their pros and cons.
As an example, it takes 3-4 hours to recompile the UE4 engine source code (for customization). Godot, about 4-12 minutes, in its entirety.
Having used C++ and Blueprints extensively, GDScript is really a breeze. Of course games perform better if made entirely in low level C++, but as an indie you have to make a choice and you have to ship a game.
Looking forward to better tilemap support in 4.0
Curious if you had a direct experience with the console side of things with your game?
Also, can I provide you an opportunity to promote your game by asking you to tell us more about the game you shipped? :)
(The rest of this isn't directed at you but more trying to clarify the Godot console situation for anyone else interested.)
I've noticed there seems to be a lot of misunderstanding (particularly by "less commercially experienced" game devs) in relation to Godot's "console support" or apparent lack thereof.
Godot do now at least have a page[1] to directly address the issue and clarify the situation which can be mostly summed up with:
"... there is no engine that is legally allowed to distribute console export templates without requiring the user to prove that they are a licensed console developer."
and:
"Console ports of Godot are offered by third-party companies (which have ported Godot on their own)."
I seem to recall there was one FLOSS game engine that got a grant or something to incorporate support for some XBox initiative (that wasn't "full devkit support" level) but for every other major console there's no engine that has FLOSS code supporting it--and if it did then no one could probably tell anyone about it because of NDAs. :D
As a side note[0]:
"Additionally, there is some unofficial third-party work being done on building for some consoles. However, none of this is included in the default build scripts or export templates at this time."
The situation is also the same for other FLOSS projects, e.g. the Rust language, where the issues tracking game console support basically say "if you have the ability to develop for (current) game consoles, you also know we can't talk about it here where others aren't under manufacturer NDA":
https://github.com/rust-gamedev/wg/issues/90
https://github.com/EmbarkStudios/rust-ecosystem/issues/18
https://www.reddit.com/r/rust/comments/jtqgn4/q_feasibility_...
Hope your game is selling well. :)
[0] https://docs.godotengine.org/en/stable/about/faq.html#which-...
[1] https://docs.godotengine.org/en/stable/tutorials/platform/co...
Godot by default does not support consoles. Yes, you can to employ another company to port it for you, but that is a no go for me. UE4 on the other hand you can do it all yourself once you get the developer kit and access (legally) to the platform of your choice.
On the other hand you can easily do mobile with Godot.
I'm very impressed with the quality of Godot and its continuous improvements.
I say this because I've shipped physics simulation games and Godot has been the simplest most reliable engine for that.
I haven't played around with other engines that much so I can't comment on how they work.
[0] https://stride3d.net/ [1] https://vvvv.org/ [2] https://janet-lang.org/
This feels so satisfying for some reason, it feels like it set ups a great feedback loop where improvements needed to improve the editor also result in improvements to the whole platform
I have no issues with current fonts. Enable filter in your font settings, can try importing at a massive size designing at a high render scale, and using the viewport scaling to scale it down.
Native viewport (no scaling) and using no scale on your labels should make it all render as you'd expect, however.
The animation support is also excellent, allowing to key every node property and even adding code calls perfectly adjustable in the timeline. I never used Flash to create things myself, but I hear people comparing Godot to it in terms of being able to do stuff. And from my own experience I believe it.
For 2D games I can't quite think of anything better. My own stuff has plenty of 2D visual effects (think of a discount version of the Super Robot Wars series in terms of looks), shaders, a zillion explosions and even my former computer (already a toaster circa 2014) barely registered CPU activity. 3D wasn't as good, although I was able to do little things that looked fine and performed okay in my former computer, it was noticeably more intensive, and the 3D demos by other people with full effects and high poly counts went at like 5FPS (they run smooth in my new machine, but gotta think of the weakest link). Godot 4.0 promises interesting upgrades on that field, though.
Since my game is going to need 3D for dungeon navigation I think I'll try to wait until 4.0 is released to finish that part, even if I have to port my code to accommodate for breaking changes. I did it with an earlier game in the transition from 2.x to 3.x and was a bit tedious but not really difficult. I'm not in a hurry and I can improve plot and features while at it, I'm just going to release it as FOSS when done, so I can wait and see if the improvements are worth it.
That's a preamble to recommending to check out popular open source games like OpenTTD, 0 A.D., or Cataclysm: Dark Days Ahead. None of them use Godot, but they all use game development principles that you would apply in Godot if you were using it.
Might be third party companies out there that could be hired to do the porting, but I don’t know.
This is an open source project, so they can do what they want.
Isn't it a bit onerous to ask the users to build/rebuild the whole engine/toolchain if we want to use the c++ version in Windows.
I don't compile Intellij for my environment to use if, for example.
And of course on the blue website /r/godot and /r/madewithgodot
[0]https://www.youtube.com/watch?v=yRHN_WEulLc
[1]https://www.youtube.com/channel/UCrHQNOyU1q6BFEfkNq2CYMA
[2]https://www.youtube.com/c/Gdquest/videos
[3]https://www.youtube.com/watch?v=iDEcP8Mc-7s&list=PLS9MbmO_ss...
I really enjoyed his style and he does a good job hitting all the important points.
It was a very simple process, there were one or two typos I found in the code that an experienced programmer should be able to resolve themselves if they haven't been fixed yet.
I haven't done more yet since but would like to. Unfortunately playing games is too fun.
I mean, yes and no? In that the 3D renderer is a completely separate system to the 2D renderer. But, that means that the 3D renderer... was designed from the ground up to do 3D. Unlike the other direction with Unity, where 2D support is a hack of the 3D engine.
I've been using Godot 3's 3D features for quite a while now, and obviously as a single indie developer I'm not using it for AAA features, but it's still as competent as any other renderer I've used for my use cases.
> Last I checked the editor has no advanced 3D scene editing features, and the engine itself has no basic capabilities that are needed for large open world 3D games, like being able to load tons of stuff on the fly as the player moves in a way the player doesn't notice.
You're going to have to be more specific about "advanced 3D scene editing features", as the editor is actually very good, besides which, I compose most of my 3D scenes in code. Meanwhile, Godot supports everything needed to stream assets at runtime, from multi-threading support, to async resource loaders, LOD, and so on. Granted, you have to kind of roll your own.
The main issue people bring up for large, open world 3D games (which may be a dream of most developers who've not really made a game yet, but in any engine quickly becomes a "one day" project and not something feasible for most people) is the 3D renderer itself, which doesn't have occlusion culling, but again in most realistic cases you wouldn't ever notice this (and it has been added as a feature to Godot 4 already).
For example, recently I was messing around with voxels, and recompiled the engine with a C++ module called "Voxel Tools"[^1]. This supports level streaming and movement throughout large levels without floating point errors (ie, you have a VoxelViewer node that gives the illusion of moving through a large space, while actually not moving further from the origin than you can see).
Do other engines cull parts of objects?
That would only leave 3D models + minimal scene (e.g. top-down/isometric games), which minimizes the amount of occlusion?
For a couple of data points, here is the official Godot third person shooter demo:
https://github.com/godotengine/tps-demo
And you can also find "Platformer 3D" demo here (playable in browser too):
https://godotengine.github.io/godot-demo-projects/
The showcase also has some 3D games that have been produced:
https://godotengine.org/showcase
Also TailQuest in development 3D Platform/Puzzle:
https://www.reddit.com/r/godot/comments/gnfjn9/tailquest_so_...
Various people have experimented with voxel worlds and other things which push the limits of the engine & are viewable on YT.
In short, with 3.0, Godot isn't competing with, say, Unreal in the 3D realism stakes but it still has more 3D capability than most people who start to make a 3D game will actually hit when the scope of the work required becomes apparent. :)
facebook is a large financial contributor to the godot project. I think they do some dev work too. I get the impression they really want more VR games to exist, and work well on their device, no matter how they get there.
There is limiting of overdraw (not rendering the same pixel multiple times) which is easy with Z-buffers. There is frustum culling (not rendering triangles that are outside your FoV or facing away from you) already of course.
The final type of culling is occlusion culling which is avoiding rendering that starship because it's on the other side of a planet from your viewpoint (for example). That's not a feature of 3.X but it's a feature of 4.0. The technical details are pretty interesting, it uses Intel Embree (the raytracing library) to do a low-res raytrace to find the occlusions.
Occlusion culling in Unity is fairly straightforward. Simply requires a bake. It also supports 'occlusion areas' where you can give it a hint to do a higher resolution occlusion bake e.g. if you think the player will likely be in that area.
Edit: originally misread parent as stating Unity didn't frustum cull by default. Parent comment is correct.
All builds (except for server/headless build which is Linux only) are available for Linux, macos and Windows as binaries. This includes the standard build and the Mono build. All builds are also capable of loading dynamic libraries at runtime which you can write in C++.
Compiling the whole thing definitely seems onerous but it's surprisingly easy, even for me who barely knows C++. If you're interested you can read about it here: https://docs.godotengine.org/en/stable/development/compiling...
Most people don't compile the engine themselves though, but it's a very viable option if you know how to use a command line.
The tutorial starts with C but there is a C++ one as well.
Again though, I would recommend at least trying to compile the engine once. It's simple, reasonably fast and you can extend the engine as much as you like https://docs.godotengine.org/en/stable/development/cpp/custo...
I don't even see what you mean by it being "a c++ available for linux". You got the same choices for all systems. Just download the editor/engine and start programming. No need to compile anything, except your own scripts/logic if you choose to use a compiled language.
I'm curious because i'm dabbling in some gamedev and wanting to eventually ship mobile and console. I'm more focused on bleeding edge tooling though, Rust gamedev specifically, but i'm curious if the reasons Godot doesn't ship to console also means any Rust project won't be able to ever, either.
Is there something preventing opensource lowbudget projects from shipping to console? Are you forced to go UE4/etc if you want to ship consoles?
* Godot dev team isn't a commercial entity with console development license agreements.
* Even if they were, the console support couldn't be truly Open Source due to licensing & NDA agreements with the console manufacturers.
* There are third parties who have ported Godot to consoles who may work with you port your own Godot game.
* You could always port it yourself.
Another aspect that they don't mention is that for the Godot dev team themselves to support consoles they'd essentially have to create an entire parallel development infrastructure (repo, issue tracking, CI etc etc) per console to maintain the NDA confidentially requirements.
In regard to Rust, they were another example I mentioned up thread about this very situation:
"""
The situation is also the same for other FLOSS projects, e.g. the Rust language, where the issues tracking game console support basically say "if you have the ability to develop for (current) game consoles, you also know we can't talk about it here where others aren't under manufacturer NDA":
https://github.com/rust-gamedev/wg/issues/90
https://github.com/EmbarkStudios/rust-ecosystem/issues/18
https://www.reddit.com/r/rust/comments/jtqgn4/q_feasibility_...
"""
So, the "something" that is "preventing opensource lowbudget projects from shipping to console" is manufacturer license agreements/NDAs that are the antithesis of & a barrier to cross-company Open Source development. :)
[0] https://docs.godotengine.org/en/3.0/tutorials/platform/conso...
Console SDK seems to be not compatible with open source
https://docs.godotengine.org/en/3.0/tutorials/platform/conso...
It is another, smaller engine. I would say less featureful than Godot, but I imagine there are some overlapping use-cases?
Ed: and for something quite different - dragon ruby seems a lot of fun (not free, not open source, though): https://dragonruby.org/
And, yeah, that's fair enough--although I imagine if you offered one of the companies enough money they might be willing to license their port under similar terms to those Epic offers UE4 console support under. :D
(And given at least two companies have apparently ported Godot so far, porting it oneself is presumably also an option & one would have full source to work with.)
Are there other examples of it being better for 2d?
EDIT: This doesn't just apply to 2D, so maybe it's a weird reply.
It has parallax scrolling features built in. Small thing, but there are lots of little features like that scattered in the default tools that just don't exist in Unity without writing your own, or paying for an asset. In Godot you just drop the node in and you're away. Godot has an asset store too - where everything is free and open source, and linked to their git repositories. For example, you can add a minecraft-like voxel engine, dialog editors, a Redux-like store, shaders, new GUI elements, and so on in Godot for free, in a click, without an account, or a single webview or browser page in sight. Granted, this means that older assets may no longer work or be maintained, but the same can be said of Unity (and my experience with the Unity asset store is that half the time, nothing works out of the box anyway even when you've paid a chunk for it, and rarely does a tool just do the simple thing that it says it does, and therefore takes a bunch of work just to get the thing to play nice with your code).
The recent 3.3 release added a bunch of 2D renderer improvements such as BVH partitioning/batching for rendering and physics, vertex pixel snap on the GPU,
The only thing that Unity has over Godot in terms of 2D imo is the Box2D physics engine (Godot uses its own 2D physics implementation that, while adequate for a lot of games, isn't quite as flexible as Unity). That said, there are at least 2 Godot plugin modules that add (partial) Box2D support just from a brief Github search.
Moving away from 2D specifically - the animation player/controller in Godot is amazing - you create an animation player node, and you can then key in literally any property of any object from the editor to be animated, and draw out animations with bezier curves and so on, animating multiple properties at once, which you can then play back with a simple call to `AnimationPlayer.play("name");`. You can use a single animation to animate vectors, enums, bools, simultaneously by just drawing them into the animation editor. Last I checked Unity didn't have anything like that. You've got a complicated mesh structure with layers of materials and shaders, and you want to interpolate various properties on various materials of those mesh structures, it's as simple as creating the animation, going to the materials, and hitting the key button on the properties you want to alter.
From a general design perspective, Godot's scene tree works kind of like Unity's nested prefabs - a feature they implemented long after Godot had nailed this kind of structure, and it still does it in a much simpler and less hacky way than Unity. Everything in a Godot game is already essentially a nested prefab, without the clunk of having to distinguish between regular prefabs holding nested prefabs, or ensuring your modified prefabs are in sync, and so on. You can create simple components composed of complicated structures of nodes, save them into a new scene file with a click, and drop that anywhere else in your scene tree wherever you like, as a native and expected behaviour. It's a bit like React components in that you can very easily combine and produce new combinations of your existing work, even at runtime. You can then easily share these nodes between godot projects, or even write a simple plugin to add them to Godot's list of built-in nodes.
Oh, and all of those scene, node and resource files are just plain text files, easily editable in a text editor, and extremely friendly to VCS.
Besides all of this, if you write a game in Godot you own 100% of the source code, both your game code and the engine supporting it. No licensing, no pricing plans, no salespeople. No official support, yet the community and contributors are extremely helpful. Engine doesn't do something you want? You can patch it and recompile, and add new third party C++ modules (eg, you can add full Javascript/Typescript/Rust/D/Python/Nim scripting support this way, as well as new engine features with native speed) by dropping them in the modules folder of the engine source. There's a legendary talk at GDC by Jeff Vogel, who's been writing obscure, ugly RPGs as Spiderweb Software since the mid-90s. One of his points is that if you want to make a living writing indie games as a solo developer, owning the source code is one of the best things you can do, since 20 years down the line you can still update and compile it, remaster, and sell more copies of work you finished long ago (which Jeff has done many times, and is still now writing those obscure games and supporting his family from it). Good luck getting Unity 2020 to work, build your game, and have the license to use it commercially in 2040 ;)
Plus, you can support a much larger range of hardware with a true 2D renderer that targets specific 2D graphics APIs, than with a cutting-edge 3D engine hacked to look 2D.
Like, there's Node2D and RigidBody2D and Bone2D and Camera2D etc etc etc.
Essentially the main parts are probably:
* Support the platform native C compiler. (e.g. convert your build system & any idiosyncrasies in your/their code).
* Support the platform OS.
* Support the platform native graphics API.
And, yeah, the easiest way to do this (while still maintaining cross-platform compatibility) is to have an abstraction layer of some sort between the game engine & console specifics.
And, Godot does already have this abstraction layer to support multiple platforms, it's just that everyone who wants to use it on consoles has to reimplement it themselves--unless they work with a third party who has already ported it.
(AFAICT there's nothing that would stop a company from doing a console Godot port and then saying "We can't Open Source this code but will license it freely to anyone who can prove they're a registered console developer" but I'm not sure what the commercial incentives for that might be.
It'd reduce unnecessary duplication and could in theory allow for (licensed developers) to improve the code base in cooperation but would be quite the undertaking & also a significant but also necessarily invisible community contribution!)
He doesn't post often, but when he does, it's a great one about indie game development.
It doesn't seem like they've made much progress in Godot 3.3 - seems like a grant ran out so they had to let their C# dev go, so I don't expect any major changes for the foreseeable future.
Keep in mind that I'm obviously quite soured by the experienced - Godot might still be the right choice for anyone who is considering. I'd just recommend anyone to factor the very rough C# support into their choice, especially for anyone planning to use it for a more involved project.
Now, I did already know the Godot API quite well when I started using C# so that contributes. But I haven't found it to be a second-class citizen at all, and in fact allows me to use features that I wouldn't have been able to in GDScript (native event handling, offloading to native data structures for computation rather than using the Godot API for them, nuget packages, and so on). I can also use eg Jetbrains DotTrace to profile code in much more detail than GDScript, and edit and launch my game code from an IDE without ever opening the editor.
You can also opt to use the dotnet-core compiler instead of the bundled Mono one these days which allows you to use some more modern features.
The only clunky thing I've found is that trying to use a native C# data type in a Godot Node object causes marshalling errors, but I'm pretty sure that would apply to nearly any Mono game engine and that Unity has similar issues (having to wrap things in MonoBehaviours etc- it's been a while so this may be inaccurate). The simple workaround is just to use the Godot API for things that are in the scene tree, and native types when you need to compute stuff with better performance.
I'm curious as to what actually felt rough to you in C#?
Also, the async/threading model breaks it's chains and requires developers to know about the internal implementation. That to me is a serious WTF.
You're going to have to know that stuff for any game engine that isn't just a pure C# framework. Unity is no exception afaik, you have to use the Unity API Job system to be able to run threads safely. I use async/await in Godot C# all the time. Threading requires using the Godot API, sure, that's natural, since threading can be a mess in video games.
"It uses a syntax similar to Python (blocks are indent-based and many keywords are similar)."
And[1]:
"If you've ever written anything in a language like Python before then you'll feel right at home."
So it's more than just whitespace.
I seem to recall it being acknowledged that Python was a big influence on GDScript's design and in a number of cases "How does Python handle this?" drove some of the design decisions.
[0] https://docs.godotengine.org/en/stable/getting_started/scrip...
[1] https://docs.godotengine.org/en/stable/about/faq.html#what-i...
> The default language in the engine is basically python, so it could cause a performance bottleneck.
https://docs.godotengine.org/en/stable/about/faq.html#what-w...
The key aspect seems to be that there's a commercial entity behind the project who presumably has console development licenses.
AFAICT none of the console specific source is Open Source but the implication seems to be that the source is (freely?) made available to registered console developers due to the fact the developer of both is a licensed console developer and has decided to make it available to others.
Console development/distribution is mentioned in a couple of places in the documentation[0]:
"The hello.hl file contains bytecode that can be run with the HashLink virtual machine using hl hello.hl. It does give quite good performances and have been proven by successful commercial games such as Northgard or Dead Cells.
However, it is also possible to compile the HashLink code using a native compiler. This allows to compile for consoles and mobile.
This will create a directory out containing a lot of generated C code that needs to be built using a native compiler and linked to the same HashLink runtime[...]"
With regard to console support it says:
"... for Consoles (Nintendo Switch, Sony PS4, Microsoft XBoxOne), please contact us at nicolas @ haxe.org if you are a registered developer for one or several of these"
And here[1]:
"The final resulting shader will then be compiled to the target platform native shader language (HXSL currently supports GLSL for OpenGL, HLSL for DirectX 11+, AGAL for AdobeAir, and PSSL for Sony PS4)."
Also, this post[2] describes how the lower level parts (using Haxe/hashlink) integrate with native (i.e. console) platforms:
"The game gets compiled to a cross-platform .hl file that can be run with HashLinkVM JIT. It can also be compiled to C directly and compiled using any native compiler, which we are using for our console ports on PlayStation, Xbox and Nintendo Switch."
"We also have additional platform API libraries for Steam, as well as console integration libraries that are only accessible if you have a registered developer."
In the same post the Heaps.io console implementation is described:
"This architecture allows us to integrate new renderers or platforms by just porting a few classes given that the native libraries are been made available in HashLink. Heaps.io supports the following plaforms/renderer:
[...]
HashLink/C with NVN (Nintendo Switch SDK native graphics API)
HashLink/C with GNM (PS4 SDK native graphics API)
HashLink/C for Xbox One SDK"
[0] https://heaps.io/documentation/hello-hashlink.html
The exposed console functionality interface can be found via `hl_console`, `usesys` & `usegl` references:
* https://github.com/HaxeFoundation/hashlink/search?q=hl_conso...
* https://github.com/HeapsIO/heaps/search?q=usesys&type=code
* https://github.com/HeapsIO/heaps/search?q=usegl&type=code
The "interesting" pieces are all in some other codebase, e.g.:
* https://github.com/HaxeFoundation/hashlink/blob/4c4de37d49cf...
* https://github.com/HaxeFoundation/hashlink/blob/4c4de37d49cf...
And, if you're a weirdo like me that likes trawling for small console development details (e.g. they treated as ~BSD system) in the code base check out these:
* https://github.com/HeapsIO/heaps/pull/491 (fixes for Nintendo "NVN")
* https://github.com/HaxeFoundation/hashlink/commit/7af111a38f... (PlayStation related naming becomes generic "console" naming)
* https://github.com/HeapsIO/heaps/commit/0daba3517a7193566cd0... (More specific console -> generic changes)
* https://github.com/HaxeFoundation/hashlink/blob/4c4de37d49cf... (Console brand specific defines)
* https://github.com/HeapsIO/heaps/pull/349
I guess it's all sufficiently vague to not break any NDAs. :)
I think my curiosity is now satisfied. :D
this doesn't have anything to do with the syntax. we could completely replace python syntax with e.g. pyc bytecode or serialised AST data but the language would still be challenging to execute efficiently as the language is still exactly the same
one can get a few ideas of how python could perhaps be made faster by reading about all the restrictions that rpython imposes
If "basically python" means "scripting language" vs "C++" then I can see why by that standard "performance" could be a concern to someone.
But, yeah, doesn't seem to be a Python/GDScript specific concern.
There used to be a time when we had accelerated 2D graphics cards, even with support e.g. GDI, and then the 3D graphics accelerator was an additional card.
So there was a transition period when GPUs were still 2D accelerators that could do some 3D on the side.
Then graphics cards got the ability to do matrix operations in hardware, this was still mostly 2D with 3D super powers.
However then shaders came into the picture, as consumer hardware finally became cheap enough to adopt capabilities of graphics workstations hardware.
First only Assembly language for GPUs, but by the time DirectX 8 and OpenGL 2.0 became widespread, we got C like shading languages.
GL ES 2.0 is basically OpenGL 2.0 only with shaders and hardware transform and lighting removed.
If you want to make best use of the GPU there is no way around writing shaders, regardless of it being 2D or 3D graphics engine.
In fact you want to code most of the typical 2D effects as shaders running directly on the GPU.
Graphics cards haven't had 2D acceleration for decades so you're always using the 3D features.
Is that true of eg, the graphics chip in an older android phone, that only supports gles2? That's mainly what I mean by that statement.
And so even if I was careful to write shaders that efficiently operate in 2D space, those efficiencies would be trumped by the hardware converting it all to 3D space anyway?
I guess my intuition was that if you have a full 3D shader setup, eg the Unity renderer, that you add a layer of new shaders on top of to give a friendlier 2D API, that's going to be slower than just writing the 2D API on its own.