Memoria gráfica y sprites

Subforo oficial del Sinclair QL: realiza aquí las consultas relativas a tu QL.

Moderador: Sir Cilve Sinclair

Responder
Avatar de Usuario
radastan
Phantomas
Mensajes: 2232
Registrado: Lun May 07, 2007 5:34 pm
Contactar:

Memoria gráfica y sprites

Mensaje por radastan » Sab Mar 29, 2008 7:36 pm

Bien, entremos en "tema".

Tengo el libro "QL Gamesmaster" y en él se indica que la memoria de pantalla empieza en 131072 y que se escribe en ella de forma lineal (cuando se acaba una línea se pasa a la siguiente, no como en ZX Spectrum). La cuestión es cómo realizar sprites, y es que no hay más remedio que usar ensamblador porque ni el basic estándar ni el Super Basic contemplaron esta posibilidad.

Bada, necesito un ensamblador sencillo para QL que veo muy necesario una rutina decente.

En el mismo libro se emplea una técnica para realizar en el modo de 256x256 impresión de GDU's y así tener un modo de baja resolución de 32x32 caracteres en pantalla (no hay movimiento pixel a pixel), la cual voy a ir escribiendo aquí poco a poco.

COMO CREAR GDU's EN MONOCROMO DE 8x8 PIXELS

En primer lugar hay que reservar memoria, para lo cual usamo:

Código: Seleccionar todo

C_TAB=RESPR (32*N)


C_TAB va indicar donde se sitúa la tabla de GDU's
N es el número de GDU's que vamos a usar

Ahora vamos a definir GDU's:

Código: Seleccionar todo

def_graph s,f,b,r0,r1,r2,r3,r4,r5,r6,r7


def_graph va a ser el procedimiento que nos va a definir cada GDU, el cual tiene como entrada:

s es el nº de orden del GDU dentro de la tabla, empezando por cero
f es el color del GDU
b es el color de fondo
r0-r7 son los bytes que definen el GDU, y se usan exactamente igual que en ZX Spectrum

Cada byte del GDU se calcula, si queréis hacerlo a mano, así:

| 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 |

Es decir, la línea 10001111 sería 143.

Ahora vamos a realizar la rutina que nos defina la tabla de GDU's en memoria:

Código: Seleccionar todo

1300 DEFine PROCedure def_graph (S%,f%,B%,R0%,R1%,R2%,R3%,R4%,R5%,R6%,R7)
1310 LOCal A,FH%,FL%,BH%,BL%
1320 A=C_TAB+32*S%
1330 FH%=(F% DIV 4)*2
1340 FL%=F% && 3
1350 BH%=(B% DIV 4)*2
1360 BL%=B% && 3
1370 charline(R0%)
1380 charline(R1%)
1390 charline(R2%)
1400 charline(R3%)
1410 charline(R4%)
1420 charline(R5%)
1430 charline(R6%)
1440 charline(R7%)
1499 END DEFine def_graph
1500 DEFine PROCedure charline (R%)
1510 LOCal M%,J,I,DL%,DH%
1520 M%=128
1530 FOR J=1 TO 2
1540  DL%=0:DH%=0
1550  FOR I=1 TO 4
1560   IF (R% && M%)=M% THEN
1570    DL%=FH%+DL%*4
1580    DH%=FL%+DH%*4
1590   ELSE
1600    DL%=BH%+DL%*4
1610    DH%=BL%+DH%*4
1620   END IF
1630   M%=M% DIV 2
1640  END FOR I
1650  POKE A, DL%
1660  POKE A+1, DH%
1670  A=A+2
1680 END FOR J
1699 END DEFine charlie


Ala, sin anestesia, más difícil es escribirlo que leerlo.

Para finalizar tenemos que realizar un procedimiento que nos imprima los GDU's en pantalla sin que nos den las uvas, así que tenemos que meter ensamblador de por medio. El procedimiento para imprimir GDU's es:

Código: Seleccionar todo

graph x,y,s


x es la posición horizontal (0 a 31, 0 es la izquierda)
y es la posición vertical (0 a 31, 0 es arriba)
s el GDU que queremos poner en pantalla

Esto se define así:

Código: Seleccionar todo

1700 DEFine PROCedure graph (X%,Y%,S%)
1710 CALL do_graph, X%,Y%,S%,C_TAB
1799 END DEFine graph


Y para crear la rutina ensamblador:

Código: Seleccionar todo

360 DATA -5245,-10109,-7806,-11646
370 DATA -6783,1665,2,0,8769,8316
380 DATA 0,0,9264,18432,8834,-11524,128
390 DATA 2264,-20228,32,26350,28672,20085
400 do_graph=RESPR(100)
410 RESTORE 360
420 FOR I=do_graph TO do_graph+22*2 STEP 2
430  READ B
440  POKE_W I.B
450 END FOR I


Y eso es todo por ahora, con todo lo aquí explicado podemos usar GDU's desde Super BASIC, a ver si aprendo algo de ensamblador del 68000 y genero yo otra rutina que permita sprites del tamaño que queramos con cada pixel de su color (y a ser posible que se puedan usar máscaras)
_________________________________________
Hay otras páginas.... pero no son Bytemaniacos
http://www.bytemaniacos.com
Orgullo de 8 bits
_________________________________________

Avatar de Usuario
badaman
Sabreman
Mensajes: 499
Registrado: Mar Ene 29, 2008 10:58 am
Contactar:

Re: Memoria gráfica y sprites

Mensaje por badaman » Sab Mar 29, 2008 9:11 pm

Currada te has pegao!!

Luego lo probaré a ver que tal.

Me temo que tengo malas noticias para ti, y es que con TK2 se pueden definir caracteres de forma parecida a lo que propones:

http://www.speccy.org/sinclairql/man/tk2/sec14.htm

luego puedes imprimir los caracteres, cambiarles el color del papel y la tinta, cambiar su tañaño con CSIZE...

De todas formas tus rutinas van muy bien encaminadas, y para sprites mayores van a venir muy bien.

Hay no obstante también un toolkit llamado Super Sprite Generator que añade nuevos comandos para definir sprites con máscaras, detectar colisiones, etc. Yo no lo he usado mucho, asi que lo que descubras con el nos lo cuentas.

Lo busco y os lo paso a los que estéis interesados en él.

También tengo por ahí un toolkit gráfico que entre otras cosas trae una utilidad para definir caracteres.

Si de todas formas te animas a crear tus propias rutinas para sprites o cuando menos para volcar áreas de memoria de pantalla, te recomiendo que leas y escribas palabras largas (32 bits) en vez de bytes, pues es mucho más rápido.

A la hora de almacenar la imagen del sprite, reserva un color de los 8 que hay para la máscara, pues una máscara a parte ocuparia mucho.

Luego busco eso y te lo mando.

Saludos y que siga la cosa así.
Sinclair QL, la respuesta profesional de los 80

Avatar de Usuario
radastan
Phantomas
Mensajes: 2232
Registrado: Lun May 07, 2007 5:34 pm
Contactar:

Re: Memoria gráfica y sprites

Mensaje por radastan » Sab Mar 29, 2008 10:19 pm

badaman escribió:Me temo que tengo malas noticias para ti, y es que con TK2 se pueden definir caracteres de forma parecida a lo que propones:


No es lo mismo, de hecho en ese caso estás atado a una resolución mucho mayor de caracteres y al número de caracteres del set que se va a redefinir. Aquí tu decides cuantos GDU's necesitas, que es lo importante, y sin necesidad de tocar el set original que nos puede venir bien para otras cosas (y no tenemos que andar cambiando de sets).

badaman escribió:De todas formas tus rutinas van muy bien encaminadas, y para sprites mayores van a venir muy bien.


Esa es la idea, retocar ahora estas rutinas y el código ensamblador para poder definir sprites mayores y con cada pixel de su color, que es el resultado perfecto para hacer juegos de todo tipo.

badaman escribió:Hay no obstante también un toolkit llamado Super Sprite Generator que añade nuevos comandos para definir sprites con máscaras, detectar colisiones, etc. Yo no lo he usado mucho, asi que lo que descubras con el nos lo cuentas.

Lo busco y os lo paso a los que estéis interesados en él.


Ya estás pasando el enlace y la documentación, porque si está bien realizado no hace falta hacer nuevas rutinas. De todas formas, por experiencia en cosas similares, creo que tendrá varias pegas o ocupará mucha memoria el propio toolkit.

badaman escribió:Si de todas formas te animas a crear tus propias rutinas para sprites o cuando menos para volcar áreas de memoria de pantalla, te recomiendo que leas y escribas palabras largas (32 bits) en vez de bytes, pues es mucho más rápido.


No hace falta que me lo jures, se perfectamente que el 68000 trabaja en 32 bits de forma interna, pero por desgracia el QL usa la versión 68008 que tiene un bus de 8 bits de datos y habría que estudiar que es lo que verdaderamente es más rápido. Lo que podemos aprovechar es que como puede manejar 32 bits los sprites podríamos hacerlos de 16x16 y que la rutina fuera como una moto (metería los 16 pixels de cada línea del tirón). Yo veo lógico hacer dos rutinas, una de 8x8 y otra de 16x16 para aprovechar la velocidad al 100%.

badaman escribió:A la hora de almacenar la imagen del sprite, reserva un color de los 8 que hay para la máscara, pues una máscara a parte ocuparia mucho.


No, me niego en redondo. Eso puede ser ideal en algún juego donde prime la velocidad, pero perder un color me parece una salvajada teniendo en cuenta que ya hemos perdido 8 colores de paleta respecto a los ZX Spectrum.
_________________________________________
Hay otras páginas.... pero no son Bytemaniacos
http://www.bytemaniacos.com
Orgullo de 8 bits
_________________________________________

Avatar de Usuario
badaman
Sabreman
Mensajes: 499
Registrado: Mar Ene 29, 2008 10:58 am
Contactar:

Re: Memoria gráfica y sprites

Mensaje por badaman » Dom Mar 30, 2008 4:10 am

radastan escribió:No es lo mismo, de hecho en ese caso estás atado a una resolución mucho mayor de caracteres y al número de caracteres del set que se va a redefinir. Aquí tu decides cuantos GDU's necesitas, que es lo importante, y sin necesidad de tocar el set original que nos puede venir bien para otras cosas (y no tenemos que andar cambiando de sets).


Hombre, no se yo si vas a usar muchos UDGs, pero ni tienes que rellenar los 256 caracteres ni es necesario que cargues y descargues el set de caracteres, -cosa que tampoco sería muy complicada con los comandos que se facilitan-, pues el juego de caracteres se define para cada canal, es decir, que si tienes dos ventanas con números de canales distintos (obvio) pero las ventanas están superpuestas, cuando queramos escribir con la fuente original imprimimos en un canal y cuando queremos escribir con la nueva fuente imprimimos en el canal donde hemos redefinido el juego de caracteres.

Además cito:

"Las fuentes sustitutas no tienen porqué tener el mismo rango de caracteres que las fuentes internas. Puede, por ejemplo, definir una fuente que tenga todos los valores desde el 128 al 255."

Y yo añado: O no. Puede ser que sólo quieras redefinir, por ejemplo, 3 caracteres.

Usa este pequeño programa para ver la tabla de caracteres del QL y descubrirás que hay muchos de ellos sin definir:

FOR bucle=32 TO 255 : PRINT CHR$(bucle);

Y sigue el texto con lo siguiente:

"El formato de una fuente del QL es:
* 1 byte que indica el carácter más bajo de la fuente
* 1 byte que indica el número de caracteres válidos - 1
* 9 bytes con el patrón del carácter más bajo
* 9 bytes con el patrón del siguiente carácter
* etc."

En el caso de los 3 caracteres del ejemplo que propongo, primero ponemos el valor en la tabla de caracteres del carácter 1 para entendernos su chr$(). luego el número de caracteres que vamos a definir menos uno (3-1) y luego las definiciones de cada carácter.

radastan escribió:No hace falta que me lo jures, se perfectamente que el 68000 trabaja en 32 bits de forma interna, pero por desgracia el QL usa la versión 68008 que tiene un bus de 8 bits de datos y habría que estudiar que es lo que verdaderamente es más rápido.


No confundamos conceptos. Una cosa es la capacidad y/o velocidad en la transmisión de datos por el bus y otra el número de operaciones y ciclos de reloj que vamos a utilizar. Si en una operación procesas 32 bits de una vez siempre será mas rápido que 4 operaciones de 8 bits. Si la operación es de 8 bits o de 32 bits para el bus es lo mismo, pues tardará lo mismo en transmitir los datos, pero ya me contarás si notas la ventaja de operar con palabras largas cuando tengas que hacer operaciones con las mascaras.

radastan escribió:No, me niego en redondo. Eso puede ser ideal en algún juego donde prime la velocidad, pero perder un color me parece una salvajada teniendo en cuenta que ya hemos perdido 8 colores de paleta respecto a los ZX Spectrum.


No creo que sea un argumento. Raramente necesitarás usar en un Sprite los 8 colores, pero aún si así fuese, la ventaja en ahorro de memoria que supone destinar un color a la máscara es algo a considerar. Estudialo y ve si te compensa.

Por cierto, si no recuerdo mal, el Super Sprite Generator hace esto mismo.
Sinclair QL, la respuesta profesional de los 80

Avatar de Usuario
radastan
Phantomas
Mensajes: 2232
Registrado: Lun May 07, 2007 5:34 pm
Contactar:

Re: Memoria gráfica y sprites

Mensaje por radastan » Dom Mar 30, 2008 10:52 am

badaman escribió:
radastan escribió:No hace falta que me lo jures, se perfectamente que el 68000 trabaja en 32 bits de forma interna, pero por desgracia el QL usa la versión 68008 que tiene un bus de 8 bits de datos y habría que estudiar que es lo que verdaderamente es más rápido.


No confundamos conceptos. Una cosa es la capacidad y/o velocidad en la transmisión de datos por el bus y otra el número de operaciones y ciclos de reloj que vamos a utilizar. Si en una operación procesas 32 bits de una vez siempre será mas rápido que 4 operaciones de 8 bits. Si la operación es de 8 bits o de 32 bits para el bus es lo mismo, pues tardará lo mismo en transmitir los datos, pero ya me contarás si notas la ventaja de operar con palabras largas cuando tengas que hacer operaciones con las mascaras.


Si y no, depende del procesador/microcontrolador, y no es lo mismo transmitir 32 bits en un bus de 32 bits que en un bus de 8 bits. Si la arquitectura es inteligente, transmitir 32 bits en un bus de 8 debe ser más rápido que transmitir cuatro bloques de 8 bits, pero he visto casos en que no es así (generalmente microcontroladores).

De todas formas supondré que en QL no hay problema, mejor.

badaman escribió:
radastan escribió:No, me niego en redondo. Eso puede ser ideal en algún juego donde prime la velocidad, pero perder un color me parece una salvajada teniendo en cuenta que ya hemos perdido 8 colores de paleta respecto a los ZX Spectrum.


No creo que sea un argumento. Raramente necesitarás usar en un Sprite los 8 colores, pero aún si así fuese, la ventaja en ahorro de memoria que supone destinar un color a la máscara es algo a considerar. Estudialo y ve si te compensa.

Por cierto, si no recuerdo mal, el Super Sprite Generator hace esto mismo.


Tampoco vayas a creer que se debe ahorrar mucha memoria, la máscara es mucho menor en tamaño de bytes que el sprite, al fin y al cabo basta un bit por pixel para definir la máscara. Además, la rutina sin máscara es mucho más rápida y la podemos usar de forma genérica en juego con fondo y sin él.

Por favor, que hablamos de un QL, que el que quiere usar muchos gráficos puede exigir tranquilamente más memoria porque pocos usuarios de QL tienen el ordenador a secas sin expansión alguna. Además, el QL tiene 128K de memoria, por mucho que se pierda en el sistema nos sobra para hacer cosas realmente interesantes.
_________________________________________
Hay otras páginas.... pero no son Bytemaniacos
http://www.bytemaniacos.com
Orgullo de 8 bits
_________________________________________

Avatar de Usuario
badaman
Sabreman
Mensajes: 499
Registrado: Mar Ene 29, 2008 10:58 am
Contactar:

Re: Memoria gráfica y sprites

Mensaje por badaman » Lun Abr 07, 2008 2:25 pm

He estado mirando el Super Sprite Generator 2.0 y parece ser que sólo funciona bien en 128, o al menos no le va muy bien con la Gold Card instalada. Vete a saber si es cosa del TK2, del acceso a memoria de las rutunas, etc...

Ahora, como utilidad es más completa de lo que recordaba. Soporta también planes (Distintos planos), además de colisiones, volteo vertical y horizontal de los sprites, etc... y creo que trae un diseñador de Sprites.

Mira con Quill o Xchange los _doc que acompañan al programa por si te dan alguna idea para tu sistema de Sprites.

Si quieres ponerlo en marcha en QLay2, deberás modificar el código de al menos el BOOT, y los programas DEMO y DEMO2 para que donde pone "mdv1_" indique el trayecto donde esté ubicado el SSG, y decirle al emulador que tiene 128 Kb de memoria. Prueba a no cargar el TKII en el BOOT del emulador (con un REM es suficiente).
Sinclair QL, la respuesta profesional de los 80

Avatar de Usuario
radastan
Phantomas
Mensajes: 2232
Registrado: Lun May 07, 2007 5:34 pm
Contactar:

Re: Memoria gráfica y sprites

Mensaje por radastan » Lun Abr 07, 2008 5:53 pm

No, mi rutinas es mucho más simple: sólo dos funciones que lo hacen todo.

put_sprite

get_sprite


La primera pone un sprite en pantalla, y en los parámetros eliges si la máscara va integrada en el mismo sprite (definiendo un color de máscara) o a continuación (usaré el color de flash para indicar tal efecto).

La segunda es simple, introduce un sprite en pantalla y lo mete en memoria. Como verás es lo único que hace falta para poder mantener el fondo cuando movamos el sprite (primero coges lo que hay, dibujas encima, y luego repones el fondo). Además nos permite crear sprites de forma sencilla, basta coger cualquier programa de diseño y recoger zonas de pantalla para crear sprites, para por último grabar la memoria de sprites y ya tienes todo listo.

Creo que es la forma más sencilla, no tiene ningún misterio, y es lo que necesitas en el 99% de las veces.
_________________________________________
Hay otras páginas.... pero no son Bytemaniacos
http://www.bytemaniacos.com
Orgullo de 8 bits
_________________________________________

Avatar de Usuario
na_th_an
Nonamed
Mensajes: 1889
Registrado: Lun May 07, 2007 10:16 am
Ubicación: Andalucía

Re: Memoria gráfica y sprites

Mensaje por na_th_an » Lun Abr 07, 2008 6:14 pm

El problema será sincronizar todo eso bien para que no haya parpadeos. Lo suyo sería poder trabajar con buffers. ¿Es el procesador lo suficientemente rápido para poder hacer una copia de buffer a VRAM en tiempo razonable?

Avatar de Usuario
badaman
Sabreman
Mensajes: 499
Registrado: Mar Ene 29, 2008 10:58 am
Contactar:

Re: Memoria gráfica y sprites

Mensaje por badaman » Lun Abr 07, 2008 6:31 pm

na_th_an escribió:El problema será sincronizar todo eso bien para que no haya parpadeos. Lo suyo sería poder trabajar con buffers. ¿Es el procesador lo suficientemente rápido para poder hacer una copia de buffer a VRAM en tiempo razonable?


Desconozco lo que preguntas. ¿Podrías detallarlo un poco más a ver si puedo decirte algo?

Va por delante, si sirve de algo la aclaración, que la memoria de pantalla y cualquier otra zona de memoria que pueda utilizarse como memoria intermedia son el mismo tipo de memoria ubicadas simplemente en distintas posiciones de memoria.
Sinclair QL, la respuesta profesional de los 80

Avatar de Usuario
radastan
Phantomas
Mensajes: 2232
Registrado: Lun May 07, 2007 5:34 pm
Contactar:

Re: Memoria gráfica y sprites

Mensaje por radastan » Lun Abr 07, 2008 7:51 pm

na_th_an escribió:El problema será sincronizar todo eso bien para que no haya parpadeos. Lo suyo sería poder trabajar con buffers. ¿Es el procesador lo suficientemente rápido para poder hacer una copia de buffer a VRAM en tiempo razonable?


Hombre... de momento creo que tener esas rutinas ya suponen un gran avance, ahora tendría que investigar si es posible sincronizarse con la pantalla como en el ZX Spectrum.

Y respecto al buffer, si , el 68008 es lo suficientemente rápido para usar buffer de pantalla.
_________________________________________
Hay otras páginas.... pero no son Bytemaniacos
http://www.bytemaniacos.com
Orgullo de 8 bits
_________________________________________

Avatar de Usuario
na_th_an
Nonamed
Mensajes: 1889
Registrado: Lun May 07, 2007 10:16 am
Ubicación: Andalucía

Re: Memoria gráfica y sprites

Mensaje por na_th_an » Mar Abr 08, 2008 9:08 am

radastan escribió:
na_th_an escribió:El problema será sincronizar todo eso bien para que no haya parpadeos. Lo suyo sería poder trabajar con buffers. ¿Es el procesador lo suficientemente rápido para poder hacer una copia de buffer a VRAM en tiempo razonable?


Hombre... de momento creo que tener esas rutinas ya suponen un gran avance, ahora tendría que investigar si es posible sincronizarse con la pantalla como en el ZX Spectrum.

Y respecto al buffer, si , el 68008 es lo suficientemente rápido para usar buffer de pantalla.


Perfecto, pues. Lo suyo sería eso, precísamente: que GET y PUT actuasen sobre un buffer y luego poder implementar un dirty rectangles o algo así.

Avatar de Usuario
radastan
Phantomas
Mensajes: 2232
Registrado: Lun May 07, 2007 5:34 pm
Contactar:

Re: Memoria gráfica y sprites

Mensaje por radastan » Mar Abr 08, 2008 11:28 am

na_th_an escribió:
radastan escribió:
na_th_an escribió:El problema será sincronizar todo eso bien para que no haya parpadeos. Lo suyo sería poder trabajar con buffers. ¿Es el procesador lo suficientemente rápido para poder hacer una copia de buffer a VRAM en tiempo razonable?


Hombre... de momento creo que tener esas rutinas ya suponen un gran avance, ahora tendría que investigar si es posible sincronizarse con la pantalla como en el ZX Spectrum.

Y respecto al buffer, si , el 68008 es lo suficientemente rápido para usar buffer de pantalla.


Perfecto, pues. Lo suyo sería eso, precísamente: que GET y PUT actuasen sobre un buffer y luego poder implementar un dirty rectangles o algo así.


Si, sería lo suyo, pero ocuparíamos mucha más memoria que desde Super BASIC no es precisamente sobrada.

Eso estaría genial desde ensamblador, pero no desde Super BASIC.
_________________________________________
Hay otras páginas.... pero no son Bytemaniacos
http://www.bytemaniacos.com
Orgullo de 8 bits
_________________________________________

Avatar de Usuario
na_th_an
Nonamed
Mensajes: 1889
Registrado: Lun May 07, 2007 10:16 am
Ubicación: Andalucía

Re: Memoria gráfica y sprites

Mensaje por na_th_an » Mar Abr 08, 2008 12:43 pm

radastan escribió:
na_th_an escribió:
radastan escribió:Perfecto, pues. Lo suyo sería eso, precísamente: que GET y PUT actuasen sobre un buffer y luego poder implementar un dirty rectangles o algo así.


Si, sería lo suyo, pero ocuparíamos mucha más memoria que desde Super BASIC no es precisamente sobrada.

Eso estaría genial desde ensamblador, pero no desde Super BASIC.


Ocuparía mucha memoria, eso sí. ¿No hay posibilidad de tomar memoria "de fuera" de Super BASIC desde Super BASIC? Algo así como lo que podía hacerse con QBasic (el intérprete, no el compilador QuickBASIC), en el que podía llamarse directamente al sistema operativo y reservar memoria "externa" al entorno que te creaba el intérprete.

Aun así, siempre podría tomarse un buffer más pequeño que la pantalla. Según creo tenemos 4 bits por pixel. Tomar media pantalla por ejemplo sería tomar 256x128 píxels lo que ocuparía 16K.

Avatar de Usuario
radastan
Phantomas
Mensajes: 2232
Registrado: Lun May 07, 2007 5:34 pm
Contactar:

Re: Memoria gráfica y sprites

Mensaje por radastan » Mar Abr 08, 2008 12:54 pm

No, si el QL gestiona toda la memoria desde Super BASIC, pero es que en cuanto cargas algunas cosas no queda mucho en 128K. Evidentemente, si usamos más memoria pensando en que el usuario tiene una expansión no hay problema, pero es mejro que nos ciñamos a un QL estándar para empezar.

Y otra cuestión, ¿usar buffer desde BASIC? ¿es práctico? lo digo porque lo lento no van a ser las rutinas de vídeo, y no creo que alguien se ponga a hacer scroll o barbaridades semejantes desde BASIC manejando decenas de enemigos.

Lo dicho, primero las rutinas fáciles, y el que quiera más modernismos siempre tiene el Sprite pack o como se llame que nos recomendó Badaman y hace todo este tipo de cosas. Yo prefiero ir a lo sencillo y que realmente ponga en bandeja hacer juegos decentes sin mucho esfuerzo.
_________________________________________
Hay otras páginas.... pero no son Bytemaniacos
http://www.bytemaniacos.com
Orgullo de 8 bits
_________________________________________

Responder

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 9 invitados