Uso de linguagens de Script

[msamsoniuk]

A parada do assembly foi brincadeira... Foi se o tempo do Atari aonde o processador tinha que processar o jogo somente durante o retorno do traço do CRT.

daqui uns anos vao perguntar o que eh CRT... e daih vc vai responder "ora! eh tubo de raios catodicos em ingles!" e as pessoas vao rir... ou chorar! huahuahua :v

[mastk]

A parada do assembly foi brincadeira... Foi se o tempo do Atari aonde o processador tinha que processar o jogo somente durante o retorno do traço do CRT.

O Quake 3, por exemplo, teve varias parte de sua ENGINE em ASM, o que chega a ser engracado, ja que tinha que se ter um sistema potente de toda a maneira para rodar ele.

[KrafT]

A parada do assembly foi brincadeira... Foi se o tempo do Atari aonde o processador tinha que processar o jogo somente durante o retorno do traço do CRT.

O Quake 3, por exemplo, teve varias parte de sua ENGINE em ASM, o que chega a ser engracado, ja que tinha que se ter um sistema potente de toda a maneira para rodar ele.

Chegasse a baixar o fonte dele?

Lembro que quando a ID Software liberou o fonte do DOOM, achei que ia fazer altas alterações no jogo e tal... Não entendi bulufas do código e conclui que não sei programar.

Anos depois quando liberaram o fonte do Rage, já sabia que além de não entender o código eu não teria poder computacional para compilar as texturas do jogo. Nem pensei em baixar...

[vtrx]

O Quake 3, por exemplo, teve varias parte de sua ENGINE em ASM, o que chega a ser engracado, ja que tinha que se ter um sistema potente de toda a maneira para rodar ele.

Provavelmente culpa do OpenGL ou DirectX da época.
Vamos ver se o DirectX 12 vai realmente usar todos os núcleos do processador...

[polesapart]

Então... Tava lendo que muito aplicativos e jogos pesados, se não todos, tem seu core programado numa linguagem decente tipo C++ e depois o resto é feito com scripts...

Como programação nesse nível não é coisa do meu dia a dia, fico curioso. Por exemplo, houve um tempo que a linguagem de script do Autocad era o Autolisp e dava para fazer coisas legais nele, mas como a própria suite do Autocad pode fazer uso do Autolisp?

Vejo que tem jogos que usam LUA, ou suas próprias linguagens de script. É evidente que tem vantagens nisso, se não não seria feito, mas minha mente de programador assembly tende à pensar que em vez de criar a linguagem e seu interpretador, tudo poderia estar no código do programa "principal".

Quanto ao caso dos jogos, imagine o seguinte script em pseudo-código que recebe um evento em um jogo:

EventoDeTiro(Player atirador, Coord viewpoint) {

Objects affected = CalculaColisao(atirador, viewpoint);
for (i : affected) {
NotificaAlvejado(i, CalculaImpacto(viewpoint, i));
}
}

Com fragmentos simples de código como este dá pra fazer toda a lógica de um jogo. A questão neste caso é bem simples: fazer esta lógica em uma linguagem de nivel mais baixo requer escrever mais código. As vezes quem faz isso é um artista gráfico, usando por exemplo, Lua. E o básico de Lua, ele vai aprender a chamar métodos, talvez não precise nem fazer objetos compostos.

A *implementação* dos métodos chamados em uma linguagem de mais alto nível, por outro lado, pode requerer muito mais trabalho de cpu, supondo que o interpretador não consiga otimizar isso. Então estes métodos podem estar implementados em uma linguagem de baixo nível, ou alguma maluquice como mandar uma mensagem para um diversos nanoprogramas que rodam dentro do processador gráfico da unidade, que vão fazer um calculo monstruoso e devolver um "verdadeiro ou falso". Você não ia fazer isso no teu programa de qualquer forma, ia delegar: considerando que o cérebro começa a interpretar o delay percepivel a partir de mais ou menos 200ms, importa para o jogador se teu programa usa 100000 instruções a mais para delegar em uma rotina de alto nível, do que faria em uma de baixo otimizada à mão? faça as contas de quanto tempo leva 100000 instruções numa cpu de 2ghz, versus quanto tempo o cara (que não sabe programar) levaria para aprender uma linguagem de baixo nível e se tornar suficientemente bom nela a ponto de começar a otimizar coisas?

A idéia de "scriptar" um programa tem sido usada desta forma há décadas já: permitir que rotinas abstratas possam ser escritas numa linguagem mais abstrata, e a implementação é feita - quando isto é gargalo - em linguagem de nível mais baixo.

Essa tua dúvida é uma das razões pelas quais programadores via de regra são péssimos para prever o desempenho de aplicações concretas: eles imaginam que determinados trechos de código precisam reagir de forma otimizada e passam semanas otimizando-os, depois quando resolvem colocar no profiler observam que 90% do tempo de cpu está sendo gasto no código que ele achou que era a coisa mais bonita que já tinha visto na vida

Um exemplo clássico: um programador PIC considera uma rotina pra copiar a memória que seja um loop apertado (um loop com poucas instruções) que copia byte a byte quase tão bonito quanto a mãe dele acha que ele (o programador) é; E não deixa de ser (o código), mas não tem nada menos eficiente numa cpu moderna com predição de branching do que um loop apertado, especialmente se ele for copiar byte a byte e o barramento para o cache for de 16 bytes

Otimização prematura é um vício terrível. Compiladores existem para te ajudar a focar na interface e deixar o ajuste fino da implementação para o que o resultado dos benchmarks informarem.

Tudo bem que temos maus exemplos do lado da "desotimização" total e do desperdício de recursos, mas exceção não deveria virar regra. Avisem a microsoft.

[tcpipchip]

Vi o Quack rodando no A5

[KrafT]

Ao que eu sei, os jogos desse tipo (tipo, 3d) usam calculo vetorial, em vez de coordenadas absolutas, para poder lidar melhor com a imprevisibilidade o tráfego TCP/IP. Lembrando que mesmo na máquina local, até aonde acompanhei, o jogador é um cliente que se comunica com o servidor do jogo via TCP, ficando à mercê das variáveis que afetam essa comunicação.

Como os estúdios mais puristas morreram ou foram incorporadas às gigantes que só trabalham para produzir blockbusters, larguei mão de acompanhar essas coisas de tecnologias de jogos.

E de de jogo grotesco em desempenho mas de ótima experiência de jogo, temos o Minecraft: Um lixo de software, um primor de jogo.

[KrafT]

Bah, Primor era um óleo de soja das antiga...

[Alexandro]

Mas pra entender como funciona engine feito em C com Script basta olhar o AGS Editor, muitos jogos 2D do Android/IOS tem sido feito nele.
www.adventuregamestudio.co.uk