hello luke,
I am working on a similar project right now. but not with that many [squares], because pd becomes extremely slow at that stage. still, I just raised the number of my grid and tested >22.000 tiles without crashing. and I am putting movies on each tile. it took 3minutes to start up the patch and the framerate is poor. but it is not crashing.
one thing that I remember people kept telling me is, not to use too many objects in one canvas. so I created a subpatch for each row and put all the tiles of one row into that subpatch. none of the patches containes more than 200 objects.
another thing is that I am using extremely small textures. I resize them to the minimum necessary pixels before I load them into the pix_buffer.
I also think that textures on the gpu are uncompressed, so 162 mb of jpg might end up in 1,6GB of actual data. but I might be wrong here.
I am using pd-x 41.4 on MacOS X 10.5.
marius.
Luke Iannini wrote:
Hallooo, I seem to be a crash-generating machine lately.
I'm spawning about 11,000 copies of an abstraction containing basically a [gemhead], [pix_texture] and a [square] and then loading a 57x57 pixel texture onto each square. If the GEM window is open, it crashes at (I believe) around 9000 squares, and if I leave it closed while the object spawning (successfully) takes place, it shows up black, sits around for a couple minutes, and then crashes. I attached a log of each variant. The former crash seems to happen in Pd, and the latter in Gem. The textures are only 162mb total and I've got a 512M card so I don't think I'm hitting limits there (and I saw Gem successfully report "out of memory" when loading textures on my less memory-endowed laptop).
I guess I can whip up a repro out of this, I'll do that next. Best Luke
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list