1. is there any easy way to find out
how much memory my program is using? The application I'm writing needs to
run on 8 meg systems and it keeps locking up at a certain point. No error
message, just dead. It runs flawlessly on my 32 and 64 meg systems here,
but not on my boss' 8 meg machine (yeah, the same one with the printing
problem - how come stuff always works here and not for the people paying
me?) It MUST work on their systems, and I'm guessing it's a memory
issue. Also the program must run from floppy. Does the Virtual memory
thing try to swap to the drive the program was run from? There's no room
on the floppy left, so this would be a bad thing I'd imagine.
My program is in 640x480x256, with gui stuff and about 40 sound clips and
a bunch of 150x150 images.
Also, is an image is stored in a sequence after a read_gif() stored one
byte per pixel, or as something else? i.e. is a 640x480 image stored in a
640x480 sequence (without palette data) 307,200 bytes? or is it bigger?
My program needs to run on any 8mb computer without any user
configuration. It's first job is in the LA missions testing people in
drug rehab and they know squat about computers.
If anyone wants to help me test this thing, it would be appreciated.
Thanx
Michael Packard
Lord Generic Productions
2. Re: is there any easy way to find out
Michael Packard writes:
> how much memory my program is using?
You might try Jacques' memory routines on the Recent Contributions page.
> The application I'm writing needs to
> run on 8 meg systems and it keeps locking up at a certain point. No error
> message, just dead. It runs flawlessly on my 32 and 64 meg systems here,
> but not on my boss' 8 meg machine
If he has allocated a lot of space for SMARTDRV in his autoexec.bat
that could cause a shortage of extended memory.
I tried your program on an 8Mb 486 with no sound card. Under both pure
DOS 6.2, and win3.1, it displayed the opening logo, but then stopped when it
realized
there was no sound card.
I tried it on a 32Mb Pentium and it ran fine when win95 was restarted
in DOS mode, but the screen went blank and it locked up in a win95
DOS window. My S3 graphics card always does that in some SVGA modes
under win95.
> Also the program must run from floppy. Does the Virtual memory
> thing try to swap to the drive the program was run from? There's no room
> on the floppy left, so this would be a bad thing I'd imagine.
If you run under a Windows DOS window, then the system swap file
(on hard disk) will be used. If you run under pure DOS, Causeway
tries to use the TEMP directory, or if TEMP isn't defined, it uses TMP,
else it uses the directory where the program is stored. You can:
SET CAUSEWAY=SWAP:path
in a .bat file to choose your own path to the swap file directory.
> My program is in 640x480x256, with gui stuff and about 40 sound clips and
> a bunch of 150x150 images.
That's considered SVGA. A much safer bet would be Mode 18 (VGA) 640x480
which should work on all VGA or higher machines, (but it only has 16 colors).
> Also, is an image is stored in a sequence after a read_gif() stored one
> byte per pixel, or as something else? i.e. is a 640x480 image stored in a
> 640x480 sequence (without palette data) 307,200 bytes? or is it bigger?
It's stored as 4-bytes per pixel, plus overhead of 32 bytes per sequence.
This might be optimized someday, but for now it makes things simpler and
faster.
Be careful that you aren't keeping any unnecessary copies of those
big images. Setting a sequence to {} will immediately free up the memory.
I didn't go as far as printing your report, but I have an HP 550C inket
printer that always works fine when I open PRN and print the way that you do
under DOS, win3.1 or win95. I wonder if your boss is using Windows NT.
I vaguely remember having problems with PRN when I was using NT.
Maybe an NT user can answer this. In the worst case you might have
to print to a file, and then run a separate program to do the printing,
perhaps by
calling system().
Regards,
Rob Craig
Rapid Deployment Software
