phsoft
|
|
« : 12 de Septiembre de 2011, 03:30:56 pm » |
|
buenas a todos,
vengo utilizando bit buster "extreme" con el código que colgara pitpan en los snippets (código que me funciona descomentando los 4 primeros inc hl) y me gustaría saber si alguien ha utilizado msx-o-mizer y/o pletter con asMSX, qué opinión le merecen estos tres (u otros, como exomizer), cuál utilizáis de manera habitual, etc
luego también consultaros la manera como venís usando estos compresores. lo que hago en mis pruebas es comprimir un solo bloque homogéneo de datos (un pantallazo de screen2, un banco de sonido de ayFX, una pantalla del juego). esto va en rom, en mi caso. cada vez que quiero usarlo tengo que reservarle un espacio en ram, obviamente, donde descomprimir antes de utilizar (para carga a vram, pej), y no conocer las direcciones dentro del bloque comprimido (de las diferentes partes del mismo, caso de haberlas) resulta en un poco coñazo a la hora de redireccionar (una vez está descomprimido). imaginad que el bloque contiene 10 pantallas en lugar de una y que quiero cargar la número 3. no sé si me explico. la cuestión es cómo manejáis vosotros este asunto.. con etiquetas en el fichero bin, por ejemplo, con el que generáis los datas que vais a comprimir, y tirando luego de fichero de símbolos para recalcular las direcciones?.. así es como lo vengo haciendo pero ya digo que es un poco coñazo, no?
otra duda es qué sabéis sobre los resultados.. serán mejores al comprimir un bloque de datos pequeño (como una pantalla del juego) o mejorarán si se comprimen bloques grandes?
otra duda más es qué sabéis sobre la posibilidad de descomprimir parcialmente un bloque de datos. es decir: existe alguna forma de disponer de subbloques de datos dentro del fichero comprimido para poder tirar desde cada uno de ellos y descomprimir solo desde ahí y hasta el sgte, por ejemplo?
saludos, - paco
|
|
|
En línea
|
|
|
|
samsaga2
|
|
« Respuesta #1 : 12 de Septiembre de 2011, 03:55:37 pm » |
|
De todos los que he probado el que mejor me ha ido es el pletter. Es un poco más lento que la media pero comprime más.
Por otro lado con ningún compresor lograrás descomprimir sólo una única parte del bloque. Lo que puedes hacer es separar esas partes y comprimirlas una por una.
Asegurate que realmente te hace falta comprimir porque ralentiza bastante la carga. Pudiendo tener cartuchos de un mega muchas veces no hace falta.
|
|
|
En línea
|
|
|
|
pitpan
|
|
« Respuesta #2 : 12 de Septiembre de 2011, 04:08:16 pm » |
|
Ralentizaciones? Pues llevo bastante usando compresores y descompresores y no me ha sucedido nunca. Evidentemente, no descomprimo con el juego en acción, con todo en marcha, sino entre partes que permiten hacer una pausa, pero vamos, que no se me escapan muchos frames cuando me pongo a descomprimir...
Pletter comprime mejor, pero el descompresor es más grande - y necesitas un descompresor distinto para cada tipo de compresión aplicado - . Con el Bitbuster me manejo mejor, y la ganancia que me aporta Pletter no justifica el cambio.
En cuanto a que si es mejor comprimir mucho o poco, sólo te puedo dar una respuesta: depende. Por lo tanto, haz pruebas con los datos concretos que tengas y determina cuál es la mejor solución para cada escenario. Ten en cuenta que la efectividad de la compresión tiene que ver con lo que se repiten los datos. Al final, es pura estadística.
Había por ahí una rutina de descompresión directa de bitbuster a VRAM que no funcionaba mal, aunque era un poco lenta si no se le ponía un buffer adecuado de memoria para trabajar.
|
|
|
En línea
|
|
|
|
samsaga2
|
|
« Respuesta #3 : 12 de Septiembre de 2011, 04:22:09 pm » |
|
Ralentizaciones? Pues llevo bastante usando compresores y descompresores y no me ha sucedido nunca. Evidentemente, no descomprimo con el juego en acción, con todo en marcha, sino entre partes que permiten hacer una pausa, pero vamos, que no se me escapan muchos frames cuando me pongo a descomprimir...
Tal vez me expliqué mal. Me refiero a la hora de cargar. Y claro está todo depende de la cantidad de datos. Cargar una pantalla comprimida con pletter en screen 8 tarda sus buenos segundos. Si tienes una rom en la que te sobra el espacio pues realmente no hace falta comprimir muchos datos, pero esto ya depende de lo que esté montando y la cantidad de datos que le sean necesarios.
|
|
|
En línea
|
|
|
|
phsoft
|
|
« Respuesta #4 : 12 de Septiembre de 2011, 07:48:42 pm » |
|
buenas, ñores, gracias por comentar sam, si tienes un descompresor para pletter funcional con código asMSX pues te agradecería que lo compartieras, claro. en las pruebas que hice, que tampoco hice muchas, ojo, no logré que funcionara. teniendo bitbuster este tema pues no es importante -para mi, digo- solo curiosidad, de momento. entiendo lo que dices de los megaroms pero por ahora pretendo crear una rom de 32kbs. si pudiera ser de 16kbs pues todavía mejor, pero con logo, pantalla inicial, 3 ó 4 pistas de pt3, etc, pues lo dudo en cuanto a la velocidad no tengo queja de bitbuster... bueno, tampoco la tengo en ningún otro sentido, conste, y aunque en mis pruebas caseras pues es el que menos comprime de los mencionados, esto también. yo hago como pitpan, nunca descomprimo nada en momentos críticos, podríamos decir. utilizo los cambios de pantalla, las transiciones, etc. de todas formas en alguna prueba de las que he subido si que descomprimía una pista de PT3 de casi 4kbs y, como digo, bitbuster en velocidad va estupendo me parece un poco raro, no sé, que no exista un compresor que genere bloques de codigo comprimido de los que puedas tirar y un tabla, al inicio, con los punteros de descompresion a dichos bloques. a 2bytes x puntero a bloque + palabra fin bloque, si hiciera falta, tampoco sería pa matarse, no sé. igual digo una tontada ya que esto se puede generar con facilidad desde asMSX, claro, pero a la hora de trabajar con datos comprimidos que el bloque ya te venga indexado me parece lo más práctico... que no es por no currar... si hay que currar se curra, eh! en fin, pienso que al comprimir más datos, pongamos 2kb-4kb, el resultado será mejor, en líneas generales, que al comprimir bloques más pequeños 512-768bytes (una pantalla en screen1, pej). ahora que, como bien dice pitpan, esto habría que verlo con las pistolas en la mano pero claro, el tema de descomprimir bte de golpe -pongamos 8kb- te genera también el poblema adicional de dónde sacar ram (sin rutinas de cambios de páginas y con bios activa, se entiende) para descomprimir aquello, no sé.. vosotros los cartuchos los hacéis desde 0 o 0x4000 o cómo? con bios o sin bios? volcáis a páginas ocultas para tareas, pej, de descompresión de datos? saludos, - paco pd: por cierto que el descompresor para bitbuster/asMSX de pitpan va con el ejemplo del ayfx
|
|
|
En línea
|
|
|
|
pitpan
|
|
« Respuesta #5 : 12 de Septiembre de 2011, 08:58:30 pm » |
|
Hola. Hazte un favor y deja la BIOS siempre a la vista si estás programando una ROM para MSX1. Si no tienes que llegar a las 48 KB, mejor que mejor. En cuanto al uso de RAM, dependerá de lo que quieras hacer y del objetivo que tengas en mente. Pero si Konami pudo hacer todos sus juegos para MSX compatibles con MSX con 8 KB de RAM (si no recuerdo mal, claro) es que con 8 KB debería bastar. Evidentemente, las rutinas de compresión de Konami no tiraban de RAM a saco, como sí nos sucede ahora con todos los compresores basados en métodos de Huffman y compañía. Al menos, si estás arrancando ahora, complícate la vida lo menos posible: ROM en página 1 si es de 32 KB o en página 2 si es de 16 KB, RAM en la página 3 tal cual, y usar la BIOS para todo o casi todo. Tiempo tendrás después para enredarte y hacer inventos, pero de momento, aplica la metodología KISS: Keep It So Simple! A mi lo que me gusta es programar ROMs de 8 KB que además requieran sólo de 8 KB de RAM. Así, con el mismo código, puedes relocalizar el programa y hacer que sea compatible con carga por cassette directa en MSX con sólo 16 KB de RAM. Pero en fin, lo mío es muy retro siempre
|
|
|
En línea
|
|
|
|
phsoft
|
|
« Respuesta #6 : 12 de Septiembre de 2011, 09:30:31 pm » |
|
ok, jefe: rom rom rom, la botella de rom! aquello era pura especulación teórica basada en que el banco 0 son 16kbs de lo más jugoso donde meter datas a saco, y que se utilizan -al menos yo- pocas rutinas esenciales de la bios. alguna (si no todas), además se puede desensamblar y pegar sin mayor problema... que, por cierto, no está la rom desensamblada entera?... y la c-bios?... sobre konami -y amigos- me llama la atención que no sepamos casi nada hoy día -al menos yo, quiero decir- sobre las herramientas que usaron aquellos tipos geniales. no hay artículos donde expliquen cómo hacían los gráficos? cómo comprimían el mapeado? con qué herramientas componían y cómo lo convertían al msx etc? sería una lectura interesante, no sé saludos, - paco pd: pues si, la c-bios (no se me había ocurrido antes) contiene código supongo que compatible con el de la rom bios del msx. pej, del cb_main.a80, va esta rutina con sus cp a,d y todo ;-------------------------------- ; 0020h DCOMPR ; in .. hl,de= wordcomp ld a,h cp a,d ret nz ld a,l cp a,e ret que para echar un vistazo de vez en cuando -sin abusar!!!-, o por si alguien quiere su pepe-bios personalizada, pues igual no está mal
|
|
« Última modificación: 12 de Septiembre de 2011, 09:50:26 pm por phsoft »
|
En línea
|
|
|
|
nenefranz
Karoshi Fan
Mensajes: 67
|
|
« Respuesta #7 : 12 de Septiembre de 2011, 10:05:41 pm » |
|
ejemplo de descompresor pletter funcional (de momento me ha funcionado bien tanto pletter5b como con pletter5c1): hacer "call pletter_unpack" teniendo en HL la direccion de los datos comprimidos y en DE la dirección donde descomprimir (modifica todos los registros). ; pletter v0.5 msx unpacker
; call pletter_unpack with hl pointing to some pletter5 data, and de pointing to the destination. ; changes all registers
; module pletter
;macro GETBIT ; add a, a ; call z, pletter_getbit ;endmacro
;macro GETBITEXX ; add a, a ; call z, pletter_getbitexx ;endmacro
pletter_unpack: ld a, [hl] inc hl exx ld de, 0 add a, a inc a rl e add a, a rl e add a, a rl e rl e ld hl, pletter_modes add hl, de ld e, [hl] ld ixl, e inc hl ld e, [hl] ld ixh, e ld e, 1 exx ld iy, pletter_loop pletter_literal: ldi pletter_loop: ; GETBIT add a, a call z, pletter_getbit jr nc, pletter_literal exx ld h, d ld l, e pletter_getlen: ; GETBITEXX add a, a call z, pletter_getbitexx jr nc, pletter_lenok pletter_lus: ; GETBITEXX add a, a call z, pletter_getbitexx adc hl, hl ret c ; GETBITEXX add a, a call z, pletter_getbitexx jr nc, pletter_lenok ; GETBITEXX add a, a call z, pletter_getbitexx adc hl, hl ret c ; GETBITEXX add a, a call z, pletter_getbitexx jp c, pletter_lus pletter_lenok: inc hl exx ld c, [hl] inc hl ld b, 0 bit 7, c jp z, pletter_offsok jp ix pletter_mode7: ; GETBIT add a, a call z, pletter_getbit rl b pletter_mode6: ; GETBIT add a, a call z, pletter_getbit rl b pletter_mode5: ; GETBIT add a, a call z, pletter_getbit rl b pletter_mode4: ; GETBIT add a, a call z, pletter_getbit rl b pletter_mode3: ; GETBIT add a, a call z, pletter_getbit rl b pletter_mode2: ; GETBIT add a, a call z, pletter_getbit rl b ; GETBIT add a, a call z, pletter_getbit jr nc, pletter_offsok or a inc b res 7, c pletter_offsok: inc bc push hl exx push hl exx ld l, e ld h, d sbc hl, bc pop bc ldir pop hl jp iy
pletter_getbit: ld a, [hl] inc hl rla ret
pletter_getbitexx: exx ld a, [hl] inc hl exx rla ret
;modes ; word offsok ; word mode2 ; word mode3 ; word mode4 ; word mode5 ; word mode6 ; word mode7
pletter_modes: dw pletter_offsok dw pletter_mode2 dw pletter_mode3 dw pletter_mode4 dw pletter_mode5 dw pletter_mode6 dw pletter_mode7
utilizo el pletter simplemente porque fue el primero que conseguí hacer funcionar!!! quizá podría hacer pruebas con el bitbuster. Tampoco descomprimo en "tiempo de juego", sino entre pantallas o inicializaciones, por eso no he notado que sea lento. saludos,
|
|
|
En línea
|
|
|
|
phsoft
|
|
« Respuesta #8 : 12 de Septiembre de 2011, 10:53:27 pm » |
|
gracias, nene ese código se parece a la adaptación que le hice (al descompresor estandar que trae) pero que, por alguna razón, no me funcionó, no sé... esos dw finales se me hacen raros para asMSX. compararé ambas versiones con windiff. ya digo que apenas he probado este descompresor puesto que cuando funcionó bitbuster ya me desentendí del asunto. en fin, subiré un ejemplo de carga de pantallazo descomprimido con unpletter.. ejemp... solo para estar seguros X...-D en las pruebas que hice, por cierto, msx-o-mizer comprimía aún más que pletter. la verdad que el ratio de compresión de mom era excelente... y nada, si no estás muy liado y te apetece, claro, ponme un email y hablamos de nuestras cosas, amor saludos, - paco
|
|
|
En línea
|
|
|
|
nenefranz
Karoshi Fan
Mensajes: 67
|
|
« Respuesta #9 : 12 de Septiembre de 2011, 11:05:11 pm » |
|
es que precisamente el código que he puesto es una adaptación del código estandar que trae ... como se puede ver he sustituido las macros por el código directamente ... y la tabla de dw del final. (aunque parezca raro si tiene su utilidad) Creo que esto último es lo que faltaba en tu adaptación, vamos que debe ser la única diferencia. Parece que si comprime más el mom, pero también creo que es más lento. cuando subiste tu proyecto con los algoritmos de descompresión probé el mom ... pero no conseguí que me funcionara!! quizá podría intentar hacer alguna prueba más a ver si lo consigo. saludos,
|
|
|
En línea
|
|
|
|
SapphiRe_MSX
Visitante
|
|
« Respuesta #10 : 13 de Septiembre de 2011, 08:48:19 am » |
|
Hombre, si alguien quiere rutinas para hacer una ROM de 32k o de 48k con posibilidad de volver a la BIOS siempre que se quiera y no quiere comerse el coco para hacerlas... no se, que me diga algo
|
|
|
En línea
|
|
|
|
pitpan
|
|
« Respuesta #11 : 13 de Septiembre de 2011, 09:10:51 am » |
|
Las rutinas en sí no son complicadas, aunque hay que tener un par de detalles importantes en mente. Lo que se vuelve complejo es depurar un proyecto así si empieza a dar problemas... Por eso recomiendo empezar con la gama básica: 8-32 KB de ROM (págs. 1-2), RAM en pag. 3.
Y, por supuesto, usar la BIOS siempre que sea posible, lo que quiere decir SIEMPRE, excepto si necesitamos volcar muchos datos por frame, para lo cual, tendremos que tener muy en cuenta lo que dice el tutorial de desarrollo compatible para MSX.
Viva el estándar.
|
|
|
En línea
|
|
|
|
Metalbrain
Karoshi Fan
Mensajes: 92
Z80jutsushi
|
|
« Respuesta #12 : 13 de Septiembre de 2011, 10:04:42 am » |
|
Creo que jamás entenderé la adoración que siente la escena MSX por los compresores bitbuster y pletter. Los mejores compresores son sin duda exomizer, aPLib y pucrunch (enlaces aquí). Ciertamente son más lentos que otros, pero si se hace la descompresión donde se puede hacer una pausa, no debería haber ningún problema. El único de estos tres que parece haber calado en la escena MSX es el exomizer, y eso solo porque alguien lo modificó, creando una versión reducida a la que le han quitado todo lo que tenía de commodore y le ha puesto el nombre de "MSX-o-mizer". Aparte de eso, el autor del MSX-o-mizer optimizó mi rutina de descompresión, pero me pareció ver (lo mismo me equivoco) que algunas de las optimizaciones eran bastante agresivas, ya que se cargaban los datos que se iban descomprimiendo, de forma que solo deja descomprimir una vez, lo cual puede ser bueno por ejemplo para hacer una intro en 4K que se autodescomprima, pero no vale para meter las fases de un juego. Como ejemplo de uso de exomizer, podeis echarle un vistazo al código fuente de mi propio I Need Speed.
|
|
|
En línea
|
|
|
|
phsoft
|
|
« Respuesta #13 : 13 de Septiembre de 2011, 10:36:47 am » |
|
holas, @nene: el descompresor para pletter funciona perfecto. me faltaban los dw finales, como te dije por correo (la verdad que no me he parado a entender su función, y debí comentarlos o borrarlos por error en mis pruebas). pletter es algo más lento que bitbuster, y la mejora en el ratio de compresión respecto a brigittebardot tampoco da para tirar cohetes. hablo de mis pruebas siempre. las subiré cuando pueda. como m-o-m comprime más que el resto imagino que tardará un poco más en descomprimir, esto suele ser la norma. y bueno, también probé a adaptar el descompresor de mamá, que incluye, pienso, instrucciones para el z80 no documentadas o no estándar o como se demomime a eso :-) a mi que me registren el af @sap: en verdad en verdad te digo que bienvenido sea todo código aprovechable! X..-D pero en serio: de momento seguiré los sensatos consejos de pitpan. este tema de curiosear el modo de desconectar la bios y tirar de más rom me surge a raiz de algunas pruebas que estoy realizando con una rom en la que introduzco demasiados datos a pegote, de manera que me ha superado la barrera de los 16kb "como si ná" :-) y se me ha plantado en pag 2, momento en el cual se me producen extraños bugs en el fcto del juego. entiendo que no es un bug del programa puesto que solo comentando algún literal -texto- o algunas instrucciones para dejarlo dentro de pag 1 vuelve a funcionar correcto. es algo curioso que me tiene un poco pillado, no sé saludos, - paco
|
|
|
En línea
|
|
|
|
pitpan
|
|
« Respuesta #14 : 13 de Septiembre de 2011, 11:03:30 am » |
|
El "bug" que te aparece se debe muy probablemente a que no localizas la segunda página de la ROM. Ojo al dato: el MSX busca y activa la primera página que incluya la firma "AB". Pero si la ROM es de más de 16 KB, eso quiere decir que sólo te encuentra las primeras 16. Para localizar la página siguiente te lo tienes que currar tú por tu cuenta. O, para vuestro confort, emplear la pseudoinstrucción .SEARCH del asMSX, que hace exactamente eso: localizar y activar la segunda página de una ROM de 32 KB. Ya me dirás si con esto desaparece el extraño "bug"
|
|
|
En línea
|
|
|
|
|