Phantomas Saga: Infinity (CEZ Team/ESP/Karoshi) - Sp/Ams/MSX

[Randomize]

Me he quedado flipado con Infinity... pero flipado, FLIPADISIMO. ¡Cómo me gustaría que la gente se animara y sacase continuaciones de juegos en spectrum & amstrad!
Por mi parte estoy "olfateando" z88dk y tengo una duda:
¿Dónde dibujas los sprites? ¿hay algún programa de dibujo que te lo traduzca a esto?:

Código: Seleccionar todo

._sprite1
defb @00111100, @11000011
defb @01000010, @10000001
defb @10000001, @00000000
defb @10100101, @00000000
defb @10000001, @00000000
defb @10011001, @00000000
defb @01011010, @10000001
defb @00111100, @11011011

Nuevamente, enhorabuena. Ya espero con impaciencia "otro hijo tuyo".

S2.

[zyloj]

Prueba ahora.

Muchísimas gracias.

Saludos

[Karnevi]

Prueba ahora.

Muchísimas gracias.

Saludos

No hay de qué.

La verdad es que podríamos meter en los zips las versiones cinta y disco de los juegos. No supone ningún trabajo especial y os beneficia a los usuarios. Creo que lo empezaremos a hacer a partir de ahora.

[Randomize]

¿Dónde dibujas los sprites? ¿hay algún programa de dibujo que te lo traduzca a esto?:

Código: Seleccionar todo

._sprite1
defb @00111100, @11000011
defb @01000010, @10000001
defb @10000001, @00000000
defb @10100101, @00000000
defb @10000001, @00000000
defb @10011001, @00000000
defb @01011010, @10000001
defb @00111100, @11011011

S2.

Bueno he encontrado algo:
SevenuP

El problema es que te lo exporte lo mas parecido al código que he puesto.


S2.

[Konamito]

La verdad es que podríamos meter en los zips las versiones cinta y disco de los juegos. No supone ningún trabajo especial y os beneficia a los usuarios. Creo que lo empezaremos a hacer a partir de ahora.

Me parece una iniciativa fantástica. Que el usuario final elija qué formato desea usar

[na_th_an]

Me he quedado flipado con Infinity... pero flipado, FLIPADISIMO. ¡Cómo me gustaría que la gente se animara y sacase continuaciones de juegos en spectrum & amstrad!
Por mi parte estoy "olfateando" z88dk y tengo una duda:
¿Dónde dibujas los sprites? ¿hay algún programa de dibujo que te lo traduzca a esto?:

Código: Seleccionar todo

._sprite1
defb @00111100, @11000011
defb @01000010, @10000001
defb @10000001, @00000000
defb @10100101, @00000000
defb @10000001, @00000000
defb @10011001, @00000000
defb @01011010, @10000001
defb @00111100, @11011011

Nuevamente, enhorabuena. Ya espero con impaciencia "otro hijo tuyo".

S2.

SevenUP es lo más parecido, pero no. Mucho me temo que ahora mismo no hay nada, que yo sepa.

Yo lo que hago es dibujar todos mis gráficos en un programa de gráficos (Adobe Photoshop en mi caso), lo exporto en RAW o algún otro formato gráfico facilito, y luego me hago un script en cualquier lenguaje que lea ese archivo y genere el código automáticamente.

Otra cosa que puedes hacer es usar el SevenUp y reordenar la salida que te saca. Creo que te saca sprite y máscara por separado. Lo que puedes hacer es armarte de paciencia y ordenar los numeritos correctamente.

El SevenUp genera código para la biblioteca estándar de z88dk. Estaría bien hablar con su autor para que, haciendo un par de cambios, lograse que el progarma también generase código para z88dk. No debe ser mucho cambio, ya que la única diferencia así más gorda es el orden con el que salen los datos

Me alegro que te guste el juego. Pronto más.

[WYZ]

Prontomas?

[na_th_an]

[Alx]

Nathan macho, estas hecho una máquina o yo soy un analfabeto pufff....

[Ivanzx]

Me alegro que te guste el juego. Pronto más.

Como cuanto de pronto??

[Metalbrain]

Otra cosa que puedes hacer es usar el SevenUp y reordenar la salida que te saca. Creo que te saca sprite y máscara por separado. Lo que puedes hacer es armarte de paciencia y ordenar los numeritos correctamente.

El SevenUp genera código para la biblioteca estándar de z88dk. Estaría bien hablar con su autor para que, haciendo un par de cambios, lograse que el progarma también generase código para z88dk. No debe ser mucho cambio, ya que la única diferencia así más gorda es el orden con el que salen los datos

El autor soy yo, así que pide lo que te haga falta, sin problemas. Hace un par de semanas corregí algunos bugs, así que tengo pendiente sacar una nueva versión dentro de poco.

Código para Z88DK ya saca, ya que el código en C se debería poder usar directamente y la salida de ensamblador genérica funciona con el Z80ASM.

Ten en cuenta que el programa ya es bastante flexible de por sí a la hora de sacar los datos, y para entrelazar los bytes de sprite y máscara basta con subir "Mask" a la posición más alta del "Byte Sort Priority", y si prefieres que la máscara vaya antes, marcas la casilla "Mask Before Graphic".

Por si acaso no entiendes la descripción que hay ahora mismo en las instrucciones sobre como funciona la ordenación, te pongo lo que le conté a Santiago Romero hace poco por mail:

-----
· Char line itera de 0 a 7 (o a 8 si se selecciona atributo como 9º caracter, y no estamos en la máscara)
· X Char itera de 0 a (Anchura en caracteres-1)
· Y Char itera de 0 a (Altura en caracteres-1)
· Mask itera de 0 a 1 (o de 1 a 0, dependiendo de si está marcada la casilla de "Mask Before Graph") cuando existe máscara.
· Frames itera de 0 a (número de frames-1)

En cuanto al orden de iteraciones, mientras más arriba está la característica, más interno es el bucle, por lo que cambia antes. Supongo que puedes pensar en ello como una cadena de for(s) en orden al revés al que se presentan las opciones.
-----

PD: El nombre acaba en "uP", no "Up".

[na_th_an]

Perfecto, le echaré un vistazo. El splib2 necesita los sprites por columnas. La ordenación en "for"s sería la siguiente:

Código: Seleccionar todo

for i = 0 to numColumnas
   for j = 0 to numFilas
      for y = 0 to 7
         byte de sprite
         byte de máscara
      next
   next
next

Con esas indicaciones, intentaré configurar la salida de SevenuP para que pueda ser utilizada para generar código z88dk.

Para ordenar los sprites entrelazados (lo que hago es almacenar bytes de sprites donde deberían estar bytes de máscara) me parece que también va a ser posible. Me pondré a ello y os comentaré.

Gracias.

[Randomize]

El autor soy yo, así que pide lo que te haga falta, sin problemas. Hace un par de semanas corregí algunos bugs, así que tengo pendiente sacar una nueva versión dentro de poco.

Hola Metalbrain.
Menudo golpe de suerte tenerte aquí, la verdad.

He estado intentandolo una y otra vez y no consigo exportar el código exactamente como me pide z88dk:
-No salen las "@".
-Y tampoco los "defb" si exportas en binario.
No se si esto es normal.
La verdad es que si pudiera despreocuparme totalmente de este tedioso tema gráfico me quitaria un gran peso de encima porque soy bastante torpe en programación.


S2.

[Alcoholics Anonymous]

Este texto se ha pasado a través del traductor de Google. Hace mi sonido inglés como cerdo-Español. Apesadumbrado.

Puedo confirmar que SevenuP puede generar las definiciones del sprite compatibles con z88dk y splib2. Pero no puede interpolar dos definiciones de los sprite por lo que sé.

Para Metalbrain:

La versión siguiente del splib introducirá máscaras de la cualidad. Se almacenan los colores de Sprite mientras que la máscara de la cualidad + la cualidad se aparea en un arsenal en orden fila-principal. Es probablemente un dolor para agregar esto a SevenuP y no es demasiado difícil agregar las máscaras a mano, pero pensé lo mencionaría puesto que se parece que usted ahora está revisitando SevenuP.

PD: El nombre acaba en "uP", no "Up".

que nunca terminará. En el lado brillante, usted ahora me tiene deletreo él correctamente.

[Randomize]

Bueno, parte de lo que comenté antes (lo del "@" y los binarios) fue una tontería ya que me obsesioné con ver el código como yo quería mas que en probarlo en el z88dk. De hecho, ayer noche estuve probando intensamente SevenuP y concluí que:
Puedes exportar perfectamente a z88dk un solo sprite de 8x8 píxeles (1 cursor) pero cuando superas esa cifra 2x2, por ejemplo (splib2 solo trabaja con multiplos de 8 tanto en x como en y a la hora de crear gráficos) no veo combinación posible (ni ordenando la salida con byte sort priority) para que, finalmente, z88dk lo represente directamente en pantalla.
Creo que esto es lo que trata de decir tanto nuestro invitado extranjero como na_th_an.
En cualquier, caso corrige si estamos equivocados en la forma de hacerlo.



S2.

[Metalbrain]

Código: Seleccionar todo

for i = 0 to numColumnas 
   for j = 0 to numFilas 
      for y = 0 to 7 
         byte de sprite 
         byte de máscara 
      next 
   next 
next

El orden para esto sería:

Mask
Char Line
Y Char
X Char
Frame Number

-No salen las "@".
-Y tampoco los "defb" si exportas en binario.

Es que no le he puesto salida en ensamblador con formato binario porque no lo consideré importante, por defecto se usa decimal y si quieres también puedes sacar los datos en formato hexadecimal. La exportación binaria es en crudo, los bytes directamente en lugar de código.

Pero no puede interpolar dos definiciones de los sprite por lo que sé.

What do you mean by two sprite definitions? Two different sprites?

La versión siguiente del splib introducirá máscaras de la cualidad. Se almacenan los colores de Sprite mientras que la máscara de la cualidad + la cualidad se aparea en un arsenal en orden fila-principal. Es probablemente un dolor para agregar esto a SevenuP y no es demasiado difícil agregar las máscaras a mano, pero pensé lo mencionaría puesto que se parece que usted ahora está revisitando SevenuP.

I didn't get that, could you please put it in english?
Is it related to what bobs asked for here:
http://www.worldofspectrum.org/forums/v ... 9&forum=11
, or do you mean putting the attributes first?

Puedes exportar perfectamente a z88dk un solo sprite de 8x8 píxeles (1 cursor) pero cuando superas esa cifra 2x2, por ejemplo (splib2 solo trabaja con multiplos de 8 tanto en x como en y a la hora de crear gráficos) no veo convinación posible (ni ordenando la salida con byte sort priority) para que, finalmente, z88dk lo represente directamente en pantalla.

¿A que te refieres con que z88dk lo represente directamente en pantalla? ¿Usando qué funciones? (Al final me da que lo voy a tener que instalar y todo...)

[Randomize]

El orden para esto sería:
Mask
Char Line
Y Char
X Char
Frame Number

¿A que te refieres con que z88dk lo represente directamente en pantalla? ¿Usando qué funciones? (Al final me da que lo voy a tener que instalar y todo...)

¡ESA ES LA COMBINACION!
¡FUNCIONA!... al menos con 16x16px. Seguiré probando.
¡Gracias!
En cualquier caso -y que na_th_an me corrija si no es así en la última versión del z88dk- para poder desplazar un sprite (compuesto de mas de 1 cursor) es necesario introducir 1 cursor extra completamente vacio en cada array. Un ejemplo de esto extraido del tutorial Magazine ZX es:

Código: Seleccionar todo

//Primer cursor vacio. Ignoro si este hay que repetirlo si creamos otro sprite compuesto como lo es "bicho"
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111

//Comienza la creación de bicho
._bicho1
defb @00000011, @11111100
defb @00000100, @11111000
defb @00001000, @11110000
defb @00001011, @11110000
defb @00001011, @11110000
defb @00001000, @11110000
defb @00001000, @11110000
defb @00000100, @11111000

defb @00000011, @11111100
defb @00001100, @11110011
defb @00001100, @11110011
defb @00011000, @11100111
defb @00011000, @11100111
defb @01111100, @10000011
defb @01111100, @10000011
defb @00000000, @11111111

//Ahora metemos un cursor VACIO
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111

._bicho2
defb @11100000, @00011111
defb @00010000, @00001111
defb @00001000, @00000111
defb @01101000, @00000111
defb @01101000, @00000111
defb @00001000, @00000111
defb @10001000, @00000111
defb @10010000, @00001111

defb @11100000, @00011111
defb @00011000, @11100111
defb @00011000, @11100111
defb @00001100, @11110011
defb @00001100, @11110011
defb @00111110, @11000001
defb @00111110, @11000001
defb @00000000, @11111111

//Ahora metemos otro cursor VACIO
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111

//Y el sgte. COMPLETAMENTE VACIO
._bicho3
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111

defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111

defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111
defb @00000000, @11111111

Me parece una forma de "marear al personal" la manera de hacerlo así pero se ve que no ha encontrado mejor solución el programador de la splib2.
Claro, si actualmente sigue siendo necesario hacerlo así para poder mover correctamente nuestro "sprite compuesto" ¿sería mucho pedir que el código del gráfico que exportamos en SevenuP saliese con los VACIOS EXTRA?. ¿O sería mas aconsejable que los metamos nosotros a mano porque sino nos complicaría mas el tema?



Respecto a que lo represente directamente en pantalla, olvídalo, me refería a que el código que genera SevenuP funcione en z88dk solo que no me he explicado bien.


S2.

[Alcoholics Anonymous]

But cannot interpolate two definitions of sprite reason why I know.

What do you pisses by two sprite definitions? Two different sprites?

Yes, two different sprites. The problem is that splib2 defines all sprites with (graphics,mask) pairs, even sprites that are OR/XOR/LOAD type. It was done this way so that a single sprite graphic definition could be shared for different sprite types. These latter types have no use for the mask and the mask byte is in fact ignored when drawing them. As a memory saving technique, the definitions of two different sprites can be interleaved so that the graphics of sprite #2 sits in the mask bytes of sprite #1. Nathan has done this in Infinity, where all sprites are OR type, so the definitions of two different sprites are interleaved.

I am not too sure how important this is to support. I will tell you that the next version of splib (almost finished) will support 1-byte sprite definitions (graphics only) and 2-byte sprite definitions (mask,graph pairs) so this interleaving of two sprites will no longer be necessary to save space.

I didn't get that, could you please put it in english? For Is it related to what bobs asked here: http://www.worldofspectrum.org/forums/v ... 9&forum=11, or do you pisses putting the attributes first?

Randomize misunderstood me -- SevenuP as it is now can create sprites compatible with z88dk and splib2 just fine. I have used it myself He just needs to get the byte ordering correct. If the output format is not posted soon I will add it to this thread when I have some time tomorrow to try things out.

The next version of splib will introduce attribute masks to help out with the colour clash problem. A sprite's colours will be stored as (attribute mask, attribute) pairs in row-major order. None of the graphics tools have any concept of an attribute mask as far as I can tell. As I tried to explain above, this might be a pain to add and honestly it isn't difficult to add attribute masks by hand to a list of attributes.

[Randomize]

No entiendo el problema que tiene el invitado (mi inglés no alcanza). Solo entiendo eso que dice sobre que si puede exportarse correctamente un "sprite compuesto" pero habla de ¿un problema a la hora de exportar la mascara?
¿Alguien me podría traducir por encima?


S2.

[Alcoholics Anonymous]

Me parece una forma de "marear al personal" la manera de hacerlo así pero se ve que no ha encontrado mejor solución el programador de la splib2.
Claro, si actualmente sigue siendo necesario hacerlo así para poder mover correctamente nuestro "sprite compuesto" ¿sería mucho pedir que el código del gráfico que exportamos en SevenuP saliese con los VACIOS EXTRA?. ¿O sería mas aconsejable que los metamos nosotros a mano porque sino nos complicaría mas el tema?

I apologize for the English again I don't want to pollute this board with a bunch of English messages so I promise I will go back to lurking after this message

The extra space can be added simply by declaring a larger size in SevenuP. Add 8 pixels to the X size and 8 pixles to the Y size, leaving the last column and the last row blank when you draw the sprite.

As for why this is necessary, I don't think I have ever expained it plainly anywhere so I will do it here this one time. The splib2 engine is character oriented; making it character oriented allows it to act like a "differential updater" (only drawing things that change) and allows it to draw to the screen without flicker *and* without having to synchronize with the raster. The latter is a unique feature that makes it particularly well suited for use with a higher level language like C.

By declaring a sprite a certain size, for example 2x2 characters, you are telling splib2 to draw a sprite 2 characters wide and 2 characters tall. This is fine if you only draw the sprite to exact character coordinates. But if you try to move the sprite to the right, by say 3 pixels, the splib2 engine will rotate the graphics in the 2x2 array of characters to the right 3 pixels. The last 3 pixels in any horizontal row will by chopped off by this operation. By declaring the sprite to be 3 characters wide instead, those 3 final pixels in any horizontal row will be drawn as the leftmost 3 pixels in this last column.

When a sprite is drawn a fraction of a pixel downward in a character (say 5 pixels), the graphics pointers in the sprite are actually moved backward by 2*5 bytes. In your example, the engine will change the pointer _bicho1 to _bicho1-10 and _bicho2 to _bicho2-10, etc. When the sprite is drawn it will appear to move downward by 5 pixels. The change of _bicho1 to _bicho1-10 in this example should make it clear why there needs to be 7 blank pixle rows above _bicho1 in the definition.

You will also notice that if the graphics pointers are moved upward in memory, the graphics in the bottom row of the sprite will not be drawn, being clipped off. This is why the sprite must be declared to be an extra character tall - so that those clipped pixels at the bottom of the sprite are always drawn.

The next version of splib will make this all much cleaner and much more memory friendly. I have read Siew's first article on splib in Magazine ZX and found it to be excellent. I just feel badly that things will be changing shortly so that he will have to go back and yet again explain how sprites are defined

[Metalbrain]

No entiendo el problema que tiene el invitado (mi inglés no alcanza). Solo entiendo eso que dice sobre que si puede exportarse correctamente un "sprite compuesto" pero habla de ¿un problema a la hora de exportar la mascara?
¿Alguien me podría traducir por encima?

Básicamente dice que no hay soporte para mezclar dos sprites distintos metiendo el segundo en el lugar de la máscara del primero, que es lo que hace na_th_an en Infinity para ganar memoria, ya que todos los sprites en splib2 se almacenan con máscara aunque no la usen.

Y luego comenta que la nueva versión de splib tendrá posibilidad de almacenar los sprites también sin máscara, y que se introducirá una máscara para los atributos.

The next version of splib will introduce attribute masks to help out with the colour clash problem. A sprite's colours will be stored as (attribute mask, attribute) pairs in row-major order. None of the graphics tools have any concept of an attribute mask as far as I can tell. As I tried to explain above, this might be a pain to add and honestly it isn't difficult to add attribute masks by hand to a list of attributes.

Ok, I understand. Adding the extra byte to the output won't be too difficult, but honestly I don't know how to work with it in the editor. Maybe I'll just add an output option to add a fixed value for the whole sprite in that attribute mask. Would that suffice?

En español: Aquí estamos discutiendo sobre el asunto de la nueva "máscara de atributos".

[Randomize]

Se agradece la traducción Metalbrain.
Bueno, todavia no me he topado con el problema que comentais aunque ya estoy sobre aviso. Tal vez cuando llegue ya esté solucionado con una nueva version, como dices.

Por el momento soy feliz pudiendo ver mis gráficos de cualquier tamaño que le indico (el ultimo que he realizado de 4x4 cursores) sin ningún problema en el emulador, que no es poco.


S2.

[Metalbrain]

Se agradece la traducción Metalbrain.
Por el momento soy feliz pudiendo ver mis gráficos de cualquier tamaño que le indico (el ultimo que he realizado de 4x4 cursores) sin ningún problema en el emulador, que no es poco.

Tan solo he traducido la primera parte, ya leeré y traduciré lo que haga falta del último mensaje tocho en casa... Por cierto, cuando dices "cursores" supongo que te refieres a "caracteres", ¿no?

[Randomize]

Por cierto, cuando dices "cursores" supongo que te refieres a "caracteres", ¿no?

Sí, exacto. Caracteres de 8x8 px.
Y ya puestos cuando hablamos de "sprites" nos referimos a lo mismo ¿no?, es decir a una composicion de uno varios caracteres que forman el dibujillo.

Otra cosa:
Acabo de comprobar que se tiene que seguir añadiendo (tambien en la ultima version -SritePack 2.2-) esos caracteres vacios de los que hablaba en un mensaje anterior para poder ver un movimiento correcto del sprite. Estaría bien que pudieses exportar todo esto con el SevenuP.





S2.

[Metalbrain]

I apologize [...]

Traducción:

Lamento usar de nuevo el inglés. No quiero contaminar este foro con un montón de mensajes en inglés, así que prometo que volveré al lurking tras este mensaje.

El espacio extra se puede añadir simplemente declarando un tamaño mayor en SevenuP. Suma 8 pixels al tamaño X y 8 pixels al tamaño Y, dejando la última columna y la última fila en blanco cuando dibujes el sprite.

Sobre el por qué es esto necesario, creo que no lo he explicado con claridad en ninguna parte, así que lo haré aquí. El motor de splib2 está orientado a caracter; hacerlo así le permite actuar como un "actualizador diferencial" (dibujando solo las cosas que cambian) y permite dibujar la pantalla sin parpadeos *y* sin tener que sincronizar con el raster. Esta última cualidad es única y lo hace particularmente apropiado para el uso con un lenguaje de alto nivel como el C.

Al declarar el tamaño de un sprite, por ejemplo 2x2 caracteres, le dices a splib2 que dibuje un sprite de 2 caracteres de ancho y 2 de alto. Esto está bien si solo dibujas el sprite en coordenadas exactas de caracteres. Pero si intentas mover el sprite a la derecha, digamos 3 pixels, el motor de splib2 rotará el gráfico en una matriz de 2x2 caracteres a la derecha 3 pixels. Los últimos 3 pixels de cada fila horizontal serán cortados por esta operación. Si en lugar de eso declaramos que el sprite sea de 3 caracteres de ancho, esos 3 pixels finales de cada fila horizontal serán dibujados como los 3 pixeles más a la izquierda en esta última columna.

Cuando un sprite se dibuja en una fracción de pixel más abajo en el caracter (digamos 5 pixels), los punteros gráficos del sprite se mueven hacia atrás 2*5 bytes. Por ejemplo, el motor cambiará el puntero _bicho1 a bicho1-10, y _bicho2 a _bicho2-10, etc... Cuando el sprite se dibuje aparecerá movido hacia abajo por 5 pixels. El cambio de _bicho1 a _bicho1-10 en este ejemplo debe dejar claro por qué se necesitan 7 líneas de pixels por encima de _bicho1 en la definición.

También te darás cuenta de que si los punteros gráficos se mueven hacia arriba en la memoria, los gráficos en las líneas inferiores del sprite no se dibujarán, quedando cortadas. Por eso el sprite debe ser declarado con un caracter extra de alto, para que esos pixels cortados en la parte de abajo del sprite siempre se dibujen.

La siguiente versión de splib hará todo esto de forma mucho más limpia y mucho más amigable con la memoria. He leído el primer artículo de Siew en Magazine ZX y lo encontré excelente. Me siento mal porque las cosas vayan a cambiar pronto de forma que va a tener que retroceder y volver a explicar una vez más como se definen los sprites.

Y ya puestos cuando hablamos de "sprites" nos referimos a lo mismo ¿no?, es decir a una composicion de uno varios caracteres que forman el dibujillo.

En este caso sí, aunque personalmente yo prefiero reservar la palabra "sprite" para los gráficos animados (o sea, de más de un frame), y usar la palabra "gráfico" para lo que aquí le hemos estado llamando sprite todo el rato.

Acabo de comprobar que se tiene que seguir añadiendo (tambien en la ultima version -SritePack 2.2-) esos caracteres vacios de los que hablaba en un mensaje anterior para poder ver un movimiento correcto del sprite. Estaría bien que pudieses exportar todo esto con el SevenuP.

Como ya ha dicho Alvin, puedes hacerlo definiendo el espacio extra al principio, y además pronto habrá versión nueva de la librería que no necesitará el espacio adicional, así que me parece un poco absurdo añadirle eso de los espacios a estas alturas.

EDIT: Corregidos fallos.

[na_th_an]

Pero no puede interpolar dos definiciones de los sprite por lo que sé.

What do you mean by two sprite definitions? Two different sprites?

He's talking about something you can do if you are not using the mask byte to save memory. It basicly consists on placing another sprite column instead of the mask, so instead of:

Código: Seleccionar todo

._sprite1
defb byte1-1, mask1-1
defb byte1-2, mask1-2
...
defb byte1-N, mask1-N

._sprite2
defb byte2-1, mask2-1
defb byte2-2, mask2-2
...
defb byte2-N, mask2-N

You can interlace in this way:

Código: Seleccionar todo

._sprite1
defb byte1-1
._sprite2
defb byte2-1
defb byte1-2
defb byte2-2
...
defb byte1-N
defb byte2-N
defb 0

I had to do it by hand with Infinity. Next time I'll write a script... And I'll share

[Randomize]

Mil gracias por la traducción Metalbrain me ha servido de muUcho.
Mmm... no se como tomarme esto:
"La siguiente versión de splib hará todo esto de forma mucho más limpia y mucho más amigable."

Espero que no cambie mucho "el percal" porque si lo hace me veo empollando antes "EnglishSpanish Dictionary pack 1.0"




S2.

[Alcoholics Anonymous]

Ok, I understand. Adding the extra byte to the output won't be too difficult, but honestly I don't know how to work with it in the editor. Maybe I'll just add an output option to add a fixed value for the whole sprite in that attribute mask. Would that suffice?

Yes I think that would work, thanks A default of zero will cause the sprite colours to overwrite the screen.

Espero que no cambie mucho "el percal" porque si lo hace me veo empollando antes "EnglishSpanish Dictionary pack 1.0"

Tengo "paquete 1,0 del diccionario de SpanishEnglish" y no es demasiado bueno.

Los cambios son incrementales -- si usted puede utilizar sprites con splib2 que usted podrá utilizar la versión siguiente sin demasiado apuro.

Muchos de los cambios son un resultado directo de mis conversaciones con Nathan y después de examinar los juegos de Nathan. Una de las metas de la versión siguiente era incorporar algunas de las aplicaciones en el motor sí mismo de Nathan de los trucos.

[na_th_an]

Thanks Alvin, you've brought new life to the scene We're aching for SPLIB3... An the two other libs, of course Specially the 64x48 full colour, as I mentioned at WOS.

[Alcoholics Anonymous]

Thanks Alvin, you've brought new life to the scene We're aching for SPLIB3... An the two other libs, of course Specially the 64x48 full colour, as I mentioned at WOS.

I will be trying to port splib3 to a couple of other platforms this time. Hopefully this will mean games that can be ported across a few platforms from a larger pool of developers. Then there will be a pleasant surprise I think, before the next sprite engine comes out. I have hope that these things and what cez does will generate some excitement