   Windows VS fstream File Access??
  Hi all! This my fist post on the forums.  I searched around a bit, didn't find anything on it (if you found something, a link would be fine).Anyway, I'm creating a Windows 16Bit DirectDraw Game Engine, and I need to know what sort of file access method would be better for File Access.I want it to be as fast as possible, but since it's for windows only, I'm not sure if I should use the Windows API File Access Functions, or if I should use the file streaming found in the Standard C++ Library.Please help, and maybe, if possible, explain why one is better than the other.Thanks guys!   
  File access is I/O limited. In other words, it really won't matter what functions you use to access the disk because you're program will spend most of it's time waiting on the drive.   ;Quote:want it to be as fast as possible...Yeah, its file access. It's not going to be quick. Unless you use asynchronous file access (sorry, no links) its going to be pretty much the same anyway( and that will only allow you to do work while the loading is going on, it wont speed it up).IMO, use fstream. Its type safe and easier to use. Again, IMO. YMMV.Good Luck.   ;  Guys... I went to the bathroom and had 2 responses!  This forum rocks!Thanks for the help!I'll use FSTREAM.  I'm only using it to load the game configuration file at the moment.Thanks!   ;  If you want it to be fast, you should use a library that takes advantage of 3D accelerator cards over DirectDraw. Unless of course, you want to run it on old computers.   ;  I believe the streams will internally use native WinAPI functions anyway, so in that regard it wouldn't matter. But correct me if I'm wrong.   ;Quote:Original post by BoderIf you want it to be fast, you should use a library that takes advantage of 3D accelerator cards over DirectDraw. Unless of course, you want to run it on old computers.I didn't know they made 3D accelerator cards for file access. [smile]Quote:Original post by PrototypeI believe the streams will internally use native WinAPI functions anyway, so in that regard it wouldn't matter. But correct me if I'm wrong.That is also my understanding. Both the C and C++ libraries ultimately map to OS system calls.   ;Quote:Original post by SiCrane... you're program will spend most of it's time waiting on the drive.Apostrophe Abuse, anyone? ;)   ;  fstreams are actually quite a bit slower than other more low level methods. Using the standard C fwrite()/fread() calls or the win32 API is faster.From what I gather, this is because the streams read data byte by byte and other calls read in blocks of data at once. Another reason could be the overhead caused by all the abstraction.If you're only showing some stuff in the console, streams will work just file, but if you want to load large files (images, levels, ...), other methods will pay off.   ;Quote:I believe the streams will internally use native WinAPI functions anyway, so in that regard it wouldn't matter. But correct me if I'm wrong.You are correct.All of the C and C++ standard library calls (in fact, all standard library calls in any language) that deal with things like printing the screen, IO access, networking, et cetera, will simply call down to the appropriate OS functions. The standard libraries, if you think about it, are just libraries -- they have no special signifigance. If they need to get things done that require talking to drivers or executing kernel mode code, they have to go through the operating system, because the OS is really the only way to get there.Quote:fstreams are actually quite a bit slower than other more low level methods. Using the standard C fwrite()/fread() calls or the win32 API is faster.From what I gather, this is because the streams read data byte by byte and other calls read in blocks of data at once. Another reason could be the overhead caused by all the abstraction.The abstraction isn't all that much to be concerned with; the time you spend waiting for the disk will overshadow it. Additionally, the IO calls will generally default to buffered operation (read a fixed size chunk, return parts of that chunk as you request them until another chunk needs to be read, et cetera). It's possible they may not have to and still be standard-compliant, however. But they still call down to the OS calls. In any case, you can circumvent this by using the appropriate functionality to read the entire file in at once, rather than request pieces of as you go.To the OP:Making your IO access threaded (so you can background-load large chunks of data, like levels and such) can make your IO appear much faster since your game can still be processing other tasks and feeling responsive during the load.   