This means that liberal use of SheepShaver (a PPC emulator, for Classic Mac OS) is required. The API’s required were deprecated 10 years ago, and do not function correctly under 64-bit. Nothing on modern macOS will allow us to look at the contents of a resource fork easily. Good old ResEdit and Mac OS 9 to the rescue On top of that, if we parse the resources using these structures the data is completely garbled and insane due to the encryption. Yep, both resources have a different format internally, which means they can’t be read with exactly the same process. I have attached two screenshots beneath of the code structures representing the two NpïL resources. However I can not currently find it, so not able to link to it. There is a document online covering the actual data layout of the pilot resources (I believe by guy). The second issue is that the resource data itself is encrypted.Thankfully the macOS virtual file system provides us a “hack” to read the resource fork as a data fork (though who knows for how much longer). The only API’s that can are the Carbon API’s. This is a problem as none of the Cocoa or POSIX API’s can open or read from the resource fork data. This is illustrated by the fact that when we drop the file in to a hex editor, we see no content at all, despite Finder reporting an 87KB file size. This means that the actual NpïL resource is inside a true resource fork. For whatever reason AmbrosiaSW never migrated this particular file to flattened ndat files.Before we get into how this resource can be read, we need to first understand some of the complexities and issues with it. One of the more irritating resources to deal with is the player data resource, or the NpïL resource. macOS might make use of SpriteKit or Metal, whilst Linux might make use of OpenGL, and DirectX for Windows. Different platforms would include different rendering layers, i.e. This is to ensure it has no platform specific functionality.įinally a “rendering layer” will provide specific functionality for producing the games output and input for a given platform. ![]() 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. Each of these will be built in Swift using the package manager allowing them to be easily ported to Linux or Windows. I’m going to introduce another framework NovaKit, which will be responsible for handling EV Nova resources and the likes. I’m going to rebuild ResourceKit and ClassicKit. I need to make it portable, and detached from core technologies of any given operating system. Immortalised as an Open Source project that can be updated when required. The point of this whole thing, and this project is to allow EV Nova to survive. Over the past week I have been thinking (arguably a dangerous thing) about the future direction of the project. I just have a bunch of research and information on those old formats and technologies. ![]() 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 had not really anticipated how much other events in my life would begin to consume my time, thus causing the project to take longer. I had hoped to be able to complete the entire EV Nova clone project over the course of a few years. When I first began investigating the ResourceFork format back in 2014, I was aware that Carbon was already old news and utterly deprecated. 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. The latest versions of the EV Nova binary itself only contains code for the i386 architecture (32-bit intel). As someone who enjoys playing some older games, such as EV Nova, this is not so great. ![]() 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.įrom 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. Last year Apple made it clear that macOS Mojave would be the end of the line for 32-bit applications. Except this year I can’t help but feel down… Next week is WWDC, the hyped and supposedly exciting event for Apple Developers! New versions of macOS, iOS, tvOS and watchOS.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |