Juegos nuevos y sistemas de carga no estándar

[zup]

ANTECEDENTES: Esto viene de una discusión sobre Glauzone... Glauzone y Glaufight utilizan el sistema de carga Speedlock, cosa poco habitual en juegos de nueva generación para Spectrum. En el otro hilo, alguien opinaba que tenía su gracia usar una protección tan tradicional como Speedlock. Para no secuestrar el hilo, abro este otro.

Sigo con lo que estaba pensando.

Bueee... Speedlock no hubiera sido mi primera opción, siempre he considerado más "espectacular" Alkatraz (Garfield, entre muchos), y más amigable el sistema de carga que usaba el Astro Marine Corps (que si fallaba te dejaba rebobinar unas vueltas y continuar desde donde había fallado).

Mención especial al sistema de carga "comecocos" de Joe Blade 2. Yo lo tuve con el afamado sistema de carga "Transtape" (o podría haber sido el "Phoenix"), pero he probado el sistema de carga original y es la leche.

Hablando de eso... no sé hasta qué punto Alkatraz llegaba a acelerar la carga. Otra vez estamos con la jugarreta de que tenía turbo, pero entre los millones de desencriptadores y el hecho de que casi siempre cargaba toda la memoria (se usara o no) se gastaba bastante tiempo a lo tonto.

Últimamente he visto otros sistemas de carga como el de Los amores de Brunilda que no es del todo estándar (usa compresión por aquí y por allí) y el que usaba Computer Emuzone (por ejemplo, en Nanako y Phantomasa) que, aunque usaba temporización estándar, cargaba varios bloques de datos a la vez y era capaz de leer la dirección de inicio de cada bloque desde el cassette.

La pregunta del millón... ¿hay sistemas de carga de nueva generación capaces de sorprender como Speedlock o Alkatraz? ¿Sería factible hacer un juego que use Alkatraz a día de hoy (no sé si está disponible el SDK original)? En un mundo donde casi todo el mundo que publica juegos de Spectrum deja también para descargar el código fuente... ¿tiene mucho sentido usar protecciones? ¿Sería más auténtico un juego que cargue desde el BASIC o uno que use un cargador con cuenta atrás (por ejemplo)?

[GLAURUNG]

La próxima vez le pondré la carga del short circuit, para que juegues al arkanoid mientras carga (o eso decían)

[climacus]

La verdad es que es divertido andar cacharreando con las rutinas de carga. Y si encima son curiosas y entretienen o divierten a los usuarios del juego, pues mejor que mejor. Pero sea como fuere, es interesante publicar el juego en .TAP tambien, para darle otros usos, como ya ha comentado varias veces Mcleod.

[zx81]

Creo que una parte importante de usuarios actuales tiran de emulador de una forma u otra y éstos suelen acelerar la carga, de modo que el cargador pasa a un plano muy secundario. Podrás hacer virguerias, pero si el programa carga en 10 o 15 segundos como mucho, el esfuerzo será baldío.

Ahora bien, en atención a los usuarios que aún hacen buen uso de sus maquinas, me parece interesante que se acelere la carga real mediante algún tipo de turbo que, si además es original, miel sobre hojuelas. Soy de esos tipos raros que siempre tiran de emulador, pero escogiendo los tzx con ese tipo de cargas. Pero ojo, con la vista puesta en la rapidez de carga más que en el sentido antiguo de protección.

Lo que no es óbice para que se saque también en formato tap con la vista puesta en los Divides y demás.

Las rutinas y técnicas de carga siempre me han parecido muy interesantes. Aunque son lógicamente menos populares que los juegos me parece bonito que haya desarrolladores que se preocupen por ellas.

[Metalbrain]

¿Os habeis fijado en la versión .tzx del JINJ 2?

[climacus]

Yo hice mis pinitos en rutinas de carga chulas y entretenidas para mis juegos, pero sólo me funcionaban en el emulador!!!! Al usarlas en spectrums reales daban error de carga. Así que abandoné el asunto

[zx81]

¿Os habeis fijado en la versión .tzx del JINJ 2?

Casi había olvidado tu mensaje. A esto me refería yo, había cargado muchas veces en el emulador el juego, pero nunca a velocidad normal. Un original indicador de carga que no había observado.

Por cierto, ¿ese cargador lo probaste con una tele de tubo o LCD?. Lo pregunto porque con el tamaño "estándar" de borde, desaparece el indicador mucho antes del final de la carga. En cambio, con el tamaño de borde "completo" se ve hasta el final.

[Metalbrain]

Por cierto, ¿ese cargador lo probaste con una tele de tubo o LCD?. Lo pregunto porque con el tamaño "estándar" de borde, desaparece el indicador mucho antes del final de la carga. En cambio, con el tamaño de borde "completo" se ve hasta el final.

Lo he probado en mi tele de tubo, pero no recuerdo cuando desaparecía exactamente. Tampoco es que haya intentado sincronizar el final con exactitud, dada la naturaleza caótica de dicha sincronización (el efecto se consigue haciendo la carga con las interrupciones activadas. Creía que era algo original, pero luego me enteré de que ya se había hecho por ejemplo en algunas demos de la serie Song In Lines).

[Hark0]

A todo esto...

¿se puede "añadir" una carga Turbo ó especial (contador tipo Rananarama) a un programa exclusivo en BASIC?

[Player1]

Mención especial al sistema de carga "comecocos" de Joe Blade 2. Yo lo tuve con el afamado sistema de carga "Transtape" (o podría haber sido el "Phoenix"), pero he probado el sistema de carga original y es la leche.

Que bueno!!

No lo conocía, ayer lo probé con el Spectaculator y me gustó muchísimo, vaya sopresa.

Por cierto me hiciste probar todos los juegos que comentas

[zup]

A todo esto...

¿se puede "añadir" una carga Turbo ó especial (contador tipo Rananarama) a un programa exclusivo en BASIC?

No sin ciertos conocimientos avanzados. Hay un montón de juegos en BASIC (p.ej.: Ant Attack) que cargan como CODE... al cargar machacan el área de variables para que el BASIC arranque (continúe) en el sitio que debe. Si generamos ese bloque CODE y en vez de cargarlo LOAD ""CODE utilizamos una de las rutinas con contador/turbo/especiales de Microhobby, debería funcionar.

[Hark0]

A todo esto...

¿se puede "añadir" una carga Turbo ó especial (contador tipo Rananarama) a un programa exclusivo en BASIC?

No sin ciertos conocimientos avanzados. Hay un montón de juegos en BASIC (p.ej.: Ant Attack) que cargan como CODE... al cargar machacan el área de variables para que el BASIC arranque (continúe) en el sitio que debe. Si generamos ese bloque CODE y en vez de cargarlo LOAD ""CODE utilizamos una de las rutinas con contador/turbo/especiales de Microhobby, debería funcionar.

Osea, hago un save "pepito" code <dirección inicio RAM completa> , <toda la ram>

con lo que tengo "toda" la ram en bytes (no basic), con la zona de VARS, el programa Basic, etc....

y luego ¿le "aplico" una rutina de carga de bytes "especial"?

[zup]

Algo del estilo.

No necesitarás (en principio) toda la RAM. Para ir a lo seguro necesitarás el área de variables de sistema, el BASIC, el área de variables y (por si las moscas) la línea de comandos. No necesitas ni la memoria de pantalla, ni el buffer de la impresora (de hecho, te recomendaría que NO lo grabes) ni nada más allá del BASIC.

Eso significa empezar desde 23552 e irte hasta unos cuantos bytes más allá del final de las variables del BASIC.

Nunca lo he hecho, pero se puede investigar con algún programa corto. Luego ese CODE tendrás que pasárselo de alguna forma a alguna de las rutinas de salvado/carga especiales.

En el mundo real, los programadores con mala gaita llegaban a machacar la pila (para que lueo volviera a un sitio diferente) e incluso en algún caso llegaban a grabar más de 48k seguidas.

[Hark0]

Entiendo...

Supongo que me sirve algo como esto:

http://retrospec.sgn.net/users/tomcat/y ... ressor.php


EDIT, acabo de leer este articulo acerca de las protecciones... http://zonadepruebas.org/backup/modules ... ?itemid=49

Por aquella epoca yo intentaba todo con MERGE... que iluso!

[GLAURUNG]

Una protección buena, el speedLock + el de códigos aleatorios del juego Poli Díaz, aunque de nada servían si tenias un Transtape