Max Alias Frames

[Ghost_Fang]

In my attempt to allow more frames per alias model on the psp, i came across an error. It compiled and everything, but when i tried to start a new game after initial load i got this:

Code: Select all

Cache_TryAlloc: 1892880 is greater then free hunk.

Now what i did was found the only line of code that determined the max allowed frames which was

Code: Select all

#define MAXALIASFRAMES 256

and I simply changed it to 512 to stay square.

I don't know much about engine, but what i can assume is that I allowed more frames (because it actually loaded this time) but it needed more memory than the allowed hunk?

Could someone assist me in the proper way of allowing more frames per alias model? My frames for my character model are 435 and i cant really go lower than that. So could i get a little help? Maybe I just need a few more steps to finish it? Or am I doing it all wrong?

[revelator]

that is the correct way but there is a limit before you need a protocol change i think.

a few engines use dynamic allocation for a few of the otherwise static structs, try looking in QIP quake there should be some examples on how to do it that way.

[mh]

The protocol limit is 256 (from SV_WriteEntitiesToClient):

Code: Select all

if (bits & U_FRAME) MSG_WriteByte (msg, ent->v.frame);

You'd need to change that to MSG_WriteShort, and also the corresponding U_FRAME condition in CL_ParseUpdate to MSG_ReadShort.

Also look for CL_ParseBaseline and SV_CreateBaseline which also read/write the frame as a byte. Fortunately mdl_t stores numframes as an int so you don't need to go messing with binary formats. There don't appear to be any lurking problems in Mod_LoadAliasFrame or Mod_LoadAliasGroup either.

If you do change these from byte to short (which will give you 65536 frames) be aware that you're breaking compatibility with standard Quake and you won't be able to run your content on other engines, communicate with standard Quake servers, have standard Quake clients communicate with you. For the PSP that might be OK, but it's useful info if you ever work on a PC engine.

If you don't want to break compatibility a cheesy hack might be to store half your frames in one MDL and the other half in another, and switch models instead.

[revelator]

One way i thought of was having a cvar control it set to the standard
value 256 and make something in QC to change it to something higher
if the mod requests it ?.

But aye it will break protocol if set higher on standard quake so to play online both would need the same client.

[Jukki]

Hey, arent you using darkplaces for pc engine?

Because afaik there can be no darkplaces hosting and other quake clients joining?

Just this camed up when we were talking about thease things

[Spike]

/me has a look at the code.

MAXALIASFRAMES is the max number of _poses_ rather than actual frames. There's also no check to make sure its not exceeded. If it is the engine will start to stomp over other bits of memory.
So yes, if you want more than 256 frames in a model, you'll need to increase that define to something higher. It won't use much extra mem.
But its only half the story as those guys already mentioned the protocol is limited to 256 frames too.

But yeah, that won't stop you from running out of ram, which is the deal breaker. You say its a character model. Sounds like it has a lot of verticies to go with a lot of frames. So its not really too surprising that you're running out of ram.
Your options are:
use a larger heap (though I'd be surprised if a psp engine wasn't already tweeked to have as large a heap as it can).
reduce vertex count
reduce frame count
split the model into multiple models, and depend upon the cache system to flush the old ones out of ram and load new ones as needed.
use a skeletal model format, as storing bones instead of verts often takes less ram when you have 1000 verts and 500 frames.

[Ghost_Fang]

reduce vertex count
reduce frame count

Verts: 356
Faces: 692 (not much at all for each.)
Frames: 435 (and I cant go any lower than that, i already reduced the frames to the minimum i need, and I'm gona have 4 different playable character models and i would rather not have 2-3 models for each of the 4 characters.)

texture size is even small, 312 x 256..... Hmmmmm now that I think about it, does Kurok require a square texture size since its based off of Glquake?

Im not worried about compatibility, my target audience is the psp community, and as long as all my current content runs on the PSP and increasing the amount of allowed frames doesnt take up too much ram than I'm ok with that. But what kind of compatability am I losing? It already runs fine in darkplaces, I finally updated my psp version with the player model and the coded frames and it wouldnt load.

[Ghost_Fang]

EDIT: Ah crap, ignore this... (quoted not edited my second post)

[mh]

It'll work fine in DP because DP has an extended protocol that can handle the extra frames, as well as more mature memory management. Those problems just don't exist with it.

If you're not worried about compatibility then go extend the protocol yourself. Change those MSG_ReadByte/MSG_WriteByte calls to MSG_ReadShort/MSG_WriteShort. If you do, be sure to also change the value of PROTOCOL_VERSION. I'd suggest picking a really high number - something over 100,000,000 - so as to not conflict with other protocols out there.

It's a long long long time since I worked with the standard GLQuake model loader so I've no idea what it's like memory-wise (aside from the fact that it has high overhead when building those horrible strips and fans), but it wouldn't surprise me if it did have built-in assumptions about max frames. I posted a tutorial some time ago with a better MDL loader/renderer/in-memory format, you can still find it here: http://forums.inside3d.com/viewtopic.php?t=1931. It should also draw them faster (but maybe not on the PSP if indexed vertex arrays aren't it's thing) and is much more memory-efficient. It does assume a standard unmodified GLQuake though.

[Ghost_Fang]

i changed all the read/writebtyes to shorts and i get a "Host_error: CL_ParseSeverMessage: Illegible server message"

Did i do something wrong?

[mh]

i changed all the read/writebtyes to shorts and i get a "Host_error: CL_ParseSeverMessage: Illegible server message"

Did i do something wrong?

You get this when you run the engine for the first time and a demo should start? You did nothing wrong - demos aren't compatible with this change. Try entering a map and see what happens.

[Ghost_Fang]

I did i still get the same Cache_TryAlloc error

[Ghost_Fang]

do i have to change everything related to alias models? or just anything that reads and writes to U_Frame? I changed everything related to u_frame to Read/WriteShort. And I got the same Cache_TryAlloc error.

BTW, MH, I tried your better mdl tutorial, and I got too many arguments for GL_MakeAliasModelDisplayLists i think, i dont recall off the top of my head, i know i got too many arguments for something. Is your tutorial compatible with Kurok PSP?

[Spike]

read/writebytes will not affect whether you get a cache error or not.
if you have too much data then you have too much data, regardless of whether you can actually select those extra frames or not.
changing the read/writes is purely so that you are actually able to select frames beyond 255 and will not affect whether the engine is able to load a model with 255+ frames.

[Ghost_Fang]

well without the current changes i have made to get to that error, it just freezes the psp entirely. At least when i changed the #Define MAXALIASFRAMES to 512, it gave me an actual error, so regardless i would need the changes i have done so far. So what would you suggest? Get better MDL loading with MH's tutorial and try to adapt it to the psp? Or try a more memory efficient model format? Such as Md2, isnt MD2 a little bit more efficient?