I noticed this when using scrolling sectors + static (and/or dynamic) lights on version 1.29. The game losses A LOT of frames per second. On my computer, the game runs at 30 FPS approx, but when looking at a scrolling floor sector with a number of lights, the frames down to 10 or 12. This also occurs when using "Floor_LowerByValue ()", "Floor_LowerToNearest ()", and all those moving ceiling/floor functions with lights. So, i'm asking Janis if he would enhance the engine performance for that kind of common effects, if possible, of course.

oh yes, i know that problem too. actualy, it is caused by quake-style lighting engine. I've already written a pm to Janis with ideas how to optimize it. the problem is in covering ALL the map with lightmap, and when some geometry in light radius is changed, the engine rebuilds a large part of this lightmap in realtime. i think it would be better to cover the map with such a thing only in light radius, and to rebuild only a small part of it. Btw, it also slowdowns on large terrains. Anywas that is only my idea, may be im mistaking somewhere, so we have only to wait Janis's answer <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->

It doesn't cover all map with lightmap, only surfaces that are lit by the light source.

[quote="Janis Legzdinsh":2ed02q2k]It doesn't cover all map with lightmap, only surfaces that are lit by the light source. This means you will take a look at this?

Another aspect of vavoom that have to be optimized is it's starting process. I've tested vavoom 1.20 and 1.29 starting in gl mode for doom2. 1.20 = 3.7seconds 1.29 = 24.3 seconds What is that time for? I think that's about decorated game classes. Janis, i dont know why did you moved all the basic classes to decorate, but, please, move them back to Vavoom C, make them binary code, it will save lots of time when starting vavoom.

[quote="Alex-bomber_Man":1rne4sng]Another aspect of vavoom that have to be optimized is it's starting process. I've tested vavoom 1.20 and 1.29 starting in gl mode for doom2. 1.20 = 3.7seconds 1.29 = 24.3 seconds What is that time for? I think that's about decorated game classes. Janis, i dont know why did you moved all the basic classes to decorate, but, please, move them back to Vavoom C, make them binary code, it will save lots of time when starting vavoom. It's rather because basepak.pk3 now include raw progs source, that is being compiled each time you run a game. This was already reported - <!-- l --><a class="postlink-local" href="http://vavoom-engine.com/forums/viewtopic.php?p=6875#p6875">viewtopic.php?p=6875#p6875</a><!-- l --> This can be solved by replacing raw progs by compiled ones.

I've just said about that =)

[quote="Alex-bomber_Man":3oqxap5r]Another aspect of vavoom that have to be optimized is it's starting process. I've tested vavoom 1.20 and 1.29 starting in gl mode for doom2. 1.20 = 3.7seconds 1.29 = 24.3 seconds What is that time for? I think that's about decorated game classes. Janis, i dont know why did you moved all the basic classes to decorate, but, please, move them back to Vavoom C, make them binary code, it will save lots of time when starting vavoom. I second you. I think until 1.26 the engine loads fast, but since we got all in Decorate or not compiled progs, testing our MODS or maps makes us to waste lot of time in load processes. I really dont know why we have all source in Decorate, instead VavoomC. Janis, please, set all back to VavoomC. Because VavoomC is so nice, i think Vavoom worths it. <!-- s:P --><img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz" /><!-- s:P -->

Maybe make 2 variants of basepak.pk3, one with decorate and one without? Since both ways are supported. Personally I do not care much though, because it runs not very slow for me even so.

Besides, AFAIK it happens only when the game starts, not when every other map is loaded <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->.

But it makes me angry when each time i'm testing my project on vavoom, i need to wait over 30seconds! Thats too much. Bring back Vavoom C classes!!!!

[quote="Alex-bomber_Man":3lzdwnx0]But it makes me angry when each time i'm testing my project on vavoom, i need to wait over 30seconds! Thats too much. Bring back Vavoom C classes!!!! The question is: does this happen when you use raw Vavoom C code in basepak.pk3 or when you put compiled dat files as well?

I can't say - i have none of them, only standard decorate basepaks =(

[quote="Alex-bomber_Man":1jl26o5i]I can't say - i have none of them, only standard decorate basepaks =( That's absolutely impossible, there should be core VavoomC progs in this or that form. For example, check basev/common/basepak.pk3/progs/ - whatever folder there - / Which files do you see? Are these *.vc files or *.dat files?

There are decorate txt files! in actors folder. Look it yourself.

[quote="Alex-bomber_Man":bgnb7qyv]There are decorate txt files! in actors folder. Look it yourself. Ofcourse there are. But I was asking about Vavoom C progs in "progs" folder. Are they compiled or raw source code? I am asking because if there are sources, you may compile progs and put compiled progs (*.dat files) instead to increase the speed with which the game is loading. According to my experience loading goes about 2-3 times faster then.

On 1.29, the VC are not compiled. But i got high loading times on version 1.28 too, and VC are compiled on that version. Not so high as 1.29 ver., but too high for keep testing all the time. It would be nice to have the full VavoomC again.

I'm testing the latest Vavoom revision, Janis has made some nice fixes to the code,it runs much better on open maps now <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->. I'm testing it with compiled VC sources too, so I can't really say if it loads faster or not, I'll do the test thought and report later my findings <!-- s;) --><img src="{SMILIES_PATH}/icon_wink.gif" alt=";)" title="Wink" /><!-- s;) -->.

Yes, loading of DECORATE has been improved significantly. Some of those changes also improve compilation of progs. It loads much faster now. Last few days I've been playing Deus Vult II, which forced me to completely change line of sight checking code which works much faster, especially on maps with huge number of monsters. Last few maps still have performance issues that I will investigate now.

Sounds very reassuring <!-- s:D --><img src="{SMILIES_PATH}/icon_biggrin.gif" alt=":D" title="Very Happy" /><!-- s:D -->

I just noticed that in 1.28 I got a consistent 60 fps, but in 1.29 its usually around 30-40 fps <!-- s:? --><img src="{SMILIES_PATH}/icon_confused.gif" alt=":?" title="Confused" /><!-- s:? -->

Is it possible to have the in-game performance from 1.28 version (60 FPS) and the low load time of the 1.26 version? I realy like a more "bugless" and "depurated" engine, than a engine full of features, but low performance, FPS, and some annoying bugs. I think that Decorate (on Vavoom) should be an option, not a mandatory feature for "coders", because we already have VC, and I don't see a reason to have all actors in Decorate. In that case it would be better to use zDoom. Well, thats my oppinion. Salutes.

Tested a new version,liked new optimizations a lot. But i have a few more ideas for optimizing. 1-floor/ceiling movements still take a lot of processor resources. That have to be fixed, at least by changing down lighting count frequency. 2-camerastextures

Off topic alert: fernado, I had to read all 4 of your posts before I figured out you weren't a bot. Be careful about resurrecting old posts with vague responses.