🤔 Para Refletir : "Todos projetos não são unicamente meu, pois cada sugestão e critica, recursos e sugestões fazem me ver que ele leva um pedaço de cada pessoa nele" - riquecamarg0

Resolução do Xv Ace

Membro Membro
O quê? Você realmente ia ler aquilo até o final?
Postagens
327
Bravecoins
142
Atualmente,eu estou usando um script do(a) Yanfly que altera a resolução de tela do meu projeto,o problema é que quando a tela aumenta,o número mínimo de tiles aumenta também. Tem alguma forma de aumentar a resolução da tela sem precisar reajustar o tamanho dos mapas? Qual dessa resoluções você recomendam que eu use?:
q2Abs6C.png

(Essa é a resolução do RPG Maker MV,eu estava tendendo a escolher essa)
hJbaRYB.png

DF9X9Cx.png

2YII3V1.png
 
Até tem, mas a imagem vai esticar, ficar borrada e pixelada demais, fica bem feio na verdade, mas você quem sabe :) cheguei a usar esse uma vez: https://forums.rpgmakerweb.com/index.php?threads/fullscreen.14081/

Quando usei ele eu não gostei do resultado, mas testa aí, talvez funcione pra você :)

Eu particularmente só trabalho com resolução 1920x1080, mas aí vai de cada um :)
 
Hizashi_Brum comentou:
Até tem, mas a imagem vai esticar, ficar borrada e pixelada demais, fica bem feio na verdade, mas você quem sabe :) cheguei a usar esse uma vez: https://forums.rpgmakerweb.com/index.php?threads/fullscreen.14081/

Quando usei ele eu não gostei do resultado, mas testa aí, talvez funcione pra você :)

Eu particularmente só trabalho com resolução 1920x1080, mas aí vai de cada um :)
É um script interessante,mas como você disse deixa a imagem muito borrada,como eu uso o fullscreen,eu decidi usar a resolução 1280x416 e fazer uns ajustes no mapa.
 
É bom notar que aí há a escolha: Ou você mostra mais tiles, ou então terá que distorcer a imagem em resoluções maiores (que na verdade não aumentam a resolução na prática e sim esticam o conteúdo da tela).

O ideal para os padrões de hoje é uma resolução widescreen 16:9 ou 16:10, mas aí vai da sua preferência como usar.

Talvez tenha um bom jeito de unir as duas funcionalidades (mostrar mais tiles e esticar a tela) num padrão que te agrade, mas aí é só testando mesmo.
 
Eu prefiro esse aqui: ? Fullscreen por Gabriel "Gab!" Teles
Usa umas magias negras? Usa, mas é ótimo.

Segundo os meus testes e a própria descrição do script, ele não causa redimensionamento no mapa nem nada. O que pode acontecer é ficar a borda preta, mas isso não tem como evitar e não é muito problema na real, alguns jogos antigos têm isso (vide Pokémon pra GBA, em espaços internos).

Sobre qual resolução usar, eu não recomendaria prender o jogador a apenas uma opção de resolução, a menos que seja estritamente necessário para o Gameplay: pode ir atrás, em qualquer jogo mais recente, sempre dá pra ajustar a resolução do jogo pelo menu. No RM você faz isso facinho usando um evento e chamadas de Script, então não tem muita desculpa.

Caso não queira mesmo deixar a resolução ajustável por qualquer motivo que seja, recomendo 640x480, que dispensa o uso de scripts e é garantido de caber em qualquer tela que alguém vá usar no século XXI (dá pra deixar fullscreen com Alt+Enter mesmo).
 
No começo,o script ocorre normalmente,mas até certo ponto aparece esse erro:
p4rTEwy.png


Pelo que eu pesquisei,acontece esse erro quando há scripts não compatíveis no projeto,mas no mapa onde esse erro ocorro,eu não uso nenhum script específico.
 
Irineu comentou:
No começo,o script ocorre normalmente,mas até certo ponto aparece esse erro:
p4rTEwy.png


Pelo que eu pesquisei,acontece esse erro quando há scripts não compatíveis no projeto,mas no mapa onde esse erro ocorro,eu não uso nenhum script específico.

Provavelmente o jogo processou algum código de algum sistema seu nesse mapa para gerar esse erro, já testou outras vezes para ver se dá problema sempre no mesmo lugar e se esse erro aparece em outros locais também?

É um pouco chato descobrir qual sistema está conflitando com qual, porque nessa conta sempre acontece de você ter que decidir qual sistema vai ficar no jogo e qual terá que ser trocado e isso é díficil caso os dois sistemas sejam extremamente necessários.

Te sugiro tentar procurar mais sistemas de fullscreen, caso esse seja o que você precisava, você terá que descobrir qual dos seus sistemas está conflitando com esse e ver se vale a pena trocar um pelo outro.
 
Hizashi_Brum comentou:
Irineu comentou:
No começo,o script ocorre normalmente,mas até certo ponto aparece esse erro:
p4rTEwy.png


Pelo que eu pesquisei,acontece esse erro quando há scripts não compatíveis no projeto,mas no mapa onde esse erro ocorro,eu não uso nenhum script específico.

Provavelmente o jogo processou algum código de algum sistema seu nesse mapa para gerar esse erro, já testou outras vezes para ver se dá problema sempre no mesmo lugar e se esse erro aparece em outros locais também?

É um pouco chato descobrir qual sistema está conflitando com qual, porque nessa conta sempre acontece de você ter que decidir qual sistema vai ficar no jogo e qual terá que ser trocado e isso é díficil caso os dois sistemas sejam extremamente necessários.

Te sugiro tentar procurar mais sistemas de fullscreen, caso esse seja o que você precisava, você terá que descobrir qual dos seus sistemas está conflitando com esse e ver se vale a pena trocar um pelo outro.
Esse erro só acontece em um mapa específico,ironicamente esse mapa não tem nenhum sistema ligada à scripts... Eu testei em outros mapas e o erro não ocorreu. Acho que o script que não é compatível com esse é o Yanfly Ace Core,já que ele também mexe com a resolução da tela. Na minha visão,eu acho melhor deixar as coisas como está,porque todos os scripts que eu uso até agora são importantes pro projeto.
 
O script do Gab! utiliza um snippet de autor desconhecido que ninguem entende 100% seu funcionamento.
Esse código não é saudavel para o projeto, com certa resolução ela trás lag para o projeto.
O Valentine no desenvolvimento do VXA-OS estava passando pelo mesmo problema com a resolução (sou um colaborador do desenvolvimento, então estou ciente dessas paradas), então esses dias alguem postou na CRM uma alternativa bem boa e legal para isso.
https://centrorpg.com/index.php?topic=20465.0
O nome é RGDirect, eles trocam o executavel do VXA por um executavel com API gráfica DirectX, ela deixa mais rapido, pode trocar res sem perda de FPS ou lag.
Ela ta em desenvolvimento então pode haver alguns bugs.
Sobre o stack level too deep, se não me engano também ocorre quando há vazamento de memoria, mas não posso afirmar isso com precisão.
 
LeonM² comentou:
O script do Gab! utiliza um snippet de autor desconhecido que ninguem entende 100% seu funcionamento.

Discordo:
O código absurdo lá é só um hack (em um bom sentido) na memória relativa à DLL do RGSS. Ele usa a biblioteca DL (link) do Ruby pra carregar a DLL na memória e alterar o valor de alguns ponteiros.

Se você olhar com atenção, ele só substitui alguns endereços de memória pra usarem o valor desejado para a largura e altura da janela ao invés do padrão: esses endereços (quase com certeza) correspondem a comandos de PUSH pra stack ou equivalente no assembly, que depois vai ser usar em alguma chamada de função do Windows que controla as dimensões da janela. Quanto a como o cara descobriu esses endereços, é até que bem simples de fazer tendo um disassembly da DLL (mas não façam disassembly das coisas, é meio que ilegal em alguns casos :v), apesar de ser um trabalho meio braçal.

A única parte que foge um pouco disso é essa aqui:
Código:
mod.(0x195F, "\x90" * 5)
Não é difícil de entender também: o código \x90, em assembly corresponde à instrução "NOP": No OPeration (vide referência), algo com um "não faça nada", então dá pra deduzir que esse comando aí serve pra evitar que alguma operação seja feita. Fazendo um chute educado: provavelmente evita uma verificação de limites que a DLL tem pra impedir o usuário de redimensionar a janela para além de 640x480.

Tá aí, pra quem não entendia o que esse snippet fazia, é isso. E não, não tem chance de ele estar colocando algum vírus no seu computador, ainda mais usando só NOP e o tamanho da janela, rsrs.

LeonM² comentou:
Esse código não é saudavel para o projeto, com certa resolução ela trás lag para o projeto.

Eu particularmente nunca tive que lidar com lag usando esse script, mesmo com resoluções bem altas. Pode ser porque meus jogos não envolviam mapas do RPG Maker, pode ser que o problema maior seja na classe Tilemap ou sei lá. De certa forma, qualquer script que aumente sua resolução de verdade vai gerar lag, porque tem mais coisas pra serem desenhadas na tela.

Quanto ao RGDirect, eu recomendaria evitar usá-lo até que esteja realmente numa versão estável. Primeiro que é possível que a versão do DirectX que ele usa seja incompatível com qualquer máquina mais antiga, e depois que o seu uso ainda não é tão comum, então encontrar suporte pra problemas com ele vai ser mais difícil. Mas sim, uma vez que esteja funcionando nos trinques, não tem porque usar o player tradicional do RPG Maker ou qualquer script como o do Yanfly ou do Gab: use o RGDirect.



Irineu comentou:
No começo,o script ocorre normalmente,mas até certo ponto aparece esse erro:
p4rTEwy.png


Pelo que eu pesquisei,acontece esse erro quando há scripts não compatíveis no projeto,mas no mapa onde esse erro ocorro,eu não uso nenhum script específico.

Ruby-Doc: Stack level too deep

Basicamente, é um erro que acontece quando uma função chama ela mesma, aí a pilha (stack) de chamadas cresce demais e o Ruby morre.

Acho difícil o erro ser com esse script se ele está funcionando a princípio, mas vale a pena tentar colocar o Yanfly Ace Core abaixo dele na lista de scripts. Quem sabe né.

Pra todo caso, minha resposta à questão do tópico em si se mantém: a resolução deveria ou ser ajustável ou caber na tela de qualquer um, a menos que o Gameplay exija o contrário.
 
Brandt comentou:
LeonM² comentou:
O script do Gab! utiliza um snippet de autor desconhecido que ninguem entende 100% seu funcionamento.

Discordo:
O código absurdo lá é só um hack (em um bom sentido) na memória relativa à DLL do RGSS. Ele usa a biblioteca DL (link) do Ruby pra carregar a DLL na memória e alterar o valor de alguns ponteiros.

Se você olhar com atenção, ele só substitui alguns endereços de memória pra usarem o valor desejado para a largura e altura da janela ao invés do padrão: esses endereços (quase com certeza) correspondem a comandos de PUSH pra stack ou equivalente no assembly, que depois vai ser usar em alguma chamada de função do Windows que controla as dimensões da janela. Quanto a como o cara descobriu esses endereços, é até que bem simples de fazer tendo um disassembly da DLL (mas não façam disassembly das coisas, é meio que ilegal em alguns casos :v), apesar de ser um trabalho meio braçal.

A única parte que foge um pouco disso é essa aqui:
Código:
mod.(0x195F, "\x90" * 5)
Não é difícil de entender também: o código \x90, em assembly corresponde à instrução "NOP": No OPeration (vide referência), algo com um "não faça nada", então dá pra deduzir que esse comando aí serve pra evitar que alguma operação seja feita. Fazendo um chute educado: provavelmente evita uma verificação de limites que a DLL tem pra impedir o usuário de redimensionar a janela para além de 640x480.

Tá aí, pra quem não entendia o que esse snippet fazia, é isso. E não, não tem chance de ele estar colocando algum vírus no seu computador, ainda mais usando só NOP e o tamanho da janela, rsrs.

LeonM² comentou:
Esse código não é saudavel para o projeto, com certa resolução ela trás lag para o projeto.

Eu particularmente nunca tive que lidar com lag usando esse script, mesmo com resoluções bem altas. Pode ser porque meus jogos não envolviam mapas do RPG Maker, pode ser que o problema maior seja na classe Tilemap ou sei lá. De certa forma, qualquer script que aumente sua resolução de verdade vai gerar lag, porque tem mais coisas pra serem desenhadas na tela.
Essa parte, de alterar memória, eu já sabia, mesmo assim obrigado pela explicação, ela foi bem especifica nas partes que eu não entendia, o que me refiro é a ninguém entender 100% o funcionamento é o que cada parte altera na memória.
Pelo comentário incompleto que fiz, me desculpem, velho hábito de não explicar coisas.

E esse método de alterar a memoria até onde me lembro do que falavam no fórum do RPG Maker, Archeia se bem me lembro, é ilegal, logo esses scripts baseados nesse snippet não seriam bem vistos se usados, posso estar enganado, faz um tempo que li sobre isso.

O maior problema realmente é na Tilemap, eu testei num projeto meu que não usa, e não ocorreu lag, mas quando tentamos usar no VXA-OS, o maior FPS que conseguimos manter nos testes foi 55 fps, depois de grandes alterações.
Fora que, se me lembro direito dos testes, certas resoluções causavam problema com o fullscreen original do RM.
E por causa do tilemap havia bugs, a resolução teria que ser múltiplo de 32 pra não gerar problemas, 800x600 tinha bug, mas 800x608 não tinha.



Brandt comentou:
Quanto ao RGDirect, eu recomendaria evitar usá-lo até que esteja realmente numa versão estável. Primeiro que é possível que a versão do DirectX que ele usa seja incompatível com qualquer máquina mais antiga, e depois que o seu uso ainda não é tão comum, então encontrar suporte pra problemas com ele vai ser mais difícil. Mas sim, uma vez que esteja funcionando nos trinques, não tem porque usar o player tradicional do RPG Maker ou qualquer script como o do Yanfly ou do Gab: use o RGDirect.
A versão usada informada no site original informa sobre usarem DirectX9, então não creio que haverá grandes problemas com máquinas antigas. Pelo contrário, até acredito que seja melhor.
Sobre o suporte, realmente é um ponto negativo pelo fato de ser um projeto recente.
Mas mesmo assim na sua versão atual esta funcionando bem, até onde eu testei não tive nenhum problema.
Só o fato de algumas coisas estarem incompletas, que é a alteração de Viewport dentro do jogo, uma vez que altere o tamanho da tela, tem que reiniciar o Viewport de alguma forma, que não é simples.
E novamente alguns erros envolvendo Tilemap.
Alguns bugs envolvendo WindowSkin e Fontes.
Em vista dos erros e da falta de suporte eu também não recomendaria, mas é sempre bom lembrar que tem a alternativa.
Fora que quanto mais pessoas tentarem usar, mais bugs podem ser descobertos, reportando eles facilita para os desenvolvedores fazerem correções.
Tal como acontece com scripts, nada é perfeito de inicio.

Se eu falei alguma besteira grande, já me desculpo por agora mesmo. Em programação sou autodidata, então tenho muitas coisas para aprender ainda. Principalmente sobre coisas mais técnicas.

Sobre o tópico, minha resposta é a mesma que o Brandt:
"A resolução deveria ou ser ajustável ou caber na tela de qualquer um, a menos que o Gameplay exija o contrário."
 
Voltar
Topo