> Most open source C++ projects are libraries that are meant to be integrated into other applications. Plywood is the opposite of that: It gives you a workspace into which source code and libraries can be integrated. A single Plywood workspace can contain several applications – a webserver, a game engine, a command-line tool. Plywood simplifies the task of building and sharing code between them.
Well, that is implied by the title: "Plywood: A New [...] Framework". Frameworks are by definition about providing the core elements to build your stuff on top of them[0].
It has been my experience that most software posted on HN has little description of what it does, and no description of why it exists. The parent comment was highlighting the excellently concise mission statement written on the first page. I wish every project would do as well.
The word "framework" by itself provides no indication of how specialized the tool is, or what problem(s) it aims to solve.
The above description indicates that it is a very general-purpose framework (handling things as disparate as game engines and web servers) and that it aims to enable code reuse, not just eliminate boilerplate code.
Eh, no, that description doesn't do that, a better description is what is above it because it actually mentions what it does and provides. The part quoted in the message i replied is largely implied by the word "framework". Of course it isn't a bad thing to be explicit (especially since some people may think that framework is just another word for library), however it isn't any clear about what the framework does.
For example think of MFC: you know what that framework is all about (Windows GUI applications), yet the description could easily fit with MFC (and indeed all of the above have been implemented on top of it).
Actually, you could probably argue that Blender already is these four things (a framework, blender, unreal engine and visual studio (the latter two as part of the game engine(defunct) and editor for example)).
Library from authors Arc80 game engine. Author appears to significant game engine experience:
I’ve worked in the game industry for 14 years. Until 2015, I worked as a Technical Architect at Ubisoft Montreal, on franchises such as Rainbow Six, Child of Light and Assassin’s Creed. Before that, I spent a few years developing desktop graphics software at Corel.
This framework has the potential to become another Qt if UI is been added. The coding style and document[0] are solid and similar with Qt[1]. Giving the Qt is heading in an unpopular way[2], I am looking forward to this framework.
I see often, including in this case, that GitHub contains only a squashed version of the development history. Assuming that the developer keeps working on top of the original branch with full history, is there a way to keep a squashed and a not-squashed branch in sync automatically?
When you say “squashed” vs “not-squashed”, are you referring to the “squash” merge feature in Github?
If so, that turns a PR branch into a single commit onto the target branch (master). Unless the old branches are kept around, the unsquashed commits won’t be available.
I'm referring to the squash feature of git rebase. The developer collapsed years of commits into one before pushing to GitHub, I am wondering if there is a way to keep working on top of the original history privately, and pushing to the "clean" history on GitHub, without having to cherry-pick all new commits for GitHub by hand.
I guess the "easiest" solution would be a clean and separate "github" directory where no work happens and where you just cp all your changes from your actual working directory into.
If they version it, I could also imagine using master as an orphan branch and just cherry-pick the changes between two tags or commits into it.
In this particular case it seems justified as the framework was part of a bigger project. So probably the majority of the commit history would not be relevant to the project in its current state.
I usually wouldn't care about yet another c++ game framework, but this author's prototypes are so impressive and artistic that it makes me believe he's doing something more than just playing around with technology.
Browsing over the code I'd say it's solid and seems to have been used in production. Just about the right amount of abstraction for practical use.
Some parts could be replaced by standard C++ library functionality by now. My biggest issue so far: Use of bare pointers, especially in parser code. This should not appear in new code written in 2020. I'm kind of baffled by that as he seems to use stuff like std::move.
This is no replacement for either Unreal or Unity for sure, it's pretty basic in functionality.
I think "no bare pointers, ever" is overly dogmatic. Raw pointers still have a place, especially in game programming. The standard smart pointer types cover many common situations, but do not cover all situations (nor do I think were intended to).
> The standard smart pointer types cover many common situations, but do not cover all situations (nor do I think were intended to).
They also add a level of indirection, which can manifest as cache misses. If you're iterating through large numbers of objects, memory locality can be a huge gain.
neither shared_ptr nor unique_ptr add any additional indirection compared to raw pointers.
Of course if you can you should use inline value types, but that's a different thing. The parent was talking about replacing raw pointers with smart pointers (personally I have no particular issue with non-owning raw pointers).
This isn't a question of smart vs raw pointers, it's a question of pointer vs value. A std::vector<T> is considered good code in modern C++ and should often be preferred over a std::vector<std::unique_ptr<T>>.
Yeah, the indirection I was referring to generalises to this.
Edit:
You might be saying that STL data structures could have been used by the author to alleviate the memory locality issue, but as noted in another thread, it's common to use custom STL implementations or use entirely custom memory management in performance critical applications, to reduce on memory allocation frequency, memory usage and/or fragmentation. Or maybe the author is just more 133t than thou.
I think it's interesting to look at his code. I have not worked on games myself, but I've understood that most big game studios write their own versions of STL containers, in order to have close control over each and every CPU cycle spent, and in order not to get burnt by changes in the STL, or by slight, or not so slight, variations in performance between different implementations of the STL.
I see that he does the same, keeping his own lightweight string class implementation, for instance, and also his own lightweight smart pointer implementations (Owned and Borrowed). I suspect that he also uses bare pointers and new for similar reasons.
It would be interesting to know if he thinks it is necessary, or if he could have used std::string, std::unique_ptr and std::make_unique instead in this framework.
> I’m releasing part of that game engine as an open source framework
I'm curious what this means exactly. Does it mean that requires the non-open source part to function? Or is it a standalone part of the non-open source engine that can be used by other projects (like a library)?
It's the latter: A standalone framework that can be used by other projects. It's like a library (or suite of libraries) with separate modules for platform abstraction, containers, JSON, etc. A bit more "batteries included" than vanilla C++, and you only link with what you use. These modules are organized into a workspace that helps set up new build pipelines, to compensate for the lack of a standard build system in C++.
My guess would be it's the parts of the game that are generally useful and polished enough to be used as the base for other games (or non-game applications).
Games often have parts that don't quite belong to the engine layer, but also not strictly to this specific game. It might be small adhoc helper modules, glue code to other 3rd party libraries or similar random stuff.
Strictly speaking, you can do it without that stuff, here are some snippets of a test i was doing in Borland C++ Builder 1 (from 1996, that is pre-C++98) a few years ago [0] (not using any of BCB's C++ extensions) which end up with this [1] (it is a bunch of controls thrown in a form mainly to test stuff, but the interesting bit is the property editor at the right).
If you do not mind relying a bit too hard on the preprocessor you can also do it in plain C [2] (i mean, the C++ approach still relies on it a lot, but the C one goes all the way :-P).
A game engine (for a big published game, not my own stuff) i worked on at the past used this approach (the C++ one) heavily and i think it is also quite common in some frameworks.
Though personally outside of experimentation i just use Free Pascal which provides the functionality as a core feature of the language (and next version will allow attaching arbitrary attributes to properties, which addresses my "i'd like to have a description for this property for the editor without writing a GetPropertyDescription method" wish :-P).
Agreed, but that is why it has been an ongoing discussion at ISO, many devs are fed up with such approaches, because it is the kind of stuff that prevents C++ to have nice IDE tooling like Java and .NET.
And somewhat unfortunately, C++ has plan for a kind of reflection in the future [1]. But it's not here today. I'm wary of relying on a parser though: it could prove a real drag as C++ evolve and you need to keep the parser up to date.
I've recently been toying with #[derive] macros in Rust.
I have to say that framing reflection in terms of deriving an implementation of an interface is pretty powerful. But C++ makes it harder to do this than Rust, because you need to mutate the class definition to insert these methods in C++, but the Rust definition happens outside of the class (as vtable pointers are not contained within the class but passed around separately).
Not necessarily so. Consider std::hash, which is a template heavily specialized by many types. Then containers like std::unordered_set use these specializations. You can totally turn a Rust trait into a C++ templated struct, and then turn Rust impls into template specializations of that struct.
> I have to say that framing reflection in terms of deriving an implementation of an interface is pretty powerful.
Just wait till you see Haskell's Generic. (Not to be confused with generics in other languages.) It turns out for most applications you don't even need to derive an implementation of an interface.
you do not need the vtable to be inside the object itself. For example c++ std::function act similarly to an rust impl trait. But the lack of static reflection (or equivalent builtin functionality [1]) means you have to build a dedicated class for each C++ concept (the equivalent of rust trait), although libraries can help.
[1] the currently non existing equivalent in C++ has been sometimes refererred as virtual concept. Once upon a time, in the 2.x era, g++ had an extension known as 'signature' which would do exactly that.
For a statically-compiled language, runtime reflection is probably a violation of the zero-cost overhead principle. There is a limited amount of reflection that can be done cheaply that has some value: getting the address of the vtable of an object [assuming it has one] for uniqueness, or getting function pointer identities for generic invokable objects.
Given compile-time reflection, providing standard library functionality for certain runtime reflection tasks (such as providing a list of field information for a struct/class/union, or listing function arguments) could be useful. On the other hand, it could end up being a locale-like scenario where it's either overkill or too weak for your use case, never in the middle.
This might come true some day, but it seems not in C++20 and in recent static reflection proposals there was no way to distinguish reflected from non-reflected members in the same class.
I am hardly a C++ user nowadays, but such stuff interests me, because the Windows Development team managed to push C++/WinRT as replacement for C++/CX, but are declining any improvement to Visual Studio support (at least comparable to C++/CX) until ISO C++ gets similar capabilities to C++/CX.
So given that some C++ usage is required depending on which APIs you want to access from .NET, you can imagine there are many WinDevs not very happy with the downgrade in tooling support.
Back to your point, in what cases might such distinction be relevant?
Here, only one data member is meant to be serialized. The others members are there to accelerate lookups into the first data member. (Full disclosure: that structure isn't actually serialized yet, but the Arc80 Engine which uses Plywood has similar examples.)
Interesting! Could sufficiently enhanced compile-time reflection (say we do get supercharged CT reflection in C++2b*) be used to implement fully transparent&automatic versioning in serialization frameworks?
I know very little on this subject but I think boost serialization, though capable of handling multiple versions of a given class, requires manually 'tagging' source files as being say, version 1,2,etc.
I haven't looked at the C++ reflection proposal in a bit, but I think that attributes are reflected so you should be able to use your own attributes to mark non serializable objects
Perhaps, but it's easily overlooked because every project that needs runtime reflection badly enough has already rolled their own. (Some game engines have multiple reflection systems, eg. shader parameters vs. serialization.) This framework takes a particular approach and makes it an (almost) standalone component.
Why do/did you go for runtime reflection for all that? I thought you would use it for external scripting or mods or things like that, but not for eg serialization. I guess I am missing something.
Everyone misses compile time reflection because it solves many use cases easily (like serialization) without having to go for a complex solution or incur in performance penalties of runtime reflection. In contrast, I doubt many people care about general runtime reflection which I’d expect to be a mess in C++ and most likely not as fast as people wanted.
The biggest advantage I find with runtime reflection it that it's possible to load and manipulate data that has no C++ definition at all. This is actually handy when working with 3D geometry consumed by a GPU.
Ok, I am curious about the downvotes What is wrong with my comment. Open source can mean a lot (e.g. gpl) some of which cannot be used for production (in my and some other ppls environment). This one can, which is great. Reading on mobile it took 2 minutes to find out. So I thought i spare other ppl the hassle to find out themselves. And yes I believe licensing matter, and open source is too general a term.
I think this works as a good overview.