[PROGRAMACION] El spectrum no deberia programarse en C???
Luis Perez
wrote:
>***el Spectrum no deberia programarse en C***
>
>Es una maquina muy simple, con unos recursos muy escasos. En mi opinion, es
>necesario tener control absoluto de lo que hace cada BYTE, y eso no se
>consigue mas que con ensamblador. Cada problema a resolver y cada situacion
>es unica, y no valen las soluciones genéricas.
>
>Ahora, propongo que todos los flames C vs ASM sean disparados apuntando a un
>thead nuevo para no engrosar este mas de la cuenta :-)
Bueno... Es cierto que el spectrum tiene unos recursos muy
escasos pero creo que si se puede usar el C con el. Para empezar el
que el spectrum sea tan simple es una ventaja tanto para el
programador de ensamblador como para el compilador que no necesita
realizar operaciones ni calculos excesivos para optimizar el codigo.
No se la calidad de codigo que genera el compilador de C z88dk pero
bajo mi experiencia, si genera un codigo bueno, es bastante dificil de
mejorar haciendolo directamente en ensamblador. Solo seria util usar
ensamblador para las rutinas criticas o si andamos bastantes escasos
de memoria (si, el spectrum tiene poca memoria, pero depende de que
tipo de programa estemos realizando)...
Yo he hecho programas en ensamblador del 80X86, DLX, y
SuperDLX. En estos dos ultimos casos eran bastante faciles de optimzar
porque el compilador de C a DLX era una kk. ¿Y en el de 80x86? Si el
codigo en C no estaba optimizado podias mejorar algo el codigo, pero
si creabas un programa en C optimizado (duplicando bucles, haciendo
que la prediccion de salto de los pentium no falle, optimizando las
operaciones ...) y usando todas las optimizaciones del compilador
apenas (no lo consegui) puedes optizar el codigo que te genera el
compilador de C(use el GCC de linux creo que con la opcion -O3).
Lo que quiero decir es que depende mucho de lo bueno que sea
el compilador y de que programa quieras hacer. En general, si el
programa no tiene requisitos criticos, y si uno se encarga de
optimizar el codigo C, uno puede crear un programa mas o menos igual
de eficiente que uno hecho directamente en ensamblador. Ojo!!! Codigo
C optimizado!!! y para ello se necesita conocer muy bien la maquina
bajo la que se esta programando.
Como anecdota. Una vez tuve que hacer una practica de sonido
en el que utilizabamos la interrupcion del reloj para sincronizarnos
con la tarjeta de sonido. Nosotros hicimos este programa en C,
optimizando las operaciones (simplificando el calculo de la direccion
de memoria...), y lo comparamos con uno hecho realizado directamente
en ensamblador, y a pesar de que la captura de sonido pudiera ser una
rutina critica apenas se notaba la diferencia entre c y ensamblador.
Ojo!! Si se notaba la diferencia entre un programa en C normal y el de
C optimizado y el de ensamblador. El unico inconveniente es que los en
C optimizados suele ser bastante dificiles de entender...
Una de las principaples ventajas del C es que esta 'cerca de
la maquina' es un lenguaje bastante proximo al ensamblador pero
estructurado, y por ello mas dificil de entender que java, pascal pero
mas facil que ensamblador... Hace un programa en C es bastante
eficiente si uno sabe PROGRAMAR en C, conoce el compilador y es
bueno, y CONOCE bien la maquina en la que trabaja.
Saludos,
Luis Perez.
TrueVid
Mi comentario original,
***el Spectrum no deberia programarse en C***
no era un comentario en contra del C propiamente dicho, sino mas bien de su
uso en un Spectrum. En Spectrum, con el C solo veo desventajas. Lo que dices
del C como lenguaje utilizado en otros sistemaa es cierto, pero no se aplica
en un Spectrum. La simplicidad de su procesador no lo hace mas apto para
utilizar lenguajes compilados. Yo creo que es mas bien todo lo contrario. .
Por ejemplo:
Entre los programadores de Gameboy, sobretodo para la Advance, es bastante
comun utilizar el C como lenguaje principal.Y la GBA tiene un procesador mas
simple que un ladrillo, te lo aseguro. Sin embargo el codigo que generan los
compiladores es, en mi opinion, un espanto. Y el que generaban para la GB
Color, con un procesador que es como un Z80 capado (mas simple todavia)
entraba ya en el terreno de la blasfemia.
OK, en cualquier caso actualmente todo el mundo gameboyero admite que las
rutinas mas 'sensibles' sean programadas en ensamblador (principalmente,
acceso a memoria de video y tal). Y estamos hablando de un sistema con un
hardware de video sencillamente impresionante. Pues aun asi, todo el mundo,
desde amateurs a profesionales, sigue recurriendo al ensamblador para el
trabajo "sucio"
En un Spectrum, el 90% de tu codigo es trabajo sucio. No hay planos por
hardware, ni sprites, ni dmas, ni interrupciones sincronizadas con el video
(excepto el vbl claro), ni zooms ni rotaciones, ni nada de nada. Todo
depende de *tu* codigo y de tu habilidad para sincronizarte al ciclo con el
video para que todo vaya fino como una seda.
Para hacer un Cobra, o un Hysteria, o un Zynaps, necesitas control absoluto
sobre cada instruccion que se ejecuta. Entonces, en una situacion asi, como
se puede confiar en el codigo creado por un algoritmo que no sabe si esta
compilando un matamarcianos o una base de datos??
Los compiladores no se inventaron el año pasado. Funcionan desde mucho antes
de 1982, y ningun desarrollador de prestigio para Spectrum se planteo jamas
el C como alternativa al ensamblador. Ni siquiera cuando era norma convertir
el mismo juego con el mismo codigo para 3 o 4 sistemas distintos. Cuando un
lenguaje portable como el C hubiese sido la eleccion obvia, siempre se
utilizó el ensamblador.
Por algo sería, no?
--
TrueVid
www.truevideo.net
llllllllllllllll Iñigo llllllllllllllll
"Luis Perez" <lu...@fedro.ugr.es> escribió en el mensaje
news:3bef386c...@News.CIS.DFN.DE...
> On Sun, 11 Nov 2001 20:28:51 +0100, "TrueVid" <dev [@] truevideo.net>
> wrote:
>
> >***el Spectrum no deberia programarse en C***
> >
> >Es una maquina muy simple, con unos recursos muy escasos. En mi opinion,
es
> >necesario tener control absoluto de lo que hace cada BYTE, y eso no se
> >consigue mas que con ensamblador. Cada problema a resolver y cada
situacion
> >es unica, y no valen las soluciones genéricas.
> >
> >Ahora, propongo que todos los flames C vs ASM sean disparados apuntando a
un
> >thead nuevo para no engrosar este mas de la cuenta :-)
>
> Bueno... Es cierto que el spectrum tiene unos recursos muy
> escasos pero creo que si se puede usar el C con el. Para empezar el
> que el spectrum sea tan simple es una ventaja tanto para el
> programador de ensamblador como para el compilador que no necesita
> realizar operaciones ni calculos excesivos para optimizar el codigo.
> No se la calidad de codigo que genera el compilador de C z88dk pero
> bajo mi experiencia, si genera un codigo bueno, es bastante dificil de
> mejorar haciendolo directamente en ensamblador.
Siento mucho contradecirte pero el derroche de código en C es abismal y si
crees que el rendimiento que puedes obtener es similar al obtenido
programando en ensamblador es que o no has hecho nunca nada serio para el
Z80 en ensamblador o es que hablas sin conocimiento.
No dudo que tu experiencia con C sea muy alta y que el rendimiento que
obtengas sea muy grande (sobre todo en un PC) pero en un Spectrum...
incomparable al ensamblador.
Estoy convencido de que ningún juego "decente" del año 87 en adelante
escrito en ensamblador podría reescribirse en C y obtener la misma velocidad
y que quepa en esos 48Kb. Ya no es le hecho de que se deba o no, es
simplemente que no se podría hacer.
Hoy día en un PC no merece la pena programar en ensamblador porque todos los
límites de hardware de hace años se han superado con creces. ¿Que uno hace
un programa en Visual Basic y va un poco lento? No hay problema, cambias de
placa y micro y asunto arreglado. Así es como funcionan las cosas hoy en
día.
Entonces programar era un arte.
Un saludo.
Luis Perez
wrote:
>Holas a todos!
>
>Mi comentario original,
>
>***el Spectrum no deberia programarse en C***
>
>no era un comentario en contra del C propiamente dicho, sino mas bien de su
>uso en un Spectrum. En Spectrum, con el C solo veo desventajas. Lo que dices
>del C como lenguaje utilizado en otros sistemaa es cierto, pero no se aplica
>en un Spectrum. La simplicidad de su procesador no lo hace mas apto para
>utilizar lenguajes compilados. Yo creo que es mas bien todo lo contrario.
Cuanto mas simple mejor. Me explico, los compiladores de
procesadores RISC ofrecen mejores prestaciones que los compiladores de
CISC ¿Por que? En un RISC no te tienes que preocupar de los
tropecientos modos de direccionamiento de un CISC (vease pentium y sus
variantes), de cual es mas efieciente en cada caso... Luego tienes
tropecientos modos de realizar la misma operacion, que si en vez de
cmp para compara usas xor (¿creo que era esto?) haces lo mismo pero va
mas rapido y cosas por el estilo... Luego estan las excepciones,
numerosas en intel (por ser CISC) y que no ocurren en un RISC, de que
existe tal instruccion "fufufu" que toma el valor de EAX, lo
multiplica por EBX, lo divide por la razon aurea y te devuelve el
numero de 1 que queda... El meter todas estas maravillosas y
utilisimas instrucciones en un compilador y que sepa utilizarlas es
muy dificil... El z80 es CISC pero no es muy complicado, no es escalar
y no es SuperEscalar (que conste que para un compilador tambien es muy
dificil reorganizar las instrucciones de forma que se minimicen los
stalls (¿retrasos?) por los problemas que causa el acceso compartido a
la memoria, las unidades de calculo...)
>Por ejemplo:
>
>Entre los programadores de Gameboy, sobretodo para la Advance, es bastante
>comun utilizar el C como lenguaje principal.Y la GBA tiene un procesador mas
>simple que un ladrillo, te lo aseguro. Sin embargo el codigo que generan los
>compiladores es, en mi opinion, un espanto. Y el que generaban para la GB
>Color, con un procesador que es como un Z80 capado (mas simple todavia)
>entraba ya en el terreno de la blasfemia.
Como dije, el compilador tiene que ser bueno. El que yo use
para practicas de DLX y SuperDLX daba pena y hasta un nene de cuatro
meses podia optimizarlo. X-DDDD
>OK, en cualquier caso actualmente todo el mundo gameboyero admite que las
>rutinas mas 'sensibles' sean programadas en ensamblador (principalmente,
>acceso a memoria de video y tal). Y estamos hablando de un sistema con un
>hardware de video sencillamente impresionante. Pues aun asi, todo el mundo,
>desde amateurs a profesionales, sigue recurriendo al ensamblador para el
>trabajo "sucio"
Jamas quise decir que todo programa se pueda hacer unicamente
en C... Existen rutinas que se deben hacer en ensamblador porque son
criticas, son de tiempo real.... Lo que quise decir es quel, no creo
que se tenga que acudir siempre, por ser para spectrum, al
ensamblador, me explico...
Existe un hecho que es que el 90% del tiempo de ejecucion de
un programa se esta ejecutando un 10% del mismo (creo que regla que se
llama regla del 90-10). Si estas haciendo un programa (estoy hablando
de forma generica), con solo realizar en ensamblador ese 10%, el
usuario no sabria que el resto del programa (un 90%) esta hecho en
C... ¿No? A parte esta, que si el compilador de C es bueno genera un
codigo bueno. Una universidad, creo que americana, hizo una
comparacion C-ensamblador en un procesador RISC, y los programas en C
iban alrededor del 95% de rapidos que su analogo en ensamblador. J****
por una mierda de 5% mas lento que va ir el 10% de ejecucion del
programa te vas a matar a realizar el programa en ensamblador???? X-DD
Repito, hablo en general, ahora me puede venir alguien con que
tal juego solo se puede hacer en ensamblador, o tal demo... Ok, las
rutinas criticas (por ejemplo las graficas) y los programas criticos
en ensamblador! Jamas se me ocurria hacer en C para spectrum un
programa que creo que me a ocupar 40Ks si lo hiciera directamente en
ensamblador porque en C me ocuparian mas... Por cierto, existen muchos
programas que no son juegos, y juegos en el que a lo mejor el 70 o el
80% de el se pueden hacer en C... No digo que todos los juegos, ni
todos los programas se puedan hacer en C, solo que generalizar y decir
que el C y el spectrum no van bien juntos es un poco radical.
>En un Spectrum, el 90% de tu codigo es trabajo sucio. No hay planos por
>hardware, ni sprites, ni dmas, ni interrupciones sincronizadas con el video
>(excepto el vbl claro), ni zooms ni rotaciones, ni nada de nada. Todo
>depende de *tu* codigo y de tu habilidad para sincronizarte al ciclo con el
>video para que todo vaya fino como una seda.
Ese 90% dependera mucho de lo que uno quiera hacer ¿no? porque
si yo quiero hacer un edit, un aventura conversacional, un comecocos,
una base de datos, o un simple matamarcianos (sin scroll parallax ni
nada de eso), un buscaminas, o pongamonos bestias el windows, no creo
que deba usar ensamblador en tooodooo el programa o en casi todo (ya
se que el windows se podria hacer en basic). Es cierto que el spectrum
esta bastante limitado, pero hoy en dia los compiladores estan muy
avanzados y si es bueno, puede servir para generar programas bueno, a
lo mejor no obras de arte, no programas grandes, pero si utiles,
relatiavamente rapidos, y de desarrollo facil.
>Para hacer un Cobra, o un Hysteria, o un Zynaps, necesitas control absoluto
>sobre cada instruccion que se ejecuta. Entonces, en una situacion asi, como
>se puede confiar en el codigo creado por un algoritmo que no sabe si esta
>compilando un matamarcianos o una base de datos??
Aunque nos duela, a un compilador le va a dar igual compilar
un algoritmo de ordenacion de juegos de spectrum, que uno de
ordenacion de tias en bikini. X-DDD
Sobre lo otro, para crear algo en C y que sea igual de
eficiente que el ensamblador (si se puede, que no siempre se puede
hacer) tienes que conocer mucho C, saber lo que hace el Compilador
(como traduce las instrucciones ...) y conocer bien la maquina.
Sabiendo todo esto, puedes confiar en ese 'codigo' que te genera si
sabes que es bueno y si ademas le 'ayudas' a que sea bueno...
>Los compiladores no se inventaron el año pasado. Funcionan desde mucho antes
>de 1982, y ningun desarrollador de prestigio para Spectrum se planteo jamas
>el C como alternativa al ensamblador. Ni siquiera cuando era norma convertir
>el mismo juego con el mismo codigo para 3 o 4 sistemas distintos. Cuando un
>lenguaje portable como el C hubiese sido la eleccion obvia, siempre se
>utilizó el ensamblador.
>
>Por algo sería, no?
Estamos de acuerdo, pero hay que tener en cuenta que las
maquinas de ahora no son iguales que las de hace 20 anios. Por
ejemplo, los algoritmos geneticos creo que son de antes de los 80 y a
nadie se le ocurriria intentar implementar en un zx80 un algoritmo
genetico para resolver el problema x con una poblacion de 100
individuos y 1000 iteraciones, porque:
- No tienes memoria,
- Tarda mucho (¿semanas?).
Lo mismo ocurre con los compiladores, ahora que tenemos
maquinas rapidas podemos usar cosas que antes no podiamos, cosas que
existian, estaban estudiadas, pero que porque los recursos de la epoca
no podian llevarlos a la practica. El Z88dk es un compilador de C para
PC que genera codigo para Z80, tiene los recursos necesarios para ser
un compilador bueno, solo falta ver si lo es...
Un compilador tiene un analizador lexico, sintactico y otro
semantico, luego necesita crear tablas para las optimizaciones, para
guardar el nombre de las variables, direccion y operando de las
funciones, tienes que guardar el codigo fuente, el codigo generado...
Hacer un compilador de spectrum en un spectrum es muuuuyyy dificil y
ademas que optimice codigo de forma eficiente casi imposible si no es
imposible. Los compiladores actuales dan muchas vueltas al codigo,
buscan realizar los menos accesos posibles a memoria, usar el minimo
numero de instrucciones... Esto ultimo se puede hacer ahora bien
porque tenemos maquinas (actuales) que se lo pueden permitir... En los
anios 80 ninguna maquina podria ejecutar el gcc actual...
Por cierto, algunas veces el C eficiente no es portable,
porque usas 'trucos' para hacerlo mas eficiente. (por ejemplo trabajar
a nivel de bit) y puede que para hacerlo efieciente usando cosas tabus
de la programacion estructurada (los gotos, cases sin breaks...).
Y para terminar, hablando de C... El C es bastante antiguo,
(viene del Algol ¿No?) y creo que la mayor parte de Unix (y Linux)
esta basado en C ( y el Unix tambien es antiguo), y una de las razones
principales de usar C en Unix fue porque es mas facil de mantener que
el ensamblador y ofrece un rendimiento bastante similar a este. Hace
tiempo me lei el Bach (creo que se escribe asi) un libro bastante
bueno sobre Unix, y me acuerdo que en uno de los temas comparaba el
Unix con otros sistemas operativos hechos en ensamblador, y decia algo
asi, que aunque el unix estaba hecho en su mayoria en C tenia una
eficiencia similar al de otros sistemas operativos hechos en
ensamblador (y a veces mejor ¡¡Viva linux!!). ¿por que? En general
porque es un lenguaje muy cercano al ensamblador que permite
muuuuuuuchas "guarradas" y luego implementaron funciones de muy bajo
nivel... Creo que fuiste tu el que comento que hacer un rutina general
para manejar los sprites en el spectrum es poco eficiente, ¿No se
podria bajar un poco el nivel de esas rutinas y crear funciones en C
que me permitan crear facilmente construir la rutina que yo desee, o
varias rutinas especificas para los casos mas habituales con los que
me pueda encontrar? Cierto es que no seran igual de eficientes que
una en ensamblador pero a lo mejor para los propositos de la mayoria
de las personas sirve... O por ejemplo, de acceso al disco, imprimir
pantalla, calculos en coma flotante... Existe un monton de rutinas que
no se pueden crear para C y ser lo suficientemente eficientes, a lo
mejor las rutinas graficas se tenga que implementar exclusivamente en
ensamblador (no lo se)... El C no es Visual Basic, ni java, ni pascal,
ni basic..., puede que no sea tan rapido como el ensamblador, pero
tampoco se queda muy lejos de el (al 90% ...) si el compilador y el
programador son buenos...
Por cierto, En linux ha sido en el unico sistema operativo que he
logrado escuchar mp3 en mi 486 a 33Mhz sin saltos!!!.
Saludos,
Luis Perez.
Luis Perez
llllllllllllllll" <inig...@teleline.es> wrote:
>
>Siento mucho contradecirte pero el derroche de código en C es abismal y si
Dependera de que compilador uses, que instrucciones uses... Si
en vez de printf uso puts, el codigo ocupara menos, si en vez de eso
se me ocurre hacer que un puntero apunte a la zona de video menos
todavia y no creo que el compilador invente codigo para que el
programa ocupe mas y aparente mas... Ni creo que tarde tanto en
generar codigo porque tenga bucles inutiles ni nada eso... Ademas, ¿te
has puesto a estudiar el codigo optimizado por ejemplo de un algoritmo
de ordenacion creado con el gcc y optimizado por este? Yo si, y cuesta
muchiiiiiiiisimo mejorarlo.
>crees que el rendimiento que puedes obtener es similar al obtenido
>programando en ensamblador es que o no has hecho nunca nada serio para el
>Z80 en ensamblador o es que hablas sin conocimiento.
>No dudo que tu experiencia con C sea muy alta y que el rendimiento que
>obtengas sea muy grande (sobre todo en un PC) pero en un Spectrum...
Del ensamblador del z80 por desgracia se poco, pero de
ensamblador del 8086 bastante, algo del de los pentium, conozco el de
el DLX, y el de un microcontrolador de intel (no me acuerdo del
nombre), del ODE (que es un m*****, ya lo se). Se C, smalltalk, java,
c++, prolog, lisp, pascal, delphi, hope, mathematica ¿sigo? Y como he
dicho, si se han logrado compiladores que generan codigo eficientes en
C para PC, que es una arquitectura muuuuchiiisimo mas complicada y mas
dificil de aprovechar que la de un spectrum. ¿Por que no puede existir
un compilador de C que genere codigo eficiente para el spectrum? ¿Es
que el spectrum es mas feo? X-DDD
>incomparable al ensamblador.
>Estoy convencido de que ningún juego "decente" del año 87 en adelante
>escrito en ensamblador podría reescribirse en C y obtener la misma velocidad
>y que quepa en esos 48Kb. Ya no es le hecho de que se deba o no, es
>simplemente que no se podría hacer.
Parte del programa en C, no todo... En el otro mensaje tienes
una explicacion mas larga... Las rutinas criticas en ensamblador **si
hace falta** vale...
>Hoy día en un PC no merece la pena programar en ensamblador porque todos los
>límites de hardware de hace años se han superado con creces. ¿Que uno hace
>un programa en Visual Basic y va un poco lento? No hay problema, cambias de
>placa y micro y asunto arreglado. Así es como funcionan las cosas hoy en
>día.
Un algoritmo malo sera malo en ensamblador, c, visual basic, y
lisp y seguira siendo malo dentro de 20 anios. El burbuja por mucho
pentium-7 que tengas ira lento!... Un programa bueno puede ser bueno
en cualquier lenguaje, el lenguaje no va a hacer que un programa sea
bueno o malo... Y hoy en dia se programa menos en ensamblador porque
no interesa, los compiladores generan codigo bueno, las maquinas son
buenas, y sobre todo porque en ensamblador es bastante dificil de
hacer programas de CALIDAD (cuando hablo de calidad me refiero a
facilidad para el mantenimiento, libre de errores, codigo
reutilizable...).
>Entonces programar era un arte.
Y lo sigue siendo... Una vez vi un tetris en C que ocupaba un
linea, un laberinto, con graficos muy simples y scroll y el programa
ocupaba una linea... Hoy en dia se hacen maravillas en la
informatica... Algoritmos de colonias de hormigas, el calculo
simbolico es ahora cuando esta en manos de todos y es un gran progreso
en el mundo de la informatica y de las matematicas. La inteligencia
artificial esta mas desarrollada que nunca... Programar sigue siendo
un arte porque no todo el mundo es capaz de desarrollar todo con unos
conocimientos basicos, la unica diferencia es que antes hacer un juego
bueno para spectrum era dificil, y ahora un juego para pc no, pero
ahora hacer un programa que interaccione con un mundo virtual de
forma inteligente y eficiente es dificil y no todo el mundo puede
hacerlo y antes era una utopia. La informatica evoluciona y su arte
tambien. Ahora hacer dibujos como los de las cuevas de altamira no
son arte, pero quien de aqui es capaz de pintar un cuadro que parezca
real?? Pocos, el arte evoluciona, porque el hombre evoluciona y lo que
antes era dificil y era arte ahora es facil, pero lo que antes era
imposible ahora es dificil y pasa a ser arte.
Adoro el spectrum, sus programas, sus obras de arte, pero no
hay que despreciar lo actual por ser actual. Ahora tambien hay gente
que programa de verdad y lo hace tanto en visual basic como en C o en
ensamblador...
Saludos,
Luis Perez
Santiago Romero
> Existe un hecho que es que el 90% del tiempo de ejecucion de
> un programa se esta ejecutando un 10% del mismo (creo que regla que se
> llama regla del 90-10). Si estas haciendo un programa (estoy hablando
> de forma generica), con solo realizar en ensamblador ese 10%, el
> usuario no sabria que el resto del programa (un 90%) esta hecho en
> C... ¿No? A parte esta, que si el compilador de C es bueno genera un
Exacto. Es la famosa regla 90-10, y es perfectamente aplicable a
cualquier máquina. Si yo hago un juego, lo importante es que las
rutinas que dibujan 20 sprites por cada frame estén en asm, pero
que el bucle del programa
while(!finjuego)
{
for(i=0; i<lista_sprites; i++)
MoverSprites(lista, i);
blabla();
}
puede estar perfectamente en C. Con optimizar en asm las rutinas
que dibujan los sprites, bastaría (es un ejemplo).
La prueba, el DOOM de MSDOS que iba en 386 y era una maravilla para
su época, y sólo tenía 3 rutinas en ASM: el polling del joystick,
el trazado de lineas verticales texturadas y el trazado de lineas
horizontales texturadas.
saludos :)
--
Santiago Romero
Departamento de Sistemas
sro...@servicom2000.com
C/ Primado Reig, 189 entlo
46020 Valencia - Spain
Tel. (+34) 96 332 12 00
Fax. (+34) 96 332 12 01
http://www.servicom2000.com
Santiago Romero
El Tue, 13 Nov 2001 06:05:13 GMT, Luis Perez escribió:
> Del ensamblador del z80 por desgracia se poco, pero de
> ensamblador del 8086 bastante, algo del de los pentium, conozco el de
> el DLX, y el de un microcontrolador de intel (no me acuerdo del
8051, supongo :)
> nombre), del ODE (que es un m*****, ya lo se). Se C, smalltalk, java,
> c++, prolog, lisp, pascal, delphi, hope, mathematica ¿sigo? Y como he
Yo programo o he programado en BASIC, ASM de Z80, Pascal, C, ObjectPascal
(Delphi), C++, C++ Builder, asm de 80x86, asm de 8051, asm
> dicho, si se han logrado compiladores que generan codigo eficientes en
> C para PC, que es una arquitectura muuuuchiiisimo mas complicada y mas
> dificil de aprovechar que la de un spectrum. ¿Por que no puede existir
> un compilador de C que genere codigo eficiente para el spectrum? ¿Es
> que el spectrum es mas feo? X-DDD
Es más, hay compiladores de C para el 8051 (de 1 KB de RAM a 8 KB de RAM!)
y para los PIC (piccc, micros desde 192 BYTES de ram a 8KB de RAM), y
con juegos de instrucciones MUY REDUCIDOS. entonces... ¿porque no podría
programarse en C un Spectrum de 48K con un peaso z80 mejor que el 8051?
Yo he usado esos compiladores (además de programar a mano esos micros)
y son una maravilla, y no creo que z88dk lo haga peor que esos.
> Un algoritmo malo sera malo en ensamblador, c, visual basic, y
> lisp y seguira siendo malo dentro de 20 anios. El burbuja por mucho
> pentium-7 que tengas ira lento!... Un programa bueno puede ser bueno
Veo que pensamos exactamente igual, :-)))
>>Entonces programar era un arte.
>
> Y lo sigue siendo... Una vez vi un tetris en C que ocupaba una linea,
[sromero@strange:~]$ dpkg -L screen | grep tetris
/usr/share/doc/screen/terminfo/tetris.c.gz
[sromero@strange:~]$ zcat /usr/share/doc/screen/terminfo/tetris.c.gz
long h[4];t(){h[3]-=h[3]/3000;setitimer(0,h,0);}c,d,l,v[]={(int)t,0,2},w,s,I,K
=0,i=276,j,k,q[276],Q[276],*n=q,*m,x=17,f[]={7,-13,-12,1,8,-11,-12,-1,9,-1,1,
12,3,-13,-12,-1,12,-1,11,1,15,-1,13,1,18,-1,1,2,0,-12,-1,11,1,-12,1,13,10,-12,
1,12,11,-12,-1,1,2,-12,-1,12,13,-12,12,13,14,-11,-1,1,4,-13,-12,12,16,-11,-12,
12,17,-13,1,-1,5,-12,12,11,6,-12,12,24};u(){for(i=11;++i<264;)if((k=q[i])-Q[i]
){Q[i]=k;if(i-++I||i%12<1)printf("\033[%d;%dH",(I=i)/12,i%12*2+28);printf(
"\033[%dm "+(K-k?0:5),k);K=k;}Q[263]=c=getchar();}G(b){for(i=4;i--;)if(q[i?b+
n[i]:b])return 0;return 1;}g(b){for(i=4;i--;q[i?x+n[i]:x]=b);}main(C,V,a)char*
*V,*a;{h[3]=1000000/(l=C>1?atoi(V[1]):2);for(a=C>2?V[2]:"jkl pq";i;i--)*n++=i<
25||i%12<2?7:0;srand(getpid());system("stty cbreak -echo stop u");sigvec(14,v,
0);t();puts("\033[H\033[J");for(n=f+rand()%7*4;;g(7),u(),g(0)){if(c<0){if(G(x+
12))x+=12;else{g(7);++w;for(j=0;j<252;j=12*(j/12+1))for(;q[++j];)if(j%12==10){
for(;j%12;q[j--]=0);u();for(;--j;q[j+12]=q[j]);u();}n=f+rand()%7*4;G(x=17)||(c
=a[5]);}}if(c==*a)G(--x)||++x;if(c==a[1])n=f+4**(m=n),G(x)||(n=m);if(c==a[2])G
(++x)||--x;if(c==a[3])for(;G(x+12);++w)x+=12;if(c==a[4]||c==a[5]){s=sigblock(
8192);printf("\033[H\033[J\033[0m%d\n",w);if(c==a[5])break;for(j=264;j--;Q[j]=
0);while(getchar()-a[4]);puts("\033[H\033[J\033[7m");sigsetmask(s);}}d=popen(
"stty -cbreak echo stop \023;sort -mnr -o HI - HI;cat HI","w");fprintf(d,
"%4d from level %1d by %s\n",w,l,getlogin());pclose(d);}
:-)
> Adoro el spectrum, sus programas, sus obras de arte, pero no
> hay que despreciar lo actual por ser actual. Ahora tambien hay gente
> que programa de verdad y lo hace tanto en visual basic como en C o en
> ensamblador...
Si, y además (parte social de la discusión) me parece una falta de
tacto decir que algo no sirve cuando hay gente en el grupo que lo
usa. Mejor dicho, me parece muy mal que haya gente usando su tiempo,
dando de si mismos, pensando en ayudar, etc. al spectrum (aunque sea
en C) y que se le digan cosas que vengan a decir que hacer eso será
una pérdida de tiempo.
STAR me decía el otro día en el IRC que para hacer cosas malillas para
Spectrum era mejor no hacer nada. Yo no estoy de acuerdo. Es mejor
moverse ligeramente que no moverse. Que pasa, que no brincas, porque
no usas ASM y tu programa no vuela? Y qué, peor es sentarse en la
silla a esperar a que otros hagan algo, que todos hagan igual, nadie
haga nada (o muy poca gente) y se vaya todo al carajo.
Igual que Jose Manuel tiene una labor encomiable porque se mueve (a
su manera, no programando sino preservando) en el Spectrum. Si yo hago
un juego en C que va la mitad de rápido que uno en ensamblador (e
insisto en que no creo que eso sea posible porque he usado compiladores
de C en micros de 192 bytes de RAM y 2KB de ROM) no se me puede decir
que mejor no haberlo hecho, o que sea mejor no haber hecho nada.
Por supuesto, esto es sólo mi humilde opinión. Aquí todos opinamos, y
todos creemos o queremos tener la razón. Todos creemos tener más méritos
que los otros que demuestren lo que decimos. Lo importante es no
descalificar el trabajo de los demás.
Esto viene también a la coña Linux - Windows. Una cosa es un chiste de
"linux es mejor que windows" o "windows sucks" y otra es que hubiera
en el canal alguien que viviera de administrar un windows y que le gustara
y que nos dedicaramos a echar pestes de windows o decir que los que
administran windows son lamers o son de segunda. Quiero decir que yo
puedo hacer chistes, pero a la hora de hablar del trabajo o del esfuerzo
de los demás por ayudar en algo no se debe nunca criticar. Al igual que
se le puede decir cualquier cosa a zx128k, su esfuerzo por escanear
portadas en encomiable. Aunque el C fuera 300% más lento que el ASM
(cosa que me encargaré de demostrar que no es cierta) no se me puede
decir en el IRC que mejor no hacer nada que hacer algo en C.
Eso me pasa por decir las cosas a la cara, y ya sé que a alguien le
pueden doler. De hecho me siento (lamentablemente) bastante responsable
de la marcha de z-0 porque si revisais las news precisamente se enfadó
por un mensaje mío en el que le echaba un poco en cara que menospreciara
los conocimientos y trabajo de los demás. En algunos aspectos eso me
pareció, yo simplemente le dije que nadie tenía la verdad universal y
a los 2-3 días se despidió del grupo...
Espero que nadie se mosquee conmigo esta vez por mi mensaje...
saludos! :)
Kak
Luis Perez wrote:
¿te
> has puesto a estudiar el codigo optimizado por ejemplo de un algoritmo
> de ordenacion creado con el gcc y optimizado por este? Yo si, y cuesta
> muchiiiiiiiisimo mejorarlo.
vale, pero reconoces que se puede :)
> Del ensamblador del z80 por desgracia se poco, pero de
> ensamblador del 8086 bastante, algo del de los pentium, conozco el de
es que el problema esta aqui
imagina que el compilador te mete 1000 instrucciones inutiles enmedio de
tu codigo "que no necesita estar en asm", en bucles que se hacen 100
veces por segundo (por poner un ejemplo) En intel, tienes que gran parte
de las instrucciones se ejecuta en un ciclo o dos, teniendo un 1.4ghz
eso supone un 7*10e-3 % del tiempo perdido. Vale, realmente es poco :)
pero 1000 instrucciones en un z80 a 3.5 mhz, donde cada instruccion dura
4 o 8 o mas ciclos (sin pipeline) es un 11% de la cpu!
y un 11% es mucho, segun mi parecer. los datos quizas sean diferentes,
pero la proporcion sera la misma!!
obviamente si NoP quiere hacer una entry para el crap games competition
no hay ningun problema con el C :) ... aunque para ir bien tendria que
usar basic ;) , pero para hacer algo serio... no se, la verdad
> el DLX, y el de un microcontrolador de intel (no me acuerdo del
> nombre), del ODE (que es un m*****, ya lo se). Se C, smalltalk, java,
> c++, prolog, lisp, pascal, delphi, hope, mathematica ¿sigo? Y como he
yo se mas o menos los mismos, pero en realidad solo me sirven C y asm :)
cuando mas lenguajes usas, mas te alejas de la maquina. Para cierta gente
eso es bueno, o al menos eso dicen, pero son esa gente que se ganan la
vida trabajando con oracle y estudiando nuevas estafologias como .net
y similares, o sea, gente que el unico interes que pueden tener con el
spectrum es venderlo para sacar mas pasta.
> dicho, si se han logrado compiladores que generan codigo eficientes en
> C para PC, que es una arquitectura muuuuchiiisimo mas complicada y mas
> dificil de aprovechar que la de un spectrum. ¿Por que no puede existir
> un compilador de C que genere codigo eficiente para el spectrum? ¿Es
> que el spectrum es mas feo? X-DDD
> Un algoritmo malo sera malo en ensamblador, c, visual basic, y
> lisp y seguira siendo malo dentro de 20 anios. El burbuja por mucho
> pentium-7 que tengas ira lento!... Un programa bueno puede ser bueno
> en cualquier lenguaje, el lenguaje no va a hacer que un programa sea
> bueno o malo... Y hoy en dia se programa menos en ensamblador porque
> no interesa, los compiladores generan codigo bueno, las maquinas son
> buenas, y sobre todo porque en ensamblador es bastante dificil de
> hacer programas de CALIDAD (cuando hablo de calidad me refiero a
> facilidad para el mantenimiento, libre de errores, codigo
> reutilizable...).
ves! facilidad para el mantenimiento... de un programa de spectrum? que
quieres mantener? :)
libre de errores... es totalmente inherente al lenguaje de programacion
que uses
codigo reutilizable... de que? del miner willy? ;)
> Adoro el spectrum, sus programas, sus obras de arte, pero no
> hay que despreciar lo actual por ser actual. Ahora tambien hay gente
> que programa de verdad y lo hace tanto en visual basic como en C o en
> ensamblador...
pero no programa maquinas a 3.5 mhz sin pipeline, con una memoria de
pantalla muy rara y sin un api sobre el que basarse (por suerte!)
yo solo digo lo que tambien dijo TrueVid, la GB/GBC traia un z80 capado.
Hay un compilador de C, y tropecientos assemblers. Los pocos juegos
escritos en C suelen ser juegos de cartas, o directamente basura. Y tu
sabes que si , hoy en dia, una de esa gente vende juegos y le importa
tres pitos la calidad de los mismos, siempre y cuando los costes de
produccion sean minimos, no hubieran decidido hacerlos en C?
ademas, entiendo perfectamente no programar un intel en asm :) ... pero
el z80 es bonito y divertido y nada dificil, y ademas era el lenguaje de
nuestro spectrum :) porque no tener la experiencia de programar algo de
principio a fin con z80? :) se lo debeis, infieles :)
Kak
> Es más, hay compiladores de C para el 8051 (de 1 KB de RAM a 8 KB de RAM!)
> y para los PIC (piccc, micros desde 192 BYTES de ram a 8KB de RAM), y
> con juegos de instrucciones MUY REDUCIDOS. entonces... ¿porque no podría
> programarse en C un Spectrum de 48K con un peaso z80 mejor que el 8051?
pero son operaciones criticas en el tiempo? a que velocidad va un 8051?
(es que no lo se :) ) y que es exactamente lo que haceis con 8051?
(no creo que sean manic miners :) )
>> Y lo sigue siendo... Una vez vi un tetris en C que ocupaba una linea,
>>
>
> [sromero@strange:~]$ dpkg -L screen | grep tetris
> /usr/share/doc/screen/terminfo/tetris.c.gz
con todos los respetos... eso no es una linea, eso es un programa que
quita los caracteres 13 y 10 :)
> Si, y además (parte social de la discusión) me parece una falta de
> tacto decir que algo no sirve cuando hay gente en el grupo que lo
> usa. Mejor dicho, me parece muy mal que haya gente usando su tiempo,
> dando de si mismos, pensando en ayudar, etc. al spectrum (aunque sea
> en C) y que se le digan cosas que vengan a decir que hacer eso será
> una pérdida de tiempo.
eh, aqui han dicho que el C no se deberia usar en el spectrum :)
por usarlo puedes usarlo, y tambien lisp, java y cobol si quieres ;)
cosas mas raras se han visto! :)
poderse hacer cosas en C se pueden (sobretodo mas que en lisp y java y
cobol :) ), pero discutiamos sobre la parte de cpu que se pierde con C,
creo yo, vamos
> Por supuesto, esto es sólo mi humilde opinión. Aquí todos opinamos, y
> todos creemos o queremos tener la razón. Todos creemos tener más méritos
> que los otros que demuestren lo que decimos. Lo importante es no
> descalificar el trabajo de los demás.
bueno, yo pido perdon si he hecho eso, es que a veces nos acaloramos en
las discusiones... :) y C v$ ASM es demasiado tentadora ;)
por mi parte desearia que nunca os tomarais muy a pecho mis opiniones :)
> Esto viene también a la coña Linux - Windows. Una cosa es un chiste de
> "linux es mejor que windows" o "windows sucks" y otra es que hubiera
> en el canal alguien que viviera de administrar un windows y que le gustara
eso es imposible :) Un administrador de windows nunca se conecta a
ningun canal, tiene demasiada faena tapando agujeros de seguridad ;)
> Espero que nadie se mosquee conmigo esta vez por mi mensaje...
tirare un rnd(), y si sale menos de 0 me mosqueare ;)
Kak
>
> La prueba, el DOOM de MSDOS que iba en 386 y era una maravilla para
> su época, y sólo tenía 3 rutinas en ASM: el polling del joystick,
> el trazado de lineas verticales texturadas y el trazado de lineas
> horizontales texturadas.
en un 386 a 40 y con 4 megas.
y aun y asi daba saltos cuando habia unos cuantos enemigos en pantalla :)
40 mhz no son 4mhz sin pipeline ni cache. 4 megas no son 48 kas. un 32
bits no es lo mismo que un 8 bits.
el doom del scorpion (o pentagon?) en que funciona? :)
vale que haya diferencias graficas, pero son eso: graficas. tambien se
mueve a botes... pero ya me gustaria ver el doom en un 286 a 16 con 256 kas!
TrueVid
Holas a todos!
> Como dije, el compilador tiene que ser bueno. El que yo use
> para practicas de DLX y SuperDLX daba pena y hasta un nene de cuatro
> meses podia optimizarlo. X-DDDD
Umm... vuelvo a ponerte el caso de la GB Color, que es bastante
sangrante. Es una consola que mueve/ha vendido millones. No creo que
haya una sola compañia en el mundo que no haya publicado juegos para
esa consola. Pos bien, la mayoria de juegos estan programados en
ensamblador. No sabria decirte cual es la proporicion entre asm/C,
aunque la verdad es que en C tambien se han hecho bastantes, eso
tambien es cierto.
Y te preguntaras, como se yo que juegos se han hecho en C y cuales no?
Pos aqui viene lo mas gracioso: los hechos en C se reconocen con solo
echar un vistazo al codigo desensamblado. Por supuesto has de tener
cierta familiaridad con el sistema, pero el caso es que codigo en C
****SALTA A LA VISTA****
Y esto, me parece que no es muy buena señal ¬_¬
Tambien podrias decir que eso es porque han utilizado un compilador
malo. Yo seria muy esceptico en eso. No me imagino a EA, o Infogrames
o quien sea utilizando un compilador giftware o shareware de 3000
pelas en un kit de desarrollo que les ha costado mas de 1.000.000 de
pelas.
Pero bueno, estabamos hablando del Spectrum, asin que...
> Jamas quise decir que todo programa se pueda hacer unicamente
> en C... Existen rutinas que se deben hacer en ensamblador porque son
> criticas, son de tiempo real....
En esto, y si hablamos de sistemas actuales, estoy basicamente de
acuerdo contigo. Pero si nos centramos en el Spectrum, resulta que
*todas* las rutinas son criticas.
> Existe un hecho que es que el 90% del tiempo de ejecucion de
> un programa se esta ejecutando un 10% del mismo (creo que regla que se
> llama regla del 90-10).
Un mito mas, como el del 90% del cerebro humano, que resulta que no
usamos. Hasta las cifras son las mismas.
En un Spectrum esto no es cierto. Ni siquiera creo que lo sea en el
caso de ningun videojuego (sea antiguo o actual).
Esta regla del 90-10 es cierta en programas de aplicacion, por
ejemplo. Yo trabajo haciendo programas de ese tipo, y es totalmente
cierto. Pero se ha intentado transplantar al caso de los videojuegos
para justificar muchas cosas, y no es el caso.
Por ejemplo, si tuviese que hacer una lista de rutinas o modulos
importantes que forman un juego "standard" para Spectrum, empezaria
por estas:
- impresion de sprites
- deteccion de objetos
- scroll de fondo (si lo hay)
- sonido
- control de animaciones
Todas estas rutinas son el 90% de cualquier juego arcade. Y todas,
absolutamente todas, se han de ejecutar 1 vez por cuadro, 50 veces por
segundo. No vale saltarse un cuadro "porque si". Queremos que nuestro
juego vaya fino y Microhobby le ponga por lo menos un 9 movimientos y
jugabilidad, no?
El resto de rutinas que se me ocurren (la presentacion, con su
musiquita, los records), es igual que lo hagas en C o en BASIC, tanto
da. Comparadas con las de arriba, son paja.
Como te digo, en un Spectrum *todas* las rutinas son criticas.
>
> Ese 90% dependera mucho de lo que uno quiera hacer ¿no? porque
> si yo quiero hacer un edit, un aventura conversacional, un comecocos,
> una base de datos, o un simple matamarcianos (sin scroll parallax ni
> nada de eso), un buscaminas, o pongamonos bestias el windows, no creo
> que deba usar ensamblador en tooodooo el programa o en casi todo
Bueno, esto ya es otra historia. Para esta discusion, debemos dar por
sentados unas hipotesis iniciales. Estamos suponiendo que queremos
hacer un juego de gran calibre, no cualquier chorradita. Si el C es
tan eficiente, *tambien* ha de poder salir airoso en esta situacion.
Si no, ya no tiene sentido hacer comparaciones.
> Sobre lo otro, para crear algo en C y que sea igual de
> eficiente que el ensamblador (si se puede, que no siempre se puede
> hacer) tienes que conocer mucho C, saber lo que hace el Compilador
> (como traduce las instrucciones ...) y conocer bien la maquina.
> Sabiendo todo esto, puedes confiar en ese 'codigo' que te genera si
> sabes que es bueno y si ademas le 'ayudas' a que sea bueno...
Esta es una cosa que siempre me ha hecho mucha gracia.
- El C es bueno porque es mas facil que el ensamblador y no necesitas
ensuciarte con cosas a tan bajo nivel.
- El C puede ser tan rapido como el ensamblador si conoces *como
genera el codigo* y si conoces la maquina *por dentro*
Me lo parece a mi, o hay una contradiccion por aqui escondida?
>
> Estamos de acuerdo, pero hay que tener en cuenta que las
> maquinas de ahora no son iguales que las de hace 20 anios. Por
> ejemplo, los algoritmos geneticos creo que son de antes de los 80
Estamos hablando de juegos de Spectrum, no de grandes proyectos
cientificos. De todos modos, el Spectrum salio en el 82, ok, pero se
siguieron haciendo juegos hasta cuando? 1990?
En esa epoca ya habian maquinas para desarrollo asequibles para
cualquier compañia. El amiga sin ir mas lejos salio en el 85. Podrian
haber utilizado un compilador en cualquier modelo de esos y empezar a
generar codigo para sus proyectos Spectrum.
Pero no fue asi.
> nivel... Creo que fuiste tu el que comento que hacer un rutina general
> para manejar los sprites en el spectrum es poco eficiente, ¿No se
> podria bajar un poco el nivel de esas rutinas y crear funciones en C
> que me permitan crear facilmente construir la rutina que yo desee, o
> varias rutinas especificas para los casos mas habituales con los que
> me pueda encontrar?
Bueno, quizas no se me entendio bien. Cuando decia genericas, era
independientemente del lenguaje. Creo que una rutina de impresion
generica (=multiuso = que sirva a cualquiera) nunca podra ser muy
eficiente, aunque este hecha en ensamblador.
Por supuesto eso no quiere decir que no sea util. Puede servir a mucha
gente para aplicaciones sencillas.
Saludos!!!
True
Santiago Romero
>> La prueba, el DOOM de MSDOS que iba en 386 y era una maravilla para
>> su época, y sólo tenía 3 rutinas en ASM: el polling del joystick,
>> el trazado de lineas verticales texturadas y el trazado de lineas
>> horizontales texturadas.
>
> en un 386 a 40 y con 4 megas.
> y aun y asi daba saltos cuando habia unos cuantos enemigos en pantalla :)
> 40 mhz no son 4mhz sin pipeline ni cache. 4 megas no son 48 kas. un 32
> bits no es lo mismo que un 8 bits.
Y un doom en pseudo3d con raycasting no es un juego de plataformas.
Santiago Romero
>> Por supuesto, esto es sólo mi humilde opinión. Aquí todos opinamos, y
>> todos creemos o queremos tener la razón. Todos creemos tener más méritos
>> que los otros que demuestren lo que decimos. Lo importante es no
>> descalificar el trabajo de los demás.
>
> bueno, yo pido perdon si he hecho eso, es que a veces nos acaloramos en
> las discusiones... :) y C v$ ASM es demasiado tentadora ;)
> por mi parte desearia que nunca os tomarais muy a pecho mis opiniones :)
Lo gracioso del asunto es que a mi me gusta MAS programar en ASM que en
C, es que tal y como hablais parece que os poneis en el grupo de defensores
del ASM y a mi me poneis en el grupo de defensores del C. Y también
parece que porque defienda C estoy en contra de ASM. Yo sólo me baso en
mi experiencia de que ciertas cosas se hacen mejor en unos lenguajes
que en otros, por eso digo de meter código ASM para las partes criticas
de mis programas en C.
Santiago Romero
> ademas, entiendo perfectamente no programar un intel en asm :) ... pero
> el z80 es bonito y divertido y nada dificil, y ademas era el lenguaje de
> nuestro spectrum :) porque no tener la experiencia de programar algo de
> principio a fin con z80? :) se lo debeis, infieles :)
Insisto, que yo quiera usar C no quiere decir que no me guste el ASM.
De hecho quiero usar ASM en C. żalguien me lee? żmama? żhola?
TrueVid
Antes que nada, vuelvo a repetir que todos mis mensajes han de
interpretarse en el contexto de la programacion de juegos para
Spectrum o cualquier otra maquina de 8 bits. No entro en discusiones
de C vs asm en sistemas actuales o mas potentes.
sro...@servicom2000.com (Santiago Romero) wrote in message news:<slrn9v1pr3....@compiler.servicom2000>...
> Exacto. Es la famosa regla 90-10, y es perfectamente aplicable a
> cualquier máquina
Es una regla famosa. Pero tambien lo son los duros de chocolate.
Las rutinas criticas no se ejecutan el 10% de las veces y ya esta. Son
criticas precisamente porque se ejecutan **continuamente** y de forma
sincronizada. Si no, ya las hubiese llamado de otra forma.
> Si yo hago un juego, lo importante es que las
> rutinas que dibujan 20 sprites por cada frame estén en asm, pero
> que el bucle del programa
>
> while(!finjuego)
> {
> for(i=0; i<lista_sprites; i++)
> MoverSprites(lista, i);
> blabla();
> }
Esta ultra-simplificacion no sirve como argumento. Ningun juego es
asi. Ni siquiera los de Spectrum. Un juego no se limita a (1) pongo 20
sprites por pantalla antes de que se acabe el VBL (2) enchufo el resto
en un bucle y ya esta.
> puede estar perfectamente en C. Con optimizar en asm las rutinas
> que dibujan los sprites, bastaría (es un ejemplo).
No. Ningun arcade de categoria funciona asi. Cualquier juego con
scroll, ya sea vertical u horizontal, tendra que actualizar la
pantalla "al vuelo", es decir mientras se esta actualizando la imagen,
con cuidado de no ser pillado por el rayo.
Ningun compilador puede generar codigo con tanta precision.
Ojo, fijaos que he dicho precision. Ni velocidad ni tamaño, sino
precision. En un caso asi, el codigo no puede ser lento, pero tampoco
*demasiado rapido*. Ha de durar el tiempo exacto. Ni un ciclo mas ni
uno menos.
Mi Pregunta del Millon de Dolares (tm) seria:
Que compilador te deja escoger los ciclos que va a tardar en
ejecutarse tu codigo?
Y esto de ir contando ciclos y T-estados no es ninguna excentricidad,
ni ninguna rareza. Es el Pan Nuestro de cada Dia (AMEN) en cualquier
juego de Joffa Smith, por poner un ejemplo.
Saludos!
True
Kak
>>y aun y asi daba saltos cuando habia unos cuantos enemigos en pantalla :)
>>40 mhz no son 4mhz sin pipeline ni cache. 4 megas no son 48 kas. un 32
>>bits no es lo mismo que un 8 bits.
>>
>
> Y un doom en pseudo3d con raycasting no es un juego de plataformas.
bueno, pero yo me referia al caso concreto del doom de sprinter :) y ni que
no sea asi, si el plataformas tiene scroll, va a necesitar bastante CPU.
por cierto, acabo de recordar que, sobre lo que truevid comento la
posibilidad de tener todos los sprites prerotados para las 8 posiciones,
se ve que Jon Ritman no estaba muy de acuerdo con Jonathan Smith por
tener los sprites de algunos juegos de esa forma :)
http://www.zxgoldenyears.co.uk/interview1.html
ostras, lo que pagaria por ver una "discusion" entre Jon Ritman y
Jonathan Smith ;)
>>ademas, entiendo perfectamente no programar un intel en asm :) ...
>>pero
>> el z80 es bonito y divertido y nada dificil, y ademas era el
lenguaje >>de
>> nuestro spectrum :) porque no tener la experiencia de programar algo
>>de
>> principio a fin con z80? :) se lo debeis, infieles :)
>
>Insisto, que yo quiera usar C no quiere decir que no me guste el ASM.
> De hecho quiero usar ASM en C. żalguien me lee? żmama? żhola?
jo, que ese trozo era broma :)
ademas, imagina lo que vas a fardar con "yo hice (no digas cuando) un
juego de plataformas en spectrum, 100% asm" :)
no es lo mismo que "hice un juego de spectrum en C y asm", no me digas
que no ;)
TrueVid
sro...@servicom2000.com (Santiago Romero) wrote in message news:<slrn9v1sij....@compiler.servicom2000>...
> Si, y además (parte social de la discusión) me parece una falta de
> tacto decir que algo no sirve cuando hay gente en el grupo que lo
> usa. Mejor dicho, me parece muy mal que haya gente usando su tiempo,
> dando de si mismos, pensando en ayudar, etc. al spectrum (aunque sea
> en C) y que se le digan cosas que vengan a decir que hacer eso será
> una pérdida de tiempo.
Yo no me pondria tan melodramatico en esto. En ningun momento he
querido insinuar que quien esta metido en el tema "C para Spectrum"
este perdiendo el tiempo.
Es posible programar en C para Spectrum? Claro que si. Estoy
convencido de ello. Por que no?
De lo que no estoy tan convencido es de que se intente comparar el C
con el ensamblador en un Spectrum. Todos mis posts estan basados en
esta premisa: el C no es suficientemente potente para sacar adelante
un proyecto de calidad en un Spectrum (por ejemplo, un arcade (de
calidad)).
Si el compilador de C sirve para que gente que no habia programado el
Spectrum antes pueda aplicar sus conocimientos actuales para crear
algo, pues perfecto. Eso siempre sera bueno.
Es mas, si el responsable de la libreria grafica decide incluir codigo
en ensamblador para las partes de mas bajo nivel, estare encantado de
proporcionarselas. Esto es un oferta en firme.
> STAR me decía el otro día en el IRC que para hacer cosas malillas para
> Spectrum era mejor no hacer nada. Yo no estoy de acuerdo
Yo tampoco estoy de acuerdo con esto. Si se hacen cosas malillas, es
señal de que hay gente haciendo algo. Y eso es condicion indispensable
para que en algun momento acabe saliendo algo bueno.
Ademas, ya sabemos como es STAR. Tiene el pelo de color no-natural y
dice "yavestruz" copiosamente. ^L^
> Espero que nadie se mosquee conmigo esta vez por mi mensaje...
Yo me he mosqueado mucho. En señal de protesta y/o mosqueo, voy a
quemar una copia del GENS-3, avivando el fuego con el sobre sellado de
la caja de The Ultimate Collection que STAR esconde debajo de su
camastro.
Saludos!
Flint
>
>
> STAR me decía el otro día en el IRC que para hacer cosas malillas para
> Spectrum era mejor no hacer nada. Yo no estoy de acuerdo. Es mejor
> moverse ligeramente que no moverse. Que pasa, que no brincas, porque
> no usas ASM y tu programa no vuela? Y qué, peor es sentarse en la
> silla a esperar a que otros hagan algo, que todos hagan igual, nadie
> haga nada (o muy poca gente) y se vaya todo al carajo.
Pienso que STAR se equivoca aquí. Si no haces cosas "malillas" ¿cómo vas a
aprender a hacerlas buenas?.
No creo que los de ultimate (por ejemplo) programasen el knight lore la
primera vez que se sentaron delante del spectrum. Si la primera vez que
tienes que hacer algo tienes que hacer una obra maestra, nunca harás nada.
Vamos, digo yo.
Un saludo
Flint
Flint
>
> Insisto, que yo quiera usar C no quiere decir que no me guste el ASM.
> De hecho quiero usar ASM en C. żalguien me lee? żmama? żhola?
>
>
Por cierto, żdonde se puede aprender algo de CM del Z80 en castillero?
Fijo que tu tienes algun enlace, Santiago.
Un saludo
Flint
Flint
130.133.1.4:
>
> Por cierto, ¿donde se puede aprender algo de CM del Z80 en castillero?
> Fijo que tu tienes algun enlace, Santiago.
>
> Un saludo
> Flint
>
Olvídalo he visto tu enlace un poco más arriba :)
Un saludo
Flint
Luis Perez
>(es que no lo se :) ) y que es exactamente lo que haceis con 8051?
Si es que el yo use (creo que si) hice un programa que
controlaba un ascensor, iba recogiendo los pasajeros por los pisos...
Era una maqueta, no creo que ningun profesor se atreviera a probar
nuestras practicas en un ascensor de verdad... };-))))Por cierto, la
maqueta iba de pena, teniamos que poder un bucle para abrir la puerta
porque de vez en cuando al ascensor no le apetecia abrir la puerta o
te la cerraba de golpe.
>(no creo que sean manic miners :) )
Ojala!!! Habia otra practica chula de controlar un cruce de
semaforos (en maqueta).
>bueno, yo pido perdon si he hecho eso, es que a veces nos acaloramos en
>las discusiones... :) y C v$ ASM es demasiado tentadora ;)
>por mi parte desearia que nunca os tomarais muy a pecho mis opiniones :)
>
Ni yo las mias...
Saludos,
Luis Perez
Luis Perez
>
>
>Luis Perez wrote:
>
> ¿te
>> has puesto a estudiar el codigo optimizado por ejemplo de un algoritmo
>> de ordenacion creado con el gcc y optimizado por este? Yo si, y cuesta
>> muchiiiiiiiisimo mejorarlo.
>
>
>vale, pero reconoces que se puede :)
Porque me pico la curiosidad y se lo pregunte al profesor.
Mejoraba muy poco y era dependiente de la maquina, en mi k7 no
mejoraba (no recuerdo cual era la mejora).
>es que el problema esta aqui
>imagina que el compilador te mete 1000 instrucciones inutiles enmedio de
>tu codigo "que no necesita estar en asm", en bucles que se hacen 100
>veces por segundo (por poner un ejemplo) En intel, tienes que gran parte
>de las instrucciones se ejecuta en un ciclo o dos, teniendo un 1.4ghz
>eso supone un 7*10e-3 % del tiempo perdido. Vale, realmente es poco :)
>pero 1000 instrucciones en un z80 a 3.5 mhz, donde cada instruccion dura
>4 o 8 o mas ciclos (sin pipeline) es un 11% de la cpu!
>y un 11% es mucho, segun mi parecer. los datos quizas sean diferentes,
>pero la proporcion sera la misma!!
>obviamente si NoP quiere hacer una entry para el crap games competition
>no hay ningun problema con el C :) ... aunque para ir bien tendria que
>usar basic ;) , pero para hacer algo serio... no se, la verdad
Hombre, estas hablando de un rutina que se ejecuta bastante,
(100 veces por segundo). Si esta rutina es determinante para el
funcionamiento del programa entonces hay que hacerlo en ensamblador.
No estoy diciendo que el C sirva para todos los casos, y que en todos
los casos ofrezca una salida eficiente, solo que no es basic, ni un
lenguaje interpretado, y que genera un codigo lo bastante eficiente
como para poder bastarte en el la mayoria de las veces.
Ok, haces esa rutina en ensamblador. Normalmente esa rutina
hara algo especifico, por ejemplo, leer el teclado. La insertas en una
libreria C y ya tienes un funcion que lee el teclado un 11% mas
eficiente. Por cierto, no creo que un 11% sea mucho... ¿Has probado a
poner un emulador al 89%? ¿Se nota mucho? Ya se que no es lo mismo,
pero uno se puede hacer una idea de cuanto puede perder...
>cuando mas lenguajes usas, mas te alejas de la maquina. Para cierta gente
>
>eso es bueno, o al menos eso dicen, pero son esa gente que se ganan la
>
>vida trabajando con oracle y estudiando nuevas estafologias como .net
>y similares, o sea, gente que el unico interes que pueden tener con el
>spectrum es venderlo para sacar mas pasta.
Tampoco hay que ser tan critico con la sociedad ¿No? Alejarse
de la maquina tiene ciertas ventajas (y ciertos inconvenientes), java
es un buen ejemplo de ello, sera lento pero se puede ejecutar (casi)
sin problemas en cualquier ordenador y con cualquier sistema operativo
(siempre que microsoft no meta las zarpas)
>
>ves! facilidad para el mantenimiento... de un programa de spectrum? que
>quieres mantener? :)
>libre de errores... es totalmente inherente al lenguaje de programacion
>que uses
>codigo reutilizable... de que? del miner willy? ;)
En cualquier lenguaje puedes tener errores, pero normalemente
cuando cometes un error en ensamblador se cuelga el ordenador y si
tienes mala suerte se te borra la configuracion del ordenador. Es muy
dificil de depurar... No es lo mismo depurar un procedimiento en
pascal o C que uno en ensamblador.
Y sobre lo del codigo reutilizable. ¿Por que no podemos
reutilizar codigo de los grandes maestros? Por ejemplo, alguien de
aqui dijo que le gustaria toquetear el sistema operativo del sprinter
y a ese le vendria bien conocer el codigo... ¿No podriamos reutilizar
alguna rutina del sprinter? ¿no podemos reutilizar el scroll del army
moves? ¿La rutina de sonido de los 128Ks? ¿Son los juegos lo unico que
queremos en nuestro spectrum? Porque a mi me gustaria, por ejemplo,
usarlo de terminal de linux, esto es una utilidad que la puedo ir
mejorando, que puede tener errores, y que en C seria mas facil de
mantener y depurar.
>yo solo digo lo que tambien dijo TrueVid, la GB/GBC traia un z80 capado.
>Hay un compilador de C, y tropecientos assemblers. Los pocos juegos
>escritos en C suelen ser juegos de cartas, o directamente basura. Y tu
>sabes que si , hoy en dia, una de esa gente vende juegos y le importa
>tres pitos la calidad de los mismos, siempre y cuando los costes de
>produccion sean minimos, no hubieran decidido hacerlos en C?
Pero aqui interviene don dinero. La gente cuando ve un billete
de 1000 pelas hace lo minimo necesario para ganarlo. Nosotros vamos a
programar para una maquina con la que no vamos a ganar dinero. Vamos,
cuando hago unas practicas me importa muy poco si es eficiente o no,
porque voy a ganar el mismo "dinero" (una nota)tarde 5 segundos mas o
menos, cuando veo que funciona bien lo dejo... ¿existen mucha
competencia en compiladores de c para game boy? ¿Venden muchos
compiladores de c?
>ademas, entiendo perfectamente no programar un intel en asm :) ... pero
>el z80 es bonito y divertido y nada dificil, y ademas era el lenguaje de
>nuestro spectrum :) porque no tener la experiencia de programar algo de
>principio a fin con z80? :) se lo debeis, infieles :)
Y estoy en ello...
Saludos,
Luis Perez
Luis Perez
>
>Tambien podrias decir que eso es porque han utilizado un compilador
>malo. Yo seria muy esceptico en eso. No me imagino a EA, o Infogrames
>o quien sea utilizando un compilador giftware o shareware de 3000
>pelas en un kit de desarrollo que les ha costado mas de 1.000.000 de
>pelas.
>
Tampoco me imaginaba yo hace anios que una empresa con fama
(Dinamic) fuera capaz de sacar un producto (PCFutbol) que se cuelga
cada dos por tres... Don dinero manda mucho, żpara que vas a
preocuparte en crearte un super compilador de c para game boy si con
uno en el que gastes la mitad de recursos lograras algo aceptable y
vendes lo mismo? No estoy de acuerdo con esta politica, pero las
empresas tienen fines lucrativos y muchas veces solo ven las pasta
(bread para los ingleses) y no la calidad de los productos.
>En esto, y si hablamos de sistemas actuales, estoy basicamente de
>acuerdo contigo. Pero si nos centramos en el Spectrum, resulta que
>*todas* las rutinas son criticas.
En muchos casos uno descubre que una rutina es critica a
posteriori y no a priori. Decir que todas son criticas a priori es
muy fuerte żNo? Dependera del tipo de juego...
>Esta regla del 90-10 es cierta en programas de aplicacion, por
>ejemplo. Yo trabajo haciendo programas de ese tipo, y es totalmente
>cierto. Pero se ha intentado transplantar al caso de los videojuegos
>para justificar muchas cosas, y no es el caso.
Hombre, quizas no sea el 90-10 en un videojuego para spectrum
pero tampoco creo que sea un 100-100 como sugieres.
>> Ese 90% dependera mucho de lo que uno quiera hacer żno? porque
>> si yo quiero hacer un edit, un aventura conversacional, un comecocos,
>> una base de datos, o un simple matamarcianos (sin scroll parallax ni
>> nada de eso), un buscaminas, o pongamonos bestias el windows, no creo
>> que deba usar ensamblador en tooodooo el programa o en casi todo
>
>Bueno, esto ya es otra historia. Para esta discusion, debemos dar por
>sentados unas hipotesis iniciales. Estamos suponiendo que queremos
>hacer un juego de gran calibre, no cualquier chorradita. Si el C es
>tan eficiente, *tambien* ha de poder salir airoso en esta situacion.
Nunca he querido decir que el C salga airoso de todas las
situaciones... Si estas programando en tiempo real duro, por ejemplo
en un pc no puede ser y lo mas posible que no sea recomendable hacerlo
en C porque requieres tener muy controlado todo... Y sobre hacerlo con
un juego de gran calibre dependera de lo bueno del compilador y de lo
bueno que sea las librerias... Al fin y al cabo las librerias las ha
hecho un tio como tu y como yo que se dedico a machacarse dia y noche
para hacerlo eficiente... Me parece que tu si has programado para
spectrum żNo? Organizaras tus programas en rutinas, call return żNo?
Si el bucle principal del programa es C, y es eficiente, y lo que hay
dentro son llamadas a funciones que son en realidad tus rutinas żvas a
perder mucha velocidad con el programa? Ahora me diras, que ese
programa sera casi todo ensamblador y solo el bucle principal C...
Correcto!!! Pero ahora vengo yo, uso esas librerias, y me creo otras
que necesito o uso otras ya creadas o modifico las existentes, para
mi, la mayor parte del programa sera C porque apenas he tenido que
programar en ensamblador.
A lo mejor a ti te molesta el que otro use tus funciones,
pero, es por el bien del spectrum!!!
>
>Esta es una cosa que siempre me ha hecho mucha gracia.
>
>- El C es bueno porque es mas facil que el ensamblador y no necesitas
>ensuciarte con cosas a tan bajo nivel.
>- El C puede ser tan rapido como el ensamblador si conoces *como
>genera el codigo* y si conoces la maquina *por dentro*
Hombre. Lo que quiero decir, en general C es eficiente y en
general no necesitas meterte a bajo nivel porque te genera un codigo
bastante bueno (en un RISC solo es *en general* menos de 5% mas
lento)...
Ahora, te puedes encontrar con rutinas que necesiten
ejecutarse muy rapidamente. żNecesitas obligatoriamente acudir al
ensamblador? No, aunque a veces no puedes evitarlo. Uno puede
optimizar codigo desde C pero para eso necesitas conocer mucho la
maquina con la que trabajas y como funciona. Ejemplo...
while (1){
if (usuario(tu))!=usuario(spectrum)) then
kick(usuario)
else if chica(tu) then
regalo(tu)
else
charla(tu)
} //que nadie se sienta ofendido
Suponte que este codigo necesitas que se ejecute mas
rapido... żse puede mejorar en C? Si... Parto de la siguientes
hipotesis:
- El compilador compila la parte then antes que la else
(conoces como genera el codigo)
- Estas en un pentium-II o III o similar (conoces la maquina
en la que se ejecuta)
while (1){
if (usuario(tu)))==usuario(spectrum)) then
if (!chica(tu) then
charla(tu):
else
regalo(tu);
else
kick(usuario)
} //que nadie se sienta ofendido
żPor que es mejor? Por la unidad de prediccion de salto del
pentium, cuando se encuentra con un salto hacia delante por primera
vez (creo que funcionaba asi, si no los ejemplos estan al reves)
supone que no va a saltar (se metera en la parte then) por lo que, si
en los if, metes en la parte then la parte con mas posibilidades de
ejecutarse el pentium cometera menos errores de prediccion de salto e
ira mas rapido
Es un ejemplo tonto, pero como ejemplo vale.
>Me lo parece a mi, o hay una contradiccion por aqui escondida?
Mejor?
>Estamos hablando de juegos de Spectrum, no de grandes proyectos
>cientificos. De todos modos, el Spectrum salio en el 82, ok, pero se
>siguieron haciendo juegos hasta cuando? 1990?
>
>En esa epoca ya habian maquinas para desarrollo asequibles para
>cualquier compańia. El amiga sin ir mas lejos salio en el 85. Podrian
>haber utilizado un compilador en cualquier modelo de esos y empezar a
>generar codigo para sus proyectos Spectrum.
>
>Pero no fue asi.
El desarrollo de buenos compiladores ha empezado en los
ultimos anios, dudo mucho que un amiga 500 tire con el gcc de linux
(casi no puede de el mi 486 a 33 mhz). Optimizar codigo no es chuparse
los dedos, y existen tecnicas que tiran mucho de la maquina pero que
actualmente un ordenador se lo puede permitir. Cuando empece la
carrera (hace 5 anios) todos programabamos con el borland C++ 3.0 y
las rutinas graficas que manejaba eran pesimas y ahora las hay la mar
de monas. El codigo generado por el borland c++ 3.0 es bastante mas
malo que el del gcc... Estaba justificado el emplear el ensamblador
porque el codigo generado por los compiladores y las librerias que
aportaban no cumplian con algunos requisitos minimos. Hoy en dia esto
ha mejorado mucho, no porque los ordenadores vayan mas rapido, si no
porque los compiladores pueden optimizar mas en el mismo espacio de
tiempo.
Ademas, el uso masivo de compiladores ha empezado con los PC,
no con amigas, ni nada de eso... El compilador es un producto como
otro, con el amiga si sacabas un compilador superbueno żalguien te lo
iba a comprar? Muy pocos, por eso las empresas no se preocupaban de
que fuera superbueno, lo hacen, venden sus X unidades y ya esta. Hoy
en dia casi nadie usa ensamblador para un programa, usan compiladores
de c, pascal, dephi, builder... Las empresas comprar los compiladores,
los estudiantes, las universidades... Cuanto mejor sea mas vendes, los
mejoran, le crean entornos...
Te pongo ejemplo de PC, porque el compilador z88dk se ejecuta
en un PC por lo que no seria descabellado pensar que genera codigo
igual de bueno que el de pc..
>generica (=multiuso = que sirva a cualquiera) nunca podra ser muy
>eficiente, aunque este hecha en ensamblador.
>Por supuesto eso no quiere decir que no sea util. Puede servir a mucha
>gente para aplicaciones sencillas.
Una rutina generica de sprites puede que no sea eficiente,
pero como tu has dicho util si... Luego esta, porque crear una rutina
generica sola? A veces tienes tambien rutinas para casos especificos
porque son comunes, alguien se preocupo de hacerlos... Si vamos
anadiendo cada vez mas rutinas, puede que alguna vez nos encontremos
con que tenemos casi todos los casos habituales żNo?
En general, creo que el problema es que parece que tu estas
diciendo que *todo* juego se tiene que realizar *entero* en
ensamblador para que sea aceptable y parace que yo digo que *todo*
juego se puede realizar entero en *C*. No creo que ni tu ni yo estemos
diciendo eso. Digo que gran parte (cuando diga gran parte a lo mejor
estoy hablando de un 60% o mas) del juego normal (no un doom) se puede
hacer en C si, EL PROGRAMADOR ES BUENO; el compilador es bueno (los
actuales lo son), y si tienes buenas librerias, que no las tenemos
;-(,,,, (si entre todos las hacemos y ayudamos a Santiago Romero a lo
mejor en un futuro cercano podremos tenerlas).
Saludos,
Luis.
Luis Perez
Romero) wrote:
> STAR me decía el otro día en el IRC que para hacer cosas malillas para
> Spectrum era mejor no hacer nada. Yo no estoy de acuerdo. Es mejor
> moverse ligeramente que no moverse. Que pasa, que no brincas, porque
> no usas ASM y tu programa no vuela? Y qué, peor es sentarse en la
> silla a esperar a que otros hagan algo, que todos hagan igual, nadie
> haga nada (o muy poca gente) y se vaya todo al carajo.
Cuanto mas se muevan mejor. Ademas, yo me lo pasaba bomba con
el jumping jack y en realidad es una mierda de juego. Creo que
deberiamos entre todos mantener vivo el spectrum y que eso no deberia
depender tanto de si es C o ensamblador, de si va un 11% mas rapido o
no.
si deberia de depender de si un juego divierte o no, o si un
programa es util...
Hablando de STAR... YUUUUUUUUUUUUUUUUJUUUU!!!!
¿En MSX como hacen todo en general? ¿Usan compiladores de C? ¿Son
cruzados? ¿Programan directamente en MSX?
Por cierto, a lo mejor lo podemos usar el compilador de C en
el sprinter...
Saludos,
Luis Perez.
EdUarDo
alguien
que no programe muy bien en ensamblador, no va a hacer un código más
óptimo que un compilador.
Santiago Romero
> ademas, imagina lo que vas a fardar con "yo hice (no digas cuando) un
> juego de plataformas en spectrum, 100% asm" :)
> no es lo mismo que "hice un juego de spectrum en C y asm", no me digas
> que no ;)
Pues sí, es lo mismo (para mi).
Lo importante NO es "mira mi juego en asm", sino "mira mi juego".
Santiago Romero
>> Insisto, que yo quiera usar C no quiere decir que no me guste el ASM.
>
> Por cierto, ¿donde se puede aprender algo de CM del Z80 en castillero?
> Fijo que tu tienes algun enlace, Santiago.
Solo en ingles :(((
http://www.speccy.f2s.com/prog/z80asm.html
Yo es que tengo un libro en castellano de Rodnay Zacks, pero he decir
que si quieres aprender ASM de Z80 EN CASTELLANO te recomiendo este paso:
1.- libro de asm anaya (1600 pts) Coleccion Guias de Bolsillo
"ensamblador de los 80x86" de Jon Beltran de Heredia
2.- sabiendo asm de pc, leer los tutoriales en ingles de la web. En unos
dias y programando alguna cosilla ya sabrás asm de z80.
Me estoy planteando el hacer un curso de asm de z80 ...
¿tendría alguna aceptación o utilidad? :?
Santiago Romero
> Es mas, si el responsable de la libreria grafica decide incluir codigo
> en ensamblador para las partes de mas bajo nivel, estare encantado de
> proporcionarselas. Esto es un oferta en firme.
La has cagao.
Enhorabuena, has sido fichado para la z80dk Spectrum graphics library
por 0 pts y una clausula de rescision de 2000 rutinas XD
Dime un email de contacto y te comento por privado.
> Ademas, ya sabemos como es STAR. Tiene el pelo de color no-natural y
> dice "yavestruz" copiosamente. ^L^
X'DDDDDDDDDDDDD
>> Espero que nadie se mosquee conmigo esta vez por mi mensaje...
>
> Yo me he mosqueado mucho. En señal de protesta y/o mosqueo, voy a
> quemar una copia del GENS-3, avivando el fuego con el sobre sellado de
> la caja de The Ultimate Collection que STAR esconde debajo de su
> camastro.
nooooo nooooo por favorrrrr
z...@nil.fut.es
> Lo gracioso del asunto es que a mi me gusta MAS programar en ASM que en
> C, es que tal y como hablais parece que os poneis en el grupo de defensores
> del ASM y a mi me poneis en el grupo de defensores del C. Y también
Posyastá, pograma tu juoco en ASM, ¿nop? ?c?
> parece que porque defienda C estoy en contra de ASM. Yo sólo me baso en
> mi experiencia de que ciertas cosas se hacen mejor en unos lenguajes
> que en otros, por eso digo de meter código ASM para las partes criticas
> de mis programas en C.
Sip, ciertas cosas se facen "mejor/más rápido" en C en SEGÚN QUE PLATAFORMAS Y
PRODUCTOS. Una calculadora en Speccy se fará "mejor/más rápido" en BASIC que
no en ASM, y un triple scroll lo farás más rápido en C pero no mejor que en
ASM.
Y yo prefiero pensar en que un pograma está en ASM y tiene partes no tan
críticas en C, es más propio. ^c-
--
S.T.A.R.
--
z...@nil.fut.es
Venga, que solamente falto yo pa echar leña al fuego. ^c-
> STAR me decía el otro día en el IRC que para hacer cosas malillas para
> Spectrum era mejor no hacer nada. Yo no estoy de acuerdo. Es mejor
> moverse ligeramente que no moverse. Que pasa, que no brincas, porque
> no usas ASM y tu programa no vuela? Y qué, peor es sentarse en la
> silla a esperar a que otros hagan algo, que todos hagan igual, nadie
> haga nada (o muy poca gente) y se vaya todo al carajo.
Yo pienso en lo de zapatero a tus zapatos y si uno pograma juocos es, uno,
porcuá le omola, dos, sabe pogramar, tres, tiene talento pa ello. No hay
ninguna prisa pa que uno AHORA se ponga a pogramar un juoco, y más si se trata
de una máquina como el Speccy, y que si a todas luces en Speccy es mucho
melchor el ASM, pos como no hay prisas, uno se puede divertir aprendiendo
ensamblador pa obtener unos resultados óptimos y quedar como un señor y no
como uno que ha fecho un algo por facer algo en pro del Speccy.
Obviosamente, todo depende del AMOR PROPIO que tenga cadascuno, claro. Pero
como dice TrueVideo, siempre y cuando estemos garlado de un juoco "GRANDE"
de Speccy y no del tema de si se puede o no se puede pogramar en C.
Por otra parte, sin que sirva de excusa, en el irrecé creome que llegamos a
intercambiar tres/cuatro frases, y si tienes el log o Linux4All anda por aquí,
se podrá corroborar que lo que intentaba explicarte NO es facer cosas malas,
sinó NO FACER COSAS MAL, que es MUY distinto. Simplemente, facer una cosa mal
es no facerla benne cuando se puede facer benne. Creome que llegamos a
comentar que tus rutinas de "sprites" (basilisco te pusiste cuando te dije el
Speccy NO tiene sprites. ^c-) omolan pa pogramillas en plan MH Semanal y que
Linux4All y yo te comentamos temas como lo de las máscaras en los "sprites",
cosa que no habías tenido en cuenta (un descuido lo tiene cualesquiera).
Usease, cuando sentencio que prefiero NADA a cosas MALAS me refiero
obviosamente a cosas que no son correctas, que prefiero tener nada antes que
cosas que se han fecho por facer, sin ánimo de superación, sin "ganas", porcuá
quien las face (y quie nadie se sienta aludido) las face por facer
cualesquiera cosa, por bulto. Y ojito, SIEMPRE teniendo en cuenta de que TÚ sí
que puedes facerlas benne y con ganas. El facer cualesquiera cosa no significa
que por el mero fecho de facerla esté benne. Amor propio, ya digo.
Quicir que si faces un juoco en C pero mantienes que en ASM podría estar
melchor, y al mesmo tempo sabes ASM, pos como que la cosa no me casa, nosé. Si
aluego me dices que es pa que otros tambenne pogramen, pos yo te animaría a
que encaminases tu tutorial pa que la peña aprenda a pogramar en ASM, que asín
salimos ganando todos. Vamos, algo asín como mantener el genuino espíritu del
Speccy, y que el quiera facer cualquiecosa pal Speccy sea porcuá de verdaz lo
quiere, no por facer un algo en un momento determinado. Oño, es lo que dice
Kak, que lo fardas más mantiendo un status de integridad pogramando en ASM que
no en C, un juoco de Speccy se entiende.
Estás faciendo un algo pal Speccy y con todas las de la ley, y amasamás
animando a la peña pa que faga más cosas CORRECTAS. Cojonudo!
> Igual que Jose Manuel tiene una labor encomiable porque se mueve (a
> su manera, no programando sino preservando) en el Spectrum. Si yo hago
> un juego en C que va la mitad de rápido que uno en ensamblador (e
> insisto en que no creo que eso sea posible porque he usado compiladores
> de C en micros de 192 bytes de RAM y 2KB de ROM) no se me puede decir
> que mejor no haberlo hecho, o que sea mejor no haber hecho nada.
Pero yo mesmo (sin querer joder la marrana) te podría decir que, ya que sabes
ASM, ¿porcuá no has fecho ese mesmo juoco en ASM, que te irá mucho más rápido
y fonará más eficientemente? ¿Por falta de tempo? ¿Qué prisa tienes? Como
pogramador debes tener tu pofesionalidaz y suponome que preferirás CALIDAD
antes que RAPIDEZ.
> Por supuesto, esto es sólo mi humilde opinión. Aquí todos opinamos, y
> todos creemos o queremos tener la razón. Todos creemos tener más méritos
> que los otros que demuestren lo que decimos. Lo importante es no
> descalificar el trabajo de los demás.
Si me facieras un juoco SERIO de Speccy en BASIC, yo sería el primero en
descalificarte. ^c-
> Esto viene también a la coña Linux - Windows. Una cosa es un chiste de
> "linux es mejor que windows" o "windows sucks" y otra es que hubiera
> en el canal alguien que viviera de administrar un windows y que le gustara
> y que nos dedicaramos a echar pestes de windows o decir que los que
> administran windows son lamers o son de segunda. Quiero decir que yo
> puedo hacer chistes, pero a la hora de hablar del trabajo o del esfuerzo
> de los demás por ayudar en algo no se debe nunca criticar. Al igual que
> se le puede decir cualquier cosa a zx128k, su esfuerzo por escanear
> portadas en encomiable. Aunque el C fuera 300% más lento que el ASM
> (cosa que me encargaré de demostrar que no es cierta) no se me puede
> decir en el IRC que mejor no hacer nada que hacer algo en C.
Ejque, Santi, es la mesma película pero con actores diferentes, es más de lo
mesmo. Facer cosas MALAS (no malillas, MALAS, que están MAL HECHAS) no face
favor a NADIE, todo lo contrario, se PROSTITUYE el sistema, face que estemos a
la mesma altura que otras plataformas (sin incluirnos en ningún sistema en
concreto y sin señalar a ninguno otro) en las que se facen cosas DELEZNABLES.
No es el mesmo caso exacto pero paque mentiendas:
Yo tengui la Atari Lynx, y es un maquinorro con tres pares de coxones. Han
salido unos 90 juocos al mercado de los cuales solamente tengui 50 y pico.
Daquestos 50 solamente valen la pena (están a la altura del hard de la
máquina) tres o cuatro, y por distintas razones, no es que todos sean
virguerías pogramativas o tengan graficamens flipantes. Benne, amí me da mucha
vergüenza saber que hay un maquinorro como la Lynx y como la peña hizo juocos
lamentables, como por culpa daquestos juocos el maquinorro en si fue y es
despreciado por la peña. Yo comparo los juocos y me pregunto porcuá los demás
no tienen scrolls o movimientos o musicasas como esos tres o cuatro, y me da
mucha rabia videar un juoco que podría (o debería) haber sido la reoxtia y
enresulta que es uno más del montón, que por diversas culpa ajenas a la
maquinorra (que si el lenguaje utilizado, que si los pogramadores, que si el
plazo de entrega, que si la publicidad...) es aquesta la que se lleva los
palos y acaba siendo un ejemplo de mala máquina, cuando no lo es.
Tambenne está el caso del mesequix, que me dá mucha pena videar un juoco que
está fecho en BASIC, que necesita un Turbo R pa rular, y que tengan la poca
vergüenza de decir que es el único juoco que le saca TODO el partido a un
Turbo R. Sip, soy EGOISTA, no quiero que cosas asín pasen en el Speccy, y la
melchor forma es la de controlarse y sopesar benne las cualquiecosas que se
fagan SIN anteponer que sea más fácil, más rápido o más alto.
> Eso me pasa por decir las cosas a la cara, y ya sé que a alguien le
> pueden doler. De hecho me siento (lamentablemente) bastante responsable
> de la marcha de z-0 porque si revisais las news precisamente se enfadó
> por un mensaje mío en el que le echaba un poco en cara que menospreciara
> los conocimientos y trabajo de los demás. En algunos aspectos eso me
> pareció, yo simplemente le dije que nadie tenía la verdad universal y
> a los 2-3 días se despidió del grupo...
Ejque yo pienso que Z dijo cosas de cajón. Tambenne me he videado el thread
ese famoso del Nemesis, de si era un juoco bueno o malo, o lo de los
rapapolvos a Tony sobre las musicasas. ^c^
Quicir que hay cosas que no tienen vuelta de hoja, aunque si empezamos a
discutir, TODOS siempre tendremos razón, TODO es JUSTIFICABLE. Si uno se pone
en la piel de Bin Laden verá de que el pavo TIENE RAZÓN, porcuá SUS
argumentos, pa él, son correctos e irrebatibles. Todo se remite al sentido
común de cadascuno, y aquesto no es una cosa que se pueda inculcar ni obligar,
es uno mesmo el que ha de caer en la cuenta. No digo que Z tenga la verdaz
absoluta en todo, pero al videar sus mensajiquis, joer, pos como que la
chavala tenía razón, y lo digo desde un punto de vista totalmente aséptico e
imparcial, de la mesma forma que vidéo que TrueVideo ha sentenciado
aplastantemente diciendo que *todas* las rutinas son críticas en un juoco de
Speccy.
> Espero que nadie se mosquee conmigo esta vez por mi mensaje...
... o al menos no tanto como te mosqueastes tú conmigo en el ierrecé. ^c-
(de buen rollete, porsideacaso)
--
S.T.A.R.
--
z...@nil.fut.es
>> Si, y además (parte social de la discusión) me parece una falta de
>> tacto decir que algo no sirve cuando hay gente en el grupo que lo
>> usa. Mejor dicho, me parece muy mal que haya gente usando su tiempo,
>> dando de si mismos, pensando en ayudar, etc. al spectrum (aunque sea
>> en C) y que se le digan cosas que vengan a decir que hacer eso será
>> una pérdida de tiempo.
>Yo no me pondria tan melodramatico en esto. En ningun momento he
>querido insinuar que quien esta metido en el tema "C para Spectrum"
>este perdiendo el tiempo.
>Es posible programar en C para Spectrum? Claro que si. Estoy
>convencido de ello. Por que no?
>De lo que no estoy tan convencido es de que se intente comparar el C
>con el ensamblador en un Spectrum. Todos mis posts estan basados en
>esta premisa: el C no es suficientemente potente para sacar adelante
>un proyecto de calidad en un Spectrum (por ejemplo, un arcade (de
>calidad)).
Ejque creome que lo de calidaz te lo has sacado del manga, quicir que Santi no
ha dicho en ningún momento (creome) que desee facer cualquiecosa de calidaz,
sinó simplemente facer cualquiecosa.
>Si el compilador de C sirve para que gente que no habia programado el
>Spectrum antes pueda aplicar sus conocimientos actuales para crear
>algo, pues perfecto. Eso siempre sera bueno.
Témome que aquesto puede ser un arma de doble filo, pero benne, insisto,
cuestión de amor propio.
>Es mas, si el responsable de la libreria grafica decide incluir codigo
>en ensamblador para las partes de mas bajo nivel, estare encantado de
>proporcionarselas. Esto es un oferta en firme.
Cuantos más seais, más reireis. ^c-
>> STAR me decía el otro día en el IRC que para hacer cosas malillas para
>> Spectrum era mejor no hacer nada. Yo no estoy de acuerdo
>Yo tampoco estoy de acuerdo con esto. Si se hacen cosas malillas, es
>señal de que hay gente haciendo algo. Y eso es condicion indispensable
>para que en algun momento acabe saliendo algo bueno.
Hombres! ¿Por fin ha salido un juoco BUENO pa la LameBoy? ^c-
>Ademas, ya sabemos como es STAR. Tiene el pelo de color no-natural y
>dice "yavestruz" copiosamente. ^L^
Eres de Roma capital ¿verdaz? ^c-
>> Espero que nadie se mosquee conmigo esta vez por mi mensaje...
>Yo me he mosqueado mucho. En señal de protesta y/o mosqueo, voy a
>quemar una copia del GENS-3, avivando el fuego con el sobre sellado de
>la caja de The Ultimate Collection que STAR esconde debajo de su
>camastro.
JUAS! Que te crees tú que el sobre con Siete Sellos lo voy a tener debajo la
piltra! Estoy convencido de que el día que lo abra se desencadena el
APOCALIPSIS. Desagradecidos, que sois unos desagradecidos! ^c-
--
S.T.A.R.
--
z...@nil.fut.es
> Hablando de STAR... YUUUUUUUUUUUUUUUUJUUUU!!!!
>¿En MSX como hacen todo en general? ¿Usan compiladores de C? ¿Son
>cruzados? ¿Programan directamente en MSX?
El mesequix es el nido de la locura. ^c^
Los pogramadores se pueden contar con los dedos de un yakuza manco, y se
pueden clasificar por grupos:
[] SD MEXES. La Secta. Son una peña de un sitio que llaman >K (Mayorka), y
entre todos facen varias cosas:
[] Fanzine. De locos, oiga, con una jerga aún más inintelegible que la
mía pero con unas partidas de culo que es demasié.
[] SaveR aka El Puto. Cada diez años más o menos se curra un juoco en
BASIC, *PERO* la gracia está en que amasamás del soft, SE CURRA EL HARD. Ha
fecho juocos en plan Beatmania currándose él mesmo los cocksticks, como una
mesa de DJ, una guitarra freaka o una BATAKA.
[] El Mato#34 aka El Gilipollas del Decimal aka Capitán Corbata.
Famosos son sus tutoriales de como cambiar el color de pantalla desde BASIC
con imágenes explicativas o sus juocos en plan cachondeo (que regala) en
BASIC.
[] Ramonihijo. Desde face eones que se está en un proyecto secreto
(que todo el mundo conoce) pogramando un juoco en ASM.
[] Rodorón. Lo encontraron en la calle (literalmente), lo adoptaron y
se entretiene faciendo robotijos controlados por pecera.
[] Néstor Soriano aka Konamiman aka Lapichadelnéstor. Aqueste pograma
cosas en ASM, cosas como su NestorBASIC, su NesquickBASIC, NestorAcentos...
utilidades varias en ASM pa que los demás pogramen en un BASIC más extendido.
Ahora mesmo tiene como proyecto de fin de carrera una pila TCP/IP pa mesequix,
en ASM, claro.
[] boh.ken. Nombre anterior de lo que queda del grupo en el que el más
conocido es Manuel Pazos. Miembros pogramadores actuales y anteriores:
[] Manuel Pazos aka Hombretón del Norte. Se curró en ASM el Sonyc
(remake del Sonic pa mesequix), tradujo varios pogramas al castillero (pilló
unos que estaban traducidos del japo al inglesh) y se curró un juoco chorra,
HeadHunter, en ASM pa subvencionarse el viaje a una rugresca (lo vendía a 500
pelas y ahora lo tiene gratix en su site). Ha fecho tambenne varias utilidades
tipo FAT16 pa interfaces IDE y cosas desas, todo en ASM. Coautor junto a
Ramones del KPI Ball (versión del Pang). En contra de la creencia popular, NO
es el completo autor de la versión mesequix dos de La Abadía del Crimen.
[] Ramones. Aqueste pograma en ASM y dice que no pilla ningún otro
lenguaje ni que lo maten. Ha punta pistola hizo el Blue Warrior de Moai Tech
(él se curro el código pero no vió ni un duro) pa facer un favor, empezó junto
a Manuel Pazos el PuddleLand (un juoco de plataformas que perjura que NUNCA se
terminará), es quien empezó el tema de la Abadía (Pazos le terminó la rutina
de impresión de carácteres), coautor del Pang y ahora mesmo está pogramando un
juoco de mesequix en ASM, obviosamente.
[] Daniel Zorita aka Canor. Se curró el Sir Dan enteramente en ASM. Tambenne
se curró un Galaxians llamado Vader, en ASM, claro.
[] Traposoft. Lleva desde eones anunciando la inminente aparición del
SpeedLine, una suerte de Tron pa Turbor con Moonsound, enteramente escrito en
BASIC, sin compiladores.
[] Moai Tech. No se sabe a ciencia cierta quien face qué, porcuá todos dicen
que lo facen todos, pero al final no se videa ningún juoco nuovo. El Blue
Warrior, aunque firmado por su sello, es obra de Ramones, y un próximo juoco
que pretenden sacar (es secreto pero todo el mundo lo sabe) lo pograma un
desconocido, obviosamente enterito en BASIC, tambenne sin compiladores.
[] Imanok. Face juocos en BASIC, y un punto a su favor, sin ninguna pretensión
y con una modestia envidiable.
Y creome que no hay más. Ha habido algún juoco más como el Pentaro y el
Pentaro 2 (ambos en ASM), un refrito de Nemesis fecho con un game creator, y
media docena más de juocos en BASIC de cabo a rabo. Obviosamente, hay puñazos
por parte de los que utilizan BASIC porcuá dicen que son currantes como
cualesquiera otro, pero os invito a que videeis aquestos juocos y juzgueis por
vosotros mesmos. Por supuesto, aquestos juocos necesitan una máquina MUY
potente, del nivel de mesequis dos plus o turbor, preferiblemente con
Winchester y tarjeta de sonido Moonsound.
Resumancia, hay dos que facen juocos en ASM y uno que face utils algo como
chorras. El resto tira de BASIC y tan contentos. Lo jodido daquesta lista
ejque a excepción del mencionado Imanok, TODOS LOS DEMÁS defienden el BASIC a
muerte, SENCILLAMENTE porcuá no se meten a aprender ASM. Entre ellos ya se han
peleado más de una vez cuando uno les dice de buena voluntaz que lo podría
haber fecho en ASM, que no cuesta nada, que es cuestión de meterse y tal, pero
como el mesequix es el mesequix, todos van a acaparar y a ser el más, y se
ofenden cuando se les vé el plumero que facen juocos NO por facer cualesquiera
cosa, sinó por llevarse el gato al agua. Destacar que aqueste párrafo no ha
salido de mi cabeza, sinó que es una recopilación simplificada de lo que se ha
comentado en diversos ambientes mesequiseros. Yo me he limitado a transcribir
opinancias vertidas por terceros, que ya tengo prou jaleos con los
mesequiseros como pa bujcarme más dolores de cabeza. =c=
Espero que sepais sacarle la moraleja de la batallita. ^c-
> Por cierto, a lo mejor lo podemos usar el compilador de C en
>el sprinter...
Pos igual sip, porcuá el procesador va a más velocidad, tiene más modos que en
un Speccy, el modo Sprinter es diferente a un Speccy y esas cosas.
Obviosamente omolaría más que se faciese en ASM pero yo veo que es una máquina
NUEVA que se llama Sprinter y como tiene los puertos ISA y esas cosas, pos
suponome que se acerca más a la definición de Personal Computer que no a Home
Computer. Como el Sprinter no tiene antecedentes pos sois los users a quien os
toca levantarlo. Y ejque tener claro que el Sprinter NO es un Speccy.
--
S.T.A.R.
--
TrueVid
lu...@fedro.ugr.es (Luis Perez) wrote in message news:<3bf1d169...@News.CIS.DFN.DE>...
> On 13 Nov 2001 05:24:40 -0800, d...@truevideo.net (TrueVid) wrote:
> En muchos casos uno descubre que una rutina es critica a
> posteriori y no a priori. Decir que todas son criticas a priori es
> muy fuerte żNo? Dependera del tipo de juego...
Si, es verdad. Decir eso de todos los juegos es exagerado. Es obvio
que no todos los juegos para Spectrum son tan "exigentes". De hecho,
hay muy pocos que expriman al Spectrum de verdad. Pero con solo que
haya uno, ya me vale.
Me explico:
Creo que hay unos pocos juegos que se han de considerar *baremos* en
las discusiones sobre programacion en Spectrum. Estos juegos no son ni
el Jet Set Willy, ni el Jet Pac, ni el Hobbit, por famosos e
importantes que sean.
Cuando nos preguntamos "żesta el C a la altura del ensamblador en un
Spectrum?" en realidad nos debemos preguntar "żpodriamos programar un
Cobra o un I of the mask en C o en C con asm?". Creo que se ha de
enfocar asi porque estos son juegos tecnicamente perfectos. Son juegos
que marcan la diferencia entre tecnicas de programacion maestras y
tecnicas convencionales.
De hecho, estoy seguro de que se podria hacer un Jet Set Willy en C,
ok (1). Pero a mi eso no me vale como argumento en favor del C porque
el JSW no es un juego "baremo". Es un juego que se ha ganado
merecidamente el estatus de "clasico" y "obra maestra", pero no por
ello deja de ser tecnicamente muy convencional.
> Hombre, quizas no sea el 90-10 en un videojuego para spectrum
> pero tampoco creo que sea un 100-100 como sugieres.
En el caso de un Cobra o un I of the Mask, estoy convencido de que si.
> Me parece que tu si has programado para
> spectrum żNo? Organizaras tus programas en rutinas, call return żNo?
> Si el bucle principal del programa es C, y es eficiente, y lo que hay
> dentro son llamadas a funciones que son en realidad tus rutinas żvas a
> perder mucha velocidad con el programa?
No se si perderas mucha velocidad en un sentido estricto, pero el
planteamiento ya estará equivocado desde el principio. El codigo ha de
estar hecho a la medida de tu juego. Tan a la medida, que si lo
ejecutas con unos ciclos de retardo, todo se va al garete. Es la
"precision" a la que me referia en uno de los posts anteriores.
Una de las desventajas, o atractivos, de este tipo de programacion
"critica" es que acabas teniendo un nucleo que lo hace todo, y todo
acaba intimamente interrelacionado. El scroll, la rutina de impresion
y el volcado en pantalla, por ejemplo, son rutinas que no se pueden
separar en modulos independientes en un juego tipo Cobra.
Ya te digo que en estos casos se requiere un enfoque muy poco
academico.
> A lo mejor a ti te molesta el que otro use tus funciones,
> pero, es por el bien del spectrum!!!
Jajajaja, bueno, reconozco que soy baste proteccionista (se dice
asin??) con mi codigo, pero como ya dije ayer, estare encantado de
proporcionar a Santi todo el codigo que necesite para su nucleo de
bajo nivel. :-)
>
> while (1){
> if (usuario(tu)))==usuario(spectrum)) then
> if (!chica(tu) then
> charla(tu):
> else
> regalo(tu);
> else
> kick(usuario)
> } //que nadie se sienta ofendido
<SNIP>
> Es un ejemplo tonto, pero como ejemplo vale.
OK, yo no dudo de que el C pueda ser optimizado. Pero olvidemonos por
un momento de los siempre presentes ejemplos de whiles e ifs anidados.
Hagamos cosas mas de Spectrum, que es de lo que se trata.
Que tal una rutina que calcule la direccion en pantalla a partir de
las coordenadas de un pixel? O una que scrolle un tercio de la
pantalla? O una de extraccion de bits? O sonido polifonico via bocina?
O una que imprima el mayor numero de caracteres posible durante el
vbl?
Alguien se atreve a programar alguna de estas en C y enfrentarlas *en
justa lid* con mis equivalentes en ensamblador? Propongo al
"ciclometro" como juez imparcial.
Ha sonado muy descaradamente a desafio? :-) :-)
Animo, desengrasad vuestros compiladores. Eso si,
** se requiere mantener el sentido del humor en todo momento **
OK-DOKEY, saludos a todos!
True
--
(1) espero que por haber dicho esto ningun integrista binario me
golpee en la cabeza con un palo puntiagudo.
Kak
> quiere, no por facer un algo en un momento determinado. Oño, es lo que dice
> Kak, que lo fardas más mantiendo un status de integridad pogramando en ASM que
> no en C, un juoco de Speccy se entiende.
eso mismo queria decir ;)
claro que fardar tampoco es una cosa muy importante, y que hoy en dia
una cosa como esta es mas bien vista como bicho raro que como algo de
que sentirse satisfecho (lo dicho, la informatica esta muy mal), justo
por eso lo decia con un tono de broma :) (Bueno, tono de broma, pero en
serio)
y es que es eso, si no tienes deadline, no tienes obligacion de sacarlo
y lo haces por satisfaccion personal, yo creo que 100% asm es una opcion
a tener en cuenta :)
pero bueno, cada uno es libre de hacer lo que quiera, y tanto NoP como
yo sabemos que los dos somos muy tozudos y ninguno va a bajar del burro
;) o sea que cualquier intento de cualquier persona, sea asm, c o basic,
bienvenido sea! :)
Kak, cubriendose de las piedras que le van a caer para el csscgc'2001 :)
Tony Brazil
> no usas ASM y tu programa no vuela? Y qué, peor es sentarse en la
> silla a esperar a que otros hagan algo, que todos hagan igual, nadie
> haga nada (o muy poca gente) y se vaya todo al carajo.
Mi opinion totalmente de aficionado y sin idea alguna de programar es que
si que vale la pena que hagas algo. Los primeros trabajos pueden salirte
malillos o poco provechosos pero a base de continuar e insistir seguro que
al final haces un buen juego. No hacer nada de nada seguro que no ayuda de
ninguna manera.
> Igual que Jose Manuel tiene una labor encomiable porque se mueve (a
> su manera, no programando sino preservando) en el Spectrum.
Es una gran labor!.
> Espero que nadie se mosquee conmigo esta vez por mi mensaje...
Todas la opiniones son validas, puedes estra o no de acuerdo pero se es
libre de expresarlas.
Un saludo
T.BRazil
Luis Perez
Romero) wrote:
> Me estoy planteando el hacer un curso de asm de z80 ...
> ¿tendría alguna aceptación o utilidad? :?
Siii!!. Yo ya he empezado a hacer rutinitas tontas con las
instrucciones de tu pagina (en ensamblador y no en C, para que vean
que no soy un fanatico del C).
Saludos,
Luis Perez.
Luis Perez
>Cuando nos preguntamos "¿esta el C a la altura del ensamblador en un
>Spectrum?" en realidad nos debemos preguntar "¿podriamos programar un
>Cobra o un I of the mask en C o en C con asm?". Creo que se ha de
>enfocar asi porque estos son juegos tecnicamente perfectos. Son juegos
>que marcan la diferencia entre tecnicas de programacion maestras y
>tecnicas convencionales.
Ya, pero ten en cuenta que cada lenguaje esta hecho para algun
campo en especifico (o varios). Ensamblador para rutinas criticas, o
juegos como tu dices que deban aprovechar al 100% la maquina. El C
abarca muchos campos del ensamblador pero *no todos*. Cuando defendia
C, lo defendia desde el punto de vista de que sirve para muchos casos
(no todos). Al igual que a lo mejor en C no se puede hacer el Cobra,
en ensamblador no se puede hacer un programa grande como puede ser
linux, word... Ya se que son ejemplos de PC, pero es que en spectrum
no se pueden hacer programas de mucha envergadura,
>De hecho, estoy seguro de que se podria hacer un Jet Set Willy en C,
>ok (1). Pero a mi eso no me vale como argumento en favor del C porque
>el JSW no es un juego "baremo". Es un juego que se ha ganado
>merecidamente el estatus de "clasico" y "obra maestra", pero no por
>ello deja de ser tecnicamente muy convencional.
Ok. Pero tampoco debemos de matar moscas a cañonazos. Si
podemos crear algo de calidad en C ¿Para que hacerlo en ensamblador?
>
>> A lo mejor a ti te molesta el que otro use tus funciones,
>> pero, es por el bien del spectrum!!!
>
>Jajajaja, bueno, reconozco que soy baste proteccionista (se dice
>asin??) con mi codigo, pero como ya dije ayer, estare encantado de
>proporcionar a Santi todo el codigo que necesite para su nucleo de
>bajo nivel. :-)
Me parecen que ya te han pescado!!! X-DDDDDDDD (cuidadin con
lo que dices)
>
>OK, yo no dudo de que el C pueda ser optimizado. Pero olvidemonos por
>un momento de los siempre presentes ejemplos de whiles e ifs anidados.
>Hagamos cosas mas de Spectrum, que es de lo que se trata.
>Que tal una rutina que calcule la direccion en pantalla a partir de
>las coordenadas de un pixel? O una que scrolle un tercio de la
>pantalla? O una de extraccion de bits? O sonido polifonico via bocina?
>O una que imprima el mayor numero de caracteres posible durante el
>vbl?
>Alguien se atreve a programar alguna de estas en C y enfrentarlas *en
>justa lid* con mis equivalentes en ensamblador? Propongo al
>"ciclometro" como juez imparcial.
Dos cosas...
Si el programador de C es bueno y todos los demas pueda
igualar o estar muy cerca de la eficiencia del mismo programa en
ensamblador, nunca he dicho que el C tenga mejores resultados que el
ensamblador. Es una competicion que pierde el C porque el C no mejora
al ensamblador. Igualarlo algunas veces pero mejorarlo, (si el
programador es bueno) nunca. ¿Que lenguaje puede ser mas rapido que el
ensamblador? Ninguno. Mas o menos lo que decia es que:
tiempo_ejecucion_asm <= tiempo_ejecucion_C
Pero que esta difirencia en la actualidad no suele ser mucha
para la *mayoria* de los casos. Nunca he dicho que pueda ocurrir que:
tiempo_ejecucion_c < tiempo_ejecucion_asm
>Ha sonado muy descaradamente a desafio? :-) :-)
>Animo, desengrasad vuestros compiladores. Eso si,
Quizas, lo que si nos interesaria es estudiar (en casos
normales) si el codigo generado por el z88 dk es bueno, ver que
mejoras podriamos aportarle... ¿Que os parece?
Saludos,
Luis Perez
Luis Perez
>
>Yo pienso en lo de zapatero a tus zapatos y si uno pograma juocos es, uno,
>porcuá le omola, dos, sabe pogramar, tres, tiene talento pa ello. No hay
>ninguna prisa pa que uno AHORA se ponga a pogramar un juoco, y más si se trata
>de una máquina como el Speccy, y que si a todas luces en Speccy es mucho
>melchor el ASM, pos como no hay prisas, uno se puede divertir aprendiendo
>ensamblador pa obtener unos resultados óptimos y quedar como un señor y no
>como uno que ha fecho un algo por facer algo en pro del Speccy.
Bueno... Depende de lo que uno quiera hacer... Por ejemplo, si
siempre vas a ordenar 10 numeros ¿Para que vas a implementar el heap
sort que es mucho mas dificil pero el mas eficiente si en un plis-plas
puedes implementar el burbuja? Con 10 elementos ambos tardan lo mismo
¿Para que vas a programar en ASM si en C vas a producir un resultado
dentro de unos margenes aceptables?
>Quicir que si faces un juoco en C pero mantienes que en ASM podría estar
>melchor, y al mesmo tempo sabes ASM, pos como que la cosa no me casa, nosé. Si
Hablaba de programar en C en vez de ASM si la calidad del
producto no se ve degradada o apenas se nota... Nadie quiere hacer
algo malo. Nadie esta hablando de crear juegos que van a saltos.
>Pero yo mesmo (sin querer joder la marrana) te podría decir que, ya que sabes
>ASM, ¿porcuá no has fecho ese mesmo juoco en ASM, que te irá mucho más rápido
>y fonará más eficientemente? ¿Por falta de tempo? ¿Qué prisa tienes? Como
>pogramador debes tener tu pofesionalidaz y suponome que preferirás CALIDAD
>antes que RAPIDEZ.
Calidad no es igual a velocidad el programa. El uchi mata por
muy rapido que vaya es el uchi mata. La calidad en un juego puede ser,
que el movimiento sea correcto (no tiene pq ser el mas rapido), que
tenga una dificultad equilibrada ... Si algo se necesita hacer en
ensamblador. ¡Ok! Pero si no es necesario ¿Por cua?
Saludos,
Luis Perez.
David C.
> El 13 Nov 2001 19:16:26 GMT, Flint escribió:
> Me estoy planteando el hacer un curso de asm de z80 ...
> żtendría alguna aceptación o utilidad? :?
ĄSI!
> --
> Santiago Romero
> Departamento de Sistemas
> sro...@servicom2000.com
Un saludete,
David C.
Siew
> [] Rodorón. Lo encontraron en la calle (literalmente), lo adoptaron y
> se entretiene faciendo robotijos controlados por pecera.
Este personaje tiene pagina web?
>
> Espero que sepais sacarle la moraleja de la batallita. ^c-
>
>
mmm... a ver si lo entiendo... si tanta gente defiende el basic es q es
weno, no? XDDDDD (notese la ironia del comentario)
>
> --
>
> S.T.A.R.
>
> --
>
>
--
NOS VEMOS :D
Usuario registrado de Linux #203336
TrueVid
<z...@nil.fut.es> escribió en el mensaje
news:2714.718T202...@nil.fut.es...
> >De lo que no estoy tan convencido es de que se intente comparar el C
> >con el ensamblador en un Spectrum. Todos mis posts estan basados en
> >esta premisa: el C no es suficientemente potente para sacar adelante
> >un proyecto de calidad en un Spectrum (por ejemplo, un arcade (de
> >calidad)).
>
> Ejque creome que lo de calidaz te lo has sacado del manga, quicir que
Santi no
> ha dicho en ningún momento (creome) que desee facer cualquiecosa de
calidaz,
> sinó simplemente facer cualquiecosa.
Bueno, no se cuales son sus intenciones ultimisimas. Toda mi astuta
argumentacion era en base al tema C vs ASM en general, sin personalizar en
nadie. De hecho el caso particular del proyecto de Santi se perdio en el
segundo o tercer post de este thread.
Ya que estamos discutiendo si el C y el ASM son alternativas equivalentes en
potencia, no tiene sentido hacerlo sobre la hipotesis de un Tetris o un
Pograma de Quinielas ("bgue-nah suergh-teee!"). Por eso recalcaba lo del
arcade de calidad, que es el unico banco de pruebas no-engañoso (en
Spectrum, sobreentiéndese)
> Hombres! ¿Por fin ha salido un juoco BUENO pa la LameBoy? ^c-
Joder pos claro.
A ver, er....
um.
NO.
> JUAS! Que te crees tú que el sobre con Siete Sellos lo voy a tener debajo
la
> piltra!
OK. Ya sabemos donde NO lo tiene. ¬_¬ <---(dijo él con mirada aviesa..)
--
TrueVid
www.truevideo.net
Flint
> El 13 Nov 2001 19:16:26 GMT, Flint escribió:
>>> Insisto, que yo quiera usar C no quiere decir que no me guste el
>>> ASM. De hecho quiero usar ASM en C. ¿alguien me lee? ¿mama? ¿hola?
>>
>> Por cierto, ¿donde se puede aprender algo de CM del Z80 en castillero?
>> Fijo que tu tienes algun enlace, Santiago.
>
> Solo en ingles :(((
> http://www.speccy.f2s.com/prog/z80asm.html
>
> Yo es que tengo un libro en castellano de Rodnay Zacks, pero he decir
> que si quieres aprender ASM de Z80 EN CASTELLANO te recomiendo este
> paso:
>
> 1.- libro de asm anaya (1600 pts) Coleccion Guias de Bolsillo
> "ensamblador de los 80x86" de Jon Beltran de Heredia
Tomo nota
>
> 2.- sabiendo asm de pc, leer los tutoriales en ingles de la web. En
> unos
> dias y programando alguna cosilla ya sabrás asm de z80.
OK.
>
> Me estoy planteando el hacer un curso de asm de z80 ...
> ¿tendría alguna aceptación o utilidad? :?
¿Y lo preguntas???????? SI CLARO :)
Un saludo
Flint
>
Mario Sevillano Mansilla
Ante todo decir que casi me da vergüenza escribir aquí, porque con la idea
que tengo yo de programar en un Speccy, (los que hayáis visto mi Simulador
de Vuelo lo sabréis, y si no,
http://www.terra.es/personal5/akhorahil/fsim2001.TAP, y perdón por haberlo
hecho X'DDD) pues como que tengo poco que aportar... Ah, y que todo esto, de
buen rollo, no me vayáis a pegar... ;)
Lo que quiero decir es que por un lado me parece bien que se esté haciendo
un proyecto de programación del Speccy en C. Más cosas para el Spectrum, y
quien sabe, a lo mejor puede resultar útil a alguien. (Aúpa, Santi)
Por otro lado, lo que yo digo es que cuando yo haga un juego, lo que quiero
hacer es aprender ASM, porque hace ya mucho tiempo que quiero aprender, y si
en algún momento quiero hacer un juego bueno de cojones, (si soy capaz,
visto lo de arriba) pues ya tardo para ponerme a aprender ASM... Lo que yo
entiendo es que si el juego tiene que ser un juego en plan _profesional_, la
única solución viable es en ASM...(Santi, si te decides a poner un curso de
ASM en tu web, FANTÁSTICO!!! VA A SER TACO DE ÚTIL) (Aúpa, Santi... ) X'DDD
Yo entiendo que la cuestión es el contexto. Todo dependerá de las
intenciones de quien haga el juego. Creo recordar que algunos juegos, a mi
entender, buenos, se han hecho en Speccy con compiladores, como el
Profanation - sí, vale, es un ejemplo antiguo... Cierto es también que para
hacer un juego en plan "obra de arte", no te vale un compilador, por bueno
que sea, porque por lo que leo ya hay que recurrir a ASM, y no sólo eso,
sino que hay que dominar el ASM, controlar los tiempos de ejecución de las
instrucciones, y eso implica que no siempre lo más evidente, o lo más
"lógico" o lo más "de libro" es lo más correcto.
A lo que voy, si aquí estamos todos es para divertirnos, en el momento que
uno no se divierte, pues no mola. Así que si uno hace un juego en ASM y hace
una obra maestra, porque él disfruta así, pues bienvenido sea, y gracias por
su aportación. Y si otro hace un juego más modesto, pero la gente se lo pasa
bien jugando, y no tiene las pretensiones de hacer el mejor juego,
técnicamente hablando, pues está bien.
En definitiva, que puede haber gente a la que no le apetezca aprender ASM
hasta el punto de dominarlo, pero tenga ganas de hacer un jueguecillo, ya
sea para jugar con sus amiguetes en su casa, o para ponerlo en la web y
decir "mira qué juego he hecho, aunque no tenga triple scroll ni sonido a 3
canales está divertido". Y habrá gente a la que le guste estrujar la máquina
hasta el límite.
Está claro que a una máquina la levantan los users. La idea es que cada uno
haga lo que pueda, eso sí, intentándolo hacer lo mejor posible.
Dicho esto, que aquí cada uno que programe como quiera, siempre y cuando no
atente contra la cordura de la gente... (um, dicho esto, yo no debería
programar X'DDD).
Hala, a pasarlo bien...
Paz!!!
PD. Ya sé que esto no va por el hilo que iba, pero es que no sabía dónde
colgarlo
"EdUarDo" <eya...@sia.es> escribió en el mensaje
news:22eed3db.01111...@posting.google.com...
Ivan Ruiz Etxabe
Menuda cuadrilla de freakies. Pero en el tema del BASIC,
avore, :), esta bien empezar con el BASIC, diría que el
ASM es muy espeso sin tener nociones de lenguaje de alto
nivel, pero me cuesta entender la obcecación con el BASIC,
el MSX, como el resto de las máquinas, lo acaban traduciendo
a lenguaje máquina y está claro que nosotros (los humanos)
vamos a optimizar más el código que unos algoritmos de
compilación o interpretación, estas técnicas tienen muchas
limitaciones... pero si encima de obcecarte, insultas, oiga que
se fumen un porro :)
Me ha molao tu descripción
Iván
Tony Brazil
>Ejque yo pienso que Z dijo cosas de cajón. Tambenne me he videado el thread
>ese famoso del Nemesis, de si era un juoco bueno o malo, o lo de los
>rapapolvos a Tony sobre las musicasas. ^c^
XDDD. ¡que buenos tiempos!, en fin, entendi los motivos de Z-0, me explico
porque NO era la maravilla que pintabamos la mayoria. Y la verdad es que
tenia razón, aunque en su momento como no habia visto mucho me parecio
genial ;-D.
>... o al menos no tanto como te mosqueastes tú conmigo en el ierrecé. ^c-
Son opiniones diferentes, no hay porque molestarse.
El tiempo deja a cada uno en su sitio.
Un saludo
T.Brazil
Tony Brazil
>que no programe muy bien en ensamblador, no va a hacer un código más
>óptimo que un compilador.
Sin duda, sino dominas el ASM y otro domina el C es posible que haga algo
mejor XDDD
Un saludo
T.BRazil
Mario Sevillano Mansilla
Es que he dado con el concepto que quería expresar antes. Es éste:
Hagamos cosas para el Speccy, sean cuales sean los medios que se empleen,
sea en C, sea en ASM o como sea, pero hagámoslas con _cariño_, que de esa
manera no pueden salir cosas malas...
Eso era. Un saludo a toda la peña.
Fistroman
TrueVid
> Ante todo decir que casi me da vergüenza escribir aquí, porque con la idea
> que tengo yo de programar en un Speccy, (los que hayáis visto mi Simulador
> de Vuelo lo sabréis, y si no,
El dia que me sienta *verdaderamente* de muy buen humor yo tambien hare
publico mi simulador.
El simulador de RULETA RUSA.
Tiene graficos que ocupan toda la pantalla, y nivel de dificultad
seleccionable. Puedes escoger con cuantas balas juegas: de 1 (facil) a 6
(muerte segura). Y es para 2 jugadores.
No es coña.
Y ademas no está en CM, sino en BASIC. :-O
> PD. Ya sé que esto no va por el hilo que iba, pero es que no sabía dónde
> colgarlo
Si que iba al hilo. Y resume bastante bien mi postura en este thread.
Taluego,
BANG!
--
TrueVid
www.truevideo.net
Pedrete
Te falta Pedrete, con su gran programa BRUTAL CALCULATOR INTERCEPTION
GROMENAUER. Y como ahora está de moda, hala, publico el código fuente en el
GPL ese:
10 INPUT A
20 INPUT B
30 PRINT A+B
Bestial... ¿verdad?
XXDDD
> S.T.A.R.
Pedrete
EdUarDo
No me refería a eso, si no a que alguien que no controle ensamblador,
lo hará bastante peor que si lo hace en C, porque el código
ensamblador que genere el compilador de C será mejor que el del
programador novato.
>
> Un saludo
> T.BRazil
Santiago Romero
Haz un tap con bas2tap y grabalo para que haga run con un
PRINT "BRUTAL CALCULATOR" y mandalo a la competicion del CSS.
--
Santiago Romero
Departamento de Sistemas
sro...@servicom2000.com
C/ Primado Reig, 189 entlo
Tony Brazil
>Ah, y que todo esto, de buen rollo, no me vayáis a pegar... ;)
Es graciosillo ;-D
>Yo entiendo que la cuestión es el contexto. Todo dependerá de las
>intenciones de quien haga el juego.
Lo ideal claro esta es que salieran juegos nuevos a un gran nivel, pero
como bien dices el contexto es lo que importa y las pretensiones con que lo
haces. Si Santi o cualquier hace un juego y no usa ASM,etc... pero el
tampoco lo anuncia como una maravilla ni lo vende en ningun casi creo que
este haciendo daño al sistema. Otra cosa es el caso del MSX que te venden
juegos en Basic como si fueran juegazos (Nuts por ejemplo).
>bien jugando, y no tiene las pretensiones de hacer el mejor juego,
>técnicamente hablando, pues está bien.
No tiene porque hacer daños al sistema, peores bodrios se hicieron en su
momento XDDDDD (uchi mata,etc... y estos eran comerciales).
Un Saludo
T.BRazil
Ivan Ruiz Etxabe
Romero) va y suelta:
>El Thu, 15 Nov 2001 09:25:53 +0100, Pedrete escribió:
>>> Y creome que no hay más. Ha habido algún juoco más como el Pentaro y el
>>
>> Te falta Pedrete, con su gran programa BRUTAL CALCULATOR INTERCEPTION
>> GROMENAUER. Y como ahora está de moda, hala, publico el código fuente en el
>> GPL ese:
>>
>> 10 INPUT A
>> 20 INPUT B
>> 30 PRINT A+B
>>
>> Bestial... ¿verdad?
>
> Haz un tap con bas2tap y grabalo para que haga run con un
> PRINT "BRUTAL CALCULATOR" y mandalo a la competicion del CSS.
Estás de la olla? como va a mandarlo así? seria demasiado bueno. Yo
añadiría lo siguiente :
Un for grande entre el input y el print que no haga nada o haga un
print que ponga "Crunching numbers... please wait"
Tambien ayudaría poner mucha sensibilidad al teclado para que cada
vez que quieras poner un 3 te salga 33333. Es desquiciante, pero un
recurso ya conocido en la competi.
Iván
Ivan Ruiz Etxabe
el Demolishing Euro conversor.... con redondeos
a favor de la makina, y con opcion libras esterlinas,
de manera que ponga : you got 0 Euros for your
(variable) pounds. Your money has no value.
MUAJAJAJAJAJ
:)
Iván
Luis Perez
wrote:
>El dia que me sienta *verdaderamente* de muy buen humor yo tambien hare
>publico mi simulador.
>
>El simulador de RULETA RUSA.
>
>Tiene graficos que ocupan toda la pantalla, y nivel de dificultad
>seleccionable. Puedes escoger con cuantas balas juegas: de 1 (facil) a 6
>(muerte segura). Y es para 2 jugadores.
>
>No es coña.
>
>Y ademas no está en CM, sino en BASIC. :-O
>
Pillin, te pille... ¡¡Hereje del ASM!!! ¡¡Que le corten la
cabeza!!! o mejor !! A la hogera!! X-DDDDDDDDDD
Saludos,
Luis Perez
Luis Perez
Etxabe) wrote:
>vamos a optimizar más el código que unos algoritmos de
>compilación o interpretación, estas técnicas tienen muchas
>limitaciones... pero si encima de obcecarte, insultas, oiga que
J*****. Que mala fama tienen los compiladores aqui... Si te
escuchara mi antiguo profesor de procesadores de lenguajes te
incineraba. Hay muchas cosas que ya los humanos no pueden hacer mejor
que un compilador a la hora de optimizar...
Por ejemplo, dado un conjunto de instrucciones ASM, un
algoritmo te puede encontrar el mejor aprovechamiento de los registros
posibles. Un humano, tambien, porque puede aplicar en mismo algoritmo
que el compilador. O dado un conjunto de instrucciones, un compilador
te puede encontrar el mejor orden de ejecucion y asi un monton de
cosas.
Las tecnicas de compilacion en la actualidad no tienen tantas
limitaciones, en dominios especificos si. *En general* ,no es facil
mejorar el codigo generado por un compilador, muy pocas personas lo
pueden hacer (suponiendo que el compilador sea bueno). Cuando decis
cosas como esas parece que un programa C va 2 o 3 veces mas lento que
uno en ensamblador y que cualquiera puede optimizar su codigo...
Saludos,
Luis Perez.
Ivan Ruiz Etxabe
si también he tenido la asignatura de Compi,
los ETDS, las distintas pasadas etc,, Back ends, Front ends y
algoritmos
muy eficientes, pero hablando en un contexto speccy,
en el que no disponemos memoria secundaria a saco
para almacenar tablas de simbolos etc etc etc, el asm
se hace la mejor de las opciones. Hoy en día? lo que
dices es muy cierto :)
Iván
Ignacio Burgueño
"TrueVid" <d...@truevideo.net> wrote in message
news:a0d87ef1.0111...@posting.google.com...
> > Exacto. Es la famosa regla 90-10, y es perfectamente aplicable a
> > cualquier máquina
>
> Es una regla famosa. Pero tambien lo son los duros de chocolate.
>
> Las rutinas criticas no se ejecutan el 10% de las veces y ya esta. Son
> criticas precisamente porque se ejecutan **continuamente** y de forma
> sincronizada. Si no, ya las hubiese llamado de otra forma.
No, no. La regla del 90-10 dice (aprox.) que el 90% del tiempo estás
ejecutando un 10% de tu código. O sea, no es que tus rutinas críticas se
ejecuten un 10% de las veces, sino que estas se ejecutan un 90% de las
veces, y que estas representan un 10% del total del código. Por supuesto que
estos números se manejan como ejemplo, pero cualquiera que haya corrido un
profile sobre un programa sabe que si hay que empezar a optimizar a mano,
hay que empezar por la rutina que se "come" la CPU y se llama más seguido.
Esa es tu rutina "crítica".
Pero, eso sí. Estoy de acuerdo en que en el contexto de programar para un
Spectrum, lo que importa no es si el código C es casi tan rápido como lo que
vayas a hacer en ASM. El meollo del asunto está en que uno no tiene control
sobre el "timing" de las instrucciones generadas. Dicho esto, si Santiago se
aparece con un efecto Rainbow escrito en C, voy a tener que tragarme mis
palabras...
En definitiva, mi postura es un poco la de Santiago. Probemos el Z88dk, y si
necesitamos alguna rutina que se sincronize con el barrido de pantalla y
cosas así, se hace en ASM. ¿Para qué voy a arrancar haciendo el menú en ASM
si no va a ser necesario?
Bueno, saludos a todos!! Que menudo susto me dí hoy luego de unos días de no
poder ni mirar por arriba los posts y me encuentro con chiquicientos
mensajes!! Por dónde empiezo!!!??
Ignacio
--
GLECK
http://gleck.emuunlim.com
Luis Perez
<spec...@i.com.uy> wrote:
>
>En definitiva, mi postura es un poco la de Santiago. Probemos el Z88dk, y si
>necesitamos alguna rutina que se sincronize con el barrido de pantalla y
>cosas así, se hace en ASM. ¿Para qué voy a arrancar haciendo el menú en ASM
>si no va a ser necesario?
Mira, estoy de acuerdo contigo...
Saludos,
Luis Perez.
Luis Perez
De acuerdo... Pero ahora podemos usar el PC como herramienta
para programar con el spectrum... Solo hace falta ver si las
herramientas que tenemos son buenas. Este fin de semana intentare
ponerme con el z88dk y ya contare mis resultados (si a Santiago Romero
no le importa)
Saludos,
Luis Perez.
Luis Perez
X-DDDDDDDDDDDDD Muy bueno... Espero con impaciencia esa obra
de arte X-DDDDDDDDDDDD
Luis.
TrueVid
"Ignacio Burgue?" <spec...@i.com.uy> wrote in message news:<9t1q5a$16fs2l$1...@ID-30718.news.dfncis.de>...
> No, no. La regla del 90-10 dice (aprox.) que el 90% del tiempo estás
> ejecutando un 10% de tu código. O sea, no es que tus rutinas críticas se
> ejecuten un 10% de las veces, sino que estas se ejecutan un 90% de las
> veces, y que estas representan un 10% del total del código.
Estoy de acuerdo contigo. Casi. En un juego de Spectrum, las rutinas
criticas se ejecutan el 90% de las veces, sip, pero *NO* representan
el 10% del codigo. Ni por asomo, vamos.
La parte de codigo en un arcade tipo scrolla-y-mata para Spectrum es
minuscula. Estoy hablando de 4K o 5K, siendo *muy* generoso. Te lo
digo por experiencia propia y ajena. El resto son, como no, graficos,
tablas precalculadas, mas tablas precalculadas, sprites rotados... y
alguna tabla precalculada, quizas tambien haya ;-)
Una vez mas, vuelvo a repetir que estoy hablando en un contexto muy
concreto. Spectrum->juegos->arcade->el-que-tu-ya-sabes-o-parecido.
No intento extrapolarlo a ningun otro supuesto. Soy muy consciente de
que lo que digo no es aplicable en otros campos de la programacion
(que son en donde se origino precisamente esa famosa regla, p.e.). Y
tambien soy muy consciente de que todo lo que he dicho, si hablamos de
un juego "normal", son basicamente idas de pelota.
Entonces por que insisto en estos casos extremos?
El origen de este thread era (o deberia ser) "C vs asm", no "el C de
la libreria de Santi". Asi que yo me situo en el caso mas extremo que
conozco para poder evaluar un lenguaje que reclama ser "muy cercano"
al ensamblador en el caso Spectrum. Si no se hace asi, no se hace una
comparacion justa, y el ensamblador vuelve a ser el lenguaje para
gente con ganas de complicarse la vida. Pos nop.
No veo ningun sentido en decir "el C es suficientemente potente porque
serviria para hacer un Jumpin' Jack o un Manic Miner". :-/ Eso ya me
lo imagino.
>Dicho esto, si Santiago se
> aparece con un efecto Rainbow escrito en C, voy a tener que tragarme mis
> palabras...
Joer, pos imaginate yo :-)
> En definitiva, mi postura es un poco la de Santiago. Probemos el Z88dk, y si
> necesitamos alguna rutina que se sincronize con el barrido de pantalla y
> cosas así, se hace en ASM. ¿Para qué voy a arrancar haciendo el menú en ASM
> si no va a ser necesario?
Totalmente cierto.
Es tonto arañar ciclos al Z80 para programar un menu. Pero esto me
lleva a formular otra pregunta..
Imaginate que tienes un proyecto de los "complicados", y lo haces en C
con asm embedido (se dice asin? apuesto a que la proxima vez escribire
"embebido" para regocijo de los aqui presentes).. Si las partes
criticas, que son las que mas quebraderos de cabeza conllevan,
aceptamos que sean programadas en asm...
***que queda por hacer??***
No es una pregunta nada tonta, pensadla bien.
Vale, el juego no estara acabado, ok, pero si ya has sido capaz de
programar un sistema de sprites, que resulta que has tenido que
enlazar intimamente con el scroll y el volcado porque sino parpadea
todo.. y con todo el jaleo descubres muy contento que todavia queda
tiempo para sacar unos OUT's... de que te sirve ponerle un envoltorio
celofanoso de C?
Tu juego **ya estara hecho**, aunque no se pueda jugar. Y ademas no
estamos hablando de MEGAS de codigo imposibles de manejar. Tendrias
que teclear muchos meses para generar mas de 4 o 5K de codigo maquina
puro (que sea coherente, claro ;) )
Llegados a ese punto, no estoy muy seguro de que unas estructuras en C
puestas por encima de todo el nucleo vayan a facilitar la vida a
nadie. Si ya has llegado tan lejos, por que no rematar la faena en asm
y ya esta?
Alguien me quiere hacer creer que seria capaz de "embeder" (cada vez
me suena mas raro) una rutina de sprites a prueba de parpadeos en
ensamblador puro y al mismo tiempo recurrir al C para la "paja" porque
le resulta mas facil? Lo mas dificil ya estara hecho!
"Pero es que yo no tengo la necesidad de llegar tan lejos con el asm
en mi juego", podria decir alguien.
De acuerdo, seria una replica muy razonable y perfectamente valida.
Pero entonces ese juego jamas tendra triple scroll a 50fps con sonido
polifonico. Si tu juego no lo necesita, perfecto. Pero si lo necesita,
estaras en un serio apuro. Este es basicamente el razonamiento que he
intentado exponer aqui.
> Bueno, saludos a todos!! Que menudo susto me dí hoy luego de unos días de no
> poder ni mirar por arriba los posts y me encuentro con chiquicientos
> mensajes!! Por dónde empiezo!!!??
Si yo tuviese que leerme todo este super thread desde el principio...
uff que dolor de cabosia.. :)
True
Tony Brazil
> Haz un tap con bas2tap y grabalo para que haga run con un
> PRINT "BRUTAL CALCULATOR" y mandalo a la competicion del CSS.
Igual gana! XD
Un Saludo
T.BRazil
Tony Brazil
>ensamblador que genere el compilador de C será mejor que el del
>programador novato.
Eso me pasa por hablar de cosas que desconzco, perdon amigo! ;-)
Un saludo
T.BRazil
Siew
Yo personalmente creo que los lenguajes de alto nivel (C, BASIC..)
tienen mas sentido en la programación de los ordenadores actuales (no te
vas a poner a escrbir una aplicación de 'ventanucos' toda en
ensambladro, porque solo para mostrar una ventana ya serian lineas y
lineas). Sin embargo, en el caso de los ordenadores que estamos tratando
aqui (Spectrum, MSX, etc...) yo creo que tiene mas sentido el bajoi
nivel, sobre todo teniendo en cuenta cual va a ser el objetivo (juegos,
juegos, juegossssss...). Es decir, ningún tipo de lenguajes es mejor que
otro, simplemente que cada uno debe utilizarse para lo que sea mejor... no?
> Iván
Siew
Ya que has publicado tu codigo como GPL, he visto la posibilidad de
ampliarlo y mejorarlo... a ver que te parece:
10 INPUT A
20 INPUT B
30 PRINT A+B
40 GOTO 10
Por supuesto, publico mi nueva version como GPL, animando a todo el
mundo a que haga las modificaciones que considere oportunas,
>
>>S.T.A.R.
>>
>
> Pedrete
Kak
> Es decir, ningún tipo de lenguajes es mejor que
> otro, simplemente que cada uno debe utilizarse para lo que sea mejor... no?
eso es totalmente cierto, el problema es que "mejor" no es una medida
objetiva, con lo que unos pueden pensar que cierto lenguaje X en mejor
que Y en la situacion Z, y otros no :)
Siew
Claro, es que ademas de que cada lenguaje puede ser mas adecuado para
una determinada tarea, el que sea el mas adecuado es algo subjetivo... l
sea, q las peleas por ver que lenguaje es mejor son como guerras
religiosas (salvando las distancias)
Tony Brazil
> Pillin, te pille... ĄĄHereje del ASM!!! ĄĄQue le corten la
>cabeza!!! o mejor !! A la hogera!! X-DDDDDDDDDD
No, hombre no. Primero que nos pase el juego de la Ruleta rusa, despues
haced lo que querais XDDD (1)
(1) (Tbrazil haciendo un poco el interesado) copyright Ivan Ruiz. ;-)
Un Saludo
T.Brazil
Tony Brazil
>poder ni mirar por arriba los posts y me encuentro con chiquicientos
>mensajes!! Por dónde empiezo!!!??
Paciencia amigo! XDD. Por cierto, algo nuevo acerca de Gleck?
Un saludo
T.BRazil
z...@nil.fut.es
>> Ejque creome que lo de calidaz te lo has sacado del manga, quicir que
>> Santi no ha dicho en ningún momento (creome) que desee facer cualquiecosa
>> de calidaz, sinó simplemente facer cualquiecosa.
>Bueno, no se cuales son sus intenciones ultimisimas. Toda mi astuta
>argumentacion era en base al tema C vs ASM en general, sin personalizar en
>nadie. De hecho el caso particular del proyecto de Santi se perdio en el
>segundo o tercer post de este thread.
Hombres, sin entrar en proyectos personales, creome que se generalizaba en
todo momento sobre abastecer al vulgo de unos tutoriales y unas
documentaciones basadas en aprendizaje en C, aunque aluego de tantos
mensajiquis, creome que la resumancia es que la mayoría está de acuerdo en que
lo suyo es facerlo en ASM, porloqué todos los votos han sido a favor de que
Santi enfoque sus tutoriales a pogramar en ASM.
>Ya que estamos discutiendo si el C y el ASM son alternativas equivalentes en
>potencia, no tiene sentido hacerlo sobre la hipotesis de un Tetris o un
>Pograma de Quinielas ("bgue-nah suergh-teee!"). Por eso recalcaba lo del
>arcade de calidad, que es el unico banco de pruebas no-engañoso (en
>Spectrum, sobreentiéndese)
Y tal como apunté en su momento, el crear una cantera de pogramadores en ASM
se face que la calidaz vaya en aumento y no se quede en un punto muerto.
>> Hombres! ¿Por fin ha salido un juoco BUENO pa la LameBoy? ^c-
>Joder pos claro.
>A ver, er....
>um.
>NO.
¿Debo entender con aquesta negación que la creación de productos de media/baja
calidaz es inversamente proporcional al número de producciones buenas, con
una tendencia constante a cero? ^c-
>> JUAS! Que te crees tú que el sobre con Siete Sellos lo voy a tener debajo
>> la piltra!
>OK. Ya sabemos donde NO lo tiene. ¬_¬ <---(dijo él con mirada aviesa..)
Txs! Error! Ya sabeis donde no *LOS* tengui, que tengui el pack en casetese y
en disquetequese, porsideacaso, ya sabes. ^c-
--
S.T.A.R.
--
z...@nil.fut.es
>Ante todo decir que casi me da vergüenza escribir aquí, porque con la idea
>que tengo yo de programar en un Speccy, (los que hayáis visto mi Simulador
>de Vuelo lo sabréis, y si no,
>http://www.terra.es/personal5/akhorahil/fsim2001.TAP, y perdón por haberlo
>hecho X'DDD) pues como que tengo poco que aportar... Ah, y que todo esto, de
>buen rollo, no me vayáis a pegar... ;)
Pero tener en cuenta de que es un *SIMULADOR* (ejque yo no pillé a la primera.
=c=)
>Lo que quiero decir es que por un lado me parece bien que se esté haciendo
>un proyecto de programación del Speccy en C. Más cosas para el Spectrum, y
>quien sabe, a lo mejor puede resultar útil a alguien. (Aúpa, Santi)
>Por otro lado, lo que yo digo es que cuando yo haga un juego, lo que quiero
>hacer es aprender ASM, porque hace ya mucho tiempo que quiero aprender, y si
>en algún momento quiero hacer un juego bueno de cojones, (si soy capaz,
>visto lo de arriba) pues ya tardo para ponerme a aprender ASM... Lo que yo
>entiendo es que si el juego tiene que ser un juego en plan _profesional_, la
>única solución viable es en ASM...(Santi, si te decides a poner un curso de
>ASM en tu web, FANTÁSTICO!!! VA A SER TACO DE ÚTIL) (Aúpa, Santi... ) X'DDD
Suponome que a Santi le será como chungui mantener los dos tutoriales, por
razones obvias, porloqué creome que debería decantarse por uno por el otro, y
videadas las respuestas, el tutorial de ASM tiene mucha más aceptación y de
una forma más festiva.
Aupa, Santi, ASM YA! ^c-
>Yo entiendo que la cuestión es el contexto. Todo dependerá de las
>intenciones de quien haga el juego. Creo recordar que algunos juegos, a mi
>entender, buenos, se han hecho en Speccy con compiladores, como el
>Profanation - sí, vale, es un ejemplo antiguo... Cierto es también que para
>hacer un juego en plan "obra de arte", no te vale un compilador, por bueno
>que sea, porque por lo que leo ya hay que recurrir a ASM, y no sólo eso,
>sino que hay que dominar el ASM, controlar los tiempos de ejecución de las
>instrucciones, y eso implica que no siempre lo más evidente, o lo más
>"lógico" o lo más "de libro" es lo más correcto.
Ejque si uno tiene amor propio a la hora de pogramar, querrá obtener
resultados óptimos, facer cosas que tal vez el C no le permiten y que en ASM
sip, porloqué el sentido común nos dice que lo melchor es que aquel que tenga
amor propio y no quiera quedarse a medio camino ya dará por sentado facerlo en
ASM, digo yo.
>A lo que voy, si aquí estamos todos es para divertirnos, en el momento que
>uno no se divierte, pues no mola. Así que si uno hace un juego en ASM y hace
>una obra maestra, porque él disfruta así, pues bienvenido sea, y gracias por
>su aportación. Y si otro hace un juego más modesto, pero la gente se lo pasa
>bien jugando, y no tiene las pretensiones de hacer el mejor juego,
>técnicamente hablando, pues está bien.
Pero, y ojalá no pase, aluego entrar las odiosas COMPARACIONES. Quicir que un
juoco puede despertar simpatías entre los users aunque esté pogramado en
BASIC, pero no creo que los juocos aquestos sean prueba de que el mundillo se
mueve, sinó que simplemente se agita. Está claro que a todos los que estais
escribiendo se os ha subido la bilirrubina y fijo que cadascuno tiene en mente
ESE juoco que cadacuno siempre ha querido facer, y os dais cuenta de que el
estado de las cosas se balancea a favor de que la cosa vaya a buen puerto y
fijo que más de uno ya se ha bajado del WOS el Gens. ^c^
>En definitiva, que puede haber gente a la que no le apetezca aprender ASM
>hasta el punto de dominarlo, pero tenga ganas de hacer un jueguecillo, ya
>sea para jugar con sus amiguetes en su casa, o para ponerlo en la web y
>decir "mira qué juego he hecho, aunque no tenga triple scroll ni sonido a 3
>canales está divertido". Y habrá gente a la que le guste estrujar la máquina
>hasta el límite.
Ya digo, ojalá nunca pase, pero se tiende a llegar a las comparaciones, y un
juoco que es diver pero malillo siempre tendrá ese sanbenito de que podría ser
igual de diver pero mucho menos malillo si se hubiera pogramado en otro
lenguaje, ejemplarmente.
>Está claro que a una máquina la levantan los users. La idea es que cada uno
>haga lo que pueda, eso sí, intentándolo hacer lo mejor posible.
Pero que conste que el simple fecho de facer cualquiecosa NO significa que sea
favorable pa la comunidad. Que un pavo de monte sus cederrones cutres de
juocos de SNK pos como que no me parece un algo muy favorable.
>Dicho esto, que aquí cada uno que programe como quiera, siempre y cuando no
>atente contra la cordura de la gente... (um, dicho esto, yo no debería
>programar X'DDD).
Yo me remito a lo de que cada zapatero se dedique a sus zapatos.
--
S.T.A.R.
--
z...@nil.fut.es
>Lo ideal claro esta es que salieran juegos nuevos a un gran nivel, pero
>como bien dices el contexto es lo que importa y las pretensiones con que lo
>haces. Si Santi o cualquier hace un juego y no usa ASM,etc... pero el
>tampoco lo anuncia como una maravilla ni lo vende en ningun casi creo que
>este haciendo daño al sistema. Otra cosa es el caso del MSX que te venden
>juegos en Basic como si fueran juegazos (Nuts por ejemplo).
Bonito ejemplo el del Nuts. ^c-
Pon que te viniera un coleguita mesequisero la mar de contento y te enseñase
un juoco en BASIC. Tú que videas el mesequix DESDE FUERA ¿qué piensarías? ¿Que
el mesequix tiene una escena que se mueve o que son como un poco pardillos por
facer juocos en BASIC y que amasamás los venden?
>>bien jugando, y no tiene las pretensiones de hacer el mejor juego,
>>técnicamente hablando, pues está bien.
>No tiene porque hacer daños al sistema, peores bodrios se hicieron en su
>momento XDDDDD (uchi mata,etc... y estos eran comerciales).
Ya sabes que nosotros estuvimos en el Sonimag y en BCN Videojuoco. Tendrías
que videar las caras de la peña al videar juocos MALOS de face años y juocos
MALOS de ahora. A la peña normal se le face RARO que en el siglo XXI se fagan
cosas PEORES que face una década, y que encima se enseñen cosas viejas pa
atraer a la peña. Quicir que no es lógico que con los medios que tenemos ahora
y con el tempo que ha pasado, suficiente como pa aprender de los errores, se
fagan cosas peores que antes.
--
S.T.A.R.
--
z...@nil.fut.es
>> [] Rodorón. Lo encontraron en la calle (literalmente), lo adoptaron
>> y se entretiene faciendo robotijos controlados por pecera.
>Este personaje tiene pagina web?
Pos nop, pero en www.matranet.net en la sección de afotos puedes videar su
robotijo en acción.
La penitapena ejque yo fui el único que le felicitó efusivamente. Claro, como
su robotijo no se enchufa a un mesequix... =c=
>mmm... a ver si lo entiendo... si tanta gente defiende el basic es q es
>weno, no? XDDDDD (notese la ironia del comentario)
Pos fora coñas, el BASIC de mesequix es potentillo, pero no pa facer juocos,
sinó pa aprender y facer utilidades sencillas. Pa facer un juoco tipo
Beatmania pos pienso de que el BASIC de mesequix sirve pero pa facer un double
Dragon pos como que se queda corto.
--
S.T.A.R.
--
z...@nil.fut.es
>Menuda cuadrilla de freakies. Pero en el tema del BASIC,
>avore, :), esta bien empezar con el BASIC, diría que el
>ASM es muy espeso sin tener nociones de lenguaje de alto
>nivel, pero me cuesta entender la obcecación con el BASIC,
>el MSX, como el resto de las máquinas, lo acaban traduciendo
>a lenguaje máquina y está claro que nosotros (los humanos)
>vamos a optimizar más el código que unos algoritmos de
>compilación o interpretación, estas técnicas tienen muchas
>limitaciones... pero si encima de obcecarte, insultas, oiga que
>se fumen un porro :)
Pa que no me tachen de resentido o antimesequisero, pos el próximo día 4 de
diciembre se organiza la próxima rugresca de la AAM y os emplazo a que acudais
a pegarle un vistazo. No os invito porcuá cobran entrada. ^c-
Podeis videar todo lo que se presentará (que no es gran cosa, cierto) pero al
menos podreis comprobar en directo lo que os digo y que cadascuno se faga su
opinancia. Solamente os pido que lo videeis como lo que es, que es un ordenata
al que se le puede sacar mucho partido pero con el BASIC la cosa se queda como
anécdota, descirtúa por completo lo que es la máquina. Que no os sorprenda lo
que videeis, sinó que compareis los resultados obtenidos con los que se
podrían/deberían obtener, y transbordar eso con el Speccy, salvaguardando las
specs de cada máquina claro.
Más info en el site oficial de la AAM [http://www.aamsx.com] o en el site
oficioso (que no tiene NINGUNA relación con la AAM) [http://www.aamsx.org]
>Me ha molao tu descripción
Uno face lo que puede, gelipolladas. ^c-
--
S.T.A.R.
--
z...@nil.fut.es
>>Yo pienso en lo de zapatero a tus zapatos y si uno pograma juocos es, uno,
>>porcuá le omola, dos, sabe pogramar, tres, tiene talento pa ello. No hay
>>ninguna prisa pa que uno AHORA se ponga a pogramar un juoco, y más si se
>>trata de una máquina como el Speccy, y que si a todas luces en Speccy es
>>mucho melchor el ASM, pos como no hay prisas, uno se puede divertir
>>aprendiendo ensamblador pa obtener unos resultados óptimos y quedar como un
>>señor y no como uno que ha fecho un algo por facer algo en pro del Speccy.
> Bueno... Depende de lo que uno quiera hacer... Por ejemplo, si
>siempre vas a ordenar 10 numeros ¿Para que vas a implementar el heap
>sort que es mucho mas dificil pero el mas eficiente si en un plis-plas
>puedes implementar el burbuja? Con 10 elementos ambos tardan lo mismo
>¿Para que vas a programar en ASM si en C vas a producir un resultado
>dentro de unos margenes aceptables?
Sip, si tienes razón, te comprendo, pero yo te pongo de ejemplo lo de los tíos
que facen cederrones a saco, que porcuá pasarlos a TAP o TZX si con Z80 o SNA
ya rulan. El resultado es aceptable, depende del amor propio y del respeto a
los demás.
>>Quicir que si faces un juoco en C pero mantienes que en ASM podría estar
>>melchor, y al mesmo tempo sabes ASM, pos como que la cosa no me casa, nosé.
>>Si
> Hablaba de programar en C en vez de ASM si la calidad del
>producto no se ve degradada o apenas se nota... Nadie quiere hacer
>algo malo. Nadie esta hablando de crear juegos que van a saltos.
Pos entonces me remito a los mensajiquis de TrueVideo, pa no repetirnos.
>>Pero yo mesmo (sin querer joder la marrana) te podría decir que, ya que
>>sabes ASM, ¿porcuá no has fecho ese mesmo juoco en ASM, que te irá mucho más
>>rápido y fonará más eficientemente? ¿Por falta de tempo? ¿Qué prisa tienes?
>>Como pogramador debes tener tu pofesionalidaz y suponome que preferirás
>>CALIDAD antes que RAPIDEZ.
> Calidad no es igual a velocidad el programa. El uchi mata por
>muy rapido que vaya es el uchi mata. La calidad en un juego puede ser,
>que el movimiento sea correcto (no tiene pq ser el mas rapido), que
>tenga una dificultad equilibrada ... Si algo se necesita hacer en
>ensamblador. ¡Ok! Pero si no es necesario ¿Por cua?
No hombres, digo RAPIDEZ, no VELOCIDAZ. ^c-
Decía que un pogramador debe tener su pofesionalidaz y suponome que prefiere
calidaz antes que rapidez a la hora de obtener resultados. Vamos, que prefiero
tardar 10 horas en obtener un algo de calidaz que tardar 10 minutos y obtener
algo de menos calidaz.
Y lo que no es necesario el ASM, obviosamente no es necesario en todos los
casos. Ya lo decía, si pa facer una calculadora fona igual en BASIC que en
ASM, pos como que no vale la pena facerla en ASM, pero el meollo no está en
obtener resultados inmediatos o a corto plazo, sinó en invertir nuestro tempo
en que a medio/largo plazo seamos capaces y podamos facer cosas que en BASIC
se nos quedarían cortas. Inversión de futuro, vamos.
--
S.T.A.R.
--
Tony Brazil
>¿Que el mesequix tiene una escena que se mueve o que son como un poco
>pardillos por facer juocos en BASIC y que amasamás los venden?
Lo triste es que hay gente que no saben de Basic de MSX y pueden ver el
juego en un turbo-r o similar y ver que va rapido. Por tanto pensar que el
juegos es en ASM y que esta bien. Z-0 me comentó que el Nuts era un juego en
Basic y yo, desde fuera del MSX, me quede sorprendido. Claro, el basic de
Spectrum no puedes hacer cosas asi (creo). Osea que pueden timar y timan!.
>Quicir que no es lógico que con los medios que tenemos ahora y con el tempo
>que ha pasado, suficiente como pa aprender de los errores, se fagan cosas
>peores que antes.
Es que visto de ese modo es totalmente lógico y es para criticarlo.
Un saludo
T.BRazil
Siew
Te lo comentaba porque a mi la robotica me interesa bastante, y queria
saber si tenia algo de docs o algo asi... pero siempre mola tb ver los
robotitos de los demas en accion :)
>
> --
>
> S.T.A.R.
>
> --
z...@nil.fut.es
>>¿Que el mesequix tiene una escena que se mueve o que son como un poco
>>pardillos por facer juocos en BASIC y que amasamás los venden?
>Lo triste es que hay gente que no saben de Basic de MSX y pueden ver el
>juego en un turbo-r o similar y ver que va rapido. Por tanto pensar que el
>juegos es en ASM y que esta bien. Z-0 me comentó que el Nuts era un juego en
>Basic y yo, desde fuera del MSX, me quede sorprendido. Claro, el basic de
>Spectrum no puedes hacer cosas asi (creo). Osea que pueden timar y timan!.
Hombres, cabría esperar que si uno videa ahora, queseyó, la peli de Star Wars
pos como sabe cuando sale una maqueta o un monigote y a uno casi le entra la
risa floja si NO la videa como lo que es, una peli de los 70's, que no había
tantos medios como los de ahora. Pos suponome que cabría esperar lo mesmo de
los videojuocos, que si uno videa que face pampallugas o que se relantiza y
amasamás sobre una maquinorra que uno sabe que casi que está diseñada pa que
esas cosas no pasen, pos como que el que se deja timar es porcuá quiere.
>>Quicir que no es lógico que con los medios que tenemos ahora y con el tempo
>>que ha pasado, suficiente como pa aprender de los errores, se fagan cosas
>>peores que antes.
>Es que visto de ese modo es totalmente lógico y es para criticarlo.
¿Es que se puede videar de otra forma? OcO
--
S.T.A.R.
--
Tony Brazil
>esas cosas no pasen, pos como que el que se deja timar es porcuá quiere.
Aunque primero tendrias que saber si la maquina donde se ejecuta es una
maquinorra o no , que no siempre lo sabras si no estas al tanto del
mundillo.
>¿Es que se puede videar de otra forma? OcO
Sinceramente........ NO XDDDD
Un Saludo
T.BRaZIL