Mail Archives: djgpp/1997/09/22/13:25:25
Brett Porter <bporter AT rabble DOT uow DOT edu DOT au> wrote:
> > 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.
So then is the fragmentation.
> > 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.
Ok.
> > 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?
I guess then that's the reason.
> > > 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.
But if the size is 40Kb then the changes between frames are small and is better
if you keep the file compressed and expand only the frame you need. I know
that's slow if the user will jump ramdomly back and forward because you need to
start all from the beginning. In this case use another 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?
Look in my home page, the address is in the signature.
> 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?.
Yes it can because if you allocate 1024 bytes you in fact are allocating 2Kb
and to make the things worst when you free the block these 2Kb can't be used to
allocate 64000 bytes even if you have various blocks of 2Kb.
> Maybe I should delete some stuff off my HD
> and then download the djgpp sources to see how the malloc function really
> works.
Well, you can download my modified malloc and see how it works and as a plus
you can see how I reuse fragmented memory in extreme cases.
SET
------------------------------------ 0 --------------------------------
Visit my home page: http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-sot AT usa DOT net - ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013
- Raw text -