Cavernator & los límites del BASIC.

Página 6/6
1 | 2 | 3 | 4 | 5 |

Por yodh

Champion (361)

Imagen del yodh

12-10-2017, 09:15

Mejoras en CAV66:

1.- El juego ya no es tan ´cuadriculado´ la cueva ya va pareciéndose a una cueva de verdad.

2.- En la segunda parte el prota ya ´sabe´ subir cuestas hacia la derecha (se encallaba antes y no subía). El prota ya no ´se atasca´ al subir por una cuesta en dirección a la derecha/arriba (ya no hay que ´desatascarlo´ haciendo que salte). De todas formas en las zonas muy empinadas NO es lógico que el prota las suba ´sin más´, con lo cual menos en casos ´excepcionales´ como en la pantalla del muelle, dejaré que el prota NO pueda subir por cuestas con un determinado desnivel.

3.- En la primera parte (megacav1.bas) he estado haciendo ´experimentos´ a ver si salían como el que ha quedado que cuando estás en medio o al final de una cuesta el prota ´como sería lógico en el mundo real´ se irá cayendo hasta llegar al fondo de la cuesta. Se puede apreciar este efecto también en la primera pantalla (la de la casa y el árbol), si nos ponemos encima del segundo montículo (y un poco a su izquierda) veremos que el prota él solo se va cayendo hasta la primera zona un poco plana que encuentre. ¿Y para qué sirve esto? pues N.F.I. (Ni Fajolera Idea), simplemente me planteé si se podía hacer y estuve probando maneras de conseguirlo hasta que he llegado a ese curioso efectillo. Por supuesto en cualquier parte del nivel funcionará (claro: menos en las zonas planas).

Esa ´propiedad´ que le he añadido al motor del sprite protagonista sólo lo he puesto ´para un lado´ ... en la pant 5 (la que te encuentras la pala de Haslueg y puedes comerte la fruta amarilla que hay ahí) se puede ver perfectamente cómo el prota baja (si lo dejas en medio de la pendiente) toda una cuesta pero en la otra se queda donde lo dejamos. No sé por qué pero al final me da la impresión que no es lógico que se quede ahí parado... ¡tendría que resbalar (o algo) tal como lo hace en la cuesta de al lado! Smile

4.- Más curiosidades/mejoras: El prota tiene cinco sprites para él solito (realmente son diez, ya que son digamos cinco para ´un lado´ y cinco para ´el otro´), pero SIN NINGÚN problema de ralentizamiento tendría ponerle 32... ¡o TODOS los sprites disponibles! Claro: el problema vendría después ya que los enemigos no podrían ser sprites hardware ya que no habría forma/espacio de definirlos (si estoy en un error me corregís sin ningún problema). En este supuesto tendríamos que dejar de apoyarnos en las maravillosas interrupciones de sprites del MSX y probar cosas del tipo: si lo que tengo delante es de tal color entonces es decorado y si es de tal otro es que es un enemigo... con lo cual si es lo primero entonces restar o sumar el mismo número que se ha avanzado (has topado con una pared con lo cual aunque le des al cursor correspondiente no podrás avanzar), en el caso de que se tope con un enemigo entonces se podría restar un poco de vida y luego se ha de poner el sprite protagonista un poco alejado para que NO vuelva a repetirse el proceso indefinidamente (bueno o hasta que se quede sin energía o vidas) el ´bajar vida, se detecta colisión con enemigo, bajar vida y vuelta a empezar).

5.- Mejora en la detección de sprites al pasar de 2 (que tenía antes) a 10 (que tiene ahora) para el sprite prota: Algo obvio: no es lo mismo que se colisione por la izquierda que por la derecha, si el prota va caminando desde la parte izquierda a la parte derecha y colisiona con un enemigo lo lógico es que ´rebote´ un poco en la dirección contraria... osea que tendremos que situarlo unos ´píxeles´ a la izquierda (y luego: bajar energía... poner unas palabras como ´ ¡perdone-ME ud que le he golpeado! o ¡me has hecho daño! etecé, o incluso se podría acompañar todo eso con un pequeño sample con el sonido de un golpe y demás... o según cómo sea el juego incluso se podría hacer que avance un poco lo que se ha chocado dando la impresión de que lo hemos empujado... osea: podemos hacer cientos de cosas posibles). Un ejemplo práctico de todo esto que estoy escribiendo es lo que ocurre en la pantalla 21, en la cual el muelle que hay en la parte de arriba se puede mover hacia los lados (según por donde lo empujes) o puede provocar que el prota salte encima de él si caes por encima. Pero un detalle importante en este caso es saber en qué dirección se iba cuando se produjo la colisión... por supuesto el que está manejando los cursores lo está viendo in situ, pero el programa no tiene ´esa facilidad´.
Hasta hace no mucho tiempo el prota del Cavernator tenía dos sprites (el cero es el que miraba hacia la derecha y el uno hacia la izquierda), de ese modo cuando había una colisión de sprites si en ese momento estaba en pantalla el sprite cero eso quería decir que se estaba caminando hacia la derecha con lo cual ya sabía (el programa) qué hacer a continuación.

Sencillo: en el momento que definimos dos, cuatro, diez (o los que sean) sprites para el prota lo único que tenemos que variar es la línea que mira si el sprite está en ´cero´ ...

300 IF SP=0 THEN X=X-3:VI=VI-1 (...)
300 La variable ´SP´ ¿es cero? entonces ´tal y cual´

por (pongo el ejemplo de cómo lo tengo actualmente en el Cavernator: diez sprites para el prota que van del 0 al 9):

300 IF SP < 5 THEN X=X-3:VI=VI-1
300 La variable ´SP´ ¿es 4,3,2,1 ó 0? entonces ´tal y cual´ osea se atrasa hacia la izquierda (si fuera SP>4 lo que es el 5,6,7,8 ó el 9 pues obvia y justamente lo contrario Smile

Todo esto es un sencillo ejemplo de algo FANTÁSTICO: y es que si nos damos cuenta podemos llegar a saber muchas cosas de lo que puede (o no) estar ocurriendo en el juego... Dada una combinación de valores en ciertas variables... puedes desencadenar unos acontecimientos o saber que ya han ocurrido y por lo tanto no volver a hacer que ocurran, desencadenar otra secuencia e-te-cé, e-te-cé, e-te-cé.
Para que comprobéis que efectivamente se puede saber en tiempo real lo que está haciendo el que maneja al sufrido sprite protagonista he puesto en la parte de abajo a la izquierda (de la pantalla de juego) tres posibles estados en los que puede estar el sprite que manejamos: en el suelo, osea, parado o caminando... ´Salta´ , es decir, está subiendo hacia una cierta altura (creo que lo tengo en 11 posiciones, aunque se puede variar muy fácilmente), y ´baja´ que es cuando el sprite hace eso mismo (mismamente). Si os fijáis cuando ocurra alguna de esas acciones... aparecerá un puntito a la derecha de cada palabra. El puntito de ´Salta´ lo he puesto en la parte de arriba ya que me ha parecido lógico ponerlo así. Quiero aclarar que todo esto no tiene relación con nada del juego (en otras versiones lo quitaré, pero he comprobado que me ayuda a saber si funciona bien el juego) pero si lo pensamos es interesante el hecho de tener tanto control en lo que respecta a las variables... ya que se puede hacer más vistoso el juego que hagamos ya que por ej. cuando se llega a un nivel de energía pongo un aviso, y cuando se llega a otro pongo otra frase un poco más apremiante. Pero en lugar de eso (poner frases) se podría poner un pequeño gráfico de una cara un poco magullada... y cuando se llegue a tener menos nivel de energía pues poner otra que esté mucho peor (ya sé que no es original: había juegos en 3d (en el mundo pc claro) que se hacía esto).

6.- Cuando el prota salta y se encuentra techo... se produce un sonido y entonces se pone ´en modo´ bajada (la ´mejora´ viene de que ahora se oye el sonido que hace las veces del ´supuesto golpe en la cabeza´). Parece una tonteriDa pero tiene su ´miga´ ya que el motor más o menos reconoce (a su manera) que lo que ha pasado ha sido que en el salto se ha topado el prota con un obstáculo en la parte superior... por ej. cuando el prota termina de saltar y encuentra también el mismo color del techo... NO hace ningún sonido ya que el motor sabe que ese color pertenece al suelo. Todo esto es posible ya que el prota tiene una variable (variable: ´SA´ de ´salto´ y sí... no me compliqué mucho la vida con el nombre de la variable Smile ) que puede tener tres estados: si está en ´uno´ es que el prota está subiendo, si está en ´dos´ es que está bajando y si está en ´tres´ es que está en el suelo parado o moviéndose de derecha a izquierda (y es precisamente en lo que me he basado cuando he puesto todo eso de ´Suelo, salta, baja´ ). Sabiendo esto, si en un momento dado el programa detecta que por encima del prota hay una zona azul y SA=1 entonces es que estaba subiendo con lo cual se ha de poner un sonido, sample, copias el trocito de gráficos de la parte de arriba del prota a otra página y pones ahí un gráfico con un ´ ¡ay!´ (o lo que se te ocurra) y al cabo de un poco de tiempo vuelves a copiar el gráfico que había antes... En el caso de encontrar ´azul´ y SA=2 (el sprite está bajando) entonces se ha de poner SA a 3 pero no poner ningún sonido, ni un ¡ay! y demás ya que se supone que en ese caso no se produce ningún daño.

7.- En pant 22 hay un enemigo que está caminando digámoslo así:´del revés´ Tip: si dejas al prota mirando hacia la derecha el enemigo se moverá únicamente por la zona plana... ahí el efecto de moonwalk se ve un poco más conseguido que en las zonas no niveladas. Esto es un ejemplo de lo que decía antes de saber lo que está ocurriendo en pantalla por medio de las variables (en este caso se sabe que estás mirando hacia la derecha viendo el valor de ´SP´ ). Si en la segunda parte del juego hacemos un CTRL + STOP y vamos a la línea 2910 leeremos (traducido ´basic-humano´) que ´si el enemigo está en la posición 130 y el sprite que manejamos es menor de 5 (la ristra de ´esprítes´ que miran hacia la derecha) entonces hacer que el enemigo deje de avanzar y retroceda. Así, el enemigo tiene tres ´topes´ (digámoslo así) los ´normales´ que son los que están a los lados y que provocan que el enemigo se mueva de izquierda a derecha entre esos márgenes... y el que está en medio que solo ocurre si son ciertas determinadas cosas.
Totalmente obvio: si pones el tope del medio fuera del recorrido del enemigo... entonces NUNCA llegará a ese punto...
No tiene ningún misterio: hay un enemigo que hace un cierto recorrido, pero si pasan ciertas cosas hace otro (un recorrido más corto delimitado a una zona concreta). En este caso, el por qué de hacer esto es lo que he escrito antes: poder apreciar de esa manera el ´moonwalk´ en la parte plana que he puesto ex profeso. Sin embargo, esto que parece que no tiene ninguna otra utilidad... si lo pensamos podemos complicarlo hasta los límites que queramos, me explico: hace años que estuve trasteando (dándole vueltas) con esta idea... lo que se me ocurrió fue que podía haber una pantalla tipo plataformas pero que los enemigos pudieran tener una pseudo inteligencia, con lo cual te pudieran perseguir aunque hubiera un recorrido complicado entre el enemigo y nosotros.
Antes de nada diré que NO es una idea mía, sino que supongo que se me ocurrió cuando veía a los sprites del KING´S VALLEY de KONAMI cómo aparentemente iban poco a poco acercándose a donde estaba nuestro sprite. Se me ocurrió que podía poner unos enemigos que tuvieran un recorrido preestablecido... pero que si pasaban por ciertos puntos (osea: el principio de una escalera, un elevador etecé) y comprobara que nosotros estábamos (¿´Y´ es menor de 90? por ej.) en la parte superior... pues en ese caso el enemigo subiría por la escalera o por el elevador o lo que fuera y cuando llegara arriba la dirección que tomara sería hacia donde estuviéramos nosotros. Esto haría que pareciera que el enemigo tenía una cierta inteligencia... y más si a parte de eso hacemos que el enemigo antes de empezar a acercarte a tí te lo comunique con un mensaje de texto (o aún más sorprendente/impactante con un mensaje de voz: con un sample) como podría ser: ´ Sé que estás ahí arriba, voy a subir por la escalera y te voy a atrapar´ etecé.

Y la base de todo esto está en el ´tope del medio´ que he explicado antes. Tal vez se podrían confundir esos ´topes´ que comento con unos ´ ifthénes (if/then en su ´plural´) cualesquieras´ , sin embargo pienso que es un poco distinto ya que los ´topes´ están situados (en el código) por medio del ´on X gosub tal,ycual. Es decir: en el caso de tener tres topes entonces si X es 1 el enemigo irá en una dirección, si es dos irá en la contraria, si es tres entonces subirá (o bajará que también podría ser) una escalera. Ésto último no está en el Cavernator ´todavía´ Smile pero hay algo muy parecido: si el enemigo está en una posición y nuestro sprite mira hacia una dirección entonces la ´X´ valdrá ´uno´ y eso hace que se dirija hacia la derecha. (en el juego: en la línea 2910 se define M = 1, con lo cual en la línea 2900 el programa se dirigirá hacia la línea 2820 que es donde empieza la subrutina que hace que el sprite se mueva hacia la derecha. En el caso de existir una pantalla con escaleras en el juego, entonces sería necesario poner una tercera/cuarta (...) opción en el ´on X gosub tal,cual,pascual´ en donde ´pascual´ sería la subrutina para subir la escalera, pero claro, también sería necesario otra subrutina para bajar la escalera... y otras más para lo que se os ocurra que pase en el juego. Lo bueno de todo esto es que es igual de fácil hacer que un enemigo simplemente ande de derecha a izquierda... que a parte de eso, pueda subir escaleras, bajarlas, se dirija hacia tí o huya...
También muy sencillamente podemos provocar el ´tope´ haciendo que ocurra cuando lo deseemos tan solo cambiando la línea 2910 donde pone ´IFO=130AND...´ por ´IFO<130AND...´ De esta manera podemos por ej. situarnos en el gran hoyo que hay en la parte izquierda y mirando hacia la izquierda... cuando el sprite enemigo esté a punto de tocarnos nos volvemos hacia él con lo que veremos cómo cambia la dirección. Pero algo más divertido que eso (sí: yo me divierto con ´casi nada´ soy como un Homer Simpson de la informática Smile ) es perseguir al enemigo hasta el tope derecho y luego tirar hacia la izquierda haciendo el efecto de que el enemigo te persigue (y claro: lo hará hasta el tope izquierdo), pero por ej. cuando llegues a la parte de abajo del agujero te vuelves y parecerá como que se asusta ya que correrá hacia el lado contrario.
(NOTA: ¡Cómo voy a terminar el Cavernator nunca si me ´disperso´ siempre haciendo todas estas tonteriDas!!!)
Para terminar con las cosas de esta pantalla 22 diré que lo más importante de ella es el detalle de que el enemigo esté bailando el moonwalk (y hasta aquí puedo leer que ya he dicho hasta DEMASIADO) todo lo demás son como los huevos de pascua ´esos´ .

7.- En pant 31 de momento he puesto dos enemigos que van y vienen por la pantalla... la pantalla final tendrá 3-4 enemigos, los demás creo que no me queda otra que ponerlos quietos y/o/u parados (osea: sin moverse sí o sí) aunque me gustaría que todos se estuvieran moviendo. La finalidad de hacer todo eso es por la razón de que se tendrá que escoger entre todos los enemigos uno que se vea que concuerda con las pistas que se han dado previamente. En la pant 22 hay un enemigo que sabe moverse por zonas irregulares y las sabe sortear y encima para más inri ´bailando´ . El basic parece que puede con ello y la velocidad no se resiente, pero en la pant 31 he puesto ´a ver qué pasa´ dos enemigos que hacen lo mismo (pero NO bailan) es decir: se mueven entre cuatro ´topes´ (dos para cada enemigo) y esta vez no hay tope intermedio con lo cual da igual hacia dónde mire el prota (aquí NO hay el truco de la otra pantalla).
Los dos enemigos no tan sólo ´visten´ de diferente forma sino que parece que tengan un comportamiento diferente: el de arriba va más lento, tiene otro movimiento, de vez en cuando va mirando hacia atrás, si te pones arriba (esta vez tiene que ser forzosamente con el truco de cambiar parámetros al principio (se ha de estar en la PARTE II del juego), poner: pantalla 31 y luego hacer muchos ´RETURNeres´ y ya saldrás por la parte de arriba, sencillo ¿no? Ahora si DENTRO del recorrido del enemigo haces un agujero por el que puedas llegar al nivel de abajo verás que el enemigo termina cayendo por él y después continúa haciendo el mismo recorrido que hacía por la parte de arriba.
Aparentemente la pantalla parece muy simple: vemos dos enemigos y el prota... pero si nos fijamos los enemigos NO tan solo caminan de un lado para otro en bucle, sino que saben ´por donde´ andan subiendo o bajando las cuestas, también se caen si encuentran un agujero que habremos hecho nosotros... esto lo podemos comprobar si estando en la parte de arriba (haciendo el truco que comentaba antes) hacemos un agujero que esté entre la plataforma de en medio... veremos que el sprite situado arriba cuando llegue al agujero se caerá a la plataforma rectangular situada en el medio de la pantalla de juego y luego seguirá andando de un lado para otro como hacía arriba. Como es lógico, si volvemos a hacer un agujero en esa plataforma pues en el momento que el enemigo pase por encima del agujero... volverá a caer a la parte de abajo.

Lo que se me ha ocurrido (por aquello ´de probar´ a ver ´si sale´ ) es que cuando se produzca una colisión de sprites hacer que cambien las direcciones de los enemigos: es decir, que si el prota ´choca´ con un enemigo éste irá en dirección contraria a la que iba... pero también variará la dirección el otro enemigo. Claro, también es posible (tal como lo tengo ´los topes´ ahora) que choquen los enemigos entre sí. En ese caso estarán variando su dirección un rato hasta que se separan un rato ¡Otra cosa que veo que funciona! (lo que ocurre en pantalla es lo que me esperaba) pero que como no le veo una razón de ser... lo quitaré y pondré lo que realmente tenía pensado para esa pantalla. Creo que algo importante es el ir trasteando (probando) cosas, intentar que lo que imaginemos que podría pasar en nuestros juegos pueda aparecer en ellos. Creo que esos momentos son tan gratificantes como el momento que consideremos que ya hemos finalizado el juego al 100%.

Cada sprite enemigo (´supuesto ídem´ ) tiene sus propios límites de recorrido (o como lo llamo yo ´topes´) que se pueden variar muy fácilmente... así se puede hacer que cada uno recorra desde el principio de la pantalla hasta la mitad y el otro desde ahí hasta el final de la pantalla, pero no hay problema si hacemos que los dos recorran toda la pantalla ya que si chocaran variarían su dirección cada vez... (esto no parece tener ningún sentido, ninguna finalidad... pero... ¿para una pantalla NO con sprites sino con dos plataformas móviles que estén en un puente largo? se irían moviendo haciendo el efecto de que chocan y demás y luego el prota tendría que ir saltándolas para poder pasar al otro lado... en ese caso el código tendría más lógica, tendría más sentido. A todo esto aclaro que el juego (el Cavernator) es también a parte de un agradable pasatiempo, es una forma para mí mismo (mismamente) de aprender BASIC. Pero aprender lo que hace un PSET o un POINT o lo que sea no es el final del aprendizaje sino... el principio de todo... ya que en una pantalla puedes utilizar unas cosas para un propósito y en otras para fines muy diferentes... ahí es donde entra la imaginación-ingenio de cada uno. Así, con las mismas herramientas que nos proporciona el lenguaje BASIC (putsprites, copys, lines, psets...) podemos hacer pantallas muy diferentes y que se note que lo que se produce (lo que ocurre) en cada una de ellas es sensiblemente (o totalmente) diferente a las anteriores que ya hemos visto o que veremos. Se me ocurre el símil de un pintor que aún trabajando con la misma paleta de colores y con el mismo pincel y demás... una semana pinta un cuadro colorista y alegre... otro día pinta algo lúgubre.... otro hace un cuadro abstracto... otro uno cubista etecé.

8.- Hay desde la versión .66 un truco para los AFORTUNADOS poseedores de un TURBO R... a ver si alguien lo puede descubrir. ´Probando con los cursores´ es posible que notéis el truco. Si probáis un buen rato y no hay manera... pues una forma rápida de descubrirlo es yendo al motor del sprite... El truco sale SÓLO en un TURBO R o en su defecto en un emulador del ídem.

9.- En la secuencia de ´pasan los días y las noches...´ he mejorado un poco el efecto de amanecer y atardecer: se va oscureciendo y al final aparecen las estrellas... llega el día y las estrellas desaparecen, el sprite ya no se desliza sino que mueve los pies etecé.

PD. ¡PERDÓN POR EL ROLLÁKKKOOO!!! Smile

Cavernator V.66

Por yodh

Champion (361)

Imagen del yodh

15-10-2017, 19:58

Con respecto a la nota que me ponía a mí mismo Murdoch Smile (mismamente):

Quote:

(NOTA: ¡Cómo voy a terminar el Cavernator nunca si me ´disperso´ siempre haciendo todas estas tonteriDas!!!)

que era a la vez tanto una pequeña crítica como una forma de recordarme que tal vez (´tal vez´ NO... SEGURO Running Naked in a Field of Flowers Smile ) tendría que hacer un pensamiento para acabar el juego y dejar los experimentos y las pruebas para futuros juegos LÓGICAMENTE cuando me ponga con esos futuros juegos... y no como lo estoy haciendo hasta ahora que es programar el Cavernator y las ocurrencias de forma paralela o a la vez. Ejemplos de esas ocurrencias que se pueden ver en las versiones del juego que voy subiendo podrían ser ese indicador de lo que está haciendo el prota (subir, bajar, suelo). Otro: en la pantalla del principio de la cueva que si te das un cabezazo el prota se va quejando. Otro más: en la hasta ahora última pantalla que tiene el Cavernator si se produce una colisión de sprites (enemigo-enemigo o enemigo-prota da lo mismo) lo que ocurre es que todos cambian de dirección etecé... pero además la ´ristra´ de trasteos que como decía voy probando pero que al final no los añado a la versión que subo al MRC... Sin duda todo eso conlleva a que la conclusión del juego será en el mejor de los casos a medio (pero me lo veo venir que lo más probable será ´a largo´ Crying Smile ) plazo.

Sin embargo aunque afirme que algunas cosas (algunas programaciones) del Cavernator son ´tonteriDas´ espero que se entienda que lo digo en plan broma (creo que ya escribiendo la palabra ´tontería´ con una gran ´D´ intercalada se puede intuir si la frase la digo en serio o no.) y es que en realidad es todo lo CONTRARIO ya que personalmente este juego me lo tomo MUY en serio (aunque no lo parezca hay muchas horas ahí metidas pero la mayoría de ellas (99%) pasándomelo muy bien, el 1% restante es cuando no hay manera de conseguir hacer lo que se me ha ocurrido y demás). Para mí, cualquier clase de avance en el aprendizaje en la programación (por sencillo que sea) me produce el suficiente aliciente para seguir aprendiendo.

Más cosas: como comentaba en el anterior post el afortunado poseedor de un TURBO-R en la ver.66 hay una forma de aprovechar la potencia de ese SUPER-INFRAUTILIZADO ordenador MSXero... o cuanto menos muchísimo menos aprovechado que sus hermanos menores MSX-1 y MSX-2 (pulsando a la vez dos teclas cursoras) de momento dejo a modo de ´enigma´ el descubrimiento de esas teclas, no sé... creo que de esa forma es más divertido que si se explica todo hasta el último detalle. Lo que sí comentaré será el efecto que se conseguirá cuando se acierte con la combinación (de todas formas no es complicado, es sólo apretar dos cursores a la vez para conseguir el efecto y luego para que el juego funcione en modo MSX-2 los dos cursores opuestos) el efecto se puede apreciar en el momento que manejamos al prota: sencillamente ¡va mucho más rápido! tanto que en la mayoría de pantallas es casi imposible manejar nuestro sprite... ya en basic (en modo R800) es necesario poner más enemigos en pantalla o partes del escenario móviles o hacer el motor de nuestro sprite mucho más complicado o lo que sea para que todo se mueva a una velocidad adecuada. Mi problema viene en el momento que activo el R800 (call R800), como decía antes el juego es injugable (valga la redundancia), pero el Cavernator no es como un arcade donde hay decenas de enemigos y demás, con lo cual no tengo esa opción de llenarlo todo de sprites enemigos para hacer que todo se mueva más lentamente... Efectivamente lo más lógico y racional es hacer un ´call Z80´ para cuando se quiera jugar a velocidad ´normal´ , pero se me ocurrió una duda: ¿cómo podría llegar a la velocidad del Z-80 por medio de un sencillo ´FORX=1TO ´¿?´ ´ . Primero me puse a hacer un ´FORX=1TO500:NEXT´ puesto en medio del motor ¡pero aún iba más rápido que en un MSX-2!!! Cool luego en lugar de 500 le puse un 1000 ¡lo mismo! Cool y luego un 1800 y ahí ya noté que la velocidad era semejante a la de un MSX-2 Cool Cool Cool

Lo que se me ocurre es que ´visto lo visto´ simplemente sobre el basic (en modo R800) del TURBO-R se pueden hacer juegos cuanto menos remarcables Cool Hannibal Curiosamente si desde ahora pasara el Cavernator a versión TURBO-R (como realmente pasó de estar en MSX-1 a pasar a ser un juego de MSX-2... hay muchos trozos de código que se notan a la legua que son de la primera generación Smile ) lo que ocurriría sería que no me saldría mucho de la línea que tenía pensada, es decir: lo que me ofrece el MSX-2 me es suficiente para lo que quiero hacer, para este juego NO necesito mucha más potencia que la que me ofrecen los segunda generación de MSX.

Página 6/6
1 | 2 | 3 | 4 | 5 |
My MSX profile