You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It appears that the original SMPS drivers were binary blobs. Doing the same for this driver should help with compatibility, and ease-of-use. Then again, only one disasm primarily uses asm68k, and the actual music would need building at assemble-time, too, making SMPS2ASM a dependency. Problem is, SMPS2ASM is bound to AS in its current state.
Perhaps the driver should be pre-assembled, and music should be assembled separately, with a copy of AS.
The text was updated successfully, but these errors were encountered:
Now that I think about it, this would break the compatibility flags. That is, unless I want to add a million run-time checks. Screw it, I suppose I should just look into making the driver build separately, but at the same time as, the main hack.
It appears that the original SMPS drivers were binary blobs. Doing the same for this driver should help with compatibility, and ease-of-use. Then again, only one disasm primarily uses asm68k, and the actual music would need building at assemble-time, too, making SMPS2ASM a dependency. Problem is, SMPS2ASM is bound to AS in its current state.
Perhaps the driver should be pre-assembled, and music should be assembled separately, with a copy of AS.
The text was updated successfully, but these errors were encountered: