Já viram qual a arte dessa semana?Exposição dos Artistas #8
7 Respostas 156 Visualizações
0 Membros e 1 Visitante estão vendo este tópico.
http://wiki.c2.com/?PrematureOptimizationSugiro 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.
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
É 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.
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.
