Smith

---

multiplayer: yes teh framework is there
mod support: yes teh framework is there

---

darthbabe96 wrote:

Just a quick question that would help me out. Are .MAT files written in Unicode?

erm no, there arent any strings at all in mat files.. therefore there is nothing in them that could be considered unicode or ansi etc.

they are just binary format mostly 32bit ints and then of course the pixeldata(s)

edit: they are, however, little endian.. but so is pretty much any binary format on pcs so loading values from any of jk resources dont require any byte swapping

---

i been taking it a bit easy, playing some games and work is busy; i have a 6mo project that needs just a little final work before we(company) can release it as an update.


quite recently ive been chipping away at indy. there appears to be a new third camera type (i guess "cutscene" camera) and a bunch of associated cog verbs so i been implementing those and exploring the levels, and trying to get some of the (multitude) of in-game cutscenes to work. i extremely happy to announce that all of the really major pieces of the *.cnd format ive been able to figure out, including like the animations. and there are a loottt of animations.


most recently, and more generally, ive been considering ways to reimplement physics since there are some issues. i believe i understand the thing attachment and drag coefficients etc- you can read my research paper on JK physics here https://smith.bah.wtf/Research.pdf
but ultimately i need a really solid swept-sphere to poly soup implementation. my implementation is not great..probably because i came up with it myself.. and i think there are some edge cases (PUN INTENDED) that i do not resolve overlap in the correct way. further, smith's collision system does kinda like try to do earliest collisions first but it is not a fully iterative solver. im not sure what JK actually is, but im guessing iterative? since i cant recall ANY circumstances where an object gets stuck in a position and jumps back and forth each frame.

long story short, if i can ensure an extremely solid physics system then i can remove BVH from the engine completely, and ensure that smith will do not only rendering but also collision detection (broadphase) in the same way as JK: cell&portal. this means at that point smith, just like JK, will allow sectors to overlap.

the solid physics system, eg. swept sphere to poly soup, also allows me to model a capsule as a swept sphere and use that for other purposes where a raycast should ideally have some width. this could be useful for a lot of crap, like AI could use it to determine if the actor is at the edge of a cliff or has space to jump up onto something etc.