User Tag List

Página 3 de 3 PrimerPrimer 123
Resultados 31 al 39 de 39

Tema: Space Invaders for ZX Spectrum (By SplinterGU)

  1. #31

    Fecha de ingreso
    Jul 2009
    Mensajes
    8,679
    Mencionado
    62 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    845
    Agradecer Thanks Received 
    493
    Thanked in
    Agradecido 318 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por swapd0 Ver mensaje
    Le he echado un vistazo rápido por encima y creo que nunca me acostumbrare al ensamblador del Z80, se me hace muy raro/dificil de leer, no sé si es porque los registros van con letras o por los nemónicos de las instrucciones. Aunque viniendo del 68000 se entiende en parte porque es un procesador muy fácil de programar en ensamblador.
    muchas gracias por los comentarios, tambien he dejado todas las viejas funciones en C, comentadas, pero reemplazan las de asm... asi que cualquiera con ganas, puede facilmente pasarlo a otras plataformas directamente en C (con las minimas modificaciones pertinentes)...
    ...

  2. #32

    Fecha de ingreso
    Jun 2021
    Mensajes
    5
    Mencionado
    0 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    0
    Agradecer Thanks Received 
    1
    Thanked in
    Agradecido 1 vez en 1 post
    Muy bueno!

  3. #33

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    3,006
    Mencionado
    89 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    223
    Agradecer Thanks Received 
    663
    Thanked in
    Agradecido 351 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por swapd0 Ver mensaje
    Le he echado un vistazo rápido por encima y creo que nunca me acostumbrare al ensamblador del Z80, se me hace muy raro/dificil de leer, no sé si es porque los registros van con letras o por los nemónicos de las instrucciones. Aunque viniendo del 68000 se entiende en parte porque es un procesador muy fácil de programar en ensamblador.
    Pues con el ensamblador del 68000 cometí algunos errores, al interpretar cómo funcionaban algunas instrucciones, que provocaban unos buenos bombacos en el STE

    Ahora, ¿el ensamblador generaba código máquina incorrecto? Porque eran instrucciones que no podían hacer lo que pretendía hacer con ellas, y el muy ***** no decía nada al generar el ejecutable xD

    Y sí, el ensamblador del 68000 es amigable, aunque también depende de lo que quieras hacer; porque para orquestar la partitura que gestiona los loops que componen la música, son todo .wavs, fué mucho más simple hacerlo con una sencilla función en C con un switch y algunos if-else dentro, que hacerlo en ensamblador... de hecho en ensamblador, el comprobar si había terminado de reproducirse tantas veces un loop, y si tenía que saltar a tal posición de la partitura y reemplazar ese canal... se empezó a volver un laberinto.

    Tampoco me quiero imaginar el infierno horroroso que tiene que ser gestionar una lista de entidades, los sprites por ejemplo; saber quienes están marcados para seguir ejecutando su función de dibujado, de IA y de colisión. A quienes hay que eliminar, liberar su estructura de datos y marcarla como libre para otra posible entidad... quién se tiene que dibujar por encima de cualquier otro...

    Esa gestión en las AGT, la vez que le eché un vistazo, está escrita en C.

  4. #34

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    6,128
    Mencionado
    37 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,012
    Agradecer Thanks Received 
    1,066
    Thanked in
    Agradecido 749 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por masteries Ver mensaje
    Pues con el ensamblador del 68000 cometí algunos errores, al interpretar cómo funcionaban algunas instrucciones, que provocaban unos buenos bombacos en el STE

    Ahora, ¿el ensamblador generaba código máquina incorrecto? Porque eran instrucciones que no podían hacer lo que pretendía hacer con ellas, y el muy ***** no decía nada al generar el ejecutable xD
    No creo que sea culpa del ensamblador, pero ten en cuenta que si accedes a una dirección impar como .w o .l tendrás un address error. Y si accedes a los registros hardware o vectores de interrupción sin estar en modo supervisor tendrás un bus error.

    -----Actualizado-----

    Ahora importa poco porque lo normal es que ensambles en PC y después pruebes las cosas en un emulador, pero programar en el 68000 es muchísimo mas fácil que en cualquier procesador de 8 bits, si intentas hacer algo ilegal o haces un salto mal a una zona donde no hay código te saltara alguna excepción, en un z80 o 6502 sigue para adelante hasta que se cuelga la maquina, por lo que te costara mas encontrar el error.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  5. #35

    Fecha de ingreso
    Jul 2009
    Mensajes
    8,679
    Mencionado
    62 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    845
    Agradecer Thanks Received 
    493
    Thanked in
    Agradecido 318 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por masteries Ver mensaje
    Pues con el ensamblador del 68000 cometí algunos errores, al interpretar cómo funcionaban algunas instrucciones, que provocaban unos buenos bombacos en el STE

    Ahora, ¿el ensamblador generaba código máquina incorrecto? Porque eran instrucciones que no podían hacer lo que pretendía hacer con ellas, y el muy ***** no decía nada al generar el ejecutable xD

    Y sí, el ensamblador del 68000 es amigable, aunque también depende de lo que quieras hacer; porque para orquestar la partitura que gestiona los loops que componen la música, son todo .wavs, fué mucho más simple hacerlo con una sencilla función en C con un switch y algunos if-else dentro, que hacerlo en ensamblador... de hecho en ensamblador, el comprobar si había terminado de reproducirse tantas veces un loop, y si tenía que saltar a tal posición de la partitura y reemplazar ese canal... se empezó a volver un laberinto.

    Tampoco me quiero imaginar el infierno horroroso que tiene que ser gestionar una lista de entidades, los sprites por ejemplo; saber quienes están marcados para seguir ejecutando su función de dibujado, de IA y de colisión. A quienes hay que eliminar, liberar su estructura de datos y marcarla como libre para otra posible entidad... quién se tiene que dibujar por encima de cualquier otro...

    Esa gestión en las AGT, la vez que le eché un vistazo, está escrita en C.
    juraria recordar que habias hecho cosas en ensamblador...

    sin dudas C es mas facil... pero es cuestion de practica, yo hacia muchisimos años que no tocaba asm... bah, incluso hacia un tanto que no programaba nada... y hasta me costo unos minutos cosas como un puntero para acceder a cierta zona de la memoria... bah, no es que no lo hice, sino que lo hice muy rebuscado...
    ...

  6. #36

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    3,006
    Mencionado
    89 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    223
    Agradecer Thanks Received 
    663
    Thanked in
    Agradecido 351 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por SplinterGU Ver mensaje
    juraria recordar que habias hecho cosas en ensamblador...

    sin dudas C es mas facil... pero es cuestion de practica, yo hacia muchisimos años que no tocaba asm... bah, incluso hacia un tanto que no programaba nada... y hasta me costo unos minutos cosas como un puntero para acceder a cierta zona de la memoria... bah, no es que no lo hice, sino que lo hice muy rebuscado...
    Si, y las he hecho, y funcionando están... ¡y tan contento y orgulloso de ello!

    Pero algunas otras que he intentado (alguna cosilla con una ejecución muy condicional y con alguna realimentación por en medio), se terminaban volviendo muy farragosas en ensamblador, y en cambio en C con unas pocas líneas quedaba más elegante, legible y práctico. Por eso me dí cuenta, que depende de lo que vayas a hacer, puede ser más interesante o práctico el ensamblador o el C.

  7. El siguiente usuario agradece a masteries este mensaje:

    SplinterGU (27/06/2021)

  8. #37

    Fecha de ingreso
    Jul 2009
    Mensajes
    8,679
    Mencionado
    62 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    845
    Agradecer Thanks Received 
    493
    Thanked in
    Agradecido 318 veces en [ARG:2 UNDEFINED] posts
    ya me parecia que tan loco no podia estar...

    si, sin dudas C es mas facil, por eso empece el juego en C, y fui luego pasando a ASM por cuestiones de velocidad y espacio, donde el compilador/optimizador de C no hacia tan buen trabajo... de hecho no hace buen trabajo, mete demasiado codigo extra ASM innecesario... y ahi es donde tuve que meter mano para hacer el port a zx81 (y tambien lograr mejora en zx spectrum)
    ...

  9. #38

    Fecha de ingreso
    Mar 2004
    Ubicación
    Lleida
    Mensajes
    3,150
    Mencionado
    32 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    142
    Agradecer Thanks Received 
    1,045
    Thanked in
    Agradecido 479 veces en [ARG:2 UNDEFINED] posts
    Entradas de blog
    2
    Oye, pues si os aburrís, le podríais meter mano al Nba Jam de recreativa, jeje

    GitHub - historicalsource/nba-jam: A fast-paced basketball game

  10. #39

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    6,128
    Mencionado
    37 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,012
    Agradecer Thanks Received 
    1,066
    Thanked in
    Agradecido 749 veces en [ARG:2 UNDEFINED] posts
    Lo malo es la CPU, pero si se coge el código fuente de alguna recreativa que use un z80 o 68000... eso si, también debe incluir los gráficos y sonidos.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

Página 3 de 3 PrimerPrimer 123

Permisos de publicación

  • No puedes crear nuevos temas
  • No puedes responder temas
  • No puedes subir archivos adjuntos
  • No puedes editar tus mensajes
  •