BrDoom Fórum

Não seria a hora de ir para o C++?

DU0 escreveu:Não seria a hora de ir para o C++?

xD

A ID só foi pro C++ no Quake III, se for considerar que eu acabei de passar o Wolf 3D, então acho que ainda é muito cedo.
Ademais eu ainda não tive Programação Orientada a Objetos (terei só ano que vem) então eu pretendo ir com calma até lá...

Orientação a objeto é barbada. Anyway, eles usavam C, não Allegro ou whatever, bixo :~

Isso ae não é linguagem pra fazer jogo, é linguagem pra fazer programa de controle de estoque de mini-mercado -.-

Fiquei extremamente impressionado com o resultado, e na velocidade que você chegou nele, parabéns.

DU0 escreveu:Orientação a objeto é barbada. Anyway, eles usavam C, não Allegro ou whatever, bixo :~

Isso ae não é linguagem pra fazer jogo, é linguagem pra fazer programa de controle de estoque de mini-mercado -.-

Cara, pra ser sincero... Se eu tivesse prática nisso, eu trabalharia em cima dessa engine fazendo bitwise operations e tentaria fazê-la no mais baixo nível possível (próximo de assembly), assim eu poderia ganhar muita performace nessas contas do ray-casting (contas essas que tão "comendo" bastante o desempenho do programa)...

Essas línguagens como C++ e Java são muito boas, mas se realmente você quer algo eficiente e leve, tem que fazer em baixo nível (e até C ainda é bem alto nível, só não é tanto pois é possível operar bits no C)...

Wa59 escreveu:Fiquei extremamente impressionado com o resultado, e na velocidade que você chegou nele, parabéns.

Hehe, valew. To botando bastante empenho nele, mas mesmo assim ainda acho que ele tá uma porcaria se comparado a alguns que eu encontrei na internet... Como este ai: http://www.shinelife.co.uk/java-maze/demo/ (requer Java).

Off:

Curiosidades
1 - A Build Engine do Duke usa um ray-casting semelhante ao do Wolf 3D porém usa lines e setores (como no Doom).
2 - A engine do Doom não é semelhante a Build por causa da árvore binária que é feita no Doom para determinar as paredes vistas.

Wa59 escreveu:Fiquei extremamente impressionado com o resultado, e na velocidade que você chegou nele, parabéns.

[2]
Agora sim eu me empolguei!

Logan MTM escreveu:

Wa59 escreveu:Fiquei extremamente impressionado com o resultado, e na velocidade que você chegou nele, parabéns.

[2]
Agora sim eu me empolguei!

xD

Quando vocês verem quantos frames por segundo essa engine tá fazendo, acho que vocês não estarão mais tão empolgados... Mas eu prometo tentar dar uma otimizada ai no jogo.

Versão 0.0.4.C

Changelog Esta versão é identica a 0.0.4 mas tem um contador de FPS, por favor postem quantos frames vocês estão fazendo, em qual resolução, e qual o processador (não placa de vídeo) de vocês, esse feedback é importante pra mim...

Meus resultados Download
NeoCore v.0.0.4.C (~390kb)

Fabio914 escreveu:

Código: Selecionar todos

Frames por Segundo (média) em um AMD Athlon 64 X2 com GeForce 8600 GT:

320x240 + Baixa qualidade: ~18 fps
320x240 + Alta qualidade: ~25 fps
640x480 + Baixa qualidade: ~17 fps
640x480 + Alta qualidade: ~15 fps
1024x768 + Baixa qualidade: ~11 fps
1024x768 + Alta qualidade: ~5 fps
1280x1024 + Baixa qualidade: ~12 fps
1280x1024 + Alta qualidade: ~3 fps

oO

Pelo que eu saiba o normal seria rodar em 60 fps, mas mesmo no low fica 18..

Com tudo no máximo e ativado e etc, fica numa média de 6fps LOL
Mas acho que se tirar o céu melhora. Em corredores fechados a média ficou em 10.

Uma coisa que provávalmente melhoraria seria fazer o efeito "Playstation". Tipo, fazer o computador renderizar o mapa apenas alguns passos à frente do jogador, e não ele inteiro de uma só vez :3

DU0 escreveu:Com tudo no máximo e ativado e etc, fica numa média de 6fps LOL
Mas acho que se tirar o céu melhora. Em corredores fechados a média ficou em 10.

Na verdade o céu é uma imagem fixa, e ela não sofre deformação para o 3D... O que faz os FPS subirem quando se está nos corredores é "ver" menos partes do teto e do chão, ou, dependendo da sua proximidade com a parede, ver apenas a parede, assim o programa efetua muito menos cálculos e os FPS sobem...

DU0 escreveu: Uma coisa que provávalmente melhoraria seria fazer o efeito "Playstation". Tipo, fazer o computador renderizar o mapa apenas alguns passos à frente do jogador, e não ele inteiro de uma só vez :3

Bom, o que é calculado e renderizado na tela é apenas o que está sendo "visto" pelo jogador, o programa não processa o mapa todo de uma vez, ele processa apenas onde os "raios" atingem. Fazer o jogador enxergar até determinada distância poderia diminuir o numero de contas, mas isso não seria muito efetivo pois eu ainda teria muitos pixels para calcular...

O que deve ser feito é otimizar as contas, e diminuir o numero de loops sobre loops... Só para você ter uma idéia o código tem 4 loops...

Loop do jogo
___Loop do rendering
_____Loop do ceiling
_____Loop do floor
___Fim do loop do rendering
Fim do loop do jogo

Ou seja, para cada frame, eu faço RESX contas* para as paredes (onde RESX é a resolução X da tela) no loop do rendering.
Para cada coluna de parede (1/RESX parte de parede) eu faço de 0 a RESY/2 (onde RESY é a resolução Y da tela) contas* para o céu.
Para cada coluna de parede (1/RESX parte de parede) eu também faço de 0 a RESY/2 contas* para o chão.

Em suma, numa resolução de 1280x1024 eu posso acabar fazendo a CPU resolver até 7.870.720 contas aproximadamente para montar uma tela de paredes relativamente próximas ao jogador (para essa aproximação eu levei em conta que a parede está logo em frente ao jogador, então é como se o programa fizesse 5 contas para cada coluna, e 3 contas para céu e chão para cada parte de coluna)... Para paredes longe esse valor pode estourar para até 40 milhões de contas, ou mais (dependendo do tamanho do mapa e, principalmente, do tamanho da área do mapa observada pelo jogador).

Resumindo... no modo máximo, são feitas de 7 milhões até 40 milhões de contas por frame. E como muitas dessas contas incluem multiplicações e divisões em valores reais (float), cada conta pode custar até uns 10 clocks da CPU (não sei ao certo quantos clocks seriam, estou estimando) , ou seja pra rodar a 60 fps eu teria que ter uma CPU de 24 gHz (isso sem levar em conta os clocks para acesso de memória e eventuais delays disso e do sistema operacional)...

*: quando eu digo contas, eu me refiro a um conjunto de contas por loop (que podem, no calculo da parede, variar dependendo da distância da parede ao jogador), e não a apenas uma conta por loop

Space Marine escreveu:

Fabio914 escreveu:

Código: Selecionar todos

Frames por Segundo (média) em um AMD Athlon 64 X2 com GeForce 8600 GT:

320x240 + Baixa qualidade: ~18 fps
320x240 + Alta qualidade: ~25 fps
640x480 + Baixa qualidade: ~17 fps
640x480 + Alta qualidade: ~15 fps
1024x768 + Baixa qualidade: ~11 fps
1024x768 + Alta qualidade: ~5 fps
1280x1024 + Baixa qualidade: ~12 fps
1280x1024 + Alta qualidade: ~3 fps

oO

Pelo que eu saiba o normal seria rodar em 60 fps, mas mesmo no low fica 18..

Rodando a 20~25 já está bom... Se sua CPU for boa, rode a 320x200 na Alta qualidade que você verá que a performace é boa.