A "mere" 67MB? For just two textures, and the back buffer (oh, and I guess a few more KB for the VB)? Can you give any idea on what the total memory breakdown in your program is?

It's randomly determined! Totally random!

while(abs(rand.next())+1)
   Blah = new int;

?

67 MB ? Your two screens report a VRAM usage of 22 MB and the whole scene is in view..?

Quote:67 MB ? Your two screens report a VRAM usage of 22 MB and the whole scene is in view..?

He mentioned that it used 67MB in fullscreen mode, while the screenies are from a windowed mode.

Dunno what difference that would make though.

Quote:Can you give any idea on what the total memory breakdown in your program is?

I most definitely can [smile]

Quote:It's randomly determined! Totally random!

Quote:

while(abs(rand.next())+1)
   Blah = new int;

I experimented with random allocations, whilst they do give the best results the problem is cleaning up afterwards. If you create a random number of allocations it's a bugger trying to guess the same random numbers again to deallocate the same pointers [lol]

Seriously though...

The textures that you can see on screen amount to around 16mb in total (normal+specular+diffuse @ 1024x1024 with full mip chain), the extra memory is all in intermediary buffers/targets.

There are 3 floating point (either 64bit or 128bit and the same size as the output/display) render targets that are used to accumulate the lighting content.

I also have a single 2D shadow map for the directional lights and a single cube shadow map for point lights. These are either 16 or 32 bit floating point.

There is another "light contribution" temporary that allows for post-processing the shadows (to get a simple form of soft shadows).

There are a set of luminance and HDRI post-processing resources, all at either 32, 64 or 128 bit floating point precision. These aren't currently used - when I've finished this I'm going to be carrying on work with the tone-mapping/HDRI component.

It's not the most efficient I will admit, but at the same time - the visuals I've got at the moment aren't actually utilizing much of the planned/designed pipeline [smile]

One last thing - regarding those screenshots showing 22mb instead of 67mb... because most of the aforementioned buffers are post-processing related and/or the same size as the display, it's *very* dependent on the current resolution.

Cheers,
Jack