Flood Fill en ensamblador.

[sromero]

En un Spectrum no se puede renegar ni de goto ni de break, porque son lo más parecido que hay a las instrucciones de salto en estos lenguaje de alto nivel. Vamos, que no suponen ninguna amenaza al código porque el código en el Spectrum no es de cientos de miles de líneas como en aplicaciones actuales.

De todas formas, yo sí que sustituiría ese switch/case por ifs poniendo como primera condición aquella que tenga más probabilidades suceder (para que no se ejecute el salto).

[sromero]

El algoritmo es una chorrez, no tiene nada. Todo está en splib2/graphics.h:

Código: Seleccionar todo

      cmd = (*address_ptr);
      address_ptr++;
      x = (*address_ptr);
      address_ptr++;
      y = (*address_ptr);
      address_ptr++;
      ex = (*address_ptr);
      address_ptr++;

Eso debería ser equivalente a esto:

Código: Seleccionar todo

      cmd = *address_ptr++;
      x = *address_ptr++;
      y = *address_ptr++;
      ex = *address_ptr++;

++(expresión) realiza primero el incremento y luego evalúa la expresión.

(expresión)++ evalúa primero la expresión y luego realiza el incremento (que es lo que tú quieres).

Ya sé que es una parida, pero es más legible y quitas 4 líneas de código. Ojo, el código binario resultante será el mismo, pero para mí que sea más legible es importante (sobre todo a la hora de buscar bugs). La verdad es que soy bastante pejillero en temas de formato, el ASM siempre lo tabulo igual, me mata ver una instrucción así "LD A, 10" y otra en el mismo fichero así: "LD <tabulador> A, 10", o lo pongo todo de la misma forma, o me pongo enfermo X-D

Faltan las definiciones de los UDG para los rellenos. De todos modos en cuanto tenga esto listo lo colgaré todo de mi blog, hasta el módulo este por separado con un pequeño editor cutre por si la gente lo quiere usar para hacerse sus aventurillas

Avisa poniendo un post en este foro cuando lo cuelgues, me gustaría leerlo

[Gandulf]

Joer, el pobre Na_th_an pega un trozo de código para que veamos como es la rutina y ya lo estás corrigiendo (ya se que es de buen rollo, es broma). Me imagino que él sabe perfectamente como hacerlo mejor, pero será el típico código chorras que pones sin romperte la cabeza.

[na_th_an]

Y yo que lo puse así precísamente para que fuera más legible Cada uno vemos la legibilidad de forma diferente (normalmente yo soy de los que meten todos los gurruños de operaciones en la misma linea).

[Gandulf]

Hombre, es que legible es más legible el código de na_th_an. Meterlo todo en la misma línea es más "ofuscado".

[sromero]

Gandulf, para nada creo que se haya ofendido, si precisamente he hablado varias veces en privado con na_th_an acerca de Z88DK y Spectrum y él sabe que siempre le pego un vistazo al código fuente de sus juegos en busca de aprender cosas...

na_th_an: Yo soy de los que, cuantas menos líneas y más concisas (ojo, y no me refiero a unir líneas con puntos y coma X-D), mejor. Supongo que, como le ha dicho a Gandulf, no te ha molestado. Es más, seguro que ya sabías lo que he puesto, pero bueno, me gusta soltar las cosas al aire, tú lo sabías pero igual otro que lea los foros, no. De eso tratan los foros.

Y tenéis todos, por mi parte, la total libertad para corregirme siempre que lo consideréis oportuno, que ocasiones no os faltarán X-D

[mcleod_ideafix]

[OffTopic mayúsculo]
Cuidado no te vaya a venir un "ingeniero de software" o "consultor" a decir que los Breaks son instrucción indeseada , a mi particularmente me encanta y hago bastante uso de ella
[/OffTopic mayúsculo]

Ningún ingeniero de software sin comillas te podrá decir que el break es instrucción indeseada, sobre todo cuando lo que se programa es en lo que se denomina "C de sistemas" (que es el tipo de C que se usa en programación de pequeños micros).
En cuanto al goto... el kérnel de Linux tiene bastantes (y breaks, muchos más)... me remito a lo que acabo de decir...
Cuando les explico algorítmica a los chicos, una de las primeras cosas que les explico es que los programas (el algoritmo) deben ser correctos, robustos y elegantes, por este orden. Correcto significa que el programa debe dar la respuesta correcta cuando los datos de entrada son los adecuados. Robusto significa que el algoritmo debe ser capaz de hacer frente a entradas de datos no contempladas, y elegante significa que el código fuente debe ser fácil de leer y su lógica entendible "en un golpe de vista".
Ejemplo:

Código: Seleccionar todo

enc1=0;
for (i=0;i<N && !enc1;i++)
{
  proceso
  proceso
  if (pasa algo)
    enc1=1;
  else
  {
     mas proceso
     mas proceso
  }
}
if (enc1)
{
  i--;
  proceso si pasó algo en la iteracion i-esima
}

Código: Seleccionar todo

for (i=0;i<N;i++)
{
  proceso
  proceso
  if (pasa algo)
    break;
  mas proceso
  mas proceso
}
if (i<N)
  proceso si pasó algo en la iteracion i-esima

Otra cosa que me gusta es usar returns en medio de un código, así en lugar de hacer esto...

Código: Seleccionar todo

int funcion (argumentos y eso)
{
  int res,error;

  res=hago_algo(...);
  if (res)
  {
     proceso;
     res=hago_otra_cosa(...);
     if (res)
     {
        proceso;
        res=hago_otra_mas(...);
        if (res)
        {
           proceso;
           error=0;
        }
        else
          error=3;
     }
     else
       error=2;
  }
  else
    error=1;

  return error;
}

Puedo hacer esto...

Código: Seleccionar todo

int funcion (argumentos y eso)
{
  res=hago_algo(...);
  if (!res)
    return 1;

  proceso;
  res=hago_otra_cosa(...);
  if (!res)
    return 2;

  proceso;
  res=hago_otra_mas(...);
  if (!res)
     return 3;

  proceso;
  return 0;
}

[sromero]

Hombre, es que legible es más legible el código de na_th_an. Meterlo todo en la misma línea es más "ofuscado".

Para un programador en C, no *debería*. Precisamente por eso existen los operadores de pre y postincremento ++(expr) y (expr)++.

De todas formas, no quiero convertir el hilo en una discusión sobre Formatting Rules X-D, ya dejo el tema X-D

PD: lo prometo, lo dejo X-D

[na_th_an]

En absoluto me ha molestao, sólo me ha hecho gracia porque yo soy un "gurruñero" a veces metiendo mil cosas en una instrucción y esta vez lo he partío para que se entendiera mejor

Nah, a mí me encantaría hablar de formatting rules porque yo también soy un friki de la indentación y esas zapatiestas. De hecho, en el curro, siempre que tengo que tocar código de otros, o me bajo un embellecedor o soy incapaz de tocarlo.

[TrueVideo]

De hecho, en el curro, siempre que tengo que tocar código de otros, o me bajo un embellecedor o soy incapaz de tocarlo.

Yo también he pasado por eso, pero acabé por dejar de hacerlo. Me ponía de mal humor y además los autores originales al ver su código reformateado me miraban raro. Pero es que se ve cada cosa...

[na_th_an]

Pues sí. Sobre todo porque cuando trabajas en un código fuente en tu ordenador usando emacs, luego lo subes y lo toca otro con el vim, luego llego yo y lo edito con el joe, luego se lo bajan en windows y lo tocan con el JEdit o el Eclipse en Ubuntu... Al final hay una tortilla de tabs y espacios que no es normal

[sromero]

¿otro fan del Joe?

Mi jefe se mosquea muchísimo cuando entra en un server UNIX/Linux y no le hemos instalado el Joe, aquí somos todos fanáticos del Vim, pero a muerte (imbatible!), y el emacs no lo instalamos ni aunque lo pida un cliente X-D

[na_th_an]

Sí, conozco estas frikeces

Yo uso el Joe porque vengo de MSDOS y el editor se maneja igual que el entorno del viejo Turbo C de Borland. Además es muy potente (al menos lo suficiente).

El vim lo considero un atraso padre por su manejo coñazo. Vale que a tí y a muchos os guste, pero me tienes que admitir que de entrada es un coñazo.

El emacs lo usé en la facultad en las asignaturas de Inteligencia Artificial y adláteres, porque los del departamento de CCIA tenían todos los intérpretes (lisp, prolog, clips, scheme...) integraos y era lo más cómodo editar en el buffer superior y ejecutar en el inferior sin tener que hacer nada más.

Supongo que cada uno tendrá lo suyo, pero yo soy de Joe. Se instala en 2 minutos y no jode.

[sromero]

El vim lo considero un atraso padre por su manejo coñazo. Vale que a tí y a muchos os guste, pero me tienes que admitir que de entrada es un coñazo.

Date una oportunidad con él y fliparás.

Estar con el cursor en el interior del "(" (o sobre él) de :

char funcion( char param1, int param2, char *cadena, blahhh )

Y teclear "df(" y quedarte con "char funcion( )" directamente, sin tener que ir borrando uno a uno los parámetros, no tiene precio. Para mí vim aumenta la productividad editando textos brutalmente.

O querer borrar 10 palabras haciendo 10dw, o copiar un bloque y pegarlo 5 veces con 5p, ponerse sobre un paréntesis, llave o corchete y pulsar '%' para que te diga el que lo abre o el que lo cierra o comentar un bloque de código entero con una sóla tecla y que te comente todo el bloque sin tener que ir línea a línea ... no tiene precio.

O, por ejemplo, poner MARCAS en el documento con la tecla 'm' en modo comando seguido de un caracter para la marca (ejemplo: teclear "ma" genera la marca a) para poder volver a ese punto del documento cuando queramos con comilla + a... cambiar una seleccion entre mayusculas o minusculas con una sola tecla (lo que me viene muy bien para homogeneizar listados ASM), etc.

http://www.sromero.org/linux/vim/Manual_VIM.html
http://www.sromero.org/linux/vim/Manual_VIM.pdf

(El tutorial es mío).

saludos.

[Gandulf]

Yo he probado los 3. Emacs, Vim y Joe. De esos 3 me quedo sin duda con Joe.

Pero en realidad no me quedo con ninguno. Los 3 apestan