After some thinking about the panel pictures....I'm gonna scrap using png files. In fact, the panels won't be using any panel specific image. The number of combinations for each panel (colors), animations (eventually), and levels for each panel...the game will be huge.
For the 6 basic tiles in 6 different colors, the file size will reach ~3MB and be over 90 pictures.
For 6 basic tiles modeled as 3d objects and dynamically colored, the file size will be ~1 MB and only need 6 objects.
What I'm thinking about doing is one of two things. Have a panel made, then moved into position with the rest of the block. Or make a block with the panel already in place. I'm hoping for the former (due to a smaller file size)....but the latter sounds more plausible.
Well, after some initial testing....it looks like I'm back to bashing my head on the wall.
ReplyDelete= Using a 3D model to represent the picture with dynamic color coding:
Pro: less files needed, smaller total program size
Con: program loads slower due to needing to build all the objects
= Using a image to represent each panel
Pro: Each panel is accounted for
Con: a lot of pictures are needed and the file size will quickly build into the MB range
....So, now I'm back to using images, BUT, this time, I'm gonna do something fancy with them. Instead of being colored to the panel's color, they will be in shades of green (red channel is used as a ID key, green channel is used for transparency). This will drop the file size per image from ~12 KB to ~4 KB (11.9 KB to 3.77 KB in one test case). And each image can be used multiple times.
Pro: There will not be more files needed per panel than the number of panels. Each panel will still be represented. I could not load cretin images yet if they aren't needed (reduces running memory)
Con: It makes my head hurt, there may be a delay in making the children from each image
Additional note: I'm unsure of how to attach each image to the blocks. I "hope" I can use object names in the Obj file.