thats what for/next loops and arrays are good for, you can do it like this...........
dim game_variables#(10000)
open to write 1,"saved_game"
for i=1 to 10000
write float game_variables#(i),1
next i
close file 1
or you could do it like this (if you where mad enough)
open to write "saved_game"
write float 1,#player_xpos
write float 1,#player_ypos
write float 1,#dah..de.dah
write float 1,#etc
write float..........
for ten thousand times over, which is the easiest?
yes it would suck if you missed even the littlest bit out, thats what debugging is for, you could read a mp3 in as raw data with the db commands, but unless you know how the compression and the file format work you still can`t get any music out of it, the programs that write these files have to do so in a fixed sequence, if you deviate just a little then they can`t read em, ever had an app that cant read png from another program for example?, I have two programs (one a discounted older program) and Adobe won`t read bitmaps from the budget label program, yet the cheapo program can read the Adobe .bmp`s just fine, the point being that the coder of the cheap app was obviously making some assumption when he writes his files that Adobe will take for granted, a lazy way to read a bitmap for example ignores extra data in the file header that tells you the colour depth, that works fine as long as you are loading files with the same colour depth that the program assumes it is getting, but if you try to load a 32 bit image into the space allocated for a 16 bit image, you are gonna get some spare data left over.
Mentor.
PC1: P4 hyperthreading 3ghz, 1gig mem, 2x160gig hd`s, ATI radeon 9800 pro gfx, 6 way surround sound, PC2: AMD 1.2ghz, 512mb ram, FX5200 ultra gfx, stereo 16 bit soundblaster, ups.
