gyrovorbis

Thanks so much for the shout-out and support! If you want more updates, make sure to also follow the lead developer, https://x.com/poiitidis, and another rock-star from our community who is supporting him, https://x.com/Frogbull55.

I hope this is a joke, considering I literally mentioned in the post: Save files sizes are substantially larger, world draw distances are greater, textures tend to be higher resolution, etc.

I do totally agree that I should've just made an engine and the toolkit and just released it as that, but it wouldn't have been "THEY should've constrainted the scope" -- as there would've been no "they." It would've been all me without a team I had to support by splitting that Kickstarter so many ways that we made under minimum wage in the end... lol.

Half fake news, half true.

I was king of scope creep, but I was also the engine and tools developer... Does it LOOK LIKE the engine and tools were the ones bottlenecking progress, or does it look like a lack of ACTUAL GAME CONTENT was the problem with Elysian Shadows? The engine and tools (which were my job) are probably easily at 90% done.

What I do own up to is being so bogged down with coding up a whole cross-platform engine and toolkit that I was an absolutely horrible manager who just relied on the rest of the team to know what needed to get done and take care of it, which obviously never actually happened. I was not as involved in the rest of the actual game aspect of ES independent of the tech than I should've been, and I own up to that...

But if you actually think THAT is what caused this game to never get done, you aren't seeing clearly. That's the one aspect of the game (other than audio, which was never a problem) which was actually where it should've been in terms of progress.

Also, for the record, LOL, ElysianVMU caused "drama" and extra work for the team? Funny, not one person other than me wrote a line of code for EVMU or even implemented the single line of Lua code it takes to display a VMU icon in-game... and as far as I ever knew, Patryk enjoyed getting to take a few hours to get away from killing himself being overworked on terrain and character assets to get to draw VMU icons, or so I'm assuming based on the fact half of what he drew were penises and jokes, initially. ;)

Uh, for the record, like... I've been more than open about my past history with ES, and have spent the last 2+ years straight giving back to the Dreamcast community, supporting every game and project I've been able to find time for, fixing many bugs that have plagued this scene for decades and becoming the developer with the second-most commits to the KallistiOS repo in just 2 years, beaten only by the lead maintainer with over a decade of work...

But yes, way to take the spotlight away from the developers who are pouring their hearts and souls into this project, of which I'm only an insignificant part of, to bring up some irrelevant shit from my past which I have owned up to and am literally working to correct by supporting projects like this... total douche bag move. Makes me feel sorry for the rest of the team, tbh.

Pretty much true. Not only that, but if you look at the Kickstarter page, what exactly was my job? Engine programmer. Not gameplay. Th engine is pretty much complete, as are all of the tools. Problem is it taxed me so hard and left me with so little extra time and cognitive resources that I could not properly lead the rest of the project or the team-mates whose job it was to do the gameplay aspect... Which is absolutely a leadership failure on my part, and I'll happily own up to that.

Jokes do tend to be inane...

Haha, somebody knows their Objective-C!

^ This, 100%. GTk's GObject type system which powers the entire GNOME stack is a similar object-oriented C type system with a virtual table pointer as the first member of an object, similar to Microsoft COM and C++.

The entire Objective-C runtime which is what powers the OO core of the language was also written with a similar purely C type system... It's just a small compiler layer on top...

I'm a huge academic fan of what GTk has accomplished (thanks to their GObject type system), and as much as I know the C89 crowd who thinks macros are all evil probably abhor this kind of thing, I think GTk is one of the most epic, impressive, ambitious C codebases in existence. Witness as non-OO C matches, rivals, and quite often beats Qt on equivalent classes/features in plain C... It's even above "just C++ style C," as they have added features like a property and signal system...

I'm such a fanboy it inspired my own type system and massive core library, libgimbal, which uses a type system similar to GObject and targets game consoles like the Sega Dreamcast: https://github.com/gyrovorbis/libgimbal.

Exactly. Amen. GTk is the shining proudest most epic achievement of object-oriented C programming, and they still enjoy massive benefits in terms of being able to interop with every language ever because of this approach.

Reminds me a lot of the magic that is the Objective-C runtime. Fantastic paper. Thanks for sharing.

"Thankfully" he says.

Now witness as Rust struggles to produce a compelling widgeting environment that isn't Qt or GTk bindings to other languages which support OO constructs. Witness as apparently creating a "Rust-friendly" OO paradigm or framework is an ongoing academic endeavor, because of this...

Believe it or not, for some domains, object-orientation is the right tool for the job... as some problems are just inherently modeled better with such a paradigm, and are able to take advantage of what it has to offer (encapsulation, polymorphism, inheritance).

It's just the latest hipster language trend. When OO was new, structural C was evil. When functional programming happened, everything before that was evil...

Because, yes, sharing state among classes for code reuse, is fundamentally evil... How dare you want to couple state and logic?

Almost like every single UI framework in every mainstream language has converged upon OO as the best way to model the problem at hand... GTk even invented a similar type system to what was mentioned in this PDF just to give C OOP constructs... Now witness as the Rust language has failed to produce a compelling UI/widgeting framework or paradigm, and the best ones out there are Qt-based or GTk-bindings (letting C hilariously handle the OOP for Rust).

This book is an absolute classic. I came from C++20, using concepts and constraints, doing a lot of compile-time metaprogramming and shenanigans, and I set off on a quest to rewrite a lot of my core tech stack in plain ol' C ('17 revision) for language interoperability reasons...

...and I literally almost gave up on being a C programmer because of bashing my head against language limitations... This book completely and totally changed everything and is the reason I completed this very ambitious project (https://github.com/gyrovorbis/libgimbal)... It's not just good for object-oriented C, but also for approaching the C language differently in general. For pushing its boundaries rather than accepting its limitations.

Anyway, this "PDF" was such an inspiration on me as a C programmer that I managed to track down a physical copy on Ebay. lol.

This. The entire GNOME stack is based on a steroided-out C-based OO type system in the same vein as the OP's PDF... and it's actually how it gets bindings to every language ever so easily...

Anyway, I was sent down a rabbit hole of wanting to do object-oriented C for a language independent core as well, starting off with buying the physical copy of this PDF, because I liked it so much...

I have to say GStreamer is probably the absolute best, most ambitious, shining example of such a type system, as it's already built upon GObject, fixes a lot of its shortcomings, and just really takes the whole thing to the next level with a complex, highly OO architecture. Fantastic reference and inspiration for this kind of stuff.

I'm the author of the libGimbal project linked to there. It's a massive object-oriented C codebase with an entire cross-language type system that was inspired by GTk's GObject, Microsoft COM, and the Objective-C language.

I've studied everything out there on achieving OOP in C, and actually the OP's book reference was my original inspiration. There's a fine art to doing it and a few good codebases are out there that do it well... The entire GNOME stack is based on this kind of stuff.

Anyway let me know if you have any questions. lol.

There are a few niche reasons. The entire GNOME/GTk stack benefits greatly in the realm of language interop from being C at its core. This is why it easily has bindings to every language ever.

I'm not porting MacOS. I'm porting just the Foundation layer, and I'm not using Apple's implementation, I'm using GNUStep's.

But hey, maybe having a core, foundational framework written in the most performant language out there with the most hardware support should've been a priority. ;)

Wow, thank you for sharing!

Dude, clicked your profile links, and wtf? Objective-S looks awesome! I had never even heard of it, but creating a more easy-to-use language ontop of the Obj-C runtime is epic!

I actually wrote my own C-based meta type system for giving my core library and applications that use it a language-independent object-oriented C layer for interop. That's actually how I discovered the magic that is Objective-C and how powerful the C runtime actually is... that's why I'm sad to see it slowly disappear, and anything like this that keeps it alive and uses it is really cool to me. :)

I just wrote unit tests for making sure the Objective-C runtime is working and doesn't accidentally get broken in the indie SDK, KallistiOS, for the Sega Dreamcast: https://github.com/KallistiOS/KallistiOS/pull/202, haha.

It really is a beautiful language, and some of the most powerful aspects of Swift are due to its Objective-C roots.

Hot-take from someone who is currently helping to port GNUStep's implementation of the Foundation framework to the Sega Dreamcast:

Gross. The whole appeal of Foundation was having this incredibly convenient, beautiful, high-level object-oriented API ontop of low-level, statically compiled performant C...

The true path forward for computing is clearly an alliance among the holy trinity of god's C languages: C, C++, and Objective-C.

Yes, the future is in Objective-C++'s hands.

Uh, guys, I just ported C++20 to the thing and the absolute latest tip of GCC12.2.0, Binutils, and Newlib. I'm also in the process of porting the Objective-C foundation framework to it as well... you have no idea how good the development tools are. This shit's more modern than what I have running on my host machine. lmao.

The SuperH is still fully supported by the GCC toolchain and is well maintained.

Also the guy behind compiler explorer, Matt Godbolt, himself was a DC developer and has added the SH architecture there as well.

https://github.com/KallistiOS/KallistiOS/commit/99c716c8915f...

This is an internal library for the kickstarted game Elysian Shadows that was not yet ready to go open source. He's plagiarized it... and used his real account with all of his contact information... oooopsies!

I don't suggest that. This man has stolen my work and is about to be in deep shit.

Almost like... this was a private repository that was literally just stolen. A DCMA complaint has been filed. This man literally stole my own work of several years, which wasn't even ready to go open source, and decided to take credit for it.

This is my work that I've been working on the last several years. I was not ready to release it open source, and this idiot just proceeded to steal it from an internal repository and POST IT UNDER HIS OWN NAME WITH ALL OF HIS PERSONAL INFORMATION.

Yeah, because it is my work and this guy has literally 100% stolen it. It was not ready to go open-source.

I'm the author of ElysianVMU, and I actually have yet to emulate the BIOS for that exact reason... Still working on it... But that's really badass that you have your emulator running in the browser, man. Epic.