blitz-research
commented
10 years ago Not gonna commit this for now as I need to think through the meta data stuff a bit more!
But my first thoughts are I do think it's useful to have a BINARY_FILES var, in-so-far as I think file type filters should probably reflect the commands they are used with, ie: any files matching the BINARY_FILES filter should be loadable by DataBuffer.Load().
I think this should apply to all files - ie: by default, people shouldn't expect to be able to load png's into databuffers (although it'll probably 'just work' on most targets - although we COULD 'fix' this by checking meta data more thoroughly before loading stuff), because BINARYFILES does not contain a .png filter. If for some reason someone does require this, they should probably have to use BINARYFILES+=".png".
This means that any data pre-processor can take steps to ensure that the file is present in the native project in the correct format(s). It may in fact be necessary to duplicate the data in some cases, eg: XNA would probably require this as images need to be in a special format for LoadImage, while the original 'raw' data would need to be available for use with DataBuffer.Load.
devolonter
This patch allows to use universal “SOMETHING_FILES” config setting for data files. For example, VIDEO_FILES, FONT_FILES, etc. Currently we can use BINARY_FILES for that, but I think it isn’t semantic a little, because images and sounds are also binary files, in some way. What do you think about that?