I just got a weird theory to optimize texture memory... There are times when you just need textures that are not power of 2, for example odd 300x200 image. nxPascal can currently load that as either scaled to nearby size (256x256 in this case) or pixel-perfectly unaltered but fit in 512x256 "frame". However the "frame" will in this case waste alot of unused memory.
What i came up with (as just idea so far), is that i'd have 2 integer (word) variables per texture: XPart, YPart. The loader would calculate perfect fit for image that is divided in 1, 2 or 4 subtextures. That 300x200 would be divided in 2 parts to make as whole a 320x256 "frame", because the height cannot be split in 2:
256x256, 64x256
If i count memory saving for RGBA image:
300x200 originally as 512x256 "frame" needs 524288 bytes.
2 subtextures need 262144 + 65536 = 327680 bytes
which is 62.5% of memory that would normally be reserved.
Obviously this will need draw functions to adapt to subtextures but it shouldn't be problem. 3D model surface would be unable to use this well, but models should always use the scaling option anyway for repeatability.
Edit: Actually it is big problem if want to support patterned drawing... I'd propably disable/ignore patterns when this is used.
Also, i just got BASS musics working with Lazarus so that's what i'll be using. Need to make a class wrapper to it to ease the procedural DLL header unit.
Reply With Quote
Bookmarks