performance comparison with parallel process

[GMN]

Hi everyone and first of all sorry for my bad english. I have a generic question (hope this is the right section for this, im apologize it's my first topic here.. ) which is better for "ingame" performance, one heavy parallel process OR more lights parallel processes? 

 

[Andar]

I've moved this thread to Ace Support. Please be sure to post your threads in the correct forum next time. Thank you.


Tech-Support is for getting the editors to run.


As for your question - that depends a lot on the exact event code.


Generally a good designed parallel process handling a lot works with less lag than several processes handling single things.


But bunching different checks together can also create more lag if that bunching together is not done right.


Different parallel processes usually require different wait numbers for optimal work - combining them means that one wait number has to work for all.


On the other hand, the number of parallel processes create overhead so they should be limited as much as possible.


Best way is to combine processes that need similiar wait numbers, but not if they are too far away from the numbers - for example a trap on the map controlled by a parallel process needs a lot less waits, because otherwise the player might dash through, than a parallel process for checking equipment - since no player can change equipment fast, that check can easily work with a wait-30 or so.


Combining them would force the equip part to run at wait-3 or so, eliminating any gain from less game loop handling.

 

[bgillisp]

Neither. Usually many parallel processes aren't needed, if clever eventing is used. Maybe post what you are needing all the parallel processes for? Maybe we can come up with another approach that works just as well.

 

[GMN]

Understood, thanks

 

[Bex]

1 with all is better than many with few stuff + some additional on paralell only for short times if needed to keep things organized.


In most cases you never need 2 at the same time, or it can be solved with a2nd temporarly paralell.


Had a paralell process checking for around 200 Conditions without any impact.


3Lines of ugly Eventcode can cause severe Lag on the other Hand. For example:


Paralell Event which changes player graphic all the time, even if it changes it to the same one again and again, can bring Performance down to 40FPS


and or cause movement stutter.


What are you trying to build? Or on what are you experimenting?

 

[GMN]

1 with all is better than many with few stuff + some additional on paralell only for short times if needed to keep things organized.


In most cases you never need 2 at the same time, or it can be solved with a2nd temporarly paralell.


Had a paralell process checking for around 200 Conditions without any impact.


3Lines of ugly Eventcode can cause severe Lag on the other Hand. For example:


Paralell Event which changes player graphic all the time, even if it changes it to the same one again and again, can bring Performance down to 40FPS


and or cause movement stutter.


What are you trying to build? Or on what are you experimenting?

at the moment i have make a map for an action BS with 4 enemyes, player have hp  and mp bar from 0to100 and level up from 1 to99 (301picture in total with conditions to display them), enemyes have only hp bar fm 0to100,  4enemyes= 404pictures with conditional to display them only when they are close to hero on the map the bars are displayed, at the moment game seems to be working fine with no lag, but this parallel process have 700 conditional branchs, i don't know if is better split into more processes..

 

[Andar]

hp  and mp bar from 0to100 and level up from 1 to99 (301picture in total with conditions to display them)

How about using three pictures and pictute priority with picture position to display every possibile part of one bar?


The picture number determines which picture gets displayed on top of which other.


You use one picture for the empty bar at bottom.


Above that gets a colored bar for the current HP for example - a full red bar that is positioned to cover part of that bar to determine how many HP you still have.


The third picture is to cover that part of the red bar that lands outside of the black bar, because that is of course not shortened this way.


This could be the face of the actoir, or a command display or just an ornamental part of the HZD - just make sure that it is large enough to hide the red bar when it is positioned for low HP.


Additional advantage this way: you can increase the gauge when leveling by having the black bar positioned and partially hidden by the face as well.

 

[GMN]

How about using three pictures and pictute priority with picture position to display every possibile part of one bar?


The picture number determines which picture gets displayed on top of which other.


You use one picture for the empty bar at bottom.


Above that gets a colored bar for the current HP for example - a full red bar that is positioned to cover part of that bar to determine how many HP you still have.


The third picture is to cover that part of the red bar that lands outside of the black bar, because that is of course not shortened this way.


This could be the face of the actoir, or a command display or just an ornamental part of the HZD - just make sure that it is large enough to hide the red bar when it is positioned for low HP.


Additional advantage this way: you can increase the gauge when leveling by having the black bar positioned and partially hidden by the face as well.

maybe is better if i show a video  how BS work








this is the parallel process that show hp, mp, lvlup pictures..








always work fine, o don't want to revolution the event, just know if is better to split into more parallel processes for having best performance ^^

 

[Bex]

My English aint the best so i dont understand all but you could use an easier Solution than using 1Picture for every Possible HP Value.


You could calculate the Percentage of HP through current HP and Max HP and than Zoom the Enemy HP acordingly. (There is a short Script that allows you to Zoom Pictures thatway)


Or


You just use a Picture each for the numbers 0 to 9. And with those Pictures in Database you can show any Number you want on the Gamescreen and how often you want.


In rm2k3 people used that to build own Menus and Battle Systems and Huds because they had no Scripting acess.


Or


If it works just let it how it is, or do you have any kind of lag or stutter on the Map?

 

[GMN]

My English aint the best so i dont understand all but you could use an easier Solution than using 1Picture for every Possible HP Value.


You could calculate the Percentage of HP through current HP and Max HP and than Zoom the Enemy HP acordingly. (There is a short Script that allows you to Zoom Pictures thatway)


Or


You just use a Picture each for the numbers 0 to 9. And with those Pictures in Database you can show any Number you want on the Gamescreen and how often you want.


In rm2k3 people used that to build own Menus and Battle Systems and Huds because they had no Scripting acess.


Or


If it works just let it how it is, or do you have any kind of lag or stutter on the Map?

tx for suggestion, as you see in video no lag for the moment everithing seems to be fine..

 

[Bex]

For moving enemys i also recoment using Screen X Y insteed of Map X Y for Hit detection.


Because the Map coordinate is sometimes allready on the next maptile while the sprite is still halfway on the last maptile,


thatway the player thinks he got a hit but the game doesnt count it. With Screenvariables this unwanted Behavior gets fixed.


Not sure how you do it at the moment.

 

[GMN]

For moving enemys i also recoment using Screen X Y insteed of Map X Y for Hit detection.


Because the Map coordinate is sometimes allready on the next maptile while the sprite is still halfway on the last maptile,


thatway the player thinks he got a hit but the game doesnt count it. With Screenvariables this unwanted Behavior gets fixed.


Not sure how you do it at the moment.

you are a genius! no one had advised me to do it, I had never thought of doing it, but I had always noticed the problem you described and I had spoken to so many people .. now I'm changing ALL events to the collision with the screen coordinates, just I do not understand how they work , do not seem to go to the different sizes of 32 ...