The Entity System:
indeed the big, scary entity system.
it is big and scary because 2D elements do not lend themselvs well to the 3D way of doing things, which I have detailed in the past.
the first hurdle to pass is creating a system of storage, thankfully this was already designed a while back.
images all exist as frames, and are grouped together via xml into a 'sheet' which is a collection of frames and associated information.
information such as, how much area world area does the image displace, how much area is availible to hit-test.
an entity contains references to a number of sheets.
the second large hurdle is the loading of each frame, the solution we will use is both design based and technical based.
Technical:
when an image is loaded, it will first try to load itself into a best-fit container, where valid W/H dimension choices are
16,32,64,128,256
if either dimension exceeds 256, the image needs to be split across multiple textures, an optimal texture size will be selected for the multiple parts.
when an image is drawn it may require multiple quads to handle the textures.
Design:
it is up to the artists (me =D) to design nicely sized images, that is, if an image can be under or at 256x256 that is optimal, and never should an image be 257x258, this would result in tremendous waste, and the image should be redesigned to fit in 256x256.
thankfully this exceptional waste case can be detected, and while the system will handle it, under debug mode it will log message giving waste ratios for all images, with warnings for more than 25% waste
more on this later, tonight i will get the frame/sheet system working.
