Actually, GEM sort of already does this, but not all the way. If you load the _exact_ same image (this means the exact same file/path name), then the pix_image has a cache system which means that it is only loaded into the computers memory once. However, each pix_image still sends its own copy down to the gfx card.
You could use a single pix_image/pix_texture with separator to do this...I have done it a lot in the past.
The reason that pix_image doesn't share the actual texture data is that you can modify the pixel data with other pix objects...pix_image doesn't actually send the texture data to the gfx card, pix_texture does.
Later, Mark
============================ = mdanks@stormfront.com = Lead Programmer PS2 = http://www.danks.org/mark ============================
-----Original Message----- From: umläute [mailto:zmoelnig@iem.mhsg.ac.at] Sent: Wednesday, August 16, 2000 1:39 PM To: Mark Danks Cc: pd-list@iem.mhsg.ac.at Subject: Re: Gem and texture size
i have noticed some times ago, that when i use a huge number of sperate textures, at a specifique point the CPU-load increases by numbers -- this is, of course, due to the lack of memory of my grafx-card
but:: since i only used few *different* texture-images (par example: only 1 single image, that is textured on let's say 128 geos), i guess there could be a way to tell the grafx-card to reserve memory only for one (or "few") image(s). so there would be no need to access the "slow" main memory. How ?
mfg.fasd.ar hannes
hi
You could use a single pix_image/pix_texture with separator to do this...I have done it a lot in the past.
The reason that pix_image doesn't share the actual texture data is that you can modify the pixel data with other pix objects...pix_image doesn't actually send the texture data to the gfx card, pix_texture does.
ah sure - this is very logical the problem with the separators is, that it makes modular programming (abstractions via patches) uncomfortable. i do not think, that it is a very good idea, to send the GemList-pointers via send/receive (on the other hand:: this looks like a good idea, now that i write it...)...you couldn't switch on/off the geos seperately (but then i had problems doing so when using long-time (weeks.months) gem-things
and i didn't think of manipulating the pixdata
mfg.ajk.sui hannes
time seems to be 1 or 2 hours early compared to what the shell says .. how = this?
|since your date is Date: Thu, 17 Aug 2000 01:24:21 +0200 (CEST) |this smacks of a GMT/Local problem. (note the +2)
sort of .. but the time object has this GMT mode, and if you dont set it its supposed t run in local mode_ also its one hour on 2 machines and 2 h's on another machine, all of them in the same TZ .. ;)
|On Thu, 17 Aug 2000, [ISO-8859-1] _-¯-_ wrote: | |> time seems to be 1 or 2 hours early compared to what the shell says .. |> how = this?
-¯- wrote:
|since your date is Date: Thu, 17 Aug 2000 01:24:21 +0200 (CEST) |this smacks of a GMT/Local problem. (note the +2)
sort of .. but the time object has this GMT mode, and if you dont set it its supposed t run in local mode_ also its one hour on 2 machines and 2 h's on another machine, all of them in the same TZ .. ;)
|On Thu, 17 Aug 2000, [ISO-8859-1] _-¯-_ wrote: | |> time seems to be 1 or 2 hours early compared to what the shell says .. |> how = this? -- abc
it works fine, i think, on Win32 machines. the problem with linux seems to be, that most (at least most i know) machines are set up badly concerning the local-time configuration (though this may not be obvious). on my machine it works fantastic (!), the bios-time was set to "local" somewhere in the Linux setup.
but of course this is a BUG - i will set it on my todo list
m.fg.ouas hannes
|it works fine, i think, on Win32 machines. |the problem with linux seems to be, that most (at least most i know) |machines are set up badly concerning the local-time configuration |(though this may not be obvious). on my machine it works fantastic (!), |the bios-time was set to "local" somewhere in the Linux setup. | |but of course this is a BUG - i will set it on my todo list
i just testet it ebfore on yet another machine my laptop and it was oke there. but i ll have a non-pd sync server around as well, so i ll need an offset layer anyhow ..