Aqui esta la direccion
http://xfaworld.balder.prohosting.com/l ... urgle.html
Saludos
Nuevo juego en Basic Compilado en WoS
-
Ivanzx
- 256 bits
- Mensajes: 4316
- Registrado: 20 Nov 2005 00:50
- Ubicación: Frankfurt, Germany
- Contactar:
Nuevo juego en Basic Compilado en WoS
Imagino que algunos de vosotros ya lo habreis visto, pero para que no se le pase a nadie aqui pongo el enlace de un juego simpatico realizado por un aficionado britanico, que ya ha realizado unos cuantos, solo que este es su primer juego realizado en Basic compilado. Se llama Legend of the Burgle, probadlo y ya me direis.
Aqui esta la direccion
http://xfaworld.balder.prohosting.com/l ... urgle.html
Saludos
Aqui esta la direccion
http://xfaworld.balder.prohosting.com/l ... urgle.html
Saludos
-
na_th_an
- 256 bits
- Mensajes: 11874
- Registrado: 22 Abr 2005 13:25
- Contactar:
-
Metalbrain
- 128 bits
- Mensajes: 1717
- Registrado: 16 Oct 2005 15:56
- Ubicación: Sevilla
- Contactar:
Re: Nuevo juego en Basic Compilado en WoS
Yo diría que es el segundo, el primero fue este:Ivanzx escribió: [...] solo que este es su primer juego realizado en Basic compilado.
http://xfaworld.balder.prohosting.com/t ... _hunt.html
-
na_th_an
- 256 bits
- Mensajes: 11874
- Registrado: 22 Abr 2005 13:25
- Contactar:
-
Metalbrain
- 128 bits
- Mensajes: 1717
- Registrado: 16 Oct 2005 15:56
- Ubicación: Sevilla
- Contactar:
El problema que les veo al On the Burgle! y su continuación (aún no he probado este tercero) es que les pone un tiempo ajustadísimo, apenas te da tiempo a pensar la ruta.na_th_an escribió:Los juegos de este chico son la caña
Creo que se decidió más bien tirar por el ASM, aunque nunca se sabe:na_th_an escribió:A ver si se nos anima a dar el salto a z88dk+splib
http://www.worldofspectrum.org/forums/s ... hp?t=11683
-
na_th_an
- 256 bits
- Mensajes: 11874
- Registrado: 22 Abr 2005 13:25
- Contactar:
-
Ivanzx
- 256 bits
- Mensajes: 4316
- Registrado: 20 Nov 2005 00:50
- Ubicación: Frankfurt, Germany
- Contactar:
-
Ivanzx
- 256 bits
- Mensajes: 4316
- Registrado: 20 Nov 2005 00:50
- Ubicación: Frankfurt, Germany
- Contactar:
Re: Nuevo juego en Basic Compilado en WoS
Metalbrain escribió:Yo diría que es el segundo, el primero fue este:Ivanzx escribió: [...] solo que este es su primer juego realizado en Basic compilado.
http://xfaworld.balder.prohosting.com/t ... _hunt.html
Pensaba que ese fue realizado unicamente en Basic. Lo probé en su dia y no etsaba mal tiene buenas ideas este chico.
Saludos
-
Gandulf
-
Alx
- 256 bits
- Mensajes: 5895
- Registrado: 25 Dic 2005 19:42
- Ubicación: Barcelona
-
na_th_an
- 256 bits
- Mensajes: 11874
- Registrado: 22 Abr 2005 13:25
- Contactar:
En la ROM del Spectrum, entre otras cosas, hay un intérprete de BASIC. Cuando escribimos RUN, este programa se encarga de leer linea a linea de la memoria, mira que todo sea correcto, y ejecuta en caso afirmativo. Instrucción por instrucción, va comprobando todo, convirtiendo los números, haciendo los cálculos, ejecutando rutinas, y saltando a otros puntos. Como verás, esta es la forma mas "segura" ya que el ordenador no va a colgarse pero también es la forma más lenta.
Al compilar el código, eso que se hace "sobre la marcha" se hace de una vez, generando un código máquina que se puede ejecutar directamente.
Como BASIC es un lenguaje de muy alto nivel, jamás en la vida va a ser tan rápido como programar en ensamblador directamente, ya que así eres tú el que decide qué se hace en cada momento y tienes mucho más control sobre todo y puedes optimizar al máximo. El código máquina generado por un compilador nunca será tan bueno como el que genera un humano (bueno, un humano que sepa programar bien
), y en lenguajes de este tipo en los que todo está hecho al final te quedas con un montón de llamadas a rutinas. Sin embargo, en cosas como comprobaciones, bucles y saltos la velocidad puede llegar a ser hasta 20 veces más rápida que en BASIC interpretado. Por término medio (muy medio, esto varía mucho dependiendo de la naturaleza de tu programa) podemos decir que un juego en BASIC si se compila irá más o menos unas cinco veces más rápido, con picos de hasta 10 o 20 veces más rápido (en los cálculos).
Te pongo un ejemplo: imaginate una instrucción POKE 23692,255 en el medio de un programa BASIC. Al hacer RUN y ejecutar el intérprete, lo primero que se hace es identificar el token "POKE", luego se ve que haya dos números. Esos dos números estarán almacenados en el formato ese de 5 bytes (punto flotante), por lo que deberán ser convertidos. El primero a un número de 16 bits sin signo, comprobando que no nos pasamos de rango. El segundo a un número de 8 bits sin signo, también con sus debidas comparaciones. ¿Y si hubieramos puesto 236920, por ejemplo? Ese número está fuera de rango, y es algo que el intérprete comprueba, perdiendo tiempo. Luego, con todo validado y convertido, pondrá un 255 en la dirección 23692.
Al compilar, es el compilador quien transforma los números, quien comprueba el rango, y al final escribirá en memoria el código máquina del movimiento de datos sin más, algo parecido a:
Ahora compara el tiempo entre ejecutar esas tres líneas de código máquina (unos cuantos ciclos), con el de tener que interpretar y comprobar todo. ¿ves la diferencia?
Sin embargo un PRINT es distinto: el código generado será seguramente una llamada a un runtime que tendrá una rutina de PRINT que no podemos alterar y que será lo más general posible: valdrá para imprimir variables, para poner colores, entenderá el AT y otros códigos... Si lo que queremos es poner un texto en la tinta actual en el cursor actual todo eso no lo necesitamos, pero sigue estando ahí. Sin embargo, al programar en código máquina directamente, bien podríamos haber optimizado al máximo eliminando casos generales, y hacer una rutina que no contemplase nada más que lo que queremos. Esa es la diferencia entre el código generado por el compilador y el que podamos escribir nosotros directamente.
En HiSoft BASIC, además, puedes definir tipos de variables numéricas. Si por ejemplo solo vas a usar valores enteros, defines las variables como enteras. Además de solo ocupar 2 bytes en lugar de 5 (que es lo que ocupan las variables que representan números "reales"), un cálculo entero es "de cajón" y por tanto mucho más rápido que uno con números reales (que están representados en algún tipo de "coma flotante"), ya que en este último caso hay que hacer muchísimas más cosas.
En definitiva, compilar tu programa en BASIC puede hacer que se vuelva muy jugable Métete en desarrollo, en uno de mis hilos 
(lo vas a ver, pone CENSORED I y ][ y está en la primera página ) y pruebalos. Están hechos en BASIC compilado. Ese mismo programa en BASIC interpretado es tan lento que no se puede jugar.
ARF! Espero que haya quedado claro
Al compilar el código, eso que se hace "sobre la marcha" se hace de una vez, generando un código máquina que se puede ejecutar directamente.
Como BASIC es un lenguaje de muy alto nivel, jamás en la vida va a ser tan rápido como programar en ensamblador directamente, ya que así eres tú el que decide qué se hace en cada momento y tienes mucho más control sobre todo y puedes optimizar al máximo. El código máquina generado por un compilador nunca será tan bueno como el que genera un humano (bueno, un humano que sepa programar bien
), y en lenguajes de este tipo en los que todo está hecho al final te quedas con un montón de llamadas a rutinas. Sin embargo, en cosas como comprobaciones, bucles y saltos la velocidad puede llegar a ser hasta 20 veces más rápida que en BASIC interpretado. Por término medio (muy medio, esto varía mucho dependiendo de la naturaleza de tu programa) podemos decir que un juego en BASIC si se compila irá más o menos unas cinco veces más rápido, con picos de hasta 10 o 20 veces más rápido (en los cálculos).Te pongo un ejemplo: imaginate una instrucción POKE 23692,255 en el medio de un programa BASIC. Al hacer RUN y ejecutar el intérprete, lo primero que se hace es identificar el token "POKE", luego se ve que haya dos números. Esos dos números estarán almacenados en el formato ese de 5 bytes (punto flotante), por lo que deberán ser convertidos. El primero a un número de 16 bits sin signo, comprobando que no nos pasamos de rango. El segundo a un número de 8 bits sin signo, también con sus debidas comparaciones. ¿Y si hubieramos puesto 236920, por ejemplo? Ese número está fuera de rango, y es algo que el intérprete comprueba, perdiendo tiempo. Luego, con todo validado y convertido, pondrá un 255 en la dirección 23692.
Al compilar, es el compilador quien transforma los números, quien comprueba el rango, y al final escribirá en memoria el código máquina del movimiento de datos sin más, algo parecido a:
Código: Seleccionar todo
ld hl, 23692
ld a, 255
ld (hl), aSin embargo un PRINT es distinto: el código generado será seguramente una llamada a un runtime que tendrá una rutina de PRINT que no podemos alterar y que será lo más general posible: valdrá para imprimir variables, para poner colores, entenderá el AT y otros códigos... Si lo que queremos es poner un texto en la tinta actual en el cursor actual todo eso no lo necesitamos, pero sigue estando ahí. Sin embargo, al programar en código máquina directamente, bien podríamos haber optimizado al máximo eliminando casos generales, y hacer una rutina que no contemplase nada más que lo que queremos. Esa es la diferencia entre el código generado por el compilador y el que podamos escribir nosotros directamente.
En HiSoft BASIC, además, puedes definir tipos de variables numéricas. Si por ejemplo solo vas a usar valores enteros, defines las variables como enteras. Además de solo ocupar 2 bytes en lugar de 5 (que es lo que ocupan las variables que representan números "reales"), un cálculo entero es "de cajón" y por tanto mucho más rápido que uno con números reales (que están representados en algún tipo de "coma flotante"), ya que en este último caso hay que hacer muchísimas más cosas.
En definitiva, compilar tu programa en BASIC puede hacer que se vuelva muy jugable
Métete en desarrollo, en uno de mis hilos (lo vas a ver, pone CENSORED I y ][ y está en la primera página ) y pruebalos. Están hechos en BASIC compilado. Ese mismo programa en BASIC interpretado es tan lento que no se puede jugar.ARF! Espero que haya quedado claro
Última edición por na_th_an el 22 Jun 2006 15:06, editado 1 vez en total.
-
Gandulf
Un programa puede ser interpretado o compilado.
Intrepretado: Cada línea de programa es traducida en tiempo de ejecución por un intérprete, que la ejecuta. Hay muchas variedades de intérpretes, desde los muy sencillos, hasta los muy óptimos, como puede ser Java. Donde tu programa queda compilado en el lenguaje de "la máquina virtual java", luego es interpretado por esta en tiempo de ejecución.
Compilado: El programa se compila. Es decir, tu código fuente genera un ejecutable para un procesador, o sea, código máquina. Este código máquina dista mucho de ser igual de óptimo que si lo hicieras en código máquina puro y duro, ya que no tienes libertad para controlar tu los registros e instrucciones máquina a utilizar, y ocupa mucha más memoria.
Cada uno tiene sus ventajas e inconvenientes.
Compilado = Más velocidad pero no es portable, a no ser que compiles para otras máquinas.
Interpretado = Menos velocidad pero más portabilidad, ya que tu mismo programa será ejecutado por el intérprete adecuado en cada máquina.
En máquinas modernas no tiene mucho sentido, o ninguno, programar en ASM, ya que los sistemas operativos modernos tienen drivers devídeo, sonido, etc, que utilizan las funciones de aceleración que proporciona el fabricante y el código resultante de una compilación cin un compilador moderno es bastante óptima. Y hay APIs multiplataforma para desarrollo de casi todo.
En máquinas de 8 bits, por el contrario, el uso de código máquina es fundamental, si se quiere aprovechar la memoria al máximo y optimizar las rutinas por t-estados de procesador. Esto no quiere decir que un programa compilado no pueda ser excelente. Por el contrario en 8 bits los programas interpretados corren a una velocidad nefasta, salvo que utilizen rutinas de vídeo escritas en asm.
Intrepretado: Cada línea de programa es traducida en tiempo de ejecución por un intérprete, que la ejecuta. Hay muchas variedades de intérpretes, desde los muy sencillos, hasta los muy óptimos, como puede ser Java. Donde tu programa queda compilado en el lenguaje de "la máquina virtual java", luego es interpretado por esta en tiempo de ejecución.
Compilado: El programa se compila. Es decir, tu código fuente genera un ejecutable para un procesador, o sea, código máquina. Este código máquina dista mucho de ser igual de óptimo que si lo hicieras en código máquina puro y duro, ya que no tienes libertad para controlar tu los registros e instrucciones máquina a utilizar, y ocupa mucha más memoria.
Cada uno tiene sus ventajas e inconvenientes.
Compilado = Más velocidad pero no es portable, a no ser que compiles para otras máquinas.
Interpretado = Menos velocidad pero más portabilidad, ya que tu mismo programa será ejecutado por el intérprete adecuado en cada máquina.
En máquinas modernas no tiene mucho sentido, o ninguno, programar en ASM, ya que los sistemas operativos modernos tienen drivers devídeo, sonido, etc, que utilizan las funciones de aceleración que proporciona el fabricante y el código resultante de una compilación cin un compilador moderno es bastante óptima. Y hay APIs multiplataforma para desarrollo de casi todo.
En máquinas de 8 bits, por el contrario, el uso de código máquina es fundamental, si se quiere aprovechar la memoria al máximo y optimizar las rutinas por t-estados de procesador. Esto no quiere decir que un programa compilado no pueda ser excelente. Por el contrario en 8 bits los programas interpretados corren a una velocidad nefasta, salvo que utilizen rutinas de vídeo escritas en asm.
-
Alx
- 256 bits
- Mensajes: 5895
- Registrado: 25 Dic 2005 19:42
- Ubicación: Barcelona
Madre mia os habeis quedado pero que muy agusto jajaja ...
O sea, que es lo que yo te decía, que va más rápido.
El interés me viene porque decidido a relizar mi sueño de hacer un juego DE SPECTRUM de momento ya me he chupado el Basic y empiezo con el código máquina /assembler, y como lo de que en la memoria rom del ZX está el programa monitor ya lo sé y me explican que código máquina es programar más directamente el Z80, pues por eso lo preguntaba, porque compilar ya sé que es traducir un lenguaje de alto nivel a código que entiende la máquina (ceritos y unitos
) y que va follao.
Gracias por las explayadas
...O sea, que es lo que yo te decía, que va más rápido.
El interés me viene porque decidido a relizar mi sueño de hacer un juego DE SPECTRUM de momento ya me he chupado el Basic y empiezo con el código máquina /assembler, y como lo de que en la memoria rom del ZX está el programa monitor ya lo sé y me explican que código máquina es programar más directamente el Z80, pues por eso lo preguntaba, porque compilar ya sé que es traducir un lenguaje de alto nivel a código que entiende la máquina (ceritos y unitos
) y que va follao.Gracias por las explayadas
1:1 Amarás al Spectrum por encima de todas las cosas
-
esteban.platz
- 8 bits
- Mensajes: 14
- Registrado: 24 May 2007 21:11
-
na_th_an
- 256 bits
- Mensajes: 11874
- Registrado: 22 Abr 2005 13:25
- Contactar:
El programa viene con completa documentación, pero siempre te puedes leer mis artículos en la revista ZXSF.
http://microhobby.speccy.cz/zxsf/pagina_1.htm
Bájate el número 11 de aquí (enlace directo):
http://microhobby.speccy.cz/zxsf/zxsf-11.pdf
http://microhobby.speccy.cz/zxsf/pagina_1.htm
Bájate el número 11 de aquí (enlace directo):
http://microhobby.speccy.cz/zxsf/zxsf-11.pdf
-
NeilParsons
- 128 bits
- Mensajes: 1725
- Registrado: 23 Oct 2006 13:21
- Ubicación: Al borde del estrecho y a un paso de Gibraltar
- Contactar:
Volviendo al hilo de este post, he entrado en los links arriba mencionados pero por algún motivo los juegos no se encuentran para descargar. Habrá que preguntar a su autor que qué passsa!!!
Por cierto, Nath, gracias por mencionar el curso que te estoy publicando con gran entusiasmo. La segunda parte del curso ya aparecerá en cuanto haga la revista, que tardará bastante en salir, mientras termino con otra cosa que ando entre manos. !!!!!
La clave es MH
Por cierto, Nath, gracias por mencionar el curso que te estoy publicando con gran entusiasmo. La segunda parte del curso ya aparecerá en cuanto haga la revista, que tardará bastante en salir, mientras termino con otra cosa que ando entre manos. !!!!!
La clave es MH
They tried to make me go to rehab
but I said, no no no.
but I said, no no no.
-
na_th_an
- 256 bits
- Mensajes: 11874
- Registrado: 22 Abr 2005 13:25
- Contactar:
-
Ivanzx
- 256 bits
- Mensajes: 4316
- Registrado: 20 Nov 2005 00:50
- Ubicación: Frankfurt, Germany
- Contactar:
Los juegos ya estan en el archivo de WoS, asi que prueba a buscarlos por ahi Ignacio, seguramente ya esten todos.RDisky escribió:Volviendo al hilo de este post, he entrado en los links arriba mencionados pero por algún motivo los juegos no se encuentran para descargar. Habrá que preguntar a su autor que qué passsa!!!
La clave es MH
MH.....a que me recuerda eso??
