[Vasudan Admiral]

Any image - including those in the interface is loaded into bmpman. I'm not sure about .ani files though, and I also don't know about where or when images are unloaded - especially in regards to interface files. Hopefully that's done efficiently but it may well not be.

As for what the FSU does with animated glowmaps - from memory I don't think anyone on the team thinks they're worth the performance hit they cause actually.
Hence the add-on VP to 'abolish' them. I doubt they'll come out entirely due to their widespread popularity until we can provide an equal or better alternative method via a material system.

[Fury]

I don't think anyone on the team thinks they're worth the performance hit they cause actually. Hence the add-on VP to 'abolish' them.

Shouldn't this be reversed?

[Vasudan Admiral]

Hmm, IIRC it was kept in the main one to make things as simple as possible to install (especially with MV_Complete), but since then the MVPs have become download-separately anyway so putting the animated glows in their own VP would probably be more ok for the next release.

[Mehrpack]

even worse when considering things altogether. under 64 bit os your 32 bit apps can use up to 2 gigs of ram. if you are lucky.

hi,
under windows x86 (XP, vista 32 bit and so on), each application has a address-space of 2 gigs.
thats not limit to the installed ram, if you have 1 gig ram installed, the application, can still address 2 gigs of address-space.
under windows 64, is the same, only if the application has flag with the "large address flag". then the application can use the full 32 bit address-space of 4 gigabyte and if you have installed 4 gig or more of ram, the application can then use then 4 gigabyte of the ram for theres data.

why its limit until 2 gig address room in windows 32 bit?
because the rest is reserved by the operation system to mapping in the graphic-card and so on.
but man can chance the reserved in the boot.ini so that the system only reserved 1 gig of the address space, for example (you can type i a amount of the address-space which has to be reserved for the operation system, but less a 1,5 gigabyte for the operation system isnt really good).
the problem is, if you limited the system to 1 gig address-space you get trouble with the drivers and the system didnt work or get instable.

Mehrpack

[pecenipicek]

pecenipicek: you'r loss

Excuse me, but how was i wrong? Its still a bad idea in my opinion, and now you just got tons of better explanations as to why its a relatively bad idea.


@Mehrpack: what you said.

Also, PAE sucks


(hint, just move the quote tag to the end of my quote, it'll be abit more readable...)

Hmm, IIRC it was kept in the main one to make things as simple as possible to install (especially with MV_Complete), but since then the MVPs have become download-separately anyway so putting the animated glows in their own VP would probably be more ok for the next release.

Arent the animated glows in the advanced part anyway?

To tell you the truth, i kinda like the animated glows on the SF Mara and SD Ravana. In my opinion, one of the better uses of animated glows.

But actually, i do support separating them to another VP, if it wont be too much of a hassle.

[Mehrpack]

[...]
@Mehrpack: what you said.

Also, PAE sucks


(hint, just move the quote tag to the end of my quote, it'll be abit more readable...)
[...]

hi,
yeah, so really, had make more trouble as solved really problems.

thanks, total oversee that i forget to close the quote *g*

Mehrpack

[Nighteyes]

pecenipicek:

So no you're correct that a 170 frame, 256 res explosion won't eat all your memory and won't murder your FPS, but it WILL eat a sizable chunk of available texture slots.

eat a chunk of texture slots, witch I have plenty to spare, so its not such a bad tradeoff IMO, as I said, its not like ALL effects are 170 frames...
and by you'r loss I was refering to you'r comment: "also, no, i will not look at diaspora as i have no interest in yer freaking toasters or however you call it"

[pecenipicek]

pecenipicek:

So no you're correct that a 170 frame, 256 res explosion won't eat all your memory and won't murder your FPS, but it WILL eat a sizable chunk of available texture slots.

eat a chunk of texture slots, witch I have plenty to spare, so its not such a bad tradeoff IMO, as I said, its not like ALL effects are 170 frames...

your loss

and by you'r loss I was refering to you'r comment: "also, no, i will not look at diaspora as i have no interest in yer freaking toasters or however you call it"

then quote properly you muppet

[Vasudan Admiral]

I would agree with Nighteyes that dedicating a reasonable chunk of slots to such widely used effects is a good idea. Unfortunately while the animated glowmaps are still lurking taking up a decidedly unreasonable chunk, we can't so easily do that. :\

[Nighteyes]

perhaps a poll should be posted, regarding moving the animated glow maps into an optional VP, while the normal mediavps don't use them, or just use them on specific parts(like the nice ravana tubes)... this won't only give some breathing space regarding new effects, but will also allow the usage of more ship diversity in mission 

[sigtau]

mv_advanced... it was made for a reason.

[The E]

mv_advanced... it was made for a reason.

Umm, sigtau, the question is not whether animated glowmaps or large effects are materail for mv_advanced or not. It's about one of the most fundamental engine limitations. Consider this: There is a fixed budget of 4750 bitmaps the engine can have loaded at any given time. You can't go over it, and going even near it can lead to strange things. Now, imagine what happens if someone builds a mod based on the mediavps. How many bitmap slots are available?

[Zacam]

perhaps a poll should be posted, regarding moving the animated glow maps into an optional VP,
...snip...

That won't be necessary. The poll that is. As it will already be happening exactly that way. Advanced will still be Advanced, with animated effects and the animated ship-maps will be separate (Which will then cause for MV_Abolish to be abolished as it won't be needed anymore).

Hopefully, we'll also be able to container all of the animated effects into a per-effect container. I had also thought about a really old trick from Win98 days to have animated BMP's in the boot screen, where you have a single static frame, and then color code to "animate" it. For a basic ship animated glowmap, we still have a few more options before we have to start looking at the model format. My guess is though that POF is running out of room and durable expansion.

[Vasudan Admiral]

A few years ago Bobboau prototyped a material system that looked really really promising. You could only do ship-wide material effects but I had loads of fun plugging different sine waves into the RGB values for the glowmaps and creating a disco on an arcadia.

I mean, that's really all a lot of the animated glowmaps do now - they take 30-90 frames to just pulse in brightness. That kind of thing is piss easy with the simplest of material systems, but if you added masks, texture translation, rotation etc (of the mask in particular) you could get some very sweet effects for the footprint of 2 or so frames compared to a 60 frame animation.

A more complete implementation could also allow you for example, to remake and even improve those shivan animated effects where the red stuff just shifts back and forth between 2 'forms', you could do things like crossfades between two (or more!) glowmaps to achieve the same effect. For stuff like the rippling flow on the ravana pipes, a translating brightness mask would work perfectly. You could make the lights on a ship flicker and fail sporadically when it's about to die like this: http://s5.photobucket.com/albums/y184/VA--Twisted_Infinities/Cutscenes/?action=view&current=FenrisGlowDie.flv

The possibilities would be endless!

[Herra Tohtori]

Endless indeed. You could pretty much do the same for a normal map, simulating (for example) a surface of water with multidirectional waves interfering each other...

[pecenipicek]

A few years ago Bobboau prototyped a material system that looked really really promising. You could only do ship-wide material effects but I had loads of fun plugging different sine waves into the RGB values for the glowmaps and creating a disco on an arcadia.

I mean, that's really all a lot of the animated glowmaps do now - they take 30-90 frames to just pulse in brightness. That kind of thing is piss easy with the simplest of material systems, but if you added masks, texture translation, rotation etc (of the mask in particular) you could get some very sweet effects for the footprint of 2 or so frames compared to a 60 frame animation.

A more complete implementation could also allow you for example, to remake and even improve those shivan animated effects where the red stuff just shifts back and forth between 2 'forms', you could do things like crossfades between two (or more!) glowmaps to achieve the same effect. For stuff like the rippling flow on the ravana pipes, a translating brightness mask would work perfectly. You could make the lights on a ship flicker and fail sporadically when it's about to die like this: http://s5.photobucket.com/albums/y184/VA--Twisted_Infinities/Cutscenes/?action=view&current=FenrisGlowDie.flv

The possibilities would be endless!

THIS!


Also, as a side question, wouldnt this be possible already if we could assign shaders on a per-ship basis and with some fancyful render-to-texture stuff? (especially for animated normalmaps

[Angelus]

Thanks for the clarification Vasudan Admiral... it works then more or less how I thought it did, and as I said in earlier threads, the FSU should consider what it best for it, stupid animated glow maps, or nicer explosions/effects that you get to notice much more...
also, for the same reason, I feel free with Diaspora, as there is absolutely no animated glow maps the limit will be hard to reach even with 10  explosions lasting 170 frames each(don't worry, most are more reasonable, from 60-120 frames)...

The E: if I'm not mistaken, the interface stuff, as well as the animated CBanims don't count to the total frame limit, only stuff that loads at the beginning of the mission, as in effects, diffuse, shine, and normal maps...

pecenipicek: you'r loss

  eyes of a Cylon? Unless you do it differently...

[Nighteyes]

eyes of a Cylon? Unless you do it differently...

well, yes there is that one, but its a tiny effect, so I don't count it

what about rippling normal maps for shield impacts?

[pecenipicek]

wouldnt work properly. would be nice to see, but i really doubt you can do anything with the shield regarding textures honestly...

[Vasudan Admiral]

If given a way to tell if the shields have been struck, then about the best you could do with the kind of material system described would be to have the whole shield shimmer. For anything more advanced you'd need to be forming systems that project certain effects onto the shield when needed, or perhaps a poor-mans UV projection system would involve the modeller unwrapping the shield mesh onto a 'shield texture', and somehow working out where on the texture space the strike occurred and passing that on to the material system to draw whatever effect was supposed to occur.

There'd be a seam though, since if the shield texture was stuck near an edge, it wouldn't neatly wrap around to the other side of the map....

Yeah that kind of location-variable effect would be quite difficult. :\