Is there a way to manipulate an entity's frames directly? That is to say, could I replace one or more frames of an entity that is already loaded with a new image? I notice that there is an entity.frame[n] variable, but it appears to be just an indication of what frame is currently shown. Is there an (undocumented) entity variable (array, obviously) that points to the frame images themselves?

I would like to be able to represent what an entity is wearing for armor and such by changing the entity frames whenever they change armor. I know there is the ChangeCHR function, but that is not a practical solution considering the number of different combinations of armor you could have.

I also figure that if no other solution exists, I could just 'overlap' each entity with the correct image... that, or scrap my idea altogether :P

Thanks,
/g

That's cool.

Thanks,
/g

Zip shutup mode activate!

Shit, look. Most maps are going to have more entities than they will have CHRs. Thats why the CHR caching thing was put in.

But OK FINE. I'll take it out, and make every entity have its own COPY of the CHR regardless of if its some demo with 100 darins on a map, don't laugh, its been done. :D

Quote:Originally posted by Toen

Quote:Originally posted by mcgrue

Zip shutup mode activate!
Biter.

What, nobody else can activate shutup mode? :(

Oh, Great Capitalism, I have been a loyal follower... why hast thou forsaken me? ;_;

You shall get your 'Royalties', Toen. I will pay you one million. Is that acceptable?

An example.
Lets imagine you want to use 48x48 CHRs. thats reasonable. Thats what VO CHRs were.

Lets say you have 50 frames. High, but reasonable, if you're including battle frames. VO had more than 50 frames. Closer to 100 frames, if I remember right.

Lets say you have only 100 entities on the map.

48x48x50x4x100 = 46 megs of RAM.

Thats totally not counting the occasional BIG chr for whatever reason. a 100x100 or larger CHR. And the hardcoded entity limit is 256, I've seen a handful of maps with >100 entities.

If there were only 10 unique CHRs on that map, then with CHR caching it'd have been 4.6 megs of runtime ram usage.

When you have CHR caching, on the assumption that you're probably not going to have a lot of UNIQUE chrs that size, you can have rediculously sized CHRs with as many frames as you like, and you'll basically never use a sizeable amount of ram.

46 megs of RAM is not a lot for me. I have a gig of ram. Thats not a worst-case scenario though, and thats only CHRs, not counting anything else that needs to be loaded. Any map with high number of entities, closer to the hard limit, will be using a lot of RAM, enough to make windows start paging stuff, even if you haven't run out of physical RAM free.

32bit? What, we have an alpha layer but not using it? Err... anyway, didn't wanna cause trouble. For the mean time, here's a little code.
Load from a plain text datafile:

// Critter file for Darin


darin.png // Image file for Darin (image)


darin.chr // Chr file for Darin (loaded to ent)


6,5 // Rows by colums of frames in image (imx,imy)


16,32 // Width by height of frame (framex,framey)


1 // Frame padding (fpad)


// To come later: colour data

Then instead of using:

int hotx_on_screen = entity.x[critter[c].ent] - xwin;


int hoty_on_screen = entity.y[critter[c].ent] - ywin;


int frame = entity.frame[critter[c].ent];


BlitEntityFrame(hotx_on_screen, hoty_on_screen,


critter[c].ent, entity.frame[critter[c].ent], image);

You use this (which is much less scary than it looks):

int x_on_screen = entity.x[critter[c].ent] - xwin - entity.hotx[critter[c].ent];


int y_on_screen = entity.y[critter[c].ent] - ywin - entity.hoty[critter[c].ent];


int frame = entity.frame[critter[c].ent];


int startx = (frame % critter[c].imy) * (critter[c].framex + critter[c].fpad);


int starty = (frame / critter[c].imy) * (critter[c].framey + critter[c].fpad);


TGrabRegion(startx + critter[c].fpad, starty + critter[c].fpad,


 startx + critter[c].framex, starty + critter[c].framey,


 x_on_screen, y_on_screen, critter[c].image,image);

Speed is fine.

Zip

Damn... now I HAVE to make the converse argument to vec.

You know the best thing about Milk? The memory it saved from having all those identical darins.

But seriously... how many verge games have 48x48x50 chrs? How many vergers are good enough and have the time to draw a game full of art like that? And then lack the style to do anything other than spawn endless duplicates on a map? And run it on ovk's computer?

Compared to that, how many vergers would like to do a game where each entity DOESN'T look the same? Have a simple way of changing the an entities sprite if their equipment changes? Have a way colour shifting entites for a bit of varity? Or just have a run animation different to the walk one?

Added to all this the fact that Chrmak5 is not... the most graphically interfaced of programs, and you waste a lot of time, effort and fps coming up with soulutions to a memory saving issue that no verge game has ever run into. Hell, first time a verge game does, I'll help them make maps which only spawn the entites for one section at a time.

Zip

Quote:Originally posted by Zip


But seriously... how many verge games have 48x48x50 chrs?

Not that many, but VO was actually a worse situation than that. We had 48x48 frames, ~100 frames, and each character was composed of on average 6 layers of equipment paperdolling.

(yeah, you get an idea why we eventually gave up)

RAM usage was through the roof without caching.

Most times I have said 'what VERGE game is going to yyy feature?' someone has asked me for it. Games aimed at 640x480 do typically not have 16x32 CHRs, thats why Grue insisted that >16x16 hotspots be part of V3's entity system.

Many people may use one template, and only have 50 drawn frames in their main characters, but other NPCs may be using a 50-frame template. With the existing system, this will not really adversely effect anything.

HookEntityRender is a much better solution than making slightly varied CHRs anyway. Gungnirs question was basically about paperdolling, and the best way to do paperdolling is with HookEntityRender.

Anyway, no point in arguing. As I said, I'll change it to work the way you guys want.