User Tag List

Página 4 de 6 PrimerPrimer 123456 ÚltimoÚltimo
Resultados 46 al 60 de 82

Tema: Programando en MSDOS con VGA

  1. #46

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    5,448
    Mencionado
    33 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    822
    Agradecer Thanks Received 
    808
    Thanked in
    Agradecido 586 veces en [ARG:2 UNDEFINED] posts
    ¿No hay manera de saber por donde va el barrido de pantalla? Aunque lo ideal seria usar doble buffer.

    En la maquina del robotron original, en vez de ir por sprites tenían un frame buffer y un blitter parar dibujar los sprites en cada frame. Para que no parpadeara ni tener que usar un doble buffer (mas memoria => mas caro) tenían la pantalla dividida en dos partes, al principio de cada frame borraban y dibujaban los sprites de la mitad inferior de la pantalla, cuando el chip de video llegaba a la mitad de la pantalla, se generaba una interrupción y se ponían a dibujar los sprites de la parte superior.

    En verdad para un frame dado estas viendo que los sprites de la parte superior corresponden al frame anterior y los de abajo al actual, pero importa poco si consigues moverlos en un frame.
    Última edición por swapd0; 23/11/2018 a las 01:53
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  2. #47

    Fecha de ingreso
    Oct 2012
    Mensajes
    190
    Mencionado
    1 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1
    Agradecer Thanks Received 
    77
    Thanked in
    Agradecido 30 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por swapd0 Ver mensaje
    ¿No hay manera de saber por donde va el barrido de pantalla? Aunque lo ideal seria usar doble buffer.

    En la maquina del robotron original, en vez de ir por sprites tenían un frame buffer y un blitter parar dibujar los sprites en cada frame. Para que no parpadeara ni tener que usar un doble buffer (mas memoria => mas caro) tenían la pantalla dividida en dos partes, al principio de cada frame borraban y dibujaban los sprites de la mitad inferior de la pantalla, cuando el chip de video llegaba a la mitad de la pantalla, se generaba una interrupción y se ponían a dibujar los sprites de la parte superior.

    En verdad para un frame dado estas viendo que los sprites de la parte superior corresponden al frame anterior y los de abajo al actual, pero importa poco si consigues moverlos en un frame.
    No tengo ni idea... Es tan complicada la VGA.

    Pero por ejemplo en el menú, si que conseguí encontrar un sample que usa interrupciones para mover solo el logo, y dejar fijo el resto.
    Se llama "split screen", y utiliza un registro que sabe en que linea está dibujando para partir la pantalla.

    Lo ideal sería empezar a dibujar los sprites a partir de la linea 32 o algo así, y haría el mismo efecto que en el robotron, pero no tengo ni idea de como se hace, voy a ver si me entero de como hace el split, porque prácticamente lo copie entero de un sample sin mirar jaja..

    Doble buffer no quería utilizar porque habría que actualizar toda la pantalla en vez de solo los bordes y los sprites, y ya iria mucísimo mas lento, como la mayoria de juegos comerciales.

  3. El siguiente usuario agradece a mills332 este mensaje:

    josepzin (23/11/2018)

  4. #48

    Fecha de ingreso
    Oct 2012
    Mensajes
    190
    Mencionado
    1 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1
    Agradecer Thanks Received 
    77
    Thanked in
    Agradecido 30 veces en [ARG:2 UNDEFINED] posts
    Bueno aquí está portado al "modo x", 320x240 60 Hz.

    No puedo probarlo en una vga real, pero si en PCem, que es bastante preciso, el vídeo está capturado del emulador, corriendo con un 8086 a 8 MHz, con una VGA ISA de 8 bit.



    El código y la demo aquí como siempre: https://github.com/mills32/Little-Game-Engine-for-VGA
    Última edición por mills332; 12/12/2018 a las 02:02

  5. Los siguientes 4 usuarios agradecen a mills332 este post:

    JoJo_ReloadeD (12/12/2018), masteries (07/07/2020), SplinterGU (16/07/2020), swapd0 (12/12/2018)

  6. #49

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    5,448
    Mencionado
    33 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    822
    Agradecer Thanks Received 
    808
    Thanked in
    Agradecido 586 veces en [ARG:2 UNDEFINED] posts
    IIRC el modo x permitia tener varias "paginas" o pantallas, así que podrías usar doble buffer y evitar el parpadeo.

    El scroll al principio debería correr mas para dejar al personaje como mínimo en el centro de la pantalla, es un fallo que tienen la mayoría de los juegos con scroll.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  7. #50

    Fecha de ingreso
    Nov 2005
    Ubicación
    Excartagenero
    Mensajes
    19,725
    Mencionado
    216 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    3,912
    Agradecer Thanks Received 
    3,221
    Thanked in
    Agradecido 2,166 veces en [ARG:2 UNDEFINED] posts
    Entradas de blog
    1
    Que bien se mueve... que suave.

  8. #51

    Fecha de ingreso
    Oct 2012
    Mensajes
    190
    Mencionado
    1 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1
    Agradecer Thanks Received 
    77
    Thanked in
    Agradecido 30 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por swapd0 Ver mensaje
    IIRC el modo x permitia tener varias "paginas" o pantallas, así que podrías usar doble buffer y evitar el parpadeo.
    Claro, pero es una decisión difícil, si uso doble buffer, limito el scroll a horizontal.

    Esta imagen la hice para representar donde están las cosas en la VRAM:
    Nombre:  VGA_MEM_MAP.png
Visitas: 569
Tamaño: 14.7 KB

    Si uso la "segunda" página, la parte gris, adiós al scroll vertical.

    Cita Iniciado por swapd0 Ver mensaje
    El scroll al principio debería correr mas para dejar al personaje como mínimo en el centro de la pantalla, es un fallo que tienen la mayoría de los juegos con scroll.
    Totalmente cierto, lo tenia pensado pero lo olvidé, de todas formas solamente hay que cambiar un valor de una variable .

  9. #52

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    5,448
    Mencionado
    33 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    822
    Agradecer Thanks Received 
    808
    Thanked in
    Agradecido 586 veces en [ARG:2 UNDEFINED] posts
    Se puede hacer scroll vertical si usas una pantalla extra y usas este buffer de tres pantallas como un buffer circular.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  10. #53

    Fecha de ingreso
    Oct 2012
    Mensajes
    190
    Mencionado
    1 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1
    Agradecer Thanks Received 
    77
    Thanked in
    Agradecido 30 veces en [ARG:2 UNDEFINED] posts
    Si le interesa a alguien, por fin encontre alguien explicando lo del scroll de VGA, con esto corregí el scroll del motor:



    Funciona en dosbox, y en el 386 con VGA real del video.

    Yo lo probé en ao486 (un pc simulado en fpga) y en PCem, y funciona con bugs (esperados).
    También funciona en SVGA y hasta en GPUs actuales que siguen siendo compatibles (si arrancas freedos desde un usb, al menos en mi pc aun es compatible).

  11. Los siguientes 5 usuarios agradecen a mills332 este post:

    fbustamante (06/07/2020), JoJo_ReloadeD (06/07/2020), Karkayu (06/07/2020), masteries (20/07/2020), romeroca (06/07/2020)

  12. #54

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    2,776
    Mencionado
    80 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    165
    Agradecer Thanks Received 
    440
    Thanked in
    Agradecido 256 veces en [ARG:2 UNDEFINED] posts
    Bastante guay, ahora queda saber en cual de esas 4 pantallas toca ir dibujando los nuevos tiles... según se vaya moviendo el scroll... ¡qué divertido!

    Iba a comentar sobre el dibujado de los sprites y el redibujado de los tiles que éstos estaban ocupando, pero tengo la sensación de que esto ya lo tienes resuelto, por los vídeos que estoy viendo.
    También queda dibujar sprites y no redibujar todo el espacio que ocupaban, sólo los tiles que hayan quedado al descubierto, necesario para utilizar sprites de gran tamaño.

  13. #55

    Fecha de ingreso
    Sep 2005
    Mensajes
    12,107
    Mencionado
    191 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    292
    Agradecer Thanks Received 
    713
    Thanked in
    Agradecido 507 veces en [ARG:2 UNDEFINED] posts
    Oye, hablando de scroll tileado, por curiosidad, porque me he enfrentado a ese problema y no sé si tengo la solución más óptima.
    Tengo entendido que el scroll va dibujando en el "buffer de vídeo" la nueva fila/columna, como si el buffer fuera cíclico tanto vertical como horizontalmente. Es decir, que no se redibuja todo el buffer, sólo una fila/columna en la posición que le toque... Bueno, ya me entiendes.
    Eso está genial cuando el desplazamiento es, como máximo de 1 pixel, pero ¿qué pasa cuando el salto es mayor? ¿Cuando se avancen 14 pixels de golpe? o por usar un teletransportador, te mueves a otra posición del mapa. ¿El algoritmo lo detecta y redibuja todo el buffer? ¿Hay algo tipo "dirty rects" que comprueba si una sección del buffer contiene los mismos colores que los que se van a dibujar?
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  14. #56

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    5,448
    Mencionado
    33 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    822
    Agradecer Thanks Received 
    808
    Thanked in
    Agradecido 586 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por Drumpi Ver mensaje
    Oye, hablando de scroll tileado, por curiosidad, porque me he enfrentado a ese problema y no sé si tengo la solución más óptima.
    Tengo entendido que el scroll va dibujando en el "buffer de vídeo" la nueva fila/columna, como si el buffer fuera cíclico tanto vertical como horizontalmente. Es decir, que no se redibuja todo el buffer, sólo una fila/columna en la posición que le toque... Bueno, ya me entiendes.
    Eso está genial cuando el desplazamiento es, como máximo de 1 pixel, pero ¿qué pasa cuando el salto es mayor? ¿Cuando se avancen 14 pixels de golpe? o por usar un teletransportador, te mueves a otra posición del mapa. ¿El algoritmo lo detecta y redibuja todo el buffer? ¿Hay algo tipo "dirty rects" que comprueba si una sección del buffer contiene los mismos colores que los que se van a dibujar?
    Si lo haces con un mapa de tiles es mas fácil si actualizas una fila o columna de tiles, no de pixels.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  15. #57

    Fecha de ingreso
    Sep 2005
    Mensajes
    12,107
    Mencionado
    191 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    292
    Agradecer Thanks Received 
    713
    Thanked in
    Agradecido 507 veces en [ARG:2 UNDEFINED] posts
    Ya, entiendo que con tiles es más fácil porque son bloques, pero no quería meterme en eso porque no sé si el scroll por HW soporta sólo pixels o también tiles/caracteres.
    Pero eso no responde a mi pregunta ¿Qué pasa cuando el desplazamiento es de media pantalla o más, por ejemplo?

    En mi caso, se me ocurrió dividir el "buffer de pantalla" en tiles, y tener aparte un array bidimensional con el número de tile de cada posición, de forma que, cuando tengo que actualizar una serie de filas o columnas, evito tocar esas posiciones que ya tienen el tile que le va a corresponder.
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  16. #58

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    5,448
    Mencionado
    33 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    822
    Agradecer Thanks Received 
    808
    Thanked in
    Agradecido 586 veces en [ARG:2 UNDEFINED] posts
    Vamos a ver, se supone que el scroll por hardware tiene precision de pixels, si quieres lo puedes mover a mas de un pixel pero siempre el redibujado de las zonas nuevas es cosa tuya. Con dividir la posición entre el tamaño de los tiles sacas la posición en el mapa, comparándola con la anterior sabes en que dirección te has movido y cuantas filas o columnas de tiles debes de dibujar.
    Última edición por swapd0; 08/07/2020 a las 12:06
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  17. #59

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    2,776
    Mencionado
    80 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    165
    Agradecer Thanks Received 
    440
    Thanked in
    Agradecido 256 veces en [ARG:2 UNDEFINED] posts
    En máquinas más viejunas, y dependiendo del harware de vídeo del que dispongas, lo que haces no es dibujar todos los nuevos tiles en un sólo frame; si has avanzado 1 píxel, dibujas una línea de cada tile de lo mínimo que dibuje el hardware (16 pixels en el caso del blitter de un STE), si has avanzado 2 pixels dibujas 2 líneas de cada tile de 16x16 ... En Amiga debe ser similar.

    en MegaDrive lo que haces es dibujar uno sólo de los tiles de 8x8 , de los 4 que componen un tile de 16x16; y dibujas 1 tile, o 2, o 3... dependiendo de si has avanzado 1 pixel, 2, 3...
    Se intenta equilibrar el consumo del hardware a un promedio más o menos constante; evitando los picos de trabajo.

    Y si has avanzado unos pixels y a continuación empiezas a retroceder, pues va pintando líneas / tiles mínimos sólo del lado que corresponda. Por eso siempre vas a necesitar una resolución virtual, algo más grande que la resolución que muestras en la pantalla; son los márgenes dónde vas pintando estas cosas.

    Y si tienes que repintarlo todo, porque te has teletransportado; ese dibujado lo haces en un espacio diferente e intentas hacer que la transición sea suave o transcurra un tiempo desde que sabes que el personaje ha entrado en el teletransporte y de verdad se ha teletrasnportado Ese tiempo lo utilizas para ir dibujando, es raro poder redibujarlo todo en lo que dura un cuadro con máquinas viejunas o no tan viejunas, no creo que incluso un Capcom CPS2 pueda redibujarlo todo en un sólo cuadro.

  18. #60

    Fecha de ingreso
    Sep 2005
    Mensajes
    12,107
    Mencionado
    191 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    292
    Agradecer Thanks Received 
    713
    Thanked in
    Agradecido 507 veces en [ARG:2 UNDEFINED] posts
    Claro, a eso voy, a las rutinas de dibujado. Yo pensaba que tal vez el scroll por HW haría las tareas de "dibujado", pero si es algo que depende del código, hay que ser imaginativo y reducir el número de operaciones.
    Es el problema que tengo en mi scroll tileado, especialmente con uno de los que diseñé para Wiz, que se parece mucho a este problema, sobre todo porque las primitivas de dibujado sobre un mapa son relativamente lentas. Quería comprobar si alguna técnica de los 70-90 me podría servir para optimizar el código.
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

Página 4 de 6 PrimerPrimer 123456 ÚltimoÚltimo

Permisos de publicación

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