Quote:Originally posted by vecna
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.
So.... you had to keep 6 times as much image data loaded in memory at once as you needed to? Which is equivalent to having 6 identical entities on the map?

Quote:Originally posted by vecna
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.
Wait a sec... keeping all that extra data in memory, and the blitting it EVERY FRAME is a better method? Than a one off blit on equipment change? How often do you see people changing equipment?

(where q = number of types of equipment)
Current method
One off: Load 1+q images
Change: Load 1 image
Every frame: Blit 1+q images
In memory: 1 image per unique ent, min 1 image per unique q

(Hopefully) new method
One off: Load 1+q images, blit q images
Change: Load 1+q images, blit q images
Every frame: Blit 1
In memory: 1 image per entity

...paperdolling with Hooks is far from easy, costs fps, and is still inflexible.

Zip

[Edit: note to self, equ is a bad variable name]

If you see any negative aspect to ditching caching gayo, I'll give you a hand drawing moar chrs. I hate endless identicals. Also, I'd can't see you having any kind of performance hit, and from what I've heard of your game, direct chr access could save you a lot of pain.

Also, gannon has just told me my last message made no sense. Basically:
entities > chr files = new takes more memory
equipment images > 0 = new takes less memory
equipment images > 0 = new is faster fps
new reqires less code to impliment

It's kinda memory on one side, and coding time, fps, flexibility and cool shit on the other.

Zip

And how many games will suffer from the extra 2.6 meg that 90 duplicate darin type images would need?

Zip

Two things.

1) The comparison to VO is a bit strained. As I said at first, our dilema had nothing to do with caching actually, what zero was saying was that we needed a thread to handle loading, which would have been true if we had continued because it would have been completely inpractical to keep all of our equipment templates in memory at once. In Anarchy Online, the characters represent by far the biggest resource drain. When they first added tower wars and the first mobs that required raiding parties of 50+ people, performance was terribly and we all thought it was lag until we figured out that if you stare at your feet the whole time, there was no lag at all. ... Anyhow. I only brought it up because its an example of how much memory CHRs CAN use, despite them being simple 2d sprites.

2) Paperdolling with hooks IS easy. For the FPS cost, its minimal in most cases. Woo you might drop from 300 fps to 280. It is more flexible for instance: If you have a 'weapon powerup' spell and want the weapon alone to glow or something, you can do that much easier with hookentityrender than with direct blitting to the entity frame.

Anyway I've decided not to do anything at this time and ponder additional options.

Zip, what I'm saying is that far more games would work fine with chr caching than wouldn't. It's also worth noting that if you only have a couple people to paperdoll (say, 5 PCs), you can just make 5 identical chrs and get the same effect, as long as some way to edit cached chrs is added. This would be exactly the same as having five versions of the same chr loaded in memory. By comparison, there's no easy fix for people who would prefer caching.

For color shifting, blit the entity frames to an image array at startup and color shift those frames. Then blit each frame(which will have already been color shifted) from the image array in HookEntityRender... Is this really so much trouble to go through? If you have an image array for every entity you want to do a color shift on, it should be much better than having a duplicate set of entity frames for every single entity on the map.

You really don't have anything forced on you...

Quote:Originally posted by vecna

its some demo with 100 darins on a map, don't laugh, its been done. :D

Who huh wha?

Quote:Originally posted by Zip

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


Darn, Zip beat me to it

I override the entity system and load the same characters over and over if needed, so each is a seperate image in memory. This allows my function UpdateRenderEntity() which basically updates ENTS[e].CurrentFrame with the correct grabregion from the main entity image. IE. I have CurrentFrame as the image of the current entity's frame. That's also what I blit with the function that HookEntityRender points to. And it only changes when needed, like Zip would with the whole changing equipment business, only updated when needed.

I like how Verge works right now, because I can override it, and that's all I ask for.

How about we all just use stupid Blit() and come up with our own animation and sprite systems? Huh?

I do think it would be good for the entity objects to have .totalframes, .framedata. That'd be simple and easy.

And an entity.framewidth and entity.frameheight. Thus you could use height, width, and totalframes to navigate the graphics in framedata.

I mean, regardless of the merits of using the entity's image data, Verge surely stores the entity's image data somewhere, right? Is it that big a deal to just expose it in VC?

Actually...the Caching idea is probably better.

something maybe like...

myentgfx = CacheCHR('darin.chr')
myentity = EntitySpawn(0, 0, myentgfx)

This way, if you ever need a duplicate graphical data for an entity, you could just set it aside, though this is exactly what everyone else has been saying...

I didn't realize that Verge3 assigns common entities to the same identical CHR graphic data, sorry about that.

But, still. If we're up for rewriting entity loading, I'd take the LoadCHR(string chrfile) in a heartbeat.

But either way, expose the graphical data. I don't care if I turn all the Darins pink, I want to be able to access the graphical data, and a .framewidth, .frameheight, .totalframes, and .framedata would come in real handy.



Maybe you could make a MakeUniqueCHR(int entity) which gives that entity it's own personal copy of graphic data so image manipulation won't affect other entities? That would work pretty good, and you wouldn't have to rewrite everything for caching and stuff.