Ver la versión completa : Programando en MSDOS con VGA
mills332
05/09/2018, 15:08
Hola, había empezado a curiosear cosas sobre programar en MSDOS y VGA.
¿Sabéis donde podría haber librerías o ejemplos de cosas en ensamblador para VGA?.
Hay poquísimos ejemplos, a parte de unos en turbo c, que van bastante lentos ya que estoy probando en 8086 o como mucho 286 (emulados con PCEM).
He conseguido cargar imágenes con los samples del turbo c, y hacer un "scrolling" por hardware en VGA, que me ha costado semanas. El scrolling es rápido, estilo los que tenían las consolas que no consume cpu, pero lo difícil es dibujar sprites encima del fondo, o copiar datos nuevos a la VRAM de forma eficiente para actualizar por ejemplo la parte derecha de la pantalla y crear la ilusión de un nivel o mapa grande para un juego.
Si a alguien le interesa, aquí dejo un sample en turbo C con lo que he conseguido, que bastante es...
51758
Es un "sprite" sobre un fondo que hace scrolling y que funciona teóricamente hasta en un 8088 a 4 Mhz (otra vez, emulándolo en PCEM), aunque no tenia ni idea de como implementar el sprite y no lo hace bien del todo (va dejando un rastro por ahi, y es lentísimo...).
51759
Optimizandolo un poco y dibujando el sprite en ensamblador, seguramente un 8086 podría mover dos o tres sprites y hacer un scrolling a 50 fps o por ahi, aunque solo sea un scroll horizontal, creo yo...
En un 286 hay ya juegos que demuestran que se podia hacer muy bien (como el Doofus).
Y Luego tenemos el commander keen que hace un scroll un poco lento y en EGA, pero que funciona en cualquier patata.
Saludos.
Por la epoca del msdos yo tenia los swags o algo así que era como una revista en CD donde tenias un montón de ejemplos, muchos en turbo pascal, donde tenias rutinas de scroll, sprites, dibujo de lineas, fractales, etc.
-----Actualizado-----
Lo encontre.
http://swag.outpostbbs.net/index.html
jduranmaster
05/09/2018, 15:53
¿ejecutas el turbo-C en DosBox o tienes MS-DOS virtualizado?
mills332
05/09/2018, 16:18
Por la epoca del msdos yo tenia los swags o algo así que era como una revista en CD donde tenias un montón de ejemplos, muchos en turbo pascal, donde tenias rutinas de scroll, sprites, dibujo de lineas, fractales, etc.
-----Actualizado-----
Lo encontre.
http://swag.outpostbbs.net/index.html
A ver como va el turbo pascal, gracias!
¿ejecutas el turbo-C en DosBox o tienes MS-DOS virtualizado?
Estaba probando todo en dosbox porque editas el codigo en notepad o lo que sea en windows y luego con el control f4 en dosbox se actualiza y lo compila. Al final lo probé en pcem, que simula de forma mas precisa los diferentes procesadores, lo he probado en 8088 a 4.7 Mhz, en 8086 a 8 Mhz y en 286.
josepzin
05/09/2018, 16:33
Yo me había hecho mis librerías en ensamblador para usar en Turbo Pascal!!! :)
Funcionaban bastante bien, al menos hice varias cosas.
Por ejemplo una versión del R-Type, basandome en las fotos que aparecían en las MicroManía.
https://1.bp.blogspot.com/-QG6ISieUffY/V_6UvCaLStI/AAAAAAAAQWA/J1iNHaLkKXgAuAjmTpEyS3hlgd0Wrq4ywCLcB/s1600/r-type-06.png
https://2.bp.blogspot.com/-PTteZUm4cBU/V_6UyK7mlsI/AAAAAAAAQWI/Ivq9PVoMdM4KSA6mOWt49lwZV_W8cRZ9QCLcB/s1600/r-type-15.png
https://4.bp.blogspot.com/-DyaNkPY3w8k/V_6U5u__jOI/AAAAAAAAQWg/l6048xARU-kcctWQycIhYcAF-LTLg_oyACLcB/s1600/r-type-25.png
O un remake del Phantomas II de Spectrum.
O un Missile Command.
-----Actualizado-----
Ese R-Type tenía un fondo suave al pixel creado con tiles y muchos sprites simultaneos en pantalla.
JoJo_ReloadeD
05/09/2018, 17:01
Echa un ojo al CPV, muy buena guia con la que en la epoca aprendi ensamblador y varios entresijos del pc:
http://www.nachocabanes.com/videojuegos/cpv/index.html
Ahi te explican desde el basico modo 13h, pasando por los modos X, hasta la svga. Sprites, transparencias, scrolles... incluso tocan el 3d, poligonos con caras ocultas...
mills332
05/09/2018, 18:01
Yo me había hecho mis librerías en ensamblador para usar en Turbo Pascal!!! :)
Funcionaban bastante bien, al menos hice varias cosas.
Por ejemplo una versión del R-Type, basandome en las fotos que aparecían en las MicroManía.
https://2.bp.blogspot.com/-PTteZUm4cBU/V_6UyK7mlsI/AAAAAAAAQWI/Ivq9PVoMdM4KSA6mOWt49lwZV_W8cRZ9QCLcB/s1600/r-type-15.png
Ese R-Type tenía un fondo suave al pixel creado con tiles y muchos sprites simultaneos en pantalla.
Que bueno ese juego, pero necesitaria un 386 por lo menos.
JoJo_ReloadeD
05/09/2018, 18:42
Yo me había hecho mis librerías en ensamblador para usar en Turbo Pascal!!! :)
Funcionaban bastante bien, al menos hice varias cosas.
Por ejemplo una versión del R-Type, basandome en las fotos que aparecían en las MicroManía.
https://1.bp.blogspot.com/-QG6ISieUffY/V_6UvCaLStI/AAAAAAAAQWA/J1iNHaLkKXgAuAjmTpEyS3hlgd0Wrq4ywCLcB/s1600/r-type-06.png
https://2.bp.blogspot.com/-PTteZUm4cBU/V_6UyK7mlsI/AAAAAAAAQWI/Ivq9PVoMdM4KSA6mOWt49lwZV_W8cRZ9QCLcB/s1600/r-type-15.png
https://4.bp.blogspot.com/-DyaNkPY3w8k/V_6U5u__jOI/AAAAAAAAQWg/l6048xARU-kcctWQycIhYcAF-LTLg_oyACLcB/s1600/r-type-25.png
O un remake del Phantomas II de Spectrum.
O un Missile Command.
-----Actualizado-----
Ese R-Type tenía un fondo suave al pixel creado con tiles y muchos sprites simultaneos en pantalla.
Queremos ver esto tio, pasatelo o algo :D
josepzin
05/09/2018, 20:08
Que bueno ese juego, pero necesitaria un 386 por lo menos.
Funcionaba perfecto en un 286!
-----Actualizado-----
*****.r... mientras buscaba me aparece una chorrada de intro con los típicos saluditos a los amigos que hizo el chico que vivia conmigo, que murió de cancer... se merece que la publique en mi blog, lo menos.
-----Actualizado-----
Ajjj... justo ese Rtype no tiene el .EXE, tendría que configurar las rutas del TurboPascal y volver a generarlo.
mills332
05/09/2018, 21:55
Funcionaba perfecto en un 286!
-----Actualizado-----
*****.r... mientras buscaba me aparece una chorrada de intro con los típicos saluditos a los amigos que hizo el chico que vivia conmigo, que murió de cancer... se merece que la publique en mi blog, lo menos.
-----Actualizado-----
Ajjj... justo ese Rtype no tiene el .EXE, tendría que configurar las rutas del TurboPascal y volver a generarlo.
Hala molaria, era un 286 a 16 Mhz?... Supongo que no querrás subir el código. jeje, me encantaria trastear con algo así.
Hace tiempo intenté recompilar un game maker que hay para 286 tambien http://www.aderack.com/game-maker/index.php?title=Main_Page, lo que pasa es que es algo lento, pero creo que un 286 normalito puede con el.
josepzin
05/09/2018, 22:18
Igual mi memoria me juega malas pasadas, yo recuerdo que iba suave pero a saber.
Encontré varias pruebas donde se mueven varios sprites de naves sobre un fondo de scroll parallax con tiles. Pero estoy casi seguro que son de cuando tenía la XT con CGA, porque recuerdo que iba cambiando el tamaño de la ventana para que vaya mas o menos suave. En cambio ese juego del RType era a pantalla completa, asi que tiene que ser posterior.
Estuve un buen rato haciendo arqueología entre todas esas carpetas, que linda época de procrastinar y tiempo libre y expectativas de hacer cosas!
Por lo pronto voy a subir una carpeta con una intro para un BBS que hizo mi amigo, hay un poco de todo en esa carpeta. Archivos .cel que casi seguro vienen desde Autodesk Animator, archivos .pas, .asm, veo un par de .bas, etc.
No tengo problema en subir el código, no lo hice antes por eso de querer explicar de que va, cómo funciona... pero al final mejor mal que nunca! :D
Por lo pronto voy a subir una carpeta con una intro para un BBS que hizo mi amigo, hay un poco de todo en esa carpeta. Archivos .cel que casi seguro vienen desde Autodesk Animator, archivos .pas, .asm, veo un par de .bas, etc.
Y p0rn!!1!!!!
mills332
05/09/2018, 22:49
Seguro que es interesante la carpeta :).
No tengo mucha idea de programar en ms dos, solo instale el turbo c, he intentado pegar partes de asm (de codigos en pascal de un link que ha puesto antes jduranmaster) y nada, en turbo c dice que no.
Que necesito para compilar pascal? los links a un supuesto compilador turbo pascal estan todos mal o me llevan a cosas de windows.
josepzin
05/09/2018, 23:11
Acabo de abrir el TurboPascal para DOS que tengo en esa carpeta y funciona, claro, dentro de Dosbox!
-----Actualizado-----
Es Turbo Pascal versión 7
mills332
05/09/2018, 23:21
Acabo de abrir el TurboPascal para DOS que tengo en esa carpeta y funciona, claro, dentro de Dosbox!
-----Actualizado-----
Es Turbo Pascal versión 7
En dosbox creo que si pones 1500 ciclos, es mas o menos un 286 a 12, y entre 400 y 600 ciclos simula algo parecido al 8086 8 Mhz que tenia yo.
Voy a entretenerme y buscar el turbo pascal 7. :)
josepzin
05/09/2018, 23:32
Si no lo encuentras o si quieres te lo paso, no hay problema.
Voy a entretenerme y buscar el turbo pascal 7. :)
No se si hay version en español, pero si te vale en ingles: https://winworldpc.com/product/turbo-pascal/7x
josepzin
06/09/2018, 05:49
Antes de que publique la entrada en mi blog, aquí está la intro:
Descarga: https://mega.nz/#!3YB2UKLB!QDFJU5MVrWgEP7GOziQI0gZzuCzKxtJ6JK-BCbm3a8s
Versión SVGA:
https://www.youtube.com/watch?v=xr831fsf4Qo
No sé porqué se ve tan mal el video de la versión VGA:
https://www.youtube.com/watch?v=QwxY62qVFEQ
-----Actualizado-----
Que pasada, estoy rememorando esos tiempos de Turbo Pascal!! he configurado Dosbox como corresponde, los directorios, compilado y ejecutado programas...
masteries
06/09/2018, 08:41
¡Qué preciosa labor estáis haciendo!
¡Rescatando el Código del Pasado! Y por cierto, código bueno, pero pata negra de la buena,
Hasta lo que hoy día parece un mísero 286 sirve para probar y aprender una barbaridad de cosas,
JoJo_ReloadeD
06/09/2018, 09:14
Cojonudo josepzin, estan chulisimas :D
Antes de que publique la entrada en mi blog, aquí está la intro:
Descarga: https://mega.nz/#!3YB2UKLB!QDFJU5MVrWgEP7GOziQI0gZzuCzKxtJ6JK-BCbm3a8s
Versión SVGA:
https://www.youtube.com/watch?v=xr831fsf4Qo
No sé porqué se ve tan mal el video de la versión VGA:
https://www.youtube.com/watch?v=QwxY62qVFEQ
-----Actualizado-----
Que pasada, estoy rememorando esos tiempos de Turbo Pascal!! he configurado Dosbox como corresponde, los directorios, compilado y ejecutado programas...
No se ven ¿los has borrado?
mills332
06/09/2018, 12:46
No se si hay version en español, pero si te vale en ingles: https://winworldpc.com/product/turbo-pascal/7x
No hay problema, gracias.
Que chulas las intros, josepzin con sonido adlib y todo.
josepzin
06/09/2018, 13:12
No se ven ¿los has borrado?
Típico, me quedó en Privado, sin publicar....
JoJo_ReloadeD
06/09/2018, 13:17
Típico, me quedó en Privado, sin publicar....
Jeje ya se ve... **** compresion de youtube, las cosas en vga pura 320x200 se visualizan en 240 y ahi el bitrate es kk... si quieres que se vea mejor upscalea el video al doble y se vera en 480p, mucho mejor
josepzin
06/09/2018, 13:23
Me alegro que os guste!
Aquí va una entrada en mi blog: https://www.josepzin.com/2018/09/intros-del-ata-bbs-dosvgasvga1996.html
Típico de mi amigo :D
"Escribir sobre la Bandera: ¡Uuuhh que irrespetuoso!, ¿como vas a escribir sobre la bandera?".
https://2.bp.blogspot.com/-GDF5MqtX2WM/W5CnBsE2odI/AAAAAAAATu8/3h9g7_eLSvI5PCw1i_KP5RViFr7D9lOBQCLcBGAs/s1600/tp7_003.png
-----Actualizado-----
Jeje ya se ve... **** compresion de youtube, las cosas en vga pura 320x200 se visualizan en 240 y ahi el bitrate es kk... si quieres que se vea mejor upscalea el video al doble y se vera en 480p, mucho mejor
Eso pensé... a ver si instalo algun programa para hacer eso.
mills332
06/09/2018, 14:00
Pues conseguí el turbo pascal, de momento voy a probar cosas, pero veo que por ejemplo los samples, hacen los mismo que el turbo c, o sea que son algo lentos jeje.
Por cierto intente cargar el sample de ata en el 286 emulado en pcem, y me rei, porque salió una frase en argentino diciendo que no podía ejecutarlo jaja "vos tenés un 80286" :).
josepzin
06/09/2018, 14:46
Pibe, vos tenes un 286 :P
-----Actualizado-----
En DOSBOX a esta intro tuve que acelerar los Mhz.
mills332
06/09/2018, 19:29
Buscando mas samples, he encontrado uno super simple de turbo c, que usa el modo 13, y solo 64Kb de VRAM, y ahi me funcionó mi idea del sprite.
Lo que hice fue borrar el sprite antes de dibujarlo en la nueva posicion. Para borrarlo, metí una imagen completa del fondo en la ram, y desde esa imagen, copié el trozo que ocupaba el sprite a la memoria de video.
Si hago caso al emulador pcem, un sprite de 16x16 lo está moviendo a 75 fps (lo que tiene por defecto la vga) un 8086, y haciendo scroll del fondo con hardware :).
Lo malo es, que ese modo 13 no tiene mas memoria, y supongo que copiarlo de la RAM seria lento en un pc real.
Si activo el modo x, seria mas rápido borrar los sprites usando otra copia del fondo en VRAM, pero soy incapaz de borrar los sprites, ya que en ese modo, la memoria está organizada como en columnas y a mi las mates como que me cuestan jaja.
mills332
11/09/2018, 14:04
¿Alguien sabe por qué no compila bien este programa?. Son sprites para el modo x, super optimizados, encontré el exe compilado en https://www.pcjs.org/tests/pcx86/vga/
Funcionan super rápido, un 8086 emulado no tenia problemas. Por lo que veo en el código, sólamente redibuja el fondo que ocupan los sprites en lugar de borrar toda la pantalla, y todo en ensamblador, de ahí que vaya tan rápido
Con turbo c compila, a veces da error de "undefined _main" (si le pones el comando -ml no da errores). Aun así el exe no hace nada.
Aquí dejo el exe compilado que encontré, y el código fuente. Creo que no le falta nada, pero el exe que compila turbo c ocupa bastante menos que el original, así que tal vez necesite algún otro archivo o algo...
Es un fichero en ensamblador no en C, un programa en C siempre tiene que tener una función main y por eso te da el error. ¿Has probado en ensamblarlo con algun ensamblador?
mills332
11/09/2018, 15:18
Es un fichero en ensamblador no en C, un programa en C siempre tiene que tener una función main y por eso te da el error. ¿Has probado en ensamblarlo con algun ensamblador?
Si claro, el turbo c tiene, tasm, o directamente detecta que es ensamblador y lo compila, pero tal vez necesite otro tipo de software para generar bien el exe.
O puede que simplemente sean las funciones, como una libreria, pero que le falte algún comando que sea el equivalente a la funcion main en c (es probable). bueno seguire con ello :).
Editado:
tasm L23-1.asm
tlink L23-1.obj
Eso me pasa por no leer.
He tenido que bajar dosbox a 130 ciclos para que se ralentize un poco con 4 sprites.
mills332
10/10/2018, 00:19
Buenas.
Recogiendo cosas de aquí y allá, conseguí bastantes avances, estoy creando un "motor" para ms-dos pero de momento hay problemas con los malloc, creo que no funcionan como yo esperaba en dos, y hay interferencias en cuanto cargas varias cosas.
El código es un desastre, no soy programador, aprendi a base de buscar por la red y además utiliza C y ensamblador mezclados. Cuando consiga que cargar sprites no destruya el mapa (parece que sobreescribe partes), lo subire a github.
De momento lo que hace el motor es:
- Cargar bmp y dibujarlos. (para intros o lo que sea).
- Cargar sprites de 8x8, 16x16 y 32x32, con transparencia y con animaciones.
- Cargar mapas TMX, creados con el programa tiled: https://www.mapeditor.org/
- Scroll de los mapas a 70 fps.
- Animaciones de paleta, puedes cambiar 8 primeros colores de la paleta para hacer animaciones.
- Cargar y reproducir música en formato IMF para el chip ym3812, OPL2, o Adlib, o cualquier Sound Blaster conpatible.
Para probarlo en un hardware "real" solo tengo un portátil con Pentium 200 MMX y windows 98. Desactivando varias cosas en la bios, llega a funcionar como un 386 a 19 Mhz, aunque la tarjeta de video SVGA es mucho más rápida que una VGA claro.
En emuladores como PCem, un 8088 a 4.77 Mhz con VGA, carga los mapas y hace el scroll perfectamente a 70fps, aunque un sprite de 32x32 ya le cuesta, y la música también le cuesta un poco.
Si nos vamos al 8086 a 8 Mhz con VGA y Adlib, va de lujo si no usamos muchos sprites, aunque si nos da igual que haya parpadeos extraños, estilo NES, pues yo creo que unos cuantos sprites van bien :).
Y bueno, un 286 a 6 Mhz ya va sobradísimo si hacemos caso al emulador.
Pude enviar un demo para que lo probaran en un IBM model 30 286, y parecia cargar bien y todo, excepto que no funciona en un monitor original de esos de IBM, ya que para ocultar los bordes la resolucion es de 304x176, y aún no se como tocar los registros de la VGA para no volver locos a los monitores.
Supongo que tal y como funciona en la pantalla del portatil con win98, no tendrá problemas si conectas el 8086 o 286 a un monitor moderno VGA.
Una imagen de prueba, aquí ha cargado y mueve un mapa de ejemplo que venia en el programa tiled, y encima mueve una nave que hice yo de 32x32 pixeles con transparecia, además el agua está animada cambiando la paleta en cada frame:
51881
Para que funcione rápido:
- Utilicé el modo 13 de vga, que seguramente funcione en MCGA (si alguien tiene uno de esos IBM con MCGA para probarlo...). En el modo 13 se pueden copiar cosas es muy rápido usando una instrucción llamada movsw (sin tener que hacer cosas raras del modo x, que se complica muchísimo...).
- Scroll por hardware, las tarjetas VGA y MCGA tienen scroll por hardware, así que solamente tenemos que usar la cpu para actualizar los bordes de la imagen cuando mueves el mapa, en lugar de copiar la pantalla entera como hacen la mayoría de juegos.
Lo malo que tiene, es que dibuja los sprites directamente sobre la pantalla visible y si están en la parte superior, y el pc es lento, como un 8088, se ve que no le da tiempo a dibujarlos, o los dibuja a medias.
¿Puedes usar scroll por hardware y no tienen doble buffer? WTF!?!?
mills332
10/10/2018, 15:10
¿Puedes usar scroll por hardware y no tienen doble buffer? WTF!?!?
Ahora mismo no se en qué web lo encontré, creo que en varias y terminé recopilando todo en la función, no es como una consola que cambias la X y la Y y ya, la VGA es una cosa super rara, no parece que pensaran en juegos ni por asomo cuando la hicieron jaja.
typedef unsigned char byte;
typedef unsigned short word;
//Hardware scrolling
void MCGA_Scroll(word x, word y){
byte pix = x & 7; //calcula un valor entre 0 y 8 para el registro "pixel panning"
x=x/4;
y=y*80;
//Registro de scroll "pixel panning"
inp(0x3da);
outp(0x3c0, 0x33);
outp(0x3c0, pix*2);
//Registro de scroll, solo mueve de 4 en 4 pixels
outport(0x03d4, 0x0C | (x+y & 0xff00)); //HIGH_ADDRESS 0x0C;
outport(0x03d4, 0x0D | (x+y << 8)); //LOW_ADDRESS 0x0D
//espera a que dibuje la pantalla
while ((inp(0x03da) & 0x08));
while (!(inp(0x03da) & 0x08));
}
Resulta que unos registros van de 4 en 4, otros no, la posición del scroll hay que calcularla... en fin que lo copie de sitios por ahí hasta que funcionó.
Pero bueno sigue siendo "hardware", esos cálculos de multiplicar y dividir los pones con "<<" o ">>" y no gasta a penas cpu.
Ok, lo que escribe en el puerto 0x3d4 es el offset dentro de la memoria de video en palabras de 32 bits, como una linea son 320 pixels -> 320bytes dividido entre 4 bytes -> 80, y en el registro 0x3c0 va el desplazamiento a pixel, lo que no se es porque lo tienes que multiplicar por 2.
Lo que no se es si pones un desplazamiento de y de 100 lineas por ejemplo, que aparece a partir de la mitad de la pantalla, si es la parte correspondiente al offset 0 o sigue pasados los 64kb. Visto de otra forma, si pones un offset de 32Kb, en la pantalla ves desde 32kb hasta 32kb + 64kb, o ves primero 32kb + 32kb y después 0kb hasta 32kb (como si fuera cíclica la memoria de video).
PD: la espera del final yo la quitaría y la pondría en una función separada, ya que MCGA_Scroll se supone que tiene que "scrollar" y no "scrollar" y esperar.
mills332
10/10/2018, 16:48
Pues lo de la memoria es raro, a ver... con un código se ve mejor. En el modo 13, si la memoria tuviese 8x2 pixeles se vería así:
01234567
89ABCDEF
y si mueves el scroll a (4,0) se ve esto:
456789AB
CDEF0123
Y hacia abajo o hacia arriba parecido, lo único que hace el scroll es decir cual es la posicion en la memoria que tiene que leer la tarjeta cuando empieza a dibujar en 0,0. Pero no termino de entenderlo... ni por qué al dibujar una columna de tiles a la derecha, no se ven una línea movida hacia arriba, pero si la pones en y = -16, si que se mueven, no se, cosas mías de no procesar bien las matemáticas jaja (ahh.. al poner ese ejemplo ya lo entendí).
A ver si consigo que se vea un mapa grande esta semana y pongo todo el código fuente, porque hay cosas que no entiendo, como lo del pixel*2, si no lo multiplico por 2, va la mitad de lento, y el mapa se mueve a 35 fps.
Lo del scroll horizontal es normal que pase eso, en otros cacharros (STE y Amiga) puedes definir el ancho de la linea aunque solo veas 320 pixels y al hacer scroll horizontal no pasa eso, pero solo lo puedes usar en juegos donde te muevas poco hacia los lados por el consumo de memoria.
A ver si ya que estáis con el tema, sabéis por qué pasa lo de los colores de este vídeo. Están como cambiados en los Commander Keen.
https://www.youtube.com/watch?v=bS9hiSwL1KY
Me imagino que las tarjetas graficas actuales no han sido diseñadas pensando en ser compatibles 100% con las antiguas CGA/EGA/VGA, mas como un modo legacy para salir del paso
Por eso tambien los parpadeos y bloqueos en el Duke Nukem 3D cuando no se usa VESA
mills332
13/10/2018, 20:04
A ver si ya que estáis con el tema, sabéis por qué pasa lo de los colores de este vídeo. Están como cambiados en los Commander Keen.
Recuerdo cuando vi ese vídeo que él mismo lo decía, es lo que dijo rage, en las tarjetas actuales han dejado un modo compatible con cga/ega/vga, pero puede funcionar o no, o hacer cosas raras.
mills332
09/11/2018, 14:16
Me imagino que las tarjetas graficas actuales no han sido diseñadas pensando en ser compatibles 100% con las antiguas CGA/EGA/VGA, mas como un modo legacy para salir del paso
Por eso tambien los parpadeos y bloqueos en el Duke Nukem 3D cuando no se usa VESA
Justo ayer metí un usb con msdos en un PC nuevo con tarjeta de NVidia, y el color blanco de EGA se ve VERDE :). Lo increíble es que aun funcione y el juego se piense que el PC es un 286 :awesome:
Cambiando de tema, es interesante eso de cargar fuentes modificadas para usarlar en VGA que viene como último ejemplo de esta web que puso JoJo_ReloadeD
http://www.nachocabanes.com/videojuegos/cpv/index.html Intentaré probarlo.
También He trasteado con la VGA, el Scroll los registros etc, Ya he conseguido que la función de scroll por hardware no tenga fallos:
void MCGA_Scroll(word x, word y){
byte p[8] = {0,2,4,6};
byte pix = x & 3; //pixel panning
x=x>>2; //x/4
y=(y<<6)+(y<<4); //(y*64)+(y*16) = y*80;
while ((inp(0x03da) & 0x08)); //WaitVBL
inp(0x3da);
outp(0x3c0, 0x33);
outp(0x3c0, p[pix]); //pixel panning solamente puede ser 0,2,4 o 6, para mover de 0 a 4 pixels.
//Registros de VRAM, definen el primer pixel que leerá la tarjeta cuando empiece a dibujar en pantalla
outport(0x03d4, 0x0C | (x+y & 0xff00)); //HIGH_ADDRESS 0x0C;
outport(0x03d4, 0x0D | (x+y << 8)); //LOW_ADDRESS 0x0D
while (!(inp(0x03da) & 0x08)); //WaitVBL
}
Con el mismo PC moderno he probado el scroll y el motor que estoy haciendo, y es increíble como funciona de bien.
Como estoy utilizando el modo 13 (MCGA) y solo tiene 64Kb, he tenido que reducir la resolución a 304x176 para tener bordes donde actualizar el mapa, lo malo es que eso hace que el algunos monitores no funcionen bien:
void set_mode(byte mode){
union REGS regs;
regs.h.ah = 0x00;
regs.h.al = mode;
int86(0x10, ®s, ®s);
//Desactiva proteccion de registros
word_out(0x03d4, V_RETRACE_END, 0x2c);
//Esto funciona pero deja bordes solamente en la parte derecha y en la parte inferior en algunos monitores
word_out(0x03d4,H_DISPLAY_END, (304>>2)-1); //HORIZONTAL RESOLUTION = 304
word_out(0x03d4,V_DISPLAY_END, 176<<1); //VERTICAL RESOLUTION = 176
//Se supone que con esto se puede centrar, pero no tengo ni idea
//word_out(0x03d5,H_TOTAL,0);
//word_out(0x03d4,H_BLANK_START, 0);
//word_out(0x03d4,H_BLANK_END,0);
//word_out(0x03d4,H_RETRACE_START,0);
//word_out(0x03d4,H_RETRACE_END,0);
//word_out(0x03d4,V_BLANK_START, 0);
//word_out(0x03d4,V_BLANK_END, 0);
//word_out(0x03d4,V_RETRACE_START, 0);
//word_out(0x03d4,V_RETRACE_END, 0);
//Activa la proteccion de registros
word_out(0x03d4, V_RETRACE_END, 0x8e);
}
51983
(Lo ideal sería conseguir que en el mismo dosbox se viese algo como lo de la derecha).
Si alguien quiere trastear aquí dejo el código fuente de prueba que carga una imagen y cambia la resolución.
En dosbox simplemente cambia el tamaño de la ventana o rellena toda la pantalla.
En msdos con un pc con tarjeta gráfica de intel, rellena toda la pantalla, y con la NVidia deja un borde a la derecha y abajo.
Un usuario de otro foro lo probó en un 286 con VGA auténtica, y se comportaba exactamente igual que la NVidia :awesome:.
JoJo_ReloadeD
09/11/2018, 17:21
Jeje esos modos tweaked... mola :)
mills332
22/11/2018, 23:45
Pues bueno, no quedó mal, a pesar de los sprites corruptos y los bugs, debería funcionar perfectamente en un 8086 a 8 MHz, y un poco lento en un 8088 a 4.77.
El vídeo está capturado con dosbox daum a 600 ciclos (tras muchas pruebas, es la velocidad más parecida el 8086-8 MHz).
Necesita la tarjeta Gravis Ultrasound (para reproducir MOD).
He intentado no ser un desastre con el código, pero la verdad es que tiene funciones demasiado específicas para el tipo de juegos que quería hacer.
https://www.youtube.com/watch?v=RctvPO8WkCs
No he conseguido que funcione a 320x200 con bordes, así que se quedó a 304x176, lo que hace que algunos monitores no funcionen.
En el video puse el link a github:
https://github.com/mills32/Little-Game-Engine-for-VGA-MCGA
:awesome:
josepzin
23/11/2018, 00:14
Tiene muy buena pinta!!!
¿A qué se debe el parpadeo de los sprites cuando están en la parte de arriba en el juego tipo Zelda?
mills332
23/11/2018, 00:25
Tiene muy buena pinta!!!
¿A qué se debe el parpadeo de los sprites cuando están en la parte de arriba en el juego tipo Zelda?
Está dibujando directamente en la parte visible de la memoria, en cada frame regenera el cuadradito de fondo que ocupa el sprite y debe ser que no le da tiempo, a leer de la memoria o algo así. en un 386 que tengo no se distorsiona nada.
¿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.
mills332
23/11/2018, 11:03
¿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.
mills332
12/12/2018, 01:59
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.
https://www.youtube.com/watch?v=9vdsRD3oI3c
El código y la demo aquí como siempre: https://github.com/mills32/Little-Game-Engine-for-VGA
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.
josepzin
12/12/2018, 04:28
Que bien se mueve... que suave.
mills332
12/12/2018, 12:56
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:
52076
Si uso la "segunda" página, la parte gris, adiós al scroll vertical.
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 :).
Se puede hacer scroll vertical si usas una pantalla extra y usas este buffer de tres pantallas como un buffer circular.
mills332
06/07/2020, 01:39
Si le interesa a alguien, por fin encontre alguien explicando lo del scroll de VGA, con esto corregí el scroll del motor:
https://youtu.be/IFueAukNyxk
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).
masteries
07/07/2020, 11:17
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.
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?
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.
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.
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.
masteries
08/07/2020, 13:12
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.
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.
Es que el scroll por hardware lo único que hace es cambiar la dirección y el pixel por donde empieza a dibujar la pantalla, no te mueve nada, ves los mismos datos pero como ha empezado a leer en otra dirección de memoria ves los datos desplazados.
¿A la hora de dibujar un tile en el mapa como lo dibujas? Porque no es como un sprite que tengas que "hacer mascara" para los pixels transparentes. Tal vez la parte lenta este a la hora de representar el mapa o parte de el en pantalla.
Uso BennuGD... o Fenix, según lo antiguo que sea el cacharro.
El problema está en que usa un "blitter" propio, que se encarga de dibujar todos los gráficos (sprites, mapas, scrolls, modos7...) en una única SDLSurface, y aunque está bien programado, es un proceso que se repite con cada gráfico, y se hace todo en la segunda capa más alta (la más alta sería el código Fenix/Bennu, la segunda la del motor en C, y ya por debajo SDL), con lo que se pierde mucho rendimiento y, en palabras de uno de los desarrolladores "no se aprovecha toda la potencia y propiedades de SDL" en favor de una mayor compatibilidad. Por eso se está intentando portar Bennu a OpenGL, pero es un proceso lento y, a día de hoy, una guerra de un solo hombre.
Si a eso le sumas que el motor mío de scroll tileado se hace en la capa más alta de código, el resultado es una GP2X o una Wiz que a duras penas puede mover un scroll de 24x18 procesos, o que repinte un gráfico de 320x240 a cada frame. Por eso buscaba una forma de usar el scroll, que haría las veces de "scroll HW", con un mapa que se dibujase de forma cíclica, pero en cuanto tenía que repintar más de 40 tiles de 16x16, el uso de "procesos" se volvía más eficiente... al menos, en las pruebas que he hecho... Pero llevo tiempo sospechando que la pérdida de rendimiento no viene por el tema del scroll, ni del número de procesos, ni de lo bien que yo optimice mi código... Como si el propio blitter, al tener que dibujar tantos "sprites" con transparencias, se volviera extremadamente ineficiente.
Es que para los decorados/mapa no necesitas dibujarlo como un sprite, con hacer el equivalente a un "memcpy" seria suficiente. Claro que si eso no esta metido en el BennuGD/Fenix pues estas perdiendo el tiempo haciendo cosas de mas.
Tal vez lo mejor sea meter funciones nuevas para manejar una capa hecha por tiles. Supongo que por eso algunos juegos que he visto hechos en fénix los decorados eran un bitmap enorme.
masteries
09/07/2020, 13:58
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.
Drumpi, eso ya lo resolví en Fénix / Bennu hace la tela,
Busca el hilo con la demo técnica de la fase 3 de Viaje al Centro de La Tierra. Es un scroll de dos capas con tiles de 16x16, en Fénix. En GP2X F200 a 200MHz corre a 90 fps
NeoGeo tiene la solución a tu problema, la forma en que se hace el scroll para esa máquina da muy buenos resultados en Fénix /Bennu
Es que para los decorados/mapa no necesitas dibujarlo como un sprite, con hacer el equivalente a un "memcpy" seria suficiente. Claro que si eso no esta metido en el BennuGD/Fenix pues estas perdiendo el tiempo haciendo cosas de mas.
Tal vez lo mejor sea meter funciones nuevas para manejar una capa hecha por tiles. Supongo que por eso algunos juegos que he visto hechos en fénix los decorados eran un bitmap enorme.
No, no hay memcpy en Fenix/Bennu porque es un lenguaje de alto nivel. Hay algunas funciones para acceder al buffer de gráficos, y... bueno, sí que hay una función, creo, para copiar una serie de bytes en una zona de memoria, pero no recuerdo si no lo usé por ser demasiado avanzado o porque al final tenía el mismo rendimiento.
De todas formas, no pierdo el tiempo, al contrario, tengo que intentar evitar hacer la mayor cantidad de operaciones, y usar lo más que pueda del nivel que tengo justo debajo para eso, para mejorar el rendimiento. Si lo dejo como está, pues no irá a la velocidad adecuada.
Drumpi, eso ya lo resolví en Fénix / Bennu hace la tela,
Busca el hilo con la demo técnica de la fase 3 de Viaje al Centro de La Tierra. Es un scroll de dos capas con tiles de 16x16, en Fénix. En GP2X F200 a 200MHz corre a 90 fps
NeoGeo tiene la solución a tu problema, la forma en que se hace el scroll para esa máquina da muy buenos resultados en Fénix /Bennu
Mmmm, si no recuerdo mal, tu opción era crear un mapa grande y usar alguna de las funciones MAP_PUT para ir poniendo los tiles y luego usar el scroll de Fenix ¿no?
Si era eso, esa opción no me sirve, porque mis mapas sobrepasan por mucho el tamaño máximo de un mapa, y gastaría cerca de 10MB en una sola capa (el nivel 3 de "ese" juego eran más de 300x25 tiles de 16x16, no recuerdo bien las cifras). Mi actual método me permite crear mapas casi infinitos, con un consumo de menos de 1MB de RAM (el 80% es el tamaño del FPG con los tiles :D), y sin ninguna carga recuerdo haber conseguido velocidades de 65fps en GP2X F100 y de 95fps en Wiz sin overclock.
Con el scroll que te comento, dibujando en un mapa en un scroll cíclico, he conseguido mejoras de rendimiento notables en PC, y más o menos se nota en las portátiles, pero cuando les he puesto el resto del código encima, no había diferencia ninguna... e incluso diría que iba más lento.
Ahora, si era otra forma, lo siento, pero sólo recuerdo esa, una dll de scroll que nunca se portó a otras plataformas diferentes de PC y poco más ^^U
No sé, ya me rendí en su momento: probé eliminando los collision, probé eliminando los enemigos, y creo que hasta quitando el scroll, y por alguna razón, seguía yendo lento.
mills332
09/07/2020, 18:15
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.
Eso no se me había ocurrido...
¿qué pasa cuando el salto es mayor? ¿Cuando se avancen 14 pixels de golpe?
No pasa nada... ves toda la VRAM sin modificar, restos de sprites y de basura...
Cuando entras a un mapa nuevo, o te teletransportas, te toca dibujar todo el buffer de la VGA y esconderlo poniendo toda la paleta de colores en negro.
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...
Esas maquinas estilo MegaDrive, Snes... etc solo funcionan en una especie de modo texto, pero con 16 colores por celda, lo único que hacen es cambiar una fila o columna de celdas (y cada celda solo esta definida con uno o dos bytes que definen el nº de carácter).
Eso se puede hacer en VGA, porque el scroll por hardware pixel a pixel funciona también en modo texto. Lo que pasa es que cada celda solo tiene dos colores, como el zx spectrum,(el fondo y el color del texto) y además tienes que cargar caracteres modificados a la VGA si quieres hacer algo parecido a un juego, (se puede pero yo aún no he sido capaz).
Despues podrias simular un sprite modificando las celdas, como hacen los juegos del spectrum.
el resultado es una GP2X o una Wiz que a duras penas puede mover un scroll de 24x18 procesos.
¿No hay nada remotamente parecido a OpenGL para esos cacharros aunque no esté portado directamente?
Si usas algo parecido a OpenGL, puedes funcionar casi como una consola típica o un modo texto, solamente dibujas un plano hecho de cuadrados y vas cambiando la coordenada de textura de cada uno, para definir que tiles tienen, así hice yo un mini motor de prueba y es rápido para procesadores lentos, funcionaba en un windows con OpenGL 1.0 y CPU de unos 400Mhz, y a penas consumía CPU.
Drumpi, eso ya lo resolví en Fénix / Bennu hace la tela
Bueno entonces casi sobra mi ultimo párrafo, pero lo dejo ahí por si alguien lee esto y le da por el OpenGL.
fbustamante
09/07/2020, 21:46
Bueno. Que conste que a mí la conversación me parece interesante, aunque pille sólo la mitad. :p
Si usas algo parecido a OpenGL, puedes funcionar casi como una consola típica o un modo texto, solamente dibujas un plano hecho de cuadrados y vas cambiando la coordenada de textura de cada uno, para definir que tiles tienen, así hice yo un mini motor de prueba y es rápido para procesadores lentos, funcionaba en un windows con OpenGL 1.0 y CPU de unos 40
Los motores Fenix y BennuGD usan SDL por compatibilidad, y siempre en modo software. Eso ha permitido que se haya portado a múltiples máquinas casi sin cambios y de forma inmediata: Windows, Linux, GP2X, Wiz, PSP, PS2, Wii, Dreamcast, Ouya, Android...
Hay un proyecto para crear una versión de BennuGD en OpenGL, pero SplinterGU es el único que lo está desarrollando y no tiene demasiado tiempo libre, así que alguien que le ayude le vendría bien :lol:
Bueno. Que conste que a mí la conversación me parece interesante, aunque pille sólo la mitad. :p
Pues lo que no pilles, lo preguntas, así aprendes y disfrutas :D :D :D
masteries
10/07/2020, 11:13
Los motores Fenix y BennuGD usan SDL por compatibilidad, y siempre en modo software. Eso ha permitido que se haya portado a múltiples máquinas casi sin cambios y de forma inmediata: Windows, Linux, GP2X, Wiz, PSP, PS2, Wii, Dreamcast, Ouya, Android...
xD He leído eso y me parto. El caso de esa máquina es muy particular, porque las SDL están implementadas sin tener en cuenta muchas historias del hardware, necesarias pero no imprescindibles, y por tanto las SDL rinden y funcionan ahí como el ****. Lo más que pude hacer, es parchear aquello que sí sabía y también tuve que reescribir las SDL_sound, porque ahí o tiras de interrupciones y DMA o lo llevabas claro para reproducir sonidos de forma decente.
Y aún es un parcheo pobre, porque los juegos originales usan la CPU de PS1, presente en PS2, para implementar el mezclador de audio y encolar la reproducción de sonidos; se permiten comprimir el sonido y todo... pero no tengo ejemplos de cómo hacer eso :(
Falta demasiada documentación y ejemplos en PS2 :( Por ejemplo en PS2 no hay gestión de memoria implementada, los malloc existen, pero cuando descargas algo de la RAM, eres tú mismo el que tiene que desfragmentar la memoria, para que puedas volver a cargar cosas; en los juegos comerciales se lo implementan ellos.
El de DreamCast tengo entendido que también petardea un poco por asuntos parecidos,
Ya, pero la cosa es que estás mencionando problemas del port de SDL, no de Fenix o BennuGD :lol:
Siempre se ha dicho "si hay un port de SDL, se puede portar Fenix", pero claro, el port de SDL tiene que estar bien hecho, tener en cuenta todas esas cosillas HW/SW del aparato...
El problema es portar SDL. Una vez hecho, el port, en teoría es sencillo... no inmediato porque hay que hacer ciertos cambios, como cierto mapeo de botones, ajustar los tiempos para sincronizar los FPS... depende del bicho al que vaya. Yo pude compilar BennuGD para GP2X y lo único que tuve que cambiar fue la constante del OS-ID, un par de botones mal mapeados, y listo, el resto fue casi copiar las cosas de Wiz.
Y claro, hice dos versiones porque hubo dos versiones de SDL: las del firm oficial y las del Open2X. Con el firm oficial funcionaba de lujo, pero algo más lento porque eran SDLs más antiguas, y el firm Open2X iba mejor, pero el sonido se desfasaba medio segundo, pero ya no me puse a investigar por qué.
Y eso es lo que le achaco a la versión de RG350, que hay un par de botones mal mapeados (A y B, al parecer), que el OS-ID es el de Linux (por lo que no puedo saber si estoy ejecutando en PC o en la consola), y la versión que es bastante antigua. Tampoco que BennuGD venga integrado en el firm sin posibilidad de cargar una versión más moderna desde la SD.
Pero es eso, la mayoría de problemas de DC es por el port SDL, o al menos, creo que los problemas que había poco tenían que ver con la parte de Bennu.
masteries
13/07/2020, 19:44
Pero es eso, la mayoría de problemas de DC es por el port SDL, o al menos, creo que los problemas que había poco tenían que ver con la parte de Bennu.
Efectivamente, es un problema de los drivers para el hardware que está debajo, que no están bien hechos.
Esas máquinas como no tienen un S.O. con los drivers, si no que los tienes que incluir tú mismo en el juego / programa, pues el curro necesario es para alucinar xD
El mezclador de audio (bueno es un driver para el adaptador de audio) que tuve que escribir para la PS2 y su port de Bennu, está casi reaprovechado 1:1 para el STE :D
Vale, pero no me digas que BennuGD no es fácil de portar a PS2, si todo el problema es de SDL, porque me dejas por mentiroso sin razón :lol:
La idea de SDL es la de abstraer al código del HW o del SW que hay debajo. Claro que, si debajo no hay drivers, ni SO ni na de na, pues hay que implementarlo :D
Así que, si ya tienes las SDL... o parte de ellas en el STE, ya estás tardando en portar BennuGD :awesome: Ya sólo falta el port al frigorífico ese del anuncio y a la Pokemon Mini.
Por cierto, muchas gracias por el curro de portar Bennu (y SDL) a PS2. Te lo dije en su día, pero nunca está de más repetirse :D Es bueno para el ego y las endorfinas esas :lol:
masteries
14/07/2020, 18:43
Por cierto, muchas gracias por el curro de portar Bennu (y SDL) a PS2. Te lo dije en su día, pero nunca está de más repetirse :D Es bueno para el ego y las endorfinas esas :lol:
Tampoco es un port tan bueno; me habría gustado usar la CPU de PS1 para el tema del audio (es lo que hacen los juegos comerciales), pero no sé cómo hacerlo... y luego está el problema de cargar datos en memoria y descargarlos, que las funciones load y unload de Bennu no tienen su respaldo; cuando haces un unload los datos se descargan, pero la memoria no se desfragmenta y si descargas y cargas muchas cosas... al final te quedas sin memoria disponible, porque ésta queda como un queso gruyere.
Los juegos comerciales implementan ellos mismos sus funciones "malloc y free"; y lo hacen usando otra vez la CPU de PS1, y tampoco sé cómo hacerlo...
Al final lo único que descargo cuando uso Bennu en PS2 es lo último que metía en memoria; el enorme .wav con la música... así no se queda fragmentada la memoria.
Por cierto, en el ST y el STE no estamos teniendo estos problemas al hacer free; tal vez estas implementaciones vienen en la ROM de la máquina; es triste que PS2 lo único que tenga es un kernel en tiempo-real como el de un microcontrolador, y ni funciones ni leches... :( Una falta de doc. / ejemplos muy grande, o la falta del SDK comercial, más bien esto último.
Recuerdo que en su momento se solía decir que era muy difícil programar para PS2, y creo que para PS3. Los detalles los desconozco, pero lo suyo es que haya algún tipo de documentación, aunque no sea la oficial.
Pero bueno, no creo que a estas alturas te venga nadie con exigencias. Supongo que se hacía así para que la gente pudiera aprovechar el 100% de la máquina, sin depender de un SO, un firm o algo por debajo que se dedique a consumir recursos, al fin y al cabo, es una consola y no es multitarea.
Está bien saber lo de la memoria, para tener cuidado cuando se haga un juego para ella, no vaya a a ser que por aprovechar la memoria y andar cargando y descargando nos quedemos sin :D
Lo de ps3 era porque estaba "mal diseñada", pues no es lo mismo un porcesador multicore que tener un monocore con varios SPEs. Mientras que un multicore es relativamente facil de programar (cada core hace una cosa), en un procesador monocore con varios SPEs, el core principal es el que reparte el trabajo entre los hilos de los SPEs, por lo que es muy facil provocar un cuello de botella si no se programa con cuidado.
Tampoco es un port tan bueno; me habría gustado usar la CPU de PS1 para el tema del audio (es lo que hacen los juegos comerciales), pero no sé cómo hacerlo... y luego está el problema de cargar datos en memoria y descargarlos, que las funciones load y unload de Bennu no tienen su respaldo; cuando haces un unload los datos se descargan, pero la memoria no se desfragmenta y si descargas y cargas muchas cosas... al final te quedas sin memoria disponible, porque ésta queda como un queso gruyere.
Los juegos comerciales implementan ellos mismos sus funciones "malloc y free"; y lo hacen usando otra vez la CPU de PS1, y tampoco sé cómo hacerlo...
Al final lo único que descargo cuando uso Bennu en PS2 es lo último que metía en memoria; el enorme .wav con la música... así no se queda fragmentada la memoria.
Por cierto, en el ST y el STE no estamos teniendo estos problemas al hacer free; tal vez estas implementaciones vienen en la ROM de la máquina; es triste que PS2 lo único que tenga es un kernel en tiempo-real como el de un microcontrolador, y ni funciones ni leches... :( Una falta de doc. / ejemplos muy grande, o la falta del SDK comercial, más bien esto último.
Yo uso estas rutinas en la Jaguar y no tengo ningún problema.
53769
masteries
15/07/2020, 16:43
Yo uso estas rutinas en la Jaguar y no tengo ningún problema.
53769
Pintan muy bien, breves y autocontenidas.
He estado viendo que tiene función de compactado. Tendré que ir probándolas,
¡Gracias!
SplinterGU
15/07/2020, 23:29
Tampoco es un port tan bueno; me habría gustado usar la CPU de PS1 para el tema del audio (es lo que hacen los juegos comerciales), pero no sé cómo hacerlo... y luego está el problema de cargar datos en memoria y descargarlos, que las funciones load y unload de Bennu no tienen su respaldo; cuando haces un unload los datos se descargan, pero la memoria no se desfragmenta y si descargas y cargas muchas cosas... al final te quedas sin memoria disponible, porque ésta queda como un queso gruyere.
Los juegos comerciales implementan ellos mismos sus funciones "malloc y free"; y lo hacen usando otra vez la CPU de PS1, y tampoco sé cómo hacerlo...
Al final lo único que descargo cuando uso Bennu en PS2 es lo último que metía en memoria; el enorme .wav con la música... así no se queda fragmentada la memoria.
Por cierto, en el ST y el STE no estamos teniendo estos problemas al hacer free; tal vez estas implementaciones vienen en la ROM de la máquina; es triste que PS2 lo único que tenga es un kernel en tiempo-real como el de un microcontrolador, y ni funciones ni leches... :( Una falta de doc. / ejemplos muy grande, o la falta del SDK comercial, más bien esto último.
la fragmentacion de memoria siempre es un problema en todas las plataformas, yo recuerdo que hace muchos años tuve que hacer un manejador propio de memoria para PC en un sistema non-stop de alta disponibilidad, porque fragmentaba muchisimo... el tema esta en reaprovechar inteligentemente la memoria, en los mallocs/free nunca se defragmenta la memoria, lo que necesitas es un buen sistema donde los mallocs asignen el primer o ultimo segmento mas chico disponible dentro de un area ya fragmentada, intentando que los agujeros libres queden agrupados para liberarlos luego en un solo bloque mas grande...
con respecto a bennugd por opengl que menciona drumpi, esta estancado, todo lo opengl esta funcional, pero faltan algunas otras cosas, y voy a hacer un rediseño a todo, hacerlo algo mas profesional... asi como es bennugd no es muy profesional que digamos...
eso de dibujar solo los cambios de un sprite lo hace ya bennugd, son las "dirty rects"... sin embargo, en opengl ya no usa eso, dibuja completo el sprite...
SplinterGU
16/07/2020, 01:25
ahi lei el hilo, esta muy lindo el engine de msdos
mills332
16/07/2020, 17:25
es triste que PS2 lo único que tenga es un kernel en tiempo-real como el de un microcontrolador, y ni funciones ni leches... :( Una falta de doc. / ejemplos muy grande, o la falta del SDK comercial, más bien esto último.
Nunca vi demasiado homebrew para PS2, a parte de los emuladores, no se, debió ser difícil. Pero en PSP estaba tirado y aun así casi nadie usaba las funciones hardware, todo a lo bestia [Ahhh].
Normalmente a mayor éxito de la consola menor scene homebrew. Tal vez la única excepción sea la NES, pero mira que pocas sosas hay para la PSX (a pesar de tener la yaroze) y la PS2.
Y la 2600... pero ese caso creo que es porque la gente es masoca.
princemegahit
19/07/2020, 00:46
Lo de ps3 era porque estaba "mal diseñada", pues no es lo mismo un porcesador multicore que tener un monocore con varios SPEs. Mientras que un multicore es relativamente facil de programar (cada core hace una cosa), en un procesador monocore con varios SPEs, el core principal es el que reparte el trabajo entre los hilos de los SPEs, por lo que es muy facil provocar un cuello de botella si no se programa con cuidado.
Vaya timo lo de los SPEs , me gustaria saber cuantos juegos habran aprovechado de verdad los SPEs.
mills332
21/01/2021, 11:37
He hecho una demo para MS-DOS copiando la demo "Cute Demo" que hice para Game Boy Color. Quería que funcionase bien en un 8086 a 8 MHz(como siempre), y si hago caso al emulador PCem (la captura del video está sacada de PCem), pues lo conseguí. (También me han dicho que lo han probado y funciona bien en 8088 a 9 MHz).
He tenido que utilizar todas las funciones hardware de VGA que descubrí programando el motor de juego, y alguna mas que encontré (como la posibilidad de estirar la imagen por hardware). También utilizo todos los trucos del ensamblador x86 que encontré, para recrear efectos tipicos de demos (Parallax, rotozoom, ciclos de paletas...). Espero que sirva como resumen de lo que se puede lograr en los primeros PC con la ayuda de VGA.
El código fuente esta en C con ensamblador "inline" (que es como más cómodo me resulta usar el ensambblador sin perderme en miles de lineas de código).
https://www.youtube.com/watch?v=EJwx2Wd_ciQ
Fuente: https://github.com/mills32/CUTE_DEMO-MS-DOS
masteries
21/01/2021, 12:05
¡Se sale Sr. Mills332!
Un 8086 a 8 MHz con una VGA; nos queda claro que la VGA se caga en los ST/STE/Amiga 500; pese a ser a nivel hardware de vídeo un concepto más sencillo, que el global del hardware de vídeo de algunas de las citadas máquinas.
Me atrevo a decir que incluso le da sopas con onda a una Super Nintendo; cierto que se han empleado un montón de trucos y descubrimientos que en su día quizá no se conocieron, o los conocieron unos pocos. Pero es que las demos de STE / A500 que hay a este nivel, han necesitado de la colaboración de Gurús para hacerlas realidad; y disponen de una CPU mejor que el 8086, y encima nos dices
que funciona igual de bien en un 8088 que es de 8 bits, y eso ya es la traca.
Vale que muchos de los trucos que has usado los llamas "Completely faked"; pero en una demo técnica, e incluso los videojuegos; están hasta el tope de "fakes" de esos, de hecho esos "fakes" acaban siendo la manera habitual de dibujar muchas cosas... como iba a mover un Atari ST o un Amiga 500 la carretera en la serie de juegos Lotus (¿repintando el 50% de la pantalla a 50 / 60 fps? Claro que no, recurren a trucos de estos).
¡Me encanta lo que has logrado!
DarkDijkstra
21/01/2021, 12:20
¡Pintaza! :brindis:
En cuanto tenga un rato lo pruebo en mi "pequeñín" (8088 10Mhz) Lástima que no puedo pinchar la VGA y la Adlib al mismo tiempo XD
mills332
21/01/2021, 13:24
¡Se sale Sr. Mills332!
Un 8086 a 8 MHz con una VGA; nos queda claro que la VGA se caga en los ST/STE/Amiga 500; pese a ser a nivel hardware de vídeo un concepto más sencillo, que el global del hardware de vídeo de algunas de las citadas máquinas.
Me atrevo a decir que incluso le da sopas con onda a una Super Nintendo; cierto que se han empleado un montón de trucos y descubrimientos que en su día quizá no se conocieron, o los conocieron unos pocos. Pero es que las demos de STE / A500 que hay a este nivel, han necesitado de la colaboración de Gurús para hacerlas realidad; y disponen de una CPU mejor que el 8086, y encima nos dices
que funciona igual de bien en un 8088 que es de 8 bits, y eso ya es la traca.
Vale que muchos de los trucos que has usado los llamas "Completely faked"; pero en una demo técnica, e incluso los videojuegos; están hasta el tope de "fakes" de esos, de hecho esos "fakes" acaban siendo la manera habitual de dibujar muchas cosas... como iba a mover un Atari ST o un Amiga 500 la carretera en la serie de juegos Lotus (¿repintando el 50% de la pantalla a 50 / 60 fps? Claro que no, recurren a trucos de estos).
¡Me encanta lo que has logrado!
Bueno a ver, cagarse no se caga jaja. Pero es cierto que si se hubieran utilizado estos trucos en mas juegos y con un 286 (Creo que la cpu 68000 esta mas cerca del 286), si se habrian logrado cosas igual que las de amiga. Por ej, gastas 240 colores para el degradado de fondo del homer marciano, pero te quedan 16 colores para los sprites y el escenario, y podrias hacer el titus the fox a 50 fps en un 286 con los sprites y todo (ese juego solo usa 16 colores para todo). Claro que hay algun juego de 286 que hace eso, o algo parecido (doofus), pero no fue lo común.
Y claro ese sprite del cohete.. es mentira, si que esta dibujandolo, pero de 4 en 4 pixeles y no lo borra, simplemente tiene el borde con los colores del fondo y al moverse va dejando el mismo rastro y parece que se borra.
De todas formas la VGA es muy cutre, el scroll es un horror, ocupa 15 lineas de codigo, pero algo es algo.
Pero tener VGA y un 8088 era muy raro, lo normal seria tener un 386 y si me apuras un 286.
Al final pasa lo de siempre, no había mucha documentación sobre la VGA y si haces algo especifico para VGA dejas al resto de usuarios fuera.
mills332
21/01/2021, 13:48
Es cierto, los 8086 y muchos 286 aún usaban EGA o hasta CGA, pocos se molestaron en usar trucos, si a base de fuerza bruta los movía más o menos, pues ya está.
JoJo_ReloadeD
21/01/2021, 15:32
Wow, impresionante... cuando tenga un rato lo pruebo en hardware real :)
princemegahit
21/01/2021, 17:16
Wow, impresionante... cuando tenga un rato lo pruebo en hardware real :)
Queremos video. Yo seré el primero en comentar que eres un farsante , que detrás hay un pentium moviendo eso :quepalmo:
mills332
21/01/2021, 17:38
Queremos video. Yo seré el primero en comentar que eres un farsante , que detrás hay un pentium moviendo eso :quepalmo:
Jaja, Yo también quiero video, lo único que podria fallar es el scroll horizontal, pero eso tendria arreglo, lo malo es que no tengo una vga real, lo mas cercano es pcem o un core en fpga. Lo malo del scroll es que falla en algunas vga y svga, creo que por eso los juegos de commander keen tenian una opcion para que fuese compatible con mas tarjetas
JoJo_ReloadeD
21/01/2021, 18:32
Jaja, Yo también quiero video, lo único que podria fallar es el scroll horizontal, pero eso tendria arreglo, lo malo es que no tengo una vga real, lo mas cercano es pcem o un core en fpga. Lo malo del scroll es que falla en algunas vga y svga, creo que por eso los juegos de commander keen tenian una opcion para que fuese compatible con mas tarjetas
eso tiene solucion...
-----Actualizado-----
Acabo de probarlo en un v20 primero a 10mhz, aqui la musica adlib se oia mal. Luego ese mismo equipo a 4.77, aqui ya se oia perfectamente.
Impresionante, no hay mas palabras, incluso a 4.77mhz salvo un poco de flicker y alguna escena que se ralentiza un poco.. va tan fino como en el video que habeis visto. Cuando pueda hare un video en condiciones, probando tambien 8088s
mills332
21/01/2021, 19:51
eso tiene solucion...
-----Actualizado-----
Acabo de probarlo en un v20 primero a 10mhz, aqui la musica adlib se oia mal. Luego ese mismo equipo a 4.77, aqui ya se oia perfectamente.
Impresionante, no hay mas palabras, incluso a 4.77mhz salvo un poco de flicker y alguna escena que se ralentiza un poco.. va tan fino como en el video que habeis visto. Cuando pueda hare un video en condiciones, probando tambien 8088s
Que bueno, o sea que el scroll va suave :). Ý que es lo que suena mal en el v20?. Lo de la musica puede ser porque el v20 no tiene los interrupts igual que los de intel, o algo asi... y la musica la reproduce con un interrupt a veces, y otras veces va con el vsync. Luego si hay parpadeos es normal en la parte de arriba de la imagen.
JoJo_ReloadeD
22/01/2021, 09:19
Bueno, he grabado un cutrevideo en un v20, en un 8088 aun no he tenido tiempo de hacerlo. He tenido que grabarlo literalmente con el movil en un tft, el upscaler que uso para capturar literalmente se volvia loco entre escena y escena, imagino que usas timings y resoluciones no estandar y de ahi el asunto.
https://www.youtube.com/watch?v=cUcUj3pZWac&feature=youtu.be&ab_channel=jojoreloaded
Finalmente rula la adlib bien en este equipo, por algun motivo teniendolo a 10mhz se le iba la pinza. Ahora esta a 9.5mhz; la primera parte del video es la demo a esa velocidad y luego lo bajo a 4.77, todo sin editar y sin cortes.
btw, tienes un dm.
OscarBraindeaD
22/01/2021, 09:50
Hola a todos,
es sorprendente lo que has conseguido Mills, enhorabuena. He buscado la versión de la demo de Gameboy color y es aún más alucinante teniendo en cuenta las limitaciones del hardware. Realmente impresionante.
Saludos!
mills332
22/01/2021, 11:39
Bueno, he grabado un cutrevideo en un v20, en un 8088 aun no he tenido tiempo de hacerlo. He tenido que grabarlo literalmente con el movil en un tft, el upscaler que uso para capturar literalmente se volvia loco entre escena y escena, imagino que usas timings y resoluciones no estandar y de ahi el asunto.
Finalmente rula la adlib bien en este equipo, por algun motivo teniendolo a 10mhz se le iba la pinza. Ahora esta a 9.5mhz; la primera parte del video es la demo a esa velocidad y luego lo bajo a 4.77, todo sin editar y sin cortes.
btw, tienes un dm.
Muchas gracias por probarlo!.
Fíjate que el V20 va mejor que el 8086 8 MHz (según pcem) porque la nube de arriba en la escena del homer, no parpadea a 9 Mhz, (en el 8086 emulado no le daba tiempo a borrarla y dibujarla).
La música suena demasiado rápido, la hice con reality adlib tracker a 50 Hz, y se supone que la había convertido a un archivo imf con la velocidad cambiada para que funcionase bien a 60 Hz. Supongo que podría ser también cosa de los interrupts, que van diferentes. Lo que me alegra es que no parece cambiar de velocidad a pesar de el lío que hice apagando y encendiendo los interrupts para que no interfiriesen en los gráficos.
Por lo demás, solo vi que el rotozoon se invierte en algunos puntos a 9 Mhz, y no se invierte a 4.77 Mhz, pienso que será algo de las variables, que al llegar a 256 no vuelven a cero por alguna razón, o algo así... jaja.
El modo es todo el rato el mismo, 320x240 60 Hz, pero tal vez al cambiar algún parámetro, como cuando se estira la vram en el rotozoom, se vuelvan locas las capturadoras, eso ya no lo se.
Y me encanta como va de bien el scroll, solo se ralentizó un poco a 4.77, pero vamos, que en vez de 60fps tal vez se ponga a 50, todo un logro.
Gracias a los que os ha gustado (OscarBraindeaD, masteries, DarkDijkstra ...).
JoJo_ReloadeD
23/01/2021, 07:21
Otro video de la demo, aqui esta rulando en una placa de IBM 5150, el primer pc de la historia, un 8088 a 4,77mhz:
https://www.youtube.com/watch?v=4ub4jBgNdlM
Aqui ya muchas partes se le atragantan, hasta la musica adlib se ralentiza xD Aun con todo es un hito estos efectos en un equipo taaan lento.
Un par de videos mas mostrando los setups usados, primero el anterior, es una placa Xi 8088:
https://www.youtube.com/watch?v=pDElDsWmjf0
Y el 5150:
https://www.youtube.com/watch?v=hYC1uYBrVBc
masteries
23/01/2021, 11:17
Pues no se atraganta tanto como esperaba,
mills332
23/01/2021, 13:23
Se puede hacer que funcione a 30 fps y funcionaría bien a 4.77, pero para los sprites hay que añadir una especie de doble buffer pequeñito, que complica un poco el código. Lo mismo se aplica al motor de juego que hice, que es practicamente el mismo codigo que utiliza esta demo (excepto algunas cosas).
La rotación va mejor de lo que me esperaba.
mills332
23/01/2021, 14:12
La rotación va mejor de lo que me esperaba.
Me ayudó un poco "trixter" en otro foro, por lo visto es muy conocido en cosas de este tipo, y yo tenía un código funcionando a medias, me dijo que si, que esa era la forma más rápida.
La rotación la hace la CPU claro, lo que hace es guardar una imagen de 256x256 pixels ( = bytes en VGA), y con una función en ensamblador va leyendo bytes y poniendolos en pantalla. Va siguiendo una tabla que le hace saltar un número precalculado de bytes en cada linea que dibuja, y así genera la imagen rotada o con zoom. Como todo son variables de un byte, al llegar a 256 saltan a cero y hace el efecto de "wrap" o volver a cero, como si fuera una textura en hardware moderno, con lo que se repite todo el rato.
Llenar toda la pantalla seria imposible a 320x240, así que la VGA viene al rescate y puedes escribir un color a 4 pixels de una vez, si estan activados los 4 planos de la vram, con lo que la resolucioón horizontal se reduce a 80. Luego trixter me dijo que la VGA puede estirar la vram en vertical (cosa que yo no sabía), así que si la estiras 4 veces, obtienes una resolución vertical de 60 (de hecho se ve como se estira antes de empezar el rotozoom). Si le añades un poco de bordes negros, pues ya está.
También había visto un efecto asi en el demo Legend para 286, (pero no tenían la fuente liberada) en un 286 va a 60 fps :).
JoJo_ReloadeD
24/01/2021, 09:04
La ultima prueba, en un 286 a 6mhz:
https://www.youtube.com/watch?v=Sfq9gN37a4s&ab_channel=jojoreloaded
mills332
07/03/2021, 12:34
Aunque el título del hilo es "programando con VGA", meto esto aquí porque lo estoy guardando todo en el mismo github de siempre (https://github.com/mills32/Little-Game-Engine-for-VGA).
Recopilando códigos para reproducir samples con Sound Blaster, he conseguido mezclar samples con la música del chip yamaha y el resultado es mejor de lo que esperaba.
Como siempre, hay drivers creados para PC rápidos y que necesitan mas ram. Así que he creado una pequeña función que carga y reproduce los sonidos muy rápido para que funcione bien en los ordenadores mas lentos y sin utilizar mucha ram.
Las tarjetas Sound Blaster pueden leer directamente datos de la ram con DMA, pero necesitan que los datos estén dentro de una "página física" de 64K. Esto significa que la ram está dividida en partes de 64K, y si un sonido pasa a otra parte, mecesitas cambiar de "página" para que la función DMA pueda leer los datos. Eso era complicado, lento, y requiere mucha ram, así que estamos limitados a 64K de sonido.
Pero al final solo he podido utilizar 32K, porque es imposible reservar una página completa usando malloc y calloc. Reservando 32K, puedes saber si ese trozo cae dentro de una página, y si no, reservar los siguientes 32K, que estaremos seguros de que no pasan la frontera a otra página. Los primeros 32K los podemos liberar o utilizar para otra cosa.
54383
Parece que tenemos muy poco espacio para sonidos, pero nos sobra, porque he utilizado sonidos PCM de 8 bit, (8192 y 11025 Hz). Suenan suficientemente bien, y nos caben 15 o 20 samples pequeñitos.
Para sincronizar la reproducción de sonidos con la música, la función espera a que llegue el comando B0, B1 o B2 del archivo imf, (significa que se ha enviado la instrucción "seleccionar frecuencia" para los canales 0, 1 o 2 del chip OPL2, todo está resumido en el readme de github).
Además de utilizar sonidos para la percusión en la música, se pueden reproducir sonidos directamente para implementar efectos en el juego. Solo he implementado un canal, para que sea compatible con cualquier Sound Blaster, por tanto, se interrumpirá la reproduccion de samples de la música, si reproducimos un efecto de sonido, y viceversa.
He grabado estos ejemplos de dosbox porque mi pc metia mucho ruido si los grababa de la Sound Blaster real, pero sirve de ejemplo. La diferencia mas notable, es que los sonidos PCM suenan mucho más claros en el hardware real.
54380
54381
54382
JoJo_ReloadeD
08/03/2021, 13:32
Suena cojonudo :)
La verdad es que suena bien si, y si no consume muchos recursos es un puntazo.
mills332
21/06/2021, 12:32
Más pruebas extrañas en MS_DOS, en este caso quise comprobar si el modo texto se podria utilizar como un modo "map/tile" de consolas. Estos modos utilizan una parte de la memoria de video para guardar caracteres o tiles, y otra parte para guardar un mapa de como dibujarlos en pantalla.
En el caso de la VGA, el modo texto puede guardar unos 512 caracteres de 8x8 pixeles (dos colores cada uno), pero solo he conseguido que acceda a 256 caracteres. Puede mostrar mapas compuestos de 80x50 tiles (con caracteres de 8x8 pixeles), en resoluciones de 720x400 (dejando separaciones entre los tiles), o 640x400 (sin separaciones, este modo no funciona en monitores modernos).
Los caracteres se cargan desde imagenes png, modificando unos puertos de la VGA, que están pensados para cambiar la fuente del texto, pero también sirven para esto :).
Además podemos utilizar el scroll por hardware y actualizar una columna o una fila de tiles fuera de la parte visible, en un proceso muy rápido que a penas utiliza CPU. Sólamente tenemos que actualizar 80+50 => 130 x 2 = 260 bytes, ya que cada celda corresponde a dos bytes, un byte para el caracter y otro para definir los dos colores (16 colores para el fondo, 16 para el "texto").
Este modo VGA solo tiene un sprite rectangular que parpadea y solo se puede poner en posiciones multiplos de 8 (o sea, el cursor). Dibujar sprites "de verdad "se puede lograr reservando unos cuantos caracteres para guardar y actualizar gráficos, pero en las pruebas que he hecho, el proceso es muy lento, o se ve muy mal, haciendo que este modo sea poco práctico para hacer juegos bonitos.
https://www.youtube.com/watch?v=AKaxPwP3A-Y
Parece ser que la tarjeta EGA no es compatible con este modo de caracteres 8x8, aunque debería funcionar igual.
No he subido aun el código fuente a ningún sitio, porque está muy desordenado, he comprobado que funciona en vga real, y no necesita a penas cpu para mostrar el mapa, (los sprites ya son otra historia).
josepzin
21/06/2021, 14:02
Mola!!
Por lo que entiendo estas usando caracteres redefinidos?? o sea que es modo texto, verdad?
Aunque sin sprites no hay gloria :P
mills332
21/06/2021, 14:31
Mola!!
Por lo que entiendo estas usando caracteres redefinidos?? o sea que es modo texto, verdad?
Aunque sin sprites no hay gloria :P
Si, mira al principio como se ven los caracteres de texto, y luego se ve el cursor negro por la parte de arriba del mapa
Pero es que las limitaciones de colores y lo complejo de los sprites hacen que merezca mas la pena el modo grafico, incluso para los 8088.
En cuanto pasas encima de algo, a penas se ve a mario, y ademas se mueve en saltos de 8 en 8 pixeles. Moverlo pixel a pixel requiere mucha ram, o mucha cpu, porque necesita 16 celdas en el caso de este ejemplo. Y si ademas hago operaciones para que se fusionen los graficos de fondo con el sprite, para que quede mejor, ya añades un monton de cosas mas, no se, lo veo mucho mas lento que el modo grafico, pero habria que probarlo.
54585
josepzin
21/06/2021, 15:29
Si, claro, se entiende! cuando usas caracteres redefinidos no hay otra opción que los sprites se superpongan asi y hagan color clash. A menos que tengas un C64 y uses los sprites por hardware :P
masteries
21/06/2021, 18:59
Si, mira al principio como se ven los caracteres de texto, y luego se ve el cursor negro por la parte de arriba del mapa
Pero es que las limitaciones de colores y lo complejo de los sprites hacen que merezca mas la pena el modo grafico, incluso para los 8088.
En cuanto pasas encima de algo, a penas se ve a mario, y ademas se mueve en saltos de 8 en 8 pixeles. Moverlo pixel a pixel requiere mucha ram, o mucha cpu, porque necesita 16 celdas en el caso de este ejemplo. Y si ademas hago operaciones para que se fusionen los graficos de fondo con el sprite, para que quede mejor, ya añades un monton de cosas mas, no se, lo veo mucho mas lento que el modo grafico, pero habria que probarlo.
Necesita pre-desplazar los gráficos, para ahorrar memoria puede guardar sólo los predesplazamientos de 2 en 2 píxeles.
Y también necesitará optimizar el código para cada pre-desplazamiento, vamos sprites compilados.
Se está metiendo en una fiesta muy gorda xD
Creo que los gráficos pre-desplazados hay que dejarlos para las máquinas que de verdad los necesitaban para obtener un buen rendimiento,
Hay muchos juegos para Atari xe/xl que van asi, modo texto y los sprites van por software redefiniendo caracteres, aunque no necesitas tener los tiles pre-rotados porque tienes scroll por hardware.
mills332
28/03/2022, 20:43
Mas curiosidades para MS-DOS y ordenadores super lentos.
https://www.youtube.com/watch?v=JkjJUsnUdxY
A lo tonto a ver que salía, y me ha quedado muy bien. Se pueden hacer cosas estilo Spectrum perfectamente, además al tener scroll y ser un modo organizado en mapas, es mucho más rápido mover todo. Simular los sprites es algo lento, si que se pueden poner 3 o 4 en un 8088, pero el codigo es un poco malo según está.
No pude evitar usar el mapa de la demo que hice en game boy, tenía que hacer el parallax, porque podía :).
fbustamante
28/03/2022, 21:26
¡Guay!
masteries
29/03/2022, 10:03
¡Está genial!
Se nota que hay un gran trabajo detrás, y mucho mimo por los detalles. Enhorabuena :)
Sr.Polilla
29/03/2022, 14:30
Es una pasada de demo, mola muchísimo!
OscarBraindeaD
29/03/2022, 20:31
Enhorabuena, ese scroll parallax con varios planos está muy, muy logrado!
tSuKiYoMi
29/03/2022, 23:24
Vaya pasada tío. ¿Te resulto difícil encontrar documentación actualizada sobre como empezar a programar para MS-DOS?
mills332
29/03/2022, 23:50
Vaya pasada tío. ¿Te resulto difícil encontrar documentación actualizada sobre como empezar a programar para MS-DOS?
Si, sobre todo del scroll hardware, y del modo texto ya directamente el manual, o mirar lo que hace registro por registro, a penas hay ejemplos .
Que cosas, la de juegos en msdos que nos hemos comido con tearing y resulta que las tarjetas llevaban scroll por hardware, sabia que en VGA tenias pero no sabia que funcionaran en otros modos.
josepzin
30/03/2022, 13:56
Espectacular!!!!
¿Entonces esto es un 8088 con VGA?
Curiosos esos sprites espectrunianos con ¿color clash?
mills332
30/03/2022, 18:18
Espectacular!!!!
¿Entonces esto es un 8088 con VGA?
Curiosos esos sprites espectrunianos con ¿color clash?
Pues en 8088 4.77 le sobra si. Lo sprites con color clash claro que si, pero me parece que es mas lento que en spectrum, por que hay que ir actualizando las celdas de forma un poco complicada.
Me gustaria ver como quedan juegos de spectrum en este modo.
Es que el spectrum pese a tener un formato raro de pantalla, si estas apuntando a un carácter la linea de debajo esta a 256 bytes de distancia, por lo que puedes incrementar el registro H de la pareja HL y voila ya esta. En el PC ademas como tienes que pasar por el bus ISA eso te ralentizara mas.
mills332
30/03/2022, 20:05
Es que el spectrum pese a tener un formato raro de pantalla, si estas apuntando a un carácter la linea de debajo esta a 256 bytes de distancia, por lo que puedes incrementar el registro H de la pareja HL y voila ya esta. En el PC ademas como tienes que pasar por el bus ISA eso te ralentizara mas.
Si en este modo, estan todos los datos de los caracteres seguidos, pero cada caracter es 8x32 en la vram, y solo se ven las primeras 8 lineas claro... o sea que hay que saltar 24 bytes hasta el siguiente, y luego ir modificando el mapa claro, que no puedes dibujar nada directamente, solo mover celdas. Espero que al menos pueda mover 3 o 4 sprites como los de la demo, y ya tenemos de sobra
SplinterGU
31/03/2022, 07:27
Mas curiosidades para MS-DOS y ordenadores super lentos.
https://www.youtube.com/watch?v=JkjJUsnUdxY
A lo tonto a ver que salía, y me ha quedado muy bien. Se pueden hacer cosas estilo Spectrum perfectamente, además al tener scroll y ser un modo organizado en mapas, es mucho más rápido mover todo. Simular los sprites es algo lento, si que se pueden poner 3 o 4 en un 8088, pero el codigo es un poco malo según está.
No pude evitar usar el mapa de la demo que hice en game boy, tenía que hacer el parallax, porque podía :).
me encanto! felicitaciones! quedo formidable!
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.