Mojonia 3.0

Eso suena genial

De todos modos te digo que el cuello de botella en la churrera no es splib2, sino el lenguaje C. No poder ir sincronizados con la pantalla es un handicap que sólo se puede resolver con una biblioteca con el planteamiento que tienen splib2 o la nueva SP1 de Alvin.

Claro, si no supongo que tendríamos que andar contando ciclos, no?

$this->bbcode_second_pass_code('', '#asm
halt
#endasm
')
es tu amigo...

Sí, pero cuando tu bucle dura más que un ciclo, tu amigo no sirve.

No sé cómo serán tus rutinas, pero además, si no quieres parpadeos, vas a tener que ir por detrás del raster, porque en el borde superior no da tiempo a actualizar muchas cosas. Eso implica aún más sincronismos y esperas, y el fps total del juego bajará aún más.

Te lo digo porque todas estas cosas están ya muy trabajadas. Cuando se plantea uno hacer juegos en C tiene que saber que de él no depende controlar la duración de los ciclos. Por eso Alvin diseñó splib de la forma en la que está diseñada: para minimizar parpadeos y poder actualizar en cualquier momento. De hecho, cuando la evolucionó para construir SP1, usó el mismo paradigma.

SP1 es de hecho más rápida y tiene muchas cosas más (como por ejemplo poder usar cualquier fondo, y no solo 256 tiles, o poder marcar caracteres de la pantalla para que no se actualicen y que, de esa forma, los sprites parece que pasen por detrás, además de muchos más modos de volcado, sprites compilados, y mil mandangas), pero el footprint inicial es mucho mayor que el de splib2, y por eso no me he adaptado.

Ignoro cómo vas a construir el tema, no tengo ni idea, pero de las posibilidades que conozco, trabajar con "dirty rectangles" (o chars, mejor dicho) es la más viable que veo.

La cuestión es que desde BASIC no existe control alguno, y he podido hacer cosas muy monas. No pretendo hacer scroll parallax y demás mandangas, pero tengo una visión muy simple de lo que quiero hacer y eso significa que no será perfecto pero si me permitirá cosas que actualmente no puedo con la churrera.

Evidentemente tendré que exprimir mis rutinas hasta hacer que un HALT me valga, o cogeré otra opción, pero todo depende de lo que vaya a hacer. Es que no voy a usar un motor de movimiento pixel a pixel de momento, ya que lo que tengo en mente es a todo color y con sprites grandes (pero pocos en pantalla).

Si quiero precisión me voy al ensamblador puro y duro. Que es la opción que estaba usando hasta ahora y así me ha ido... cero juegos terminados de momento. Con C me puedo centrar en lo importante y ya lograré mejores resultados.

No me preocupa, no me da de comer esto, lo hago por diversión.

PD: Y siempre tendré la churrera para algún juego rápido en plan desahogo, ojito.

Si vas a usar movimiento a caracter la cosa cambia. Aquí por lo general hay mucho menos que hacer y si te mueves de 8 en 8 píxels te puedes permitir menos FPS, con lo que sí te da para temporizar y meter esperas y que te de tiempo a todo. Además, tu buffer puede almacenar una direccion de memoria para cada caracter, con lo que ocupará poco y tendrás una colección de punteros directos a los gráficos, y renderizando directamente sobre la pantalla, ahorrando un montón.

Así es como hicimos, por ejemplo, el primer Maritrini.

Efectivamente, usando caracteres tengo muchas triquiñuelas a mi disposición y eso me da ventaja (y rapidez). Tener movimiento al pixel es muy majo para sprites pequeños, pero echo de menos sprites más grandes con color propio.

Que no quiero hacer un Trap Door, pero si personajes en plan como los juegos de Climacus (cuando veáis su última obra lo vais a flipar en colores, literalmente). Soy fan de los juegos tipo Dan Dare III o AMC, aún recuerdo como se te quedaban los ojos como platos ante semejante despliegue de color, y el Popeye es para mi el tope de lo que un ZX Spectrum puede hacer (y en 48K, bárbaro).