so, not much notable recently...
pretty much the past month it seems has mostly been things like performance optimizing and trying to shave down the memory footprint...
well, and I also added Oculus Rift support...
however, it is still a limiting factor that I can only use the thing for short periods of time before motion-sickness sets in, but OTOH, neither my engine nor Minecraft apparently pulls off the required framerates to effectively avoid motion sickness.
have a few times considered idle ideas for a few things:
possibly moving to a 3D model format with precomputed frame vertices (and deciding between something like ".md3" or "compressed dumped VBOs");
as-is, most of this stuff is computed at runtime, which is kind of expensive, as well as the model loading times being an issue (want to load them ideally without introducing a perceptible delay, which is a problem if it would involve calculating a bunch of stuff during loading);
ideally, I also want to keep the skeleton around in the off chance I later want to add something like ragdoll or similar.
also experimentally moved textures to a package, where converting the textures from PNG to BTJ reduced them from 70MB to 22MB.
also packaged up the audio, taking it from 30MB to 8MB, but there seem to be quality issues with many of my sound-effects and my BTAC codec. (ADD, FIXED: integer overflow, needed to add range-checks and clamping).
I am tempted to look into other possible options, with the goals:
similar or lower bitrates;
better size/quality tradeoff;
supports random-access decoding.
messing more with quantized entropy-coded ADPCM-like algorithms (some of my past audio codecs), but granted my past attempts had size/quality issues;
fiddling around with an MDCT based codec (similar to Vorbis or MP3), just designing it more for random-access rather than stream decoding;
hacked random-access-oriented version of Vorbis?;
ADD: a new codec may be unnecessary... it seems the main sound-quality issue I was dealing with was due mostly to an integer overflow, which has now been fixed.
otherwise, had another idle thought related to image and video coding.
BTIC2B was probably a bit overly ambitious of a design (with too many tunable parameters, ...).
I may possibly consider an idea for "BTIC2C", which would mostly aim to be a simpler format with less encoding options.
probably: AYUV 4:2:0 with 8x8 WHT, and a YCoCg color-space, ... (and ideally simpler and faster than JPEG).
would probably aim to include basic video features in it. these would be mostly frame-deltas and block-motion-compensation. (main other options here: work more on video-coding stuff for my BTJ-NBCES format, or maybe consider using something like a hacked version of Theora...).