Motorcillo 3D para Spectrum.

[jepalza]

Tonima, tienes unas formas de decir las cosas, que parece que todo te molesta. Lo dejo pasar, por que no me siento ofendido, tengo mucho aguante, pero si quiero puntualizar, que no es que no quiera ayudar, tal como dices, que por eso te doy largas. Si no quisiera ayudar, ni te hubiera contestado. Es todo lo contrario, solo quiero que no te decepciones por tu argumento. Veo que eres tú el que te enfadas por no querer aceptar la realidad.

Pero yendo a lo nuestro, (y casi siguiendo el mismo tema del foro "casi" hermano RW), la realidad del 3D es muy dura. (ya ves que no soy el único que te lo dice), y tu idea es MUY compleja, tanto, que se quitan las ganas de meterse en un proyecto semejante. Que lo peor, sigo diciendo, es meter matemáticas en el Z80 en ASM. Que un programador sepa ASM (o sea, yo), no significa que sepa matemática en ASM, y como yo, habrán muchos mas.
Hacer una demo, no es hacer un juego. En la demo te pasas por el forro muchas cosas, y te importa un pimiento gastar RAM a lo loco, pero en el juego, debe ir todo optimizado.
Piensa, que los programadores de juegos de antaño, se tiraban mese o años desarrollando los juegos, por algo sería. Y los trucos de sus juegos 3D no salían a la calle.
Hay un motor gráfico usado en el Specrtum, el del 3D Construction KIT (el freescape) que sus creadores, NUNCA han querido regalar, ni mostrar cómo lo hicieron, para evitar que lo copiaran. Por algo sería, probablemente, por que se tirarían mese depurando semejante motor 3D, para regalarlo sin mas.

Te deseo suerte en tu embarcada, y si necesitas ayuda 3D en Basic, me tienes aquí, pero en ASM no me veo capaz.

[mcleod_ideafix]

Muchas gracias a todos, de momento lo que necesito es poder pasar los vertices de un objeto al spectrum y que se pinte en alambre, que este todo precalculado, o sea que cada frame del objeto este precalculado en los vertices y se pinte en alambre. No hay mas de momento.

Pásame por aquí un archivo de texto que contenga una lista de líneas 2D de algún gráfico que quieras renderizar. Cada línea que tenga un vértice inicial y un vértice final. Cada vértice que tenga coordenadas en el rango X (0-255), Y (0-191). Origen de coordenadas en la esquina superior izquierda de la pantalla. A ver qué podemos hacer

Por ejemplo, para una figura que fuera un cuadrado 2D de 100 píxeles de lado el archivo podría ser algo como esto:

Código: Seleccionar todo

78 28 178 28
178 28 178 128
178 128 78 128
78 128 78 28

Es decir, 4 líneas de texto, cada una se corresponde con una línea 2D (total, pues, 4 líneas que forman el cuadrado). En cada línea, 4 números que se corresponderían, los dos primeros a las coordenadas iniciales de la línea, y los dos segundos a las coordenadas finales.

Seguramente resulte después que no es la mejor forma de guardar la información. Probablemente se gane tiempo si para cada coordenada se guarda la dirección inicial de pantalla donde ha de pintarse el punto correspondiente, y además se guarda algún parámetro que se necesite después en el algoritmo de Bresenham (como por ejemplo el octante de círculo al que pertenece la línea, y cosas así)

[radastan]

Otra forma de optimizar es no usar todos los pixels del spectrum para calcular vértices.

Me explico, si usamos vértices de dos en dos pixels tardamos 4 veces menos en renderizar la pantalla, pero si se usa una presentación "wireframe" no se nota. A la hora de renderizar polígonos con textura o con ocultación de líneas no vale el método, pero en plan wireframe acelera una barbaridad la cosa.

[mentalthink]

Pues a mi por lo que me toca me interesa mucho esto que comentáis sobre todo el libro que comenta Jepalza...

Puede que sea esté:
http://www.cpcwiki.eu/index.php/Grafico ... on_Amstrad

Aunque en el Spectrum como coentáis es lento, no hace mucho vi un simular de aviones con sombreado, o sea se veia la pista de aterrizaje y demas, y a puntitos y sólido, y la verdad no iba demasiado lento, lo que si me fije, supongo que de ahí el truco, que la ventana de juego, era muchísimo más pequeña que lo normal de los juegos de la Época , pero bueno quizás pudiera ser una manera de hacer algo sólido, y que fuera suave...

Un tema extremadamente interesante este.

[Toniman]

Yo es lo que intentaba comentar desde un principio, quiero pintar wireframe, todo precalculado, que no oculte las caras. Por favor Jefalza si te ha parecido que yo he dado señales de molestia en algun momento, no es asi, ya que yo creo que en un principio no me estaba explicando bien, yo lo que quiero es todo en Wireframe, nada de rellenos solidos ni nada de eso, no me pongais como ejemplo nada que lleve poligonos solidos.

[Toniman]

Mc_Leod, yo cuando hago un objeto, me sale este codigo

Código: Seleccionar todo

 o Piramide.obj
mtllib Piramide.mtl
g default
v -1.5 0 -0
v 0 0 1.5
v 0 0 -1.5
v 0 2 -0
v 1.5 0 -0
vn -0.998733 -0.0503267 -0
vn 0 -0.0503267 0.998733
vn 0 -0.0503267 -0.998733
vn 0 1 -0
vn 0.998733 -0.0503267 -0
usemtl Default
s off
f 2//2 1//1 3//3 5//5
f 3//3 4//4 5//5
f 4//4 3//3 1//1
f 4//4 1//1 2//2
f 5//5 4//4 2//2

Esto es el codigo de una Piramide. ¿se podria convertir en vertices para ser leido en un Spectrum?

[mcleod_ideafix]

Mc_Leod, yo cuando hago un objeto, me sale este codigo
Esto es el codigo de una Piramide. ¿se podria convertir en vertices para ser leido en un Spectrum?

Pues supongo que sí, pero no sé cómo se interpreta ese código que has puesto. Para la prueba que puedo hacerte, necesito ya los vértices 2D, es decir, una vez realizada la perspectiva, y escalados para que quepan en el rectángulo de 256x192 puntos.

EDITO: entiendo que "v" son vértices, y que "vn" son las normales a cada cara de la pirámide (sólo son necesarias para ocultar líneas, en wireframe no se usan). "g" podría ser la gravedad (??). "f" no sé qué es (¿faces?, es decir, "caras").

Partiendo de los datos de "v" habría que saber qué vértices están unidos por líneas. Cuento 5 vértices, así que supongo que lo que has dibujado es una pirámide rectangular.

[mcleod_ideafix]

Ah! creo que ya lo tengo.

"v" define vértices en 3D. Eso estaba claro.
Las "vn" son las normales como dijimos. No las necesitamos.
"f" son los polígonos. El primer "f" por ejemplo es para pintar el cuadrado de la base de la pirámide. Los números entre // son los índices de los vértices que usa para dibujarlo, y el orden en que deben dibujarse. Hay un cuadrado (primer "f", que usa 4 vértices) y luego cuatro triángulos (las caras laterales de la pirámide) que usan 3 vértices cada una.

Tal como está el fichero, sí, es posible convertir eso a una lista de vértices 2D, pero habría que optimizar la generación para no generar líneas repetidas. Por ejemplo, en tu pirámide, cada triángulo que comprende una cara lateral tiene en común un lado con la base y otro lado con el siguiente triángulo. Habría que detectar estas repeticiones para no añadirlas al listado de vértices final. Esto se puede detectar fácilmente en la lista de "f" del fichero. Por ejemplo:

Código: Seleccionar todo

f 2//2 1//1 3//3 5//5

OK. Se convierte a un polígono que une los vértices 2-1-3-5-2 (cuatro líneas)

Código: Seleccionar todo

f 3//3 4//4 5//5

La línea que va de 5 a 3 (último a primer vértice) ya está incluida en el primer polígono (3 a 5), así que no se pinta. Se convierte por tanto a 3-4-5 (dos líneas)

Código: Seleccionar todo

f 4//4 3//3 1//1

La línea 4-3 está incluida en el polígono anterior (3-4). La línea 3-1 está incluida en el primer polígono (1-3). Este polígono se renderiza como 1-4 (una línea)

Código: Seleccionar todo

f 4//4 1//1 2//2

Análogo al anterior. 4-1 y 1-2 ya están incluidas en anteriores polígonos. Se renderiza como 2-4 (una línea)

Código: Seleccionar todo

f 5//5 4//4 2//2

Todas las líneas que se definen aquí ya está incluidas en polígonos anteriores. No se renderiza.

Total, 8 líneas hay que renderizar (lo mínimo como se puede comprobar, para dibujar una pirámide rectangular)

[mentalthink]

Doy una pequeña idea por si pudiera ser más rápida

Yo cuando dibujo algo en 3D "a mano"
Lo que pongo son los vertices en un array y luego pinto los Polys(estó descartado ya he leído lo que comentas ToniMan)

Quizás una manera para que las lineas fueran rápidas, aunque no sé, quizás aparezan formandose una a una o aparece un "fliker"...

Seria tener un objecto en 3d, o sea los vertices que componen esa malla, en un array, e ir dibujando con un contador de dos en dos arrays de 3 dimensiones... o sea como si solo dibujaramos 1 linea a la vez, pero que si en teoria va lu suficientemente rápido no se apreciaria la contruccion de esa malla...

O sea en vez de recorrer el array completamente con un for o como se haga en ASM con un contador...

Otra cosa que se me acaba de ocurrir asi a bote pronto, sería hacer :
En vez de pasar el objeto completo, normalmente los modelos en 3D son símetricos, copiar solo los datos que componen la mitad de los datos del .obj u otro formato, y multiplicarlo *-1 los vectores o puntos, entonces tendriamos esa mitad dibujada, solo teniendo en memoria la mitad de un objeto, o sea el array sería dim (n-1)/2

[radastan]

Me acabo de acordar, que hay un libro, que creo que se puede buscar en pdf, sobre 3D en CPC, MSX y Spectrum, que enseña a dibujar en alambre. No recuerdo ahora su título.

Creo que te refieres a este:



Lo tengo delante, una de las joyas de mi colección. Todos los listados son en BASIC, así que imagina si explica todo desde cero... buenísimo.

Si puedo lo paso a PDF, pero no puedo deciros cuando porque ando liadísimo para gastar tanto tiempo.