En sus días, los desarrolladores se ocuparon de abusar convenientemente de las rutinas de carga. Turbos, datos cargados en desorden, tonos guía casi inexistentes... un poco de todo. También hubo programas que se cargaban encriptados y al acabar la carga se desencriptaban, o juegos que cargaban datos comprimidos y luego los descomprimían. Esto pasaba en los ZX Spectrum, y supongo que en MSX y CPC pasaría lo mismo.
La pregunta es... dado que la mayoría de los algoritmos de descompresión pueden funcionar en stream, ¿hubo alguna rutina de carga que descomprimiera datos "al vuelo" mientras cargaba? ¿Habría suficiente CPU para permitirlo?
La ventaja es que no se necesitaría tanta memoria (no necesitas tener los datos cargados antes de descomprimir) y si lo juntas con una carga turbo (si hay tanta CPU), obtienes una preciosidad que reduce mucho el tiempo de carga.
En cierto juego llegué a sospechar que lo hacían, pero luego lo descarte (a veces veo cosas donde no las hay, y no soy TAN experto depurando). ¿Se hizo esto alguna vez?
CURIOSIDAD: Forzando rutinas de carga
- zup
- Amiga 2500
- Mensajes: 2973
- Registrado: 04 Sep 2009, 20:07
- Sistema Favorito: Spectrum 16Kb/48Kb
- primer_sistema: Spectrum 16Kb/48Kb
- consola_favorita: Nintendo DS/3DS
- Primera consola: Nintendo GameBoy
- Ubicación: Navarra
- Gracias dadas: 68 veces
- Gracias recibidas: 329 veces
- Contactar:
CURIOSIDAD: Forzando rutinas de carga
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start.
Además vendo cosas!
Además vendo cosas!
- Namek
- Atari 1040 STf
- Mensajes: 838
- Registrado: 11 Jul 2011, 13:13
- Gracias dadas: 18 veces
- Gracias recibidas: 63 veces
Re: CURIOSIDAD: Forzando rutinas de carga
Yo creo recordar una rutina de carga que se saltaba los ceros, osea, que cuando venian series grandes de bytes a 0 no las cargaba, sino que saltaba al siguiente dato que no era 0, esto lo vi en una pantalla de carga, pero no recuerdo de que juego.
En cuanto a lo de descomprimir mientras se carga lo veo mas una chulada que algo realmente util, ya que los descompresores actuales como exomizer por ejemplo descomprimen bastante rapido como para no necesitar hacerlo a la vez que la carga y si encima usas cargadores ultra-turbos como K7ZX, OTLA o CARGANDOLECHES tiene aun menos sentido.
Un saludito...
En cuanto a lo de descomprimir mientras se carga lo veo mas una chulada que algo realmente util, ya que los descompresores actuales como exomizer por ejemplo descomprimen bastante rapido como para no necesitar hacerlo a la vez que la carga y si encima usas cargadores ultra-turbos como K7ZX, OTLA o CARGANDOLECHES tiene aun menos sentido.
Un saludito...
- scooter
- Amiga 1200
- Mensajes: 1031
- Registrado: 17 Jul 2012, 09:25
- primer_sistema: C64
- Ubicación: Alicante
Re: CURIOSIDAD: Forzando rutinas de carga
Para C64 recuerdo haber usado una rutina de compresión para gráficos; enviaba el byte y el número de veces que se repetía. Si la pantalla estaba mas bien en blanco era eficiente, si estaba mas bien llena era una M tremenda.
- robcfg
- Amiga 2500
- Mensajes: 2148
- Registrado: 07 May 2009, 15:34
- Sistema Favorito: Amstrad CPC
- primer_sistema: Atari 800XL/600XL
- Ubicación: Estocolmo
- Gracias dadas: 868 veces
- Gracias recibidas: 172 veces
- Contactar:
Re: CURIOSIDAD: Forzando rutinas de carga
Lo que comentas es un algoritmo RLE (Run Length Encoding) y como bien dices, si tienes areas grandes del mismo color, funciona aceptablemente bien, y si no, ocupa más que el original.
-
- Amiga 1200
- Mensajes: 1442
- Registrado: 07 Nov 2009, 11:38
- Sistema Favorito: C64
- primer_sistema: Spectrum 16Kb/48Kb
- consola_favorita: Nintendo SNES
- Primera consola: Nintendo SNES
- Ubicación: Madrid
- Gracias dadas: 9 veces
- Gracias recibidas: 209 veces
Re: CURIOSIDAD: Forzando rutinas de carga
Un algoritmo RLE es posible que sí pueda darse, pero compresores serios como los actuales basados en Lempel-Ziv te aseguro que no da tiempo a cargarlos desde una cinta secuencial al vuelo, porque he probado y no hay ciclos. Tras finalizar la carga sí, son bastantes las cosas que he hecho con aPLib y descomprimen tras la carga a 35 KB/s (incluso a 50 KB/s si me molesto en usar una rutina descompresora más larga con todos los bucles completamente desenrollados) con lo que la experiencia de usuario no se ve mermada en absoluto.
En su día, cuando utilizabamos descompresores al vuelo fue en la escena del C64, para los juegos con múltiples fases, ya que la carga desde disquetera con acceso aleatorio era completamente asíncrona. No tenías que preocuparte en medir en absoluto los tiempos fijos de un bit como sucede en la cinta magnética secuencial, simplemente le pedías al dispositivo un byte, y cuando lo obtenías ibas a por el siguiente. Si la petición se hacía en medio de una rutina de descompresión, pues igual que si lo leyeses de memoria directamente solo que tardaría algo más en volver de una hipotética subrutina "OBTENER NUEVO BYTE", era transparente en ese sentido. Luego en la disquetera del C64, al ser inteligente y llevar ROM y RAM propia, podías tener una carga turbo que proporcionase en el bus serie los bits más rápido, pero de nuevo, completamente transparente en el extremo remoto: tú pedías cargar un byte, y al ser asíncrono, podrías tener una rutina de muy bajo nivel que se encargase de toda la entrada/salida, que lo que había por encima seguía siendo compatible.
Pero bueno, el mismo proceso también se da en la escena rusa del Spectrum y su ubícuo TR-DOS para carga de disco, aunque en ese caso, el compresor por excelencia siempre fue el HRUST.
En su día, cuando utilizabamos descompresores al vuelo fue en la escena del C64, para los juegos con múltiples fases, ya que la carga desde disquetera con acceso aleatorio era completamente asíncrona. No tenías que preocuparte en medir en absoluto los tiempos fijos de un bit como sucede en la cinta magnética secuencial, simplemente le pedías al dispositivo un byte, y cuando lo obtenías ibas a por el siguiente. Si la petición se hacía en medio de una rutina de descompresión, pues igual que si lo leyeses de memoria directamente solo que tardaría algo más en volver de una hipotética subrutina "OBTENER NUEVO BYTE", era transparente en ese sentido. Luego en la disquetera del C64, al ser inteligente y llevar ROM y RAM propia, podías tener una carga turbo que proporcionase en el bus serie los bits más rápido, pero de nuevo, completamente transparente en el extremo remoto: tú pedías cargar un byte, y al ser asíncrono, podrías tener una rutina de muy bajo nivel que se encargase de toda la entrada/salida, que lo que había por encima seguía siendo compatible.
Pero bueno, el mismo proceso también se da en la escena rusa del Spectrum y su ubícuo TR-DOS para carga de disco, aunque en ese caso, el compresor por excelencia siempre fue el HRUST.
- zup
- Amiga 2500
- Mensajes: 2973
- Registrado: 04 Sep 2009, 20:07
- Sistema Favorito: Spectrum 16Kb/48Kb
- primer_sistema: Spectrum 16Kb/48Kb
- consola_favorita: Nintendo DS/3DS
- Primera consola: Nintendo GameBoy
- Ubicación: Navarra
- Gracias dadas: 68 veces
- Gracias recibidas: 329 veces
- Contactar:
Re: CURIOSIDAD: Forzando rutinas de carga
Vale, era un tema de curiosidad.
La ventaja de este sistema es que no necesitas (casi) memoria RAM. En los compresores tradicionales tienes que tener por un lado los datos comprimidos y por otro suficiente espacio para descomprimir sin cargarte los que estás descomprimiendo en ese momento (podrías cargarte datos que ya hubieras descomprimido), con este sistema los datos comprimidos los vas leyendo de cinta y no ocupan lugar en la memoria.
Ahora bien, si no hay ciclos se acabó el invento. A menos que inventes una rutina de carga más lenta... lo que acaba con la ventaja de comprimir los datos.
La ventaja de este sistema es que no necesitas (casi) memoria RAM. En los compresores tradicionales tienes que tener por un lado los datos comprimidos y por otro suficiente espacio para descomprimir sin cargarte los que estás descomprimiendo en ese momento (podrías cargarte datos que ya hubieras descomprimido), con este sistema los datos comprimidos los vas leyendo de cinta y no ocupan lugar en la memoria.
Ahora bien, si no hay ciclos se acabó el invento. A menos que inventes una rutina de carga más lenta... lo que acaba con la ventaja de comprimir los datos.
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start.
Además vendo cosas!
Además vendo cosas!
- Namek
- Atari 1040 STf
- Mensajes: 838
- Registrado: 11 Jul 2011, 13:13
- Gracias dadas: 18 veces
- Gracias recibidas: 63 veces
Re: CURIOSIDAD: Forzando rutinas de carga
La mayoria de descompresores actuales para Spectrum funcionan machacando sobre los datos comprimidos que ya has descomprimido, de lo contrario seria imposible descomprimir bloques de 41K, por ejemplo el FILE COMPRESSOR que he usado bastante solo necesita los 150 bytes extra que ocupa la rutina descompresora, por tanto en un Spcetrum de 48K podrias descomprimir un bloque de casi 48K menos esos 150 bytes y lo que haga falta de STACK... Con estas cosas yo ALUCINO!!!
-
- Amiga 1200
- Mensajes: 1442
- Registrado: 07 Nov 2009, 11:38
- Sistema Favorito: C64
- primer_sistema: Spectrum 16Kb/48Kb
- consola_favorita: Nintendo SNES
- Primera consola: Nintendo SNES
- Ubicación: Madrid
- Gracias dadas: 9 veces
- Gracias recibidas: 209 veces
Re: CURIOSIDAD: Forzando rutinas de carga
Yo me hice, ya hace muchos años, de cuando preparé el paquete del Cannon Bubble, un programa en C que apoyándose sobre la librería de aPLib, iba calculando el número máximo de bytes que necesitábamos "salvar" para prevenir el solapamiento. En ese caso fueron 4 bytes solamente, aunque lo normal es que solo sean 2 ó 3, salvo que haya zonas previas no compresibles. Hay que evitar comprimir lo ya comprimido.
Ahí donde lo veis, el Cannon Bubble cuya carga es un bloque de 68 KB, en realidad luego son unos 140 KB que se van utilizando cuando toca.
Ahí donde lo veis, el Cannon Bubble cuya carga es un bloque de 68 KB, en realidad luego son unos 140 KB que se van utilizando cuando toca.
¿Quién está conectado?
Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 5 invitados