ultraq
commented
2 years ago Closing as I'm heading in a different direction with this now. Gonna follow a more common readers/writers patterns that you'll find throughout Java as it's probably more familiar to those with that or a similar programming language background. This'll let me build up layers of readers until we get to the target object we want (eg: w/ Java's file reader -> my map reader -> map), particularly useful for the explorer project and the map editor.
I currently have this abstraction of 'file types' (represented in the redhorizon-filetypes project) and 'media types' (represented as the media package in the redhorizon-engine project), where the filetype can be constructed from any file or stream, and then you use that filetype to construct the corresponding media. While this serves as a nice separation, I have 1 abstraction that hasn't been split as such - the Palette - yet it's come with some neat benefits, eg: palette files are simple enough that they're palettes in themselves, and that same object, whether a file or constructed via some other means, can be passed straight to the renderer to generate a texture. Whereas the other filetypes need to be broken down into very low-level parts (eg: image file -> image buffer, colour format, width, height -> renderer) to fit into the renderer.
I'm starting to wonder now if this abstraction can be simplified somewhat so that other things can be passed around in a similar way. Maybe combine them into an 'asset' type and then those assets are created from files/streams and can also be passed to the renderer 🤔
I'm not sure if all things would benefit from this, like I think the streaming formats (full screen animations, videos, music tracks) still need their abstractions because of that streaming requirement, but it would be neat to use the same asset type to construct sprites and image/texture maps.