RM MV - Console e performance

[Eliaquim]

Fala galera! Passando aqui pra tirar uma dúvida quanto ao uso do Console(F8 ou F12) no rm mv.
Eu gostaria de verificar nele, a performance do meu mapa quando faço um playtest. Por exemplo, o que ele tá executando, qual maneira deixa ele mais carregado etc.
Eu vejo algumas coisas na seguinte tela dele:

Spoiler

[close]

Nessa por exemplo tem um evento que está marcado como "Stepping" então vejo que o jogo está sempre pedindo a animação dele. Ok.

Nesse mesmo mapa eu tenho um evento que faz com que quando o player pise em uma determinada região, e essa região revele determinados tilesets. Eu consigo fazer isso de diversas formas, mas gostaria de saber qual dessas formas seria a mais leve para a engine.

1 - Script call + evento paralelo - Fica um evento paralelo rodando no mapa, na primeira vez que o player pisar na região, esse evento vai executar o comando de revelar os tilesets e depois vai ser apagado. Entretanto, terão várias regiões no mapa, então terão vários eventos desse no mapa...

Spoiler

[close]

2 - Yep Region Events + evento comum - Para cada nº de região, existirá um evento comum que, ao player pisar na região, o plugin ativa esse evento comum. Entretanto, esse aqui, toda vez que o player pisar na região (e não só a primeira vez), o evento comum vai ser executado.
http://yanfly.moe/2015/10/19/yep-17-region-events/

Spoiler

[close]

3 - Yep Advanced Switches e variables + evento no mapa ou evento comum - Vai ter uma switch nomeada "eval: $gamePlayer.regionId(255)" - Na primeira vez que o player pisar na região 255, essa switch ficará ON e executará um evento comum, ou um evento no mapa iguais os que estão acima.
http://yanfly.moe/2018/01/19/yep-162-advanced-switches-and-variables-rpg-maker-mv/

Me digam se isso é irrelevante. Porque eu acho que entrei em uma paranoia pra saber o que custa mais da engine e desconfio que talvez não faça muita diferença as questões acima... uahhuahuauhauhauhuahuhauhahu!
Tipo, se toda vez que o player pisar numa região um evento comum vai colocar uma switch X ON.
Essa switch já estando ON, conforme o player continua a pisar na região, o evento comum continua executando o comando de ativar a switch. Isso é algo com que devo me preocupar?

[Sotelie]

http://wiki.c2.com/?PrematureOptimization

Sugiro não ficar paranóico com performance a menos que realmente haja necessidade.
É complicado fazer Profiling numa linguagem dinâmica como Javascript (o console não é um Profiler nem um Debugger), qualquer resultado de benchmark irá variar de máquina para máquina (um pc da xuxa pode rodar abaixo de 20fps e causar problemas, enquanto um pc "gamer" pode rodar acima de 120fps e causar outros problemas).

Se realmente estiver preocupado, o maior problema se encontra no fato do jogo não ser nativo.
O que isso quer dizer? Um jogo do MV não é executado de maneira nativa pra máquina, ele é emulado em um browser. Mas não é qualquer browser, é um browser baseado em Chromium. O mesmo sistema que faz o Chrome funcionar. Então pra cada projeto do MV, você está rodando um "chrome" e esse chrome está emulando seu jogo.

Um jogo nativo é compilado diretamente para uma linguagem intermediária (C# -> CIL) que será compilada para Assembler durante a execução, ou é compilado diretamente para Assembler (C/C++ -> ASM), e de Assembler para binário. Só isso pode lhe dizer que se preocupar com performance no MV é uma tentativa que não recomendo.

Lembrando que em Javascript você não possui controle algum sobre a memória (o que é crucial para jogos), preocupe-se em fazer o jogo funcionar, já é o suficiente.

[Geraldo de Rívia]

Eu também me questiono qual o melhor meio para tal tarefa às vezes. Já reescrevi muitos códigos buscando fazer o que eu precisava com o mínimo necessário.

Quanto menos um processo rodar desnecessariamente, melhor. Por exemplo, na sua primeira opção, em que usará processos paralelos, talvez nos cinco minutos que o jogador ficar no mapa, apenas em um frame esse processo será necessário. Ou seja, em todo o restante do tempo esse processo estará comendo processamento em vão.

No lado de usar códigos de outrem que não foram feitos especificamente para o objetivo que tu quer, o problema é que muitas vezes eles executam mais funções além das que tu está usando. O caso o Yanfly é um bem explicito para isso, pois os códigos dele, em sua maioria, possuem muitas funções.

Então eu acho que as coisas devem ser pesadas. No caso de três, cinco eventos paralelos, acho viável utilizá-los. Mais que isso talvez o supérfluo do código do Yanfly tenha menos impacto no desempenho. Mas ressalto que, por mais funções que um código tenha, dificilmente ele vai "pesar" mais em um mapa do que um único processo paralelo, porém, eu prefiro utilizar o quanto possível de eventos a fim de evitar um plugin a mais no jogo.

Antes de tudo o bom-senso é o melhor parâmetro. Se achar que o mapa tá ficando cheio de eventos demais, ficar com medo de gerar algum problema, divida-o em dois, três. Dá pra fazer sempre o que queremos, só talvez não da forma como queremos.

[Eliaquim]

http://wiki.c2.com/?PrematureOptimization

Sugiro não ficar paranóico com performance a menos que realmente haja necessidade.
É complicado fazer Profiling numa linguagem dinâmica como Javascript (o console não é um Profiler nem um Debugger), qualquer resultado de benchmark irá variar de máquina para máquina (um pc da xuxa pode rodar abaixo de 20fps e causar problemas, enquanto um pc "gamer" pode rodar acima de 120fps e causar outros problemas).

Se realmente estiver preocupado, o maior problema se encontra no fato do jogo não ser nativo.
O que isso quer dizer? Um jogo do MV não é executado de maneira nativa pra máquina, ele é emulado em um browser. Mas não é qualquer browser, é um browser baseado em Chromium. O mesmo sistema que faz o Chrome funcionar. Então pra cada projeto do MV, você está rodando um "chrome" e esse chrome está emulando seu jogo.

Um jogo nativo é compilado diretamente para uma linguagem intermediária (C# -> CIL) que será compilada para Assembler durante a execução, ou é compilado diretamente para Assembler (C/C++ -> ASM), e de Assembler para binário. Só isso pode lhe dizer que se preocupar com performance no MV é uma tentativa que não recomendo.

Lembrando que em Javascript você não possui controle algum sobre a memória (o que é crucial para jogos), preocupe-se em fazer o jogo funcionar, já é o suficiente.

Saquei... pow muito obrigado! Mais coisas pra eu estudar... auhauhauhuahuah
Esse link que você mandou esclareceu muitas coisas aqui na cabeça. Vlw msm!

Eu também me questiono qual o melhor meio para tal tarefa às vezes. Já reescrevi muitos códigos buscando fazer o que eu precisava com o mínimo necessário.

Quanto menos um processo rodar desnecessariamente, melhor. Por exemplo, na sua primeira opção, em que usará processos paralelos, talvez nos cinco minutos que o jogador ficar no mapa, apenas em um frame esse processo será necessário. Ou seja, em todo o restante do tempo esse processo estará comendo processamento em vão.

No lado de usar códigos de outrem que não foram feitos especificamente para o objetivo que tu quer, o problema é que muitas vezes eles executam mais funções além das que tu está usando. O caso o Yanfly é um bem explicito para isso, pois os códigos dele, em sua maioria, possuem muitas funções.

Então eu acho que as coisas devem ser pesadas. No caso de três, cinco eventos paralelos, acho viável utilizá-los. Mais que isso talvez o supérfluo do código do Yanfly tenha menos impacto no desempenho. Mas ressalto que, por mais funções que um código tenha, dificilmente ele vai "pesar" mais em um mapa do que um único processo paralelo, porém, eu prefiro utilizar o quanto possível de eventos a fim de evitar um plugin a mais no jogo.

Antes de tudo o bom-senso é o melhor parâmetro. Se achar que o mapa tá ficando cheio de eventos demais, ficar com medo de gerar algum problema, divida-o em dois, três. Dá pra fazer sempre o que queremos, só talvez não da forma como queremos.

Caramba. Realmente um único processo paralelo, dependendo do que tem nele, pode pesar mais do que um plugin em um mapa? Po.. mas sendo assim, qual a vantagem de não usar plugin? Digo,  eu procuro usar poucos, porque com muitos no projeto tenho a sensação de que ele está poluído sei lá. Mas po os eventos paralelos são tão barra pesada assim então? uahahuahuauhauhuauha

[Geraldo de Rívia]

[...] Caramba. Realmente um único processo paralelo, dependendo do que tem nele, pode pesar mais do que um plugin em um mapa? Po.. mas sendo assim, qual a vantagem de não usar plugin? Digo,  eu procuro usar poucos, porque com muitos no projeto tenho a sensação de que ele está poluído sei lá. Mas po os eventos paralelos são tão barra pesada assim então? uahahuahuauhauhuauha

É que é o seguinte: no mapa há um "interpretador" que é responsável por ler todos os eventos no mapa e executar as funções dos que estão hábeis a fazer alguma coisa. Ele é um só e lerá cada evento de uma vez, logo, quanto mais comandos houver na programação de um evento, mais tempo ele vai demorar a ler e pular para o próximo. Quanto mais eventos ele tiver que ler, mais vai demorar para ele ler todos, e quanto mais ele demorar, maior será o tempo do quadro/frame. Quanto maior o tempo do quadro, menos quadros teu jogo terá por segundo.

Processos paralelos, uma vez possíveis de serem executados, serão lidos continuamente, então esses eventos impactarão no processo descrito acima. Porém se bem feitos, serão lidos rapidamente e não terão impacto perceptível. Pra um processo paralelo descer um frame da média de quadros ou: ele tem que ser muito extenso, ou; muito mal feito.

Na verdade se tu souber fazer a mesma coisa por código e por eventos, não há vantagem em fazê-la por eventos. Os eventos são somente uma interface amigável para o desenvolvedor programar sistemas de interação do jogador. Como não é todo mundo que sabe escrever códigos, é fundamental que um programa amador tenha esse meio mais fácil e intuitivo.

Porém, todo evento tem que ser convertido em código para ser lido, portanto os comandos por eventos nada mais são do que um intermediário a mais entre o desenvolvedor e o código. Escrevendo diretamente o código tu tá excluindo esse intermediário, logo, excluindo também coisas a mais a se processar.

Agora plugins também têm pontos negativos. Podem executar funções que tu não precisa, às vezes muito mais do que um processo paralelo feito por você mesmo somente com o que precisará. Podem dar incompatibilidade, causando disfunções no jogo. Às vezes tu nem usará o plugin sempre, só uma vez ou outra, daí sou muito mais a favor de fazer por comandos por eventos.

[Eliaquim]

É que é o seguinte: no mapa há um "interpretador" que é responsável por ler todos os eventos no mapa e executar as funções dos que estão hábeis a fazer alguma coisa. Ele é um só e lerá cada evento de uma vez, logo, quanto mais comandos houver na programação de um evento, mais tempo ele vai demorar a ler e pular para o próximo. Quanto mais eventos ele tiver que ler, mais vai demorar para ele ler todos, e quanto mais ele demorar, maior será o tempo do quadro/frame. Quanto maior o tempo do quadro, menos quadros teu jogo terá por segundo.

Processos paralelos, uma vez possíveis de serem executados, serão lidos continuamente, então esses eventos impactarão no processo descrito acima. Porém se bem feitos, serão lidos rapidamente e não terão impacto perceptível. Pra um processo paralelo descer um frame da média de quadros ou: ele tem que ser muito extenso, ou; muito mal feito.

Na verdade se tu souber fazer a mesma coisa por código e por eventos, não há vantagem em fazê-la por eventos. Os eventos são somente uma interface amigável para o desenvolvedor programar sistemas de interação do jogador. Como não é todo mundo que sabe escrever códigos, é fundamental que um programa amador tenha esse meio mais fácil e intuitivo.

Porém, todo evento tem que ser convertido em código para ser lido, portanto os comandos por eventos nada mais são do que um intermediário a mais entre o desenvolvedor e o código. Escrevendo diretamente o código tu tá excluindo esse intermediário, logo, excluindo também coisas a mais a se processar.

Agora plugins também têm pontos negativos. Podem executar funções que tu não precisa, às vezes muito mais do que um processo paralelo feito por você mesmo somente com o que precisará. Podem dar incompatibilidade, causando disfunções no jogo. Às vezes tu nem usará o plugin sempre, só uma vez ou outra, daí sou muito mais a favor de fazer por comandos por eventos.

HAMMMMM.... saqueii...
Então é questão de observar o código do plugin e o evento mesmo né.

"Porém, todo evento tem que ser convertido em código para ser lido"
Ainda que eu jogue uma script call no evento, ainda assim a engine fará esse processo de conversão? Tipo, usar uma script call pra determinar uma variável. Ou usar o comando de evento para determinar uma variável. Vai dar no mesmo ou não?

[Geraldo de Rívia]

No caso do Chamar Script tu envia um texto ao código e ele só tem que interpretar ele, imagino que um trabalho bem menor, mas desconheço o quão fácil é para o Javascript separar esse texto nas porções certas.

O restante dos comandos chamam funções em código, mas nem sempre é uma só. Por exemplo, o comando por evento chama a função A. Chamar diretamente a função A ao invés de usar o comando por evento pode não resolver muito, pois a função A chama a B, C e D. Assim você estaria cortando uma única linha de código. Isso representaria economia de processo? Sim, mas em uma quantidade que não faz a menor diferença. Daí: valeria a pena ter uma programação em um evento feita somente por Chamar Script, toda desorganizada, ao invés de uma organizadinha com comandos por eventos?

Eu acho que utilizar código é viável em situações em que tu pode usar somente uma linha de código, ou poucas, ao invés de uma programação grande por comandos por eventos. Se for pra fazer do mesmo jeito que o evento faz, não vejo vantagem.

[Eliaquim]

No caso do Chamar Script tu envia um texto ao código e ele só tem que interpretar ele, imagino que um trabalho bem menor, mas desconheço o quão fácil é para o Javascript separar esse texto nas porções certas.

O restante dos comandos chamam funções em código, mas nem sempre é uma só. Por exemplo, o comando por evento chama a função A. Chamar diretamente a função A ao invés de usar o comando por evento pode não resolver muito, pois a função A chama a B, C e D. Assim você estaria cortando uma única linha de código. Isso representaria economia de processo? Sim, mas em uma quantidade que não faz a menor diferença. Daí: valeria a pena ter uma programação em um evento feita somente por Chamar Script, toda desorganizada, ao invés de uma organizadinha com comandos por eventos?

Eu acho que utilizar código é viável em situações em que tu pode usar somente uma linha de código, ou poucas, ao invés de uma programação grande por comandos por eventos. Se for pra fazer do mesmo jeito que o evento faz, não vejo vantagem.

Beleza! Então com essa eu fico lá com o link que o Sotelie postou e vou parar de me preocupar tanto xD
Obrigado galera!!