Jump to content

  • Log In with Google      Sign In   
  • Create Account

#Actualfutlib

Posted 26 April 2013 - 09:48 PM

Can you explain what it is you're doing here? I'm having a hard time imagining a GUI that needs the better part of a gigabyte of texture memory.

 

Sure. However, note that the virtual memory size I reported is the vsize returned by top on OS X. It's 2.4 GB for the Python interpreter and even simpler tools like bc. Anyway:

The screen/scene we're talking about is where the player can create his character. He can chose from various variants of body parts (hair styles, eyes and such), all in all there are 63 variants right now. To select a variant, the player touches one of the preview images, so we also have 63 preview images which are scaled down to a width of 500 and cropped to a maximum height of 500. And there are also 63 generated images for the button down effect of the same size. The real body part images are larger, averaging around 1500x1500. Add to that a 3200x1800 background image and some less noteworthy UI graphics and that's about it.

The memory usage I reported earlier was after loading all of the preview images and some of the larger images. If I load absolutely everything, the resident memory is at almost 1 GB and the virtual memory at 3.8 GB. However, much of the larger images are still in the resolution in which the artist provided them, sometimes twice a big as necessary, so I'll be able to cut that down a bit I guess.

I just wrote a script that downscales everything for a resolution of 2000x1125 (factor 0.625), which would suffice on most screens. Virtual memory after loading all the preview images and some of the others is down to 2.8 GB, resident memory to 150 MB (was 2.7 GB and 280 MB respectively before), after loading everything (some of which is still twice as big as necessary) it's at 3.1 GB virtual memory and 500 MB resident memory.


#7futlib

Posted 26 April 2013 - 09:46 PM

Can you explain what it is you're doing here? I'm having a hard time imagining a GUI that needs the better part of a gigabyte of texture memory.



Sure. However, note that the virtual memory size I reported is the vsize returned by top on OS X. It's 2.4 GB for the Python interpreter and even simpler tools like bc. Anyway:

The screen/scene we're talking about is where the player can create his character. He can chose from various variants of body parts (hair styles, eyes and such), all in all there are 63 variants right now. To select a variant, the player touches one of the preview images, so we also have 63 preview images which are scaled down to a width of 500 and cropped to a maximum height of 500. And there are also 63 generated images for the button down effect of the same size. The real body part images are larger, averaging around 1500x1500. Add to that a 3200x1800 background image and some less noteworthy UI graphics and that's about it.

The memory usage I reported earlier was after loading all of the preview images and some of the larger images. If I load absolutely everything, the resident memory is at almost 1 GB and the virtual memory at 3.8 GB. However, much of the larger images are still in the resolution in which the artist provided them, sometimes twice a big as necessary, so I'll be able to cut that down a bit I guess.

I just wrote a script that downscales everything for a resolution of 2000x1125 (factor 0.625), which would suffice on most screens. Virtual memory after loading all the preview images and some of the others is down to 2.8 GB, resident memory to 150 MB (was 2.7 GB and 280 MB respectively before), after loading everything (some of which is still twice as big as necessary) it's at 3.1 GB and 500 MB.

#6futlib

Posted 26 April 2013 - 09:35 PM

Can you explain what it is you're doing here? I'm having a hard time imagining a GUI that needs the better part of a gigabyte of texture memory.


Sure. The screen/scene we're talking about is where the player can create his character. He can chose from various variants of body parts (hair styles, eyes and such), all in all there are 63 variants right now. To select a variant, the player touches one of the preview images, so we also have 63 preview images which are scaled down to a width of 500 and cropped to a maximum height of 500. And there are also 63 generated images for the button down effect of the same size. The real body part images are larger, averaging around 1500x1500. Add to that a 3200x1800 background image and some less noteworthy UI graphics and that's about it.

The memory usage I reported earlier was after loading all of the preview images and some of the larger images. If I load absolutely everything, the resident memory is at almost 1 GB and the virtual memory at 3.8 GB. However, much of the larger images are still in the resolution in which the artist provided them, sometimes twice a big as necessary, so I'll be able to cut that down a bit I guess.

I just wrote a script that downscales everything for a resolution of 2000x1125 (factor 0.625), which would suffice on most screens. Virtual memory after loading all the preview images and some of the others is down to 2.8 GB, resident memory to 150 MB (was 2.7 GB and 280 MB respectively before), after loading everything (some of which is still twice as big as necessary) it's at 3.1 GB and 500 MB.

Note that the virtual memory size I reported is the vsize returned by top on OS X. It's 2.4 GB for the Python interpreter and even simpler tools like bc.

#5futlib

Posted 26 April 2013 - 09:34 PM

Can you explain what it is you're doing here? I'm having a hard time imagining a GUI that needs the better part of a gigabyte of texture memory.


Sure. The screen/scene we're talking about is where the player can create his character. He can chose from various variants of body parts (hair styles, eyes and such), all in all there are 63 variants right now. To select a variant, the player touches one of the preview images, so we also have 63 preview images which are scaled down to a width of 500 and cropped to a maximum height of 500. And there are also 63 generated images for the button down effect of the same size. The real body part images are larger, averaging around 1500x1500. Add to that a 3200x1800 background image and some less noteworthy UI graphics and that's about it.

The memory usage I reported earlier was after loading all of the preview images and some of the larger images. If I load absolutely everything, the resident memory is at almost 1 GB and the virtual memory at 3.8 GB. However, much of the larger images are still in the resolution in which the artist provided them, sometimes twice a big as necessary, so I'll be able to cut that down a bit I guess.

I just wrote a script that downscales everything for a resolution of 2000x1125 (factor 0.625), which would suffice on most screens. Virtual memory after loading all the preview images and some of the others is down to 2.8 GB, resident memory to 150 MB (was 2.7 GB and 280 MB respectively before), after loading everything (some of which is still twice as big as necessary) it's at 3.1 GB and 500 MB.

Note that the virtual memory size I reported is the vsize returned by top on OS X. It's 2.4 GB for the Python interpreter and even simpler tools like bc.

#4futlib

Posted 26 April 2013 - 09:33 PM

Can you explain what it is you're doing here? I'm having a hard time imagining a GUI that needs the better part of a gigabyte of texture memory.


Sure. The screen/scene we're talking about is where the player can create his character. He can chose from various variants of body parts (hair styles, eyes and such), all in all there are 63 variants right now. To select a variant, the player touches one of the preview images, so we also have 63 preview images which are scaled down to a width of 500 and cropped to a maximum height of 500. And there are also 63 generated images for the button down effect of the same size. The real body part images are larger, averaging around 1500x1500. Add to that a 3200x1800 background image and some less noteworthy UI graphics and that's about it.

The memory usage I reported earlier was after loading all of the preview images and some of the larger images. If I load absolutely everything, the resident memory is at almost 1 GB and the virtual memory at 3.8 GB. However, much of the larger images are still in the resolution in which the artist provided them, sometimes twice a big as necessary, so I'll be able to cut that down a bit I guess.

I just wrote a script that downscales everything for a resolution of 2000x1125 (factor 0.625), which would suffice on most screens. Virtual memory after loading all the preview images and some of the others is down to 2.8 GB, resident memory to 150 MB (was 2.7 GB and 280 MB respectively before), after loading everything (some of which is still twice as big as necessary) it's at 3.1 GB and 500 MB.

Note that the virtual memory size I reported is the vsize returned by top on OS X. It's 2.4 GB for the Python interpreter and even simpler tools like bc.

#3futlib

Posted 26 April 2013 - 09:33 PM

Can you explain what it is you're doing here? I'm having a hard time imagining a GUI that needs the better part of a gigabyte of texture memory.


Sure. The screen/scene we're talking about is where the player can create his character. He can chose from various variants of body parts (hair styles, eyes and such), all in all there are 63 variants right now. To select a variant, the player touches one of the preview images, so we also have 63 preview images which are scaled down to a width of 500 and cropped to a maximum height of 500. And there are also 63 generated images for the button down effect of the same size. The real body part images are larger, averaging around 1500x1500. Add to that a 3200x1800 background image and some less noteworthy UI graphics and that's about it.

The memory usage I reported earlier was after loading all of the preview images and some of the larger images. If I load absolutely everything, the resident memory is at almost 1 GB and the virtual memory at 3.8 GB. However, much of the larger images are still in the resolution in which the artist provided them, sometimes twice a big as necessary, so I'll be able to cut that down a bit I guess.

I just wrote a script that downscales everything for a resolution of 2000x1125 (factor 0.625), which would suffice on most screens. Virtual memory after loading all the preview images and some of the others is down to 2.8 GB, resident memory to 150 MB (was 2.7 GB and 280 MB respectively before), after loading everything (some of which is still twice as big as necessary) it's at 3.1 GB and 500 MB.

Note that the virtual memory size I reported is the vsize returned by top on OS X. It's 2.4 GB for the Python interpreter and even simpler tools like bc.

PARTNERS