Tag: ResourceKit

Graphite

Here we go… time to start properly building this thing, and the first step of the journey is going to be Graphite.

What is Graphite?

Graphite is going to be a Swift package containing all the modern implementations of old legacy code found on the Macintosh platform in the Carbon era. It is fully written in Swift, and the name is a play on the name Carbon, of which Graphite is a type.

The early versions of Graphite will basically provide enough functionality for me to get my EV Nova clone up and running. Read resource files, handle some QuickDraw media and play some sound clips. Certainly not enough to provide a fully compliant Carbon environment. Maybe it’ll get to that point one day, but I certainly don’t see a need for that.

As a result this means that it is a combination of ResourceKit and ClassicKit, two earlier frameworks that I developed for accomplishing these goals. However they are written in Objective-C and strongly coupled to Apple’s Cocoa environment.

Graphite, on the other hand is written in Swift and, in theory, is not coupled to Apple’s ecosystem.

I’m not quite ready to setup the Open Source project page for Graphite just yet, as I want to get some tests in place and ensure the code and project are nicely documented. However I hope to get this up soon.

The end of an era…

Next week is WWDC, the hyped and supposedly exciting event for Apple Developers! New versions of macOS, iOS, tvOS and watchOS. New API’s. New things to take advantage of. Except this year I can’t help but feel down…

Last year Apple made it clear that macOS Mojave would be the end of the line for 32-bit applications. This means that the next version of macOS will have stripped out all 32-bit functionality from the Kernel and any frameworks that still have it, and most likely Carbon will be finally put to rest.

From the point of view as a developer, this is great! Refinement, cleaning up and optimisation in the tools I use everyday is a great thing and makes my job easier. As someone who enjoys playing some older games, such as EV Nova, this is not so great.

The latest versions of the EV Nova binary itself only contains code for the i386 architecture (32-bit intel). Earlier version also contain 32-bit PowerPC, but thats even more obsolete! From now on it looks like if I ever want to play EV Nova I’ll be firing up a VM in order to do so.

When I first began investigating the ResourceFork format back in 2014, I was aware that Carbon was already old news and utterly deprecated. I had hoped to be able to complete the entire EV Nova clone project over the course of a few years. I had not really anticipated how much other events in my life would begin to consume my time, thus causing the project to take longer.

Now here we are, more or less the end of the road for the technologies of the old world, and I’ve not been able to get the game completed or really even started in any meaningful capacity. I just have a bunch of research and information on those old formats and technologies.

Forging a new path

Over the past week I have been thinking (arguably a dangerous thing) about the future direction of the project. The point of this whole thing, and this project is to allow EV Nova to survive. Immortalised as an Open Source project that can be updated when required.

This means I need to do it right. I need to make it future proof. I need to make it portable, and detached from core technologies of any given operating system. So I’m going back to ground zero. I’m going to rebuild ResourceKit and ClassicKit. I’m going to introduce another framework NovaKit, which will be responsible for handling EV Nova resources and the likes. Each of these will be built in Swift using the package manager allowing them to be easily ported to Linux or Windows.

They will then be used by the main engine which will also be Swift, using the package manager again to provide and construct the core functionality of the game, sans any kind of graphical output. This is to ensure it has no platform specific functionality.

Finally a “rendering layer” will provide specific functionality for producing the games output and input for a given platform. Different platforms would include different rendering layers, i.e. macOS might make use of SpriteKit or Metal, whilst Linux might make use of OpenGL, and DirectX for Windows.