| Disch User Level: 9 ![]() Posts: 2/11 EXP: 2498 For next: 664 Since: 06-18-09 Since last post: 12.4 years Last activity: 12.2 years |
|
||
Originally posted by Sukasa Mwahahahahahahahah I made some changes to make it easier to load audio files from normal files (ie: via a file/path name).
These two are more or less equivilent. SoundSource::Load queries the "smart loader" which examines the file header to determine the file type, and creates the approprite SoundSource object. Currently the only supported format is .ogg so it's not all that significant, but as support for more formats are added in the future this will be handy. The smart loader already existed in the version I gave Sukasa, but you had to give it a FilePtr... ie: "Load( new File( "file.ogg" ) )". I did some more work on some different File structures. Nothing that would have much practical use outside the lib (and least I wouldn't think so), but some stuff that will be useful for internal workings. As for an overall layout of dshlib: Stuff that's done: - Unicode friendly strings (classes for utf8, utf16 and utf32 strings, all interchangable and having the same interface). These strings are used internally by dshlib for things like file and pathnames (and anything else where strings are used), so Unicode support is built-in, effortless, and idiot proof. - Abstracted FileBase for I/O operations. Most things in dshlib that perform I/O do so through a FilePtr -- what that FilePtr represents is up to you: a file on the disk, a temporary file that's deleted on close, an in-memory buffer, a file inside a .zip archive, etc. Complete with file resizing capabilities, endian-safe read/write routines for integers (still need to come up with something for floating points, though), and other goodies. - Abstracted interface for the FileSystem, and file searching. Search for specific file(s) based on name ("somedir/*.png") and get a compiled list of matches. Abstracted interface makes it easily portable, and applicable to filesystems other than the computer's file system. IE: a .zip archive would have the exact same interface -- and you could traverse its directories and search for files in the same manner. - A "FileName" class which parses a string and separates it into a list of directories, a file title, and extension. - Smart pointers (dshlib::refptr) which auto-delete the owned object when all references to it lose scope. Not unlike boost::shared_ptr, except refptrs are thread-safe (needed this for the audio engine, where objects may be shared between multiple threads). A similar refarray class for arrays. Worry not about memory leaks. - Highly abstracted Audio system with rich feature list and powerful adaptability. The interface is set up so it's easy to do basic things, but is still possible to have more fine control. - An abstracted "Transform" interface for doing conversions of any sort. Useful for things like compression, encryption, or simply converting binary data from one format to another. - Classes to wrap zlib inflate and deflate behind the abstracted Transform interface, for much simpler compression/decompression of data. - Everything is very modular and OO friendly. Anything that uses an external lib (like the SDL based audio device, or the vorbis file .ogg reader, etc) is behind an #ifdef, so if you don't want to use that lib you can change a line in the header file and remove those classes from the lib. Everything that requires something lib or OS specific is contained in its own class, so if SDL audio doesn't suit your needs, you can write a new AudioOut class to use whichever output method you need, and everything in dshlib will work exactly the same. OS specific classes (for stuff like directory searching, file I/O, etc) are isolated and modular so porting to other systems is easy. To add support for Windows I couldn't use any of the code I was using for Linux, and was still able to add support for it in a day. Stuff that I'm still working on: - .zip file support. The goal is to use an abstract 'Archive' class so that other formats like .7z or .rar may be easily added in the future. Other goals are for transparent reading/writing of files, creating new files/directories in the archive and deleting existing ones. Optional caching of the archived file to a temp file, so that you can do seek operations, and so it only needs to be decompressed once. Basically the goal is to make the fact that the files are in an archive and don't actually exist completely transparent to the user, so that files can be treated just as if they were normal files. This is quite a task, but the interface is there -- I just have to write the code for it. I've got a layout in mind and a lot of the hard code written already. - A Checksum abstraction, behind which will be things like MD5, CRC32, etc. I'll need to add this for .zip files anyway, but it could have other uses. - A DSPSound abstraction, which can act as a filter for sounds. So if you want to add echo, or to muffle the sound, or something like that. This would also be used to re-sample a sound so that you can play a file with a samplerate that doesn't match your output samplerate -- which is currently prohibited by dshlib. Stuff I plan to do eventually: - a pRNG abstraction. Behind which could be one or more RNGs of varying complexity. Pick the one you want and use it anywhere. I'm not a fan of Mersenne Twister because it's very obfuscated -- but I've come across other RNGs. Two in particular that I like: one that is quick and simple with a 32-bit period, and another with an even longer period than MT, but not as computationally expensive, and much easier to understand and use. RNGs would be able to have their state dumped and reloaded, allowing you to reproduce the same string of random numbers if required like for a movie recording or something -- or for reproducing the same randomly generated dungeon multiple times. - An abstracted interface for images, image data, and the like. .png/.bmp/whathaveyou file loading/saving. - An abstracted interface for texture/drawing surfaces that work with .png/etc loaders. IE: load a png directly to an OpenGL texture, or an SDL surface. - A bitmapped font file format (vwf data followed by .pngs containing the bitmapped font) and ways to draw text using the bitmapped file. I actually had a font bitmapper, but had to scrap it because it had a fatal bug that wasn't exposed on my computer, but crashed on every other computer that ran it . But I have the file format down, and have the ability to bitmap files.- A flexible text file format (possibly something similar to xml, but maybe something custom) to keep all game text in an external file for easy translation/internationalization. I kicked around ideas for this but never actually commited to anything yet. I figured I shouldn't focus on it until I finish the bitmapped font stuff. - .spc / .nsf file support. weeeeeeeeeeeee. The interface is already there, I'd just have to write a player for it (I've written players for both, before) ANYWAY that's dshlib in a nutshell. My goals/dreams/etc. I don't know how much of this is useful for this particular game but I felt compelled to write this huge post anyway. Like I say if you guys have features you'd like me to focus on for this game, I'd be willing to consider giving them a higher priority. |





. But I have the file format down, and have the ability to bitmap files.





.

