[EMAIL PROTECTED] schreef:
> On Tue, 26 Jun 2007 18:33:44 -0400 Giel van Schijndel 
> <[EMAIL PROTECTED]> wrote:
>   
>> [EMAIL PROTECTED] schreef:
>>     
>>> Should not memory be H*W*color depth ?
>>> Example 1024x768x4(RGBA) = 3145728, but game does 
>>> 1024x768x2=1572864.
>>> If have 1600x1200x4, then that is 7.68MB, but game has 3.84MB .
>>> Even with 1600x1200x3 (RGB) = 5.76MB. 
>>>
>>> The confuse part  is DisplayBuffer is used to load wrf, .gam and 
>>>       
>>> other file types.  What has this to do with what your resolution 
>>>       
>> is?
>>     
>>> SDL does correct calculation for screen space, so I no 
>>>       
>> understand 
>>     
>>> this?
>>>   
>>>       
>> You most likely discovered badly written code. Without a 
>> file:linenumber
>> we can't see for ourselves though (and more importantly can't do 
>> much
>> about it). So if you could point out where this is, I'd appreciate 
>> that.
>>
>> As for the display depth. Depending on what piece of code you're 
>> looking
>> at, it ought to be either RGB or RGBA, so 3 could be a valid value 
>> just
>> as well.
>>
>> Anyway, as of now I should have been in bed already. So I'll look 
>> into
>> the specifics somewhere tomorrow.  
>>
>>     
> allocate here,
> init.c(959):  displayBufferSize = 
> pie_GetVideoBufferWidth()*pie_GetVideoBufferHeight()*2;
>
> and now show strange loads into this "DisplayBuffer" ,
> src\game.c(1374):     pFileData = DisplayBuffer; (loads up the .gam 
> file)
>
> src\game.c(1465): pFileData = DisplayBuffer;  (use here to load 
> savegame file)
>
> src\game.c(11305):    pFileData = DisplayBuffer; (use here to load 
> script file)
>
> and this strange stuff goes on...
>
> I think this buffer should be rename to GeneralBuffer.
> I still no see how that 5000000 value or video resolution plays 
> role yet.
> Last I check, no wrf file or any file in wz over 1MB.  Maybe for 
> safety, but that is too much safe.
>   
Well it seems that this var, "DisplayBuffer", is a global var. I guess
implemented there as some misguided attempt at saving a few bytes of
memory. The problem is that this global var is so widely spread, that
I'm having _a_lot_ of trouble, tracking its state throughout program
execution. So unfortunately I cannot just rip this var out.

If you (or anyone else) has any idea of any location where the usage of
DisplayBuffer can, *safely*, be removed please feel free to point that
location out or to submit a patch.

-- 
Giel

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Warzone-dev mailing list
[email protected]
https://mail.gna.org/listinfo/warzone-dev

Reply via email to