gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > fscan

#98873 - dustin - Fri Aug 18, 2006 5:07 am

Hi I have looked and I can't seem to find any type of fscan in Chism's Fat library. Is there another library/ another version of Chism's I should be using that has fscan. If not I assume I should just make my own way of reading a .txt document into an array correct? There is not some other function I missed that does what I want is there? Thanks
_________________
www.thrivepresents.com
palib.dustin.info

#98874 - tepples - Fri Aug 18, 2006 5:16 am

gba_nds_fat or libfat?

It's not so hard: fopen() the file, find the size of the file using fstat() or something similar, malloc() enough room, fread() it as one chunk, fclose(), and you're done.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#98877 - GPFerror - Fri Aug 18, 2006 5:27 am

this is what I did for fscanf for use with fatlib

Code:
int      FAT_fscanf(FAT_FILE *kf, const char *fmt, ...)
{      
      char line[256];
      int i;
      va_list args;
      FAT_fgets(line, 255, kf);
      va_start(args, fmt);
      i=vsscanf (line, fmt, args);
      va_end(args);
      
      return i;
}




Troy(GPF)
http://gpf.dcemu.co.uk

#98878 - dustin - Fri Aug 18, 2006 5:28 am

gba_nds_fat at the moment. The reason I was trying to use fscan is that I have a text document that is a series of numbers divided by , . If I used something like fscan I could say %d,%d,%d... and get an array without having to deal with ASCI or anything. Maybe I'm mistaken, is something like that not do able in fscan normally? By just freading it in I'll have to convert the ASCI numbers into there corresponding int's right? Sorry if that doesn't make sense I might be misunderstanding something.

Edit: GPFerror explained it while I was typing up my post.
_________________
www.thrivepresents.com
palib.dustin.info

#98888 - sajiimori - Fri Aug 18, 2006 8:00 am

Incidentally, real games don't normally store numbers as strings of ASCII digits. It's better to store them as binary values.

#98901 - chishm - Fri Aug 18, 2006 10:50 am

libfat has fscan by extension from newlib.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

#98940 - dustin - Fri Aug 18, 2006 4:53 pm

excellent I'll be sure to check libfat out. Sajiimori the reason I am using strings to store numbers is for easy level creation. It's a puzzle game (masyu), and it seemed to me the easiest way for myself and/or other people to make puzzles would be to edit a text document. This will also hopefully make it easy to add new levels to the game without having to recompile or anything. Is there some better way you think I should consider doing it?
_________________
www.thrivepresents.com
palib.dustin.info

#98948 - tepples - Fri Aug 18, 2006 5:35 pm

Make an editor in the Java programming language that can read and write the binary puzzle files that your game uses.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#98954 - sajiimori - Fri Aug 18, 2006 6:13 pm

If a text editor is good enough as a level editing interface, I'd still suggest at least writing a preprocessor that converts the text to binary.

The best format is one that lets you fread straight into your data structures, without any runtime reformatting.

#98959 - tepples - Fri Aug 18, 2006 7:05 pm

sajiimori wrote:
The best format is one that lets you fread straight into your data structures, without any runtime reformatting.

Unless you want to use the same data files on platforms with big-endian (GameCube, Power Mac, Xbox 360, PS3, Wii) and little-endian (PC, GBA, PS2, Xbox, DS, Intel Mac) CPUs. Or unless you have data structures more complicated than arrays of structs, in which case you may have to relocate the pointers.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#98998 - sajiimori - Fri Aug 18, 2006 11:52 pm

I'd recommend producing different binaries for different platforms where appropriate.

It's true that runtime preprocessing can be useful. Replacing indexes with pointers at load time can be a helpful optimization, especially if there are multiple levels of indirection.

And of course, compression is a way to save ROM space at the cost of extra preprocessing.

That said, my collision file format has multiple sections and variable-length structures of several kinds, but it's designed to be used verbatim.

#99038 - tepples - Sat Aug 19, 2006 5:49 am

sajiimori wrote:
I'd recommend producing different binaries for different platforms where appropriate.

True, but "where appropriate" will shrink as players start to expect cross-platform online features.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.