FavoritoHJS

i was thinking of it being used for full-blown cuboid fills, but i don't think those will be helpful enough to matter...

Overrideable Blocks: basically a normal, renderable block that can also be placed over, like tall grass or snow in MC DEPRECATED: not useful unless you HAVE to input an id for each possible block position, which no packet does atm. Noop ID: Reserve the highest id representable (currently 0x3FF, 1023) as a "noop" - this means that trying to place this block in any way results in nothing happening, leaving the current block in its place Extended Extended IDs: Increase the highest valid block to 1023. Will need to find a way to fit the extra 256 ids into the system MCGalaxy uses, which should be possible if so much as a single free bit is found in all size-constrained structures. Advanced Filling: Adds the following: A slight modification on how block indices are used: Indexes -1 to -256 mean "skip forward this many indices". This means, for the most common operations (large fills or copies, for example), poorly-compressing number changes are replaced with long runs of a few numbers (with the most common case of -1 being 4 FF bytes), all at the low cost of shrinking the maximum world area size by 256 - assuming unsigned ints for the index are even enforced, otherwise there's no change! Paletted Bulk Update: Many operations tend to modify a large amount of blocks, but only do so with a few block types. This packet takes advantage of this redundancy to decrease size of payload data. TODO: Check if this is worthwhile in bandwidth. Count is an unsigned integer, just like in BulkBlockUpdate 16 block definitions (totaling 16 bytes for non-extid or 20 bytes for extid) 256 ints for block indices, same as BulkBlockUpdate 128 bytes for what block id is used for this position. Bulker Block Update: Same as BulkBlockUpdate and its paletted counterpart, just with all fields increased in size by around 16x, creating a larger packet that should be able to compress better over the network. (if you aren't transparently compressing packets, it might be worthwhile to make these a variable-length packet for a compressed version of this) Count can become a short or remain as a single byte, whose value is multiplied by 16 to get the used count. Up to 15 extra SetBlock packets after this should be small enough to not really matter. NEW! 01-12-23 Model part properties: 2 new property type values, each one being a bitmask, with each bit enabling or disabling one of the 64 parts of a model. Useful for making multiple small variations of a single model without relying on transparent textures. Alternatively, more properties can be used, and a way to turn such info into an animdata field added to allow for further per-model customization. Sounds: Already explained here:

fair enough, though the option of a dmca takedown seems a bit too nuclear imho. ...wait a minute we're verging right off topic aren't we? answering the op's question, i fear the mere fact of asking said question has locked you out of the sigma chromie rank. have fun!

(laughs like that guy who cross-compiled 1.5.2 into javascript, see eaglercraft) (cries in surprise takedown) (realizes they probably copied his homework as well) yet another reason why microjang is dead to me

hmm, i wonder how acceptable a 16-color pack would be if manually pixeled... something somewhat important is what shade of brown is to be used? iirc windows used dark yellow which could make creating a good dirt kinda difficult...

well, from what i recall 3dfx glide does have a dos api, and i'm sure a voodoo 2 should be able to render enough polys at a playable framerate to match a tiny render distance. EDIT: Here's a rough performance estimate, based on the 3dfx Voodoo Banshee technical reference at https://3dfxarchive.com/reference.htm. Wanted to use the Voodoo 2 reference, but the performance numbers there were illegible... The card should be appears mostly fill-rate limited, with a maximum fill rate of around 50Megapixels per second rendering trilinear texture-mapped polygons. Assuming a 20fps framerate, this equates to 2,5Megapixels per frame, or 5 full 800x600 repaints. Of course you'll probably want a higher framerate. If purely fill-rate limited, you could achieve 100fps, but that would require having no overdraw whatsoever, something that sounds tricky. With sufficient optimizations, I'm sure 45fps is possible, and maybe even 60 if you have low enough overdraw.