QStar2 revisitado: modo de color de alta definición

[andrew]

La imagen de Windows adjunta (comprimida) incluye ambas versiones: la versión anterior en modo 8 y la nueva versión en color de alta definición.
Avísame si encuentras algún error.
¡Diviértete!

1.jpg (204.72 KiB) Visto 279 veces

3.jpg (151.14 KiB) Visto 279 veces

[afx]

Hola Andrew, he probado QStar286 y funciona a la perfección en mis sistemas Q68 y QPC2.

Es de agradecer que también hayas publicado los fuentes, sin duda un material muy interesante para su estudio. Gracias por el esfuerzo y por tu generosidad.

[andrew]

Es de agradecer que también hayas publicado los fuentes, sin duda un material muy interesante para su estudio. Gracias por el esfuerzo y por tu generosidad.

Creo en el código abierto.
También creo que el problema del Sinclair QL no es el hardware, ya que ahora tenemos muchas opciones nuevas.
El problema es que tenemos muy pocos programas nuevos.
Y espero que otros comiencen a escribir programas para el QL.

[andrew]

QStar2 Sprite Sheet
Hay 5 sprites para cada dirección, pero el movimiento utiliza 8 pasos, ya que algunos sprites se utilizan dos veces.
Por lo tanto, para cada dirección, un movimiento de 16 píxeles es: 3 - 2 - 3 - 1 - 4 - 5 - 4 - 1
(cada sprite se mueve 2 píxeles en la dirección del movimiento)

QStar2SpriteSheet.png (36.59 KiB) Visto 203 veces

[afx]

Creo en el código abierto.
También creo que el problema del Sinclair QL no es el hardware, ya que ahora tenemos muchas opciones nuevas.
El problema es que tenemos muy pocos programas nuevos.
Y espero que otros comiencen a escribir programas para el QL.

Estoy completamente de acuerdo contigo, efectivamente, el principal problema del Sinclair QL en la actualidad no radica en el hardware, sino en la falta de nuevos programas.

En el ámbito del hardware, hemos sido testigos durante el último año de avances considerables en el mundo QL: nuevas placas de expansión, adaptadores modernos y soluciones que mejoran la conectividad y la capacidad del QL. En mi opinión, todo este avance es facilitado por un desarrollo más "estructurado" en mundo hardware donde hay acceso a componentes modernos (como son las FPGAs,...) que permiten una integración perfecta en nuestras máquinas clásicas. Esto no quita mérito a la gran capacidad y el conocimiento de la máquina que han mostrado los desarrolladores hardware del QL.

Sin embargo, el panorama en el mundo del software para el Sinclair QL creo que es muy distinto. Aquí, el progreso ha sido más limitado. Los lenguajes, herramientas y frameworks de desarrollo para estas plataformas no han evolucionado al mismo ritmo. Esto dificulta la creación de nuevo software, especialmente para aquellos que, como yo, no tienen conocimientos profundos de programación a bajo nivel.

Creo que una solución viable podría ser el desarrollo de "frameworks" o "kits de desarrollo" de alto nivel más modernos específicamente diseñados para el QL. Estas herramientas podrían simplificar y agilizar el proceso de creación de programas, permitiendo que más entusiastas contribuyan con software nuevo y útil. Por ejemplo, frameworks que integren herramientas gráficas, gestión más eficiente de entradas-salidas, o incluso que ofrezcan APIs para explotar las capacidades ampliadas del hardware moderno que se ha desarrollado para el QL.

Volviendo al tema de este hilo, por los resultados que has mostrado en tus últimos desarrollos, has dado un gran salto hacia delante al desarrollar una serie de juegos muy vistosos y muy bien adaptados a la diversidad de hardware que hay en estos momentos en el QL. He visto tu código muy por encima y me gustan varias cosas: 1) que al estar escrito en SuperBasic es relativamente fácil de seguir, 2) que te las has ingeniado para no tener excesivas dependencias de toolkits extraños. Aunque..., para poder comprender bien el código de tus programas debemos invertir (al menos yo) un buen número de horas en su estudio. En este sentido ¿Te has planteado la construcción de un "framework" o "kit de desarrollo" que facilite el uso de tus herramientas y tu técnica para que otros usuarios puedan desarrollar sus propios juegos de una forma simple y estandarizada?

Saludos!

[andrew]

El código que escribí creo que está bien estructurado y es fácil de seguir. Todas las funciones y procedimientos tienen nombres sugerentes y algunos comentarios.
Todos los juegos tienen algunas áreas comunes:
Lectura del teclado: bucle principal para leer las pulsaciones del teclado
PutSprite: una función para dibujar un sprite en la pantalla en una dirección de pantalla
(esta función no utiliza bucles FOR, para que sea más rápida)
PutBigSprite (o algún otro nombre) para poner en la pantalla sprites con tamaño variable
MoveUp, MoveDown, MoveLeft, MoveRight: funciones para calcular si es posible el movimiento y qué sprite poner en la pantalla para el movimiento
DoBeep: reproduce un sonido
InfoWindow +RedoBkg: muestra en la pantalla una ventana y rehace el fondo después de que se cierra la ventana

El siguiente paso es escribir el código que utiliza sprites transparentes. Debido a las limitaciones de SuperBasic, no estoy seguro de que el código sea lo suficientemente rápido para la animación. Si no es lo suficientemente rápido, tendré que pasar al lenguaje C (y aprender C desde cero una vez más)

[afx]

El código que escribí creo que está bien estructurado y es fácil de seguir. Todas las funciones y procedimientos tienen nombres sugerentes y algunos comentarios.
Todos los juegos tienen algunas áreas comunes:
Lectura del teclado: bucle principal para leer las pulsaciones del teclado
PutSprite: una función para dibujar un sprite en la pantalla en una dirección de pantalla
(esta función no utiliza bucles FOR, para que sea más rápida)
PutBigSprite (o algún otro nombre) para poner en la pantalla sprites con tamaño variable
MoveUp, MoveDown, MoveLeft, MoveRight: funciones para calcular si es posible el movimiento y qué sprite poner en la pantalla para el movimiento
DoBeep: reproduce un sonido
InfoWindow +RedoBkg: muestra en la pantalla una ventana y rehace el fondo después de que se cierra la ventana

Gracias Andrew por los comentarios.

La verdad es que el código de QStar es muy compacto, pequeño y se lee bien. Hay funciones y procedimientos muy útiles, por ejemplo, hace tiempo que estaba buscando unos procedimientos como SaveBkg y Redobkg que funcionaran con varias resoluciones de pantalla.

Por cierto, ¿Qué hacen las líneas siguientes?

Código: Seleccionar todo

180  TURBO_windo 3
190  TURBO_model 1
200  TURBO_diags 0
210  TURBO_objdat 10
220  TURBO_objstk 350
230  TURBO_taskn "QStar 1"

¿Y el comando o procedimiento T_ON de la línea 300?

[andrew]

Los TURBO_XXX son comandos de configuración del compilador TURBO. Puedes descargar los manuales de Turbo aquí: https://dilwyn.qlforum.co.uk/turbo/index.html

T_INIT, T_ON, T_OFF son comandos de temporizador: inicialización, encendido y apagado del temporizador. El temporizador se utiliza para limitar la velocidad del juego a unos 30 fotogramas por segundo.
Puedes leer sobre él y descargarlo, incluido el manual, aquí https://www.retrowiki.es/viewtopic.php? ... p200186083

[afx]

Los TURBO_XXX son comandos de configuración del compilador TURBO.

¿Tus programas están compilados con Turbo? (Yo pensaba que usabas QLiberator).

(Gracias por tus respuestas).

[andrew]

¿Tus programas están compilados con Turbo? (Yo pensaba que usabas QLiberator).

Utilicé Turbo para todos los juegos de QSTAR y Pitman porque es más rápido.
Utilicé QLiberator para PI Cole porque la velocidad no es importante en esos juegos.
¡Y utilicé QLiberator para QLCommander simplemente porque no podía compilarlo con Turbo! Turbo no es muy feliz cuando se pasan matrices multidimensionales como parámetros a funciones y procedimientos. Además, cuando escribí QLCommander no sabía nada sobre Turbo, por lo que no presté atención al pasar parámetros por nombre o por valor.
QLiberator es mucho más indulgente que Turbo, pero también el código generado es más lento.
Mi suposición es que en algo tan rápido como un SGC/Q68/QIMSI Gold no hay mucha diferencia en la velocidad entre el código SuperBasic interpretado y el código compilado de QLiberator.

[afx]

QLiberator es mucho más indulgente que Turbo, pero también el código generado es más lento.

¿Tienes alguna medida de cuánto más rápido es Turbo?

[andrew]

¿Tienes alguna medida de cuánto más rápido es Turbo?

No, no lo hago. Pero no debería ser difícil escribir un programa, compilarlo con Turbo y QLiberator y ver cuánto tarda en ejecutarse.
Tal vez lo haga durante el fin de semana, si tengo tiempo.