Motor de Raycasting con Actives

¿No habría un subforo para ejemplos inútiles? ¡Podríamos inaugurarlo con éste!
En fin, esto es lo que pasa cuando me dejan con mucho café; un motor de raycasting hecho pura y exclusivamente con actives, de cero.
Lo empecé hace algunas horas... no creí que fuera a terminar hasta este punto para hoy XD


Este ejemplo no es más que una locura matutina... un motor de Raycasting a un estilo "pre-Wolfestein3D" utilizando pura y exclusivamente actives (Y *ahem* una buena dosis de trigonometría y cálculos matemáticos). No tiene mucho uso a la hora de hacer juegos ya que es muy ineficiente en comparación con otros métodos (La extensión Raycasting object por ejemplo, la cual yo supe explotar hace un buen tiempo XD...) y si se alcanzace suficiente eficiencia, de todas formas no se vé demasiado bonito salvo que se esté haciendo un juego estilo retro.
La definición es mala, (320x160 a columnas de 4 píxeles de ancho) pero lo suficiente como para que lo pueda mover una PC normal del mercado. Y si todo falla, se puede regular la definición de la imagen (Sep, es que se puede bajar todavía más la calidad)

El principio de todo este motor es que cada columna es en esencia un active, y cada una de estas columnas puede tener una textura (implementada usando las direcciones del active) y es reescalada en tiempo real (Eje y, el eje x se mantiene siempre igual) para simular la distancia de "la cámara" a la pared en cuestión.

Se controla con las flechas, o con WASD, tiene colisiones. Y se pueden usar las teclas (-) y (+) para cambiar el FOV y (/) y (*) para el Farclip.
Si les va muy lento pueden probar pulsando la tecla Fin para reducir la cantidad de columnas, o cambiando desde el MFA la variable global Definition de 4 a 8; pierde mucha definición pero le toma la mitad de tiempo renderizar la imagen. Y ni se les ocurra ponerlo en 1, que ni mi compu lo mueve eso
Ya que están diganme a qué velocidad les funciona en general; así me doy una idea de lo consumidor que es en serio

Puede que les salte el mensaje de la versión HWA, pero no le hagan caso, lo único en HWA es la transparencia de las paredes al alejarse del jugador...
y es meramente estético
Se puede emular también utilizando el modo de compatibilidad de semitransparencia (ink effect), pero esa se las debo a ustedes.

Sobra decir que no requiere ninguna extensión
Si necesitan que los compre con algo, tiene paredes texturizadas, incluso hay paredes animadas (Muy simples, pero animadas en fin xd).
Comentado hasta donde pude... la gran mayoría de lo que hay acá es casi matemático.

Entre todas las cosas que tiene, hay mucha matemática, funciones trigonométricas, loops anidados, corte de loops, funciones con módulo, funciones con potencia -1, y varias otras cosas derrochadoras de valiosos ciclos de cpu.

---

MFA : [Tienes que estar registrado y conectado para ver este vínculo]
EXE : [Tienes que estar registrado y conectado para ver este vínculo]

Todavía les debo el motor del doom, pero por ahora entreténganse con esto
Ya... ahora sí me fuí a dormir.

Hay que ver lo que te gustan las Matematicas

me quito el sombrero [Tienes que estar registrado y conectado para ver esa imagen]

A. Con el .exe:

- Variando el Farclip (1-10000)
- Variando FOV (0-360)

Siempre el mismo resultado:
Render: 16 ms
fps: 60

Salvo en los valores altos de Farclip y al principio de los pasillos largos:
Render: 25 ms (muy breve)
fps: mínimo 45 (muy breve también)

B. Con el .mfa:

- Con global value (Definition) = 1

Render: 90-100 ms
fps: 9-10

Interesante propuesta !
Un buen ejercicio es ver dónde y cómo conseguir mayor rendimiento. Con LUA quizás ? mmm

bueno, le veo una ventaja a este, en una imagen veo una muralla circular, si es así, entonces se parece mas al juego shadowcaster :p, buen uso de las matematicas

Gracias gente!

elpupas7 escribió:

Interesante propuesta !
Un buen ejercicio es ver dónde y cómo conseguir mayor rendimiento. Con LUA quizás ? mmm

Gracias por el test de rendimiento!
Variar el FOV no mejor ni empeora el rendimiento, solo cambia el campo de visión
Reducir el farclip (far) solo mejora el rendimiento cuando se está mirando a un espacio vacío (Hace que la vista decaiga más antes, evitando comprobar si hay algo "más allá de lo que se vé").

Los demás valores no se pueden cambiar en tiempo real, pero cuanto más grande es el Definition, menos columnas se dibujan en pantalla y más rápido es el motor.
Cabe aclarar que definition debe ser un divisor del ancho de la pantalla, sino el cálculo falla.

Con lua el cálculo de las funciones sería bastante más rápido (Hasta se podría optimizar muchísimo el código) pero está la desventaja de tener que detectar las colisiones con las paredes desde fuera (Lua no sabe de máscaras de colisión, aunque claro, podría usar funciones cruzadas para que el mismo código lua invoque una función que calcule si un punto está ocupado). Aparte si ya uso una extensión pierde la gracia de ser solo con actives... para ese entonces podría usar unas cuantas extensiones para acelerar el proceso

Por ejemplo, no sé, algún objeto que me facilite los cálculos de funciones, o algún objeto que tarde menos en renderizar que el active.

Calculo así al vuelo que usando el motor de lua para hacer los cálculos, los frames se renderizan en un 60% del tiempo que tardan ahora.

---

Ahora que lo pienso, si hubiera pensado más en la técnica del doom, que usa mapas vectoriales en ves de rasterizados, podría haber obtenido una calidad mucho más grande y computable en mucho menos tiempo... pero requeriría de un poco de programación adicional para que los rayos detecten si cortan a los vectores, y en que punto... sin mencionar una forma de "hacer" los mapas vectoriales en cuestión

---

Ya de paso, v2... agrego un parámetro "Steps" que sirve para regular la precisión de los pasos para calcular la colisión del rayo. Cuando más grande el valor, mas anchos serán los pasos, por lo que tardarán mucho menos () en encontrar una pared y pueda subir un poco los FPS (Pero bajan bastante la calidad).

Fijarse donde dice Steps:
[Tienes que estar registrado y conectado para ver esa imagen]
mismo link de siempre calculo
Estoy trabajando en este momento para ver en que se puede optimizar por ahora

---

Todavía tengro problemas con la "redondéz" de las paredes debido a la impresición decimal de los cálculos del MMF2 -.-"
Bah, en realidad es porque estoy usando el puntod de corte del loop como la distancia y no calculo la distancia "real" que hay entre el punto y el cruce... si así lo hiciera, quizá el dibujo se vería un toque menos redondo acercándose a los muros.

---

Y de nuevo, perdón por editar tantas veces este mensaje, es que me voy acordando al vuelo xdd

---

ok, se los dejo en v3, y me voy a dormir un poco más, que con 5 horas de sueño no me alcanza

Eso es lo bueno del elpatrix save sacarle jugo a las mates y geometria en los videojuegos. :cheers: [Tienes que estar registrado y conectado para ver esa imagen]

Y en este momento es cuando me lamento de no saber matemáticas :_

nachosniegenserio escribió:

Y en este momento es cuando me lamento de no saber matemáticas :_

Descuida que para eso están las extensiones
Yo solo soy un masoquista que disfruta de tomar el camino dificil

Entretanto, ya voy por la revisión 5 del programa... hice unos cuantos cambios a los controles y ahora se puede cambiar la definición durante la ejecución del juego (teclas de Inicio y Fin) y se crean todas las paredes denuevo.

El link es el mismo de siempre, y estén atentos porque cada modificación que haga se sube instantáneamente (gracias dropbox por actuarme de svn )

Si mis profesores de matematicas hubiesen respondido la eterna pregunta: Para que mierda me sirve aprender esto? Diciendo: Para hacer videojuegos GIL! Hubiese prestado atencion en clase en vez de copiarme en los examenes...

Sos groso patrix, si te hubiese tenido de compañero en el colegio no me hubiese llevado matematicas a diciembre y marzo todos los años

lmchucho:

Este hilo está dedicado a un motor de raycasting propuesto por elPatrixF.

Este post tuyo, o bien sugiere una pregunta, en cuyo caso, hazla en la sección correspondiente, o bien quiere mostrarnos un avance de un proyecto, que también tiene su sección.

Antes de moverlo, espero a que me indiques la opción que prefieres.

Lo indicado sería, hacer la pregunta por un lado, en su sección y dejar aquí el comentario que le haces a elPatrixF. En todo caso la decisión la dejo en tus manos.

Respondiendo a tu pregunta, el exportador Java, tiene objetos limitados y hay que evitar usar los que no soporta, además de algunas particularidades. Esta es la razón principal, por la que pueden existir diferencias entre lo que se obtiene con .exe a lo que se obtiene con este exportador. También pueden existir variantes en función del navegador que estés usando. Por lo general uno que funciona bien en estos casos es el Chrome.

La limitación en el uso de objetos, también sucede con flash, iOS... etc.

elpupas7 escribió:

lmchucho:

Este hilo está dedicado a un motor de raycasting propuesto por elPatrixF.

Este post tuyo, o bien sugiere una pregunta, en cuyo caso, hazla en la sección correspondiente, o bien quiere mostrarnos un avance de un proyecto, que también tiene su sección.

Antes de moverlo, espero a que me indiques la opción que prefieres.

Lo indicado sería, hacer la pregunta por un lado, en su sección y dejar aquí el comentario que le haces a elPatrixF. En todo caso la decisión la dejo en tus manos.

Respondiendo a tu pregunta, el exportador Java, tiene objetos limitados y hay que evitar usar los que no soporta, además de algunas particularidades. Esta es la razón principal, por la que pueden existir diferencias entre lo que se obtiene con .exe a lo que se obtiene con este exportador. También pueden existir variantes en función del navegador que estés usando. Por lo general uno que funciona bien en estos casos es el Chrome.

La limitación en el uso de objetos, también sucede con flash, iOS... etc.

Perdon pupas, me daba fiaca hacer tres posts diferentes . No hace falta que muevas nada yo me encargo. Ahora edito el post.