Mostrar Mensajes

Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.


Mensajes - Laddh

Páginas: 1 [2] 3 4 ... 16
16
Programación / Re:Colisiones sprite<>sprite por software
« en: Mayo 05, 2018, 12:57:39 »
Dashiad, el problema que yo me he encontrado no es que tenga que ver con la interrupción IRQ porque lo aplique sin interrupciones para probar, verificando el registro de colisiones a cada movimiento X,Y de los sprites y el resultado era el mismo, se comía muchas colisiones sin detectarlo, el contexto es los 8 sprites a la vez, naves, lasers, misiles..., como expliqué anteriormente me sorprendí porque esa misma rutina de colisiones había funcionado bien en proyectos anteriores.
Tal vez tenga que ver con lo que explica Scooter, el caso es que en búsquedas profundas por internet de este tema acabas leyendo comentarios de coders que efectivamente abogan por el método soft si quieres ser fiable al 100x100, despreciando el metodo hard por registro.
Mi moraleja por ahora es, primero prueba por registro de colisiones, es fácil de programar y si funciona adelante, que no, pues sistema soft, una vez lo entiendes tambien es fácil.

17
Programación / Re:Colisiones sprite<>sprite por software
« en: Mayo 04, 2018, 18:54:03 »
Hola Dashiad, sí, me refiero a que no detecta todas las colisiones, se saltaba muchas. La verdad es que no hay color, ahora que voy evolucionando la rutina por soft, es impecable.

18
Programación / Re:Colisiones sprite<>sprite por software
« en: Mayo 02, 2018, 10:16:09 »
He hecho muchas pruebas desde que me encontré con el problema, y el bueno del registro de colisiones no daba la fiabilidad necesaria, tanto si lo miras desde la interrupción, como si lo miras inmediatamente después de cada movimiento o las dos a la vez, y en cambio la rutina por soft se muestra fiable 100*100.
Sí, obliga a que sean cuadrados pero si lo miras prácticamente todos los sprites lo son, se puede jugar con las coordenadas para que solo colisione con las centrales si el sprite tiene una forma rara.
En el ejemplo que adjunte controla los 24*21 de cada sprite como habrás visto pero es ajustable fácilmente.
Creo que a partir de ahora me decanto más por este sistema.

19
Programación / Colisiones sprite<>sprite por software
« en: Abril 30, 2018, 14:02:23 »
Buenas gente, había leído sobre este asunto en los foros y hasta ahora no le había dado importancia porque no me he encontrado con este problema, pero en lo que estoy trabando ahora las colisiones por hard no funcionaban de manera precisa, la rutina que funcionaba hasta ahora, aquí se comía la mitad de las colisiones de una manera inaceptable. Dando un vistazo por Codebase64 empiezo a encontrar muchos apuntes a las colisiones por soft para solventarlo, comentando para mi sorpresa que cuando hay que controlar muchas cosas a la vez en pantalla, el registro de colisiones ya no es el adecuado para controlarlo.
Aquí aparece la idea de colisiones por soft, se trata de determinar las cuatro esquinas que conforman el sprite y comprobar si las coordenadas del interior de este rectángulo coincide con las coordenadas de otro sprite determinado del mismo modo.
Como me ha costado unos cuantos días pelearme con esto, aquí os paso mi primera aproximación a la solución del problema, creo que cualquiera que desarrolle se encontrará con esto en algún momento.

Saludos!

Código: [Seleccionar]
; 10 SYS (2064)

v=$d000 ;inicio registros sprite

*=$0801

        BYTE    $0E, $08, $0A, $00, $9E, $20, $28,  $32, $30, $36, $34, $29, $00, $00, $00

*=$0810

        jsr sprite
l       jsr raster_wait
        jsr JOY
        jmp l

sprite  lda #3  ;pon 2 sprites en pantalla
        sta v+21
        lda #0
        sta v+39
        lda #3
        sta v+40
        lda #192
        sta 2040
        lda #193
        sta 2041
        lda #100
        sta v
        lda #190
        sta v+2
        lda #147
        sta v+1
        sta v+3
        rts

raster_wait             ;espera línea raster
l1      LDA #$EA
        CMP $D012
        BNE l1
        BIT $d011
        BMI l1
        rts

JOY     LDA $DC00   ;LEEMOS JOY
        AND #31     ;LA CUATRO DIRECCIONES ARRIBA ABAJO IZQ DER   
        CMP #30     
        BEQ ARR
        CMP #29
        BEQ ABJ
        CMP #27
        BEQ IZQ
        CMP #23
        BEQ DER
        rts

arr     dec $d001
        jsr coordenadas
        jsr comprueba_col           
        rts
abj     inc $d001   
        jsr coordenadas
        jsr comprueba_col           
        rts
izq     dec $d000
        jsr coordenadas
        jsr comprueba_col           
        rts
der     inc $d000
        jsr coordenadas
        jsr comprueba_col           
        rts

coordenadas             ;actualiza coordenadas de los 2 sprites
        lda v           ;y crea 4 variables con las 4 esquinas
        sta s1x1        ;de los sprites
        clc             ;s1x1 sprite 1 x1
        adc #23         ;s1x2 sprite 1 x2
        sta s1x2        ;etc....
        lda v+1
        sta s1y1
        clc
        adc #20
        sta s1y2

        lda v+2
        sta s2x1
        clc
        adc #23
        sta s2x2
        lda v+3
        sta s2y1
        clc
        adc #20
        sta s2y2
        rts             
s1x1    byte 0         
s1x2    byte 0
s1y1    byte 0
s1y2    byte 0
s2x1    byte 0
s2x2    byte 0
s2y1    byte 0
s2y2    byte 0

comprueba_col           ;comprueba colisión en base a las coordenadas
        lda s1x2        ;si se cumplen incrementa color borde
        cmp s2x1
        bcs comprueba_col1
        rts
comprueba_col1
        lda s1x1
        cmp s2x2
        bcc comprueba_col2
        rts
comprueba_col2
        lda s1y2
        cmp s2y1
        bcs comprueba_col3
        rts
comprueba_col3
        lda s1y1
        cmp s2y2
        bcc hit
        rts
hit     inc $d020
        rts

*=12288
incbin"prueba.bin"

20
General / Re:Retromadrid 2018
« en: Abril 30, 2018, 13:33:16 »
Gracias Errazquing, por incluirme en el slideshow, tiene usted todo mi reconocimiento y gratitud!  ;)

21
Es el único que yo he leído, lo aconsejo.

22
Han pasado unos meses pero ahora vuelvo a mirarme este tema.
Siempre me alucinaban los efectos de espejo y ondulación en las demos, intros de Amiga, me dejaban hipnotizado delante de la pantalla. Me preguntaba como se haría y resulta que es tan fácil como incrementar y decrementar los valores del registro $102 (BPLCON1)
Habrá que leerse de una p*** vez el Hardware manual!!!  ;D

23
General / Re:El Castillo del Dragón
« en: Febrero 03, 2017, 08:59:45 »
Madre mía!!! 5000!!!
Revisa, revisa, tiene que haber muchas joyas por ahí...

24
General / Re:El Castillo del Dragón
« en: Febrero 02, 2017, 10:10:46 »
Jeje, ya me lo imagino  ;D , si tiene discos de la CW sería interesante que los pusiera a disposición de los usuarios del foro, creo que varios los buscamos desde hace años.

25
General / Re:El Castillo del Dragón
« en: Febrero 02, 2017, 09:22:33 »
Como!!!!?! Almighty tenía discos de CW y permitió que me pegara la currada de typear el listado entero!!!
Imperdonable almighty!  >:(

26
Premios Commodore manía / Re:PREMIOS 2016 COMMODORE MANIA
« en: Enero 12, 2017, 09:12:12 »
A votar!!!

************** JUEGOS C64 *********
3 puntos para ... Kabura
2 puntos para ... the uni games
1 punto para ...  Nyordax

************** GRÁFICOS C64 HIRES/MC ***************
3 puntos para ... Vandalism 65
2 puntos para ... Anochecer
1 punto para ...   Los 4


************** GRÁFICOS C64 PETSCII ***************
3 puntos para ... Green Falcon
2 puntos para ... Ujanko
1 punto para ...   Pesadilla

27
Commodore Amiga / Re:Aprendiendo como van los gráficos en el Amiga
« en: Noviembre 25, 2016, 10:56:41 »
Añado el listado en ensamblador dentro de la imagen ADF para que podamos ir comentando las dudas.
Estos listados forman parte del corso di assembler de Favio Ciucci que podéis bajar de Aminet.
Es esencial ayudarse del hardware manual para ir comprendiendo que es $DFF000  ;)

He obviado decir que mi entorno de desarrollo es sobre A500 con Devpac 3.18, y Personal Paint 7.1 con el que convertir las imagenes a formato .RAW, que es con lo que trabajamos.
En este caso es una imagen a 320*256 8 colores porque así es la copperlist que hemos definido, convertida y grabada como pagan.RAW, así puedes utilizar tu propio gráfico.

28
Commodore Amiga / Re:Aprendiendo como van los gráficos en el Amiga
« en: Noviembre 24, 2016, 20:29:44 »
Sprite, aún no he llegado al blitter.

29
Commodore Amiga / Re:Aprendiendo como van los gráficos en el Amiga
« en: Noviembre 24, 2016, 17:57:36 »
Je, curso no sería la palabra adecuada ya que yo soy novato en esto, pero si que estaría bien ir discutiendo la rutina.

30
Commodore Amiga / Aprendiendo como van los gráficos en el Amiga
« en: Noviembre 24, 2016, 16:50:14 »
Después de una temporada programando en ensamblador el C64, ahora quiero quitarme la espina de hacerlo también con el Amiga. El cambio del 6510 al 68000 todos son ventajas, nada en contra, a picar código y coger soltura. El cambio a comprender como va un Amiga internamente ya es más peliagudo, aquí hay que leer y analizar muchos listados para ir comprendiendo algo, es muy diferente al C64.
Por lo pronto es esencial entender lo que es una copperlist y todo lo que se puede llegar a hacer ahí, y una mínima rutina que controle que el Amiga no se quede colgado.
De momento ya se generar y combinar una barra copper, una imagen y un sprite deambulando por ahí, y comprender porque, poca cosa pero por algo se empieza.
Se que el aprendizaje sera largo pero creo que va a valer la pena. Os dejo un ADF para que veaís el progreso actual.

Páginas: 1 [2] 3 4 ... 16