Message-Id: <199709192356.JAA19936@rabble.uow.edu.au> Subject: Re: Where is my physical memory hiding? To: salvador AT inti DOT edu DOT ar (Salvador Eduardo Tropea) Date: Sat, 20 Sep 1997 09:56:15 +1000 (EST) Cc: djgpp AT delorie DOT com (DJGPP) In-Reply-To: from Salvador Eduardo Tropea at "Sep 19, 97 03:01:21 pm" From: Brett Porter MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk > At first you are asking for: 62*65536=4063232 bytes, so 7Mb is enough. Sounds > strange, what DPMI host are you using?, are you sure is 64000 bytes or perhaps > you are allocating 0x10000? No, definately allocating 64000. > Second: as you said you have: 8Mb-2Mb(cache)-1Mb(base memory)-4Mb(if you are > using RHIDE when you run the program)= 1Mb of real memory ;-))), don't spect It still says out of memory when run outside of RHIDE - this is where the get physical memory function reports 7000000 or more free. > that the DPMI host will use ALL the available disk. > In particular CWSDPMI keeps some sanity about how much virtual memory will > report according to the real memory you have. For example, I have 24 Mb free > (after loading RHIDE), and CWSDPMI reports aprox. 150Mb free even if I have > 300Mb free on disk. Windows will report even less. > How do you find out how much CWSDPMI is using? RHIDE reports in the top-right that I have 3M physical and 19M virtual - all of it (this number decreases in Win95, and not because of a large swapfile, either.) The reason you might only have 150Mb is that I believe the FAQ says CWSDPMI uses 128Mb of Physical RAM + 128Mb of Virtual memory at most, and 24Mb+128Mb is about 150Mb, right? > > The actual sequence of calls is: (it's to load each frame of a FLI into a > > seperate buffer)... BTW the size of the FLI file is < 40Kb > So why are you trying to decompress it first, make it on the fly, I think it > will be faster because in this way you don't need to blit the whole screen. > Well, first of all I wanted to just them up on screen, and then work on the other routines, and refine the FLI stuff later. I am not actually animating the FLI... my graphics editor of choice is Autodesk Animator (when using DOS), and I store "libraries" of pictures in one FLI file (some of which are animations, on successive frames), and the program I am writing allows the user to select a frame(s) and clip a section of the screen into my game's resource format. > > * allocate a buffer for this frame (taken from frame_header.Size) > > * allocate 64000 bytes and store the frame > > * free the first buffer > And perhaps here is the problem, when you allocate this temporal buffer and > then deallocate it you are fragmenting the memory. To test if that's true try: > 1) Allocate the temporal buffer just ones. > or > 2) Use my malloc function. > > > > ... and do this 62 times. > > > > Any ideas why I am running out of memory? > Yes, fragmented memory is the most possible reason. > I'l try (1)... as for the alternative, where can I find your malloc function? I am still not sure it could be fragmentation, because I am only allocating less than a kilobyte one average when I do this, so it can't absorb that much memory, can it? Maybe I should delete some stuff off my HD and then download the djgpp sources to see how the malloc function really works. Thanks for your help Brett -- "Give me ambiguity or give me something else" -- Brett Porter blp01 AT uow DOT edu DOT au http://www.geocities.com/CollegePark/Union/3596 Humour, Programming, and more.