Propuesta: QL, Cuaderno de Programación.

[afx]

A colación de los “trozos” de código que se van publicando en el foro, por ejemplo el post superinteresante del tratamiento de imágenes en el Ql en uno de los post de badaman, me ha venido a la mente una idea (que no es original, la he visto en otros sitios Web) para poco a poco ir organizando ese material y que esas aportaciones valiosísimas no queden repartidas por diferentes post en el foro o en otros sitios de forma dispersa.

Después de todo uno va aprendiendo programación con la lectura de algunos libros y manuales, pero sobre todo de ir “copiando” (perdón … tomando prestado ) cosas de aquí y de allá.

Bueno, la propuesta es la siguiente:

La creación en sinclairQL.es una sección que podría llamarse “Cuaderno de programación”. Esa sección podría estar organizada por leguajes y dentro de ellos por secciones temáticas por ejemplo:

SuperBasic
- Lenguaje
- Gráficos
- Ficheros
- Sonido
- Imágenes

C68
- Leguaje
- E/S
- QDos

Ensamblador
- Pantalla
- ...
- ...

(La organización es sólo un ejemplo, puede ser cualquier otra).

Dentro de cada sección podríamos ir poniendo diferentes “recortes” de código comentado, a modo de programillas cortos de ejemplo, rutinas, estrategias para abordar problema, algoritmos clásicos, etc. Se debería poner de tal forma que sea fácil cortar y pegar y a ser posible con un buscador dentro de la propia sección.

Se que para badaman es un curro, pero es algo que se podría hacer despacio y sin grandes pretensiones. Creo que con la colaboración de todos y poco a poco se podría construir un repositorio de código interesante. Por mi parte podría colaborar con algunas cosillas en C68 y podría aportar algo en SuperBasic. También en las revistas CUQ y Qlipper hay cosas muy curiosas que se podrían rescatar y tener mejor organizadas (ahora es un material oscuro en ficheros .zip).

¿Cómo lo ven?.

Saludos,
afx.

[badaman]

Para lo que propones hay dos formas de hacerlo:

1.- La profesional, sería cuestión de crear in Wiki y empezar a trabajar de forma coordinada.

2.- La cutre pero efectiva y menos costosa, aunque más trabajosa, que es la que yo vengo utilizando.

Esto ultimo lo hago de la siguiente manera:

Si hay un artículo, una reseña en prensa, o una actividad relacionada con el QL lo reflejo en:

Recursos > Noticias
en
Recursos > QLInEx!
o en
Publicado > Artículos

Si lo que hay es un texto que no llega a ser un manual, pero que merece la pena rescatar, lo reflejo en:

Utilidades > Documentos

(Esto es un poco la idea que dices)

Y si el texto es un manual en toda regla, pues a manuales que va.

No se me ha ocurrido rescatar el texto del volcado de patalla, pero ahora que lo dices prepararé algo estos días para subirlo a la web. Lástima no contar con una rutina en C/M para hacer el volcado a pantalla.

Desde luego cualquier colaboración es bienvenida, y cualquier cosa con suficiente interés que se quiera publicar tan sólo ha de enviárseme en un formato de texto estándar y con las fotos necesarias y yo prepararé un HTML para enlazarlo al resto de documentos.

Así que ya sabes. Cuando termines el osusq, si te animas, me pasas algún artículo o reseña y lo publicamos en sinclairql.es en documentos.

Espero que esto esté en la línea de lo que decías.

Saludos

[radastan]

No se me ha ocurrido rescatar el texto del volcado de patalla, pero ahora que lo dices prepararé algo estos días para subirlo a la web. Lástima no contar con una rutina en C/M para hacer el volcado a pantalla.

Estoy en ello, la rutina de sprites que estoy preparando vale también para esto.

[badaman]

Si lo ves viable, ¿podrías hacer una rutina en C/M que hiciese lo mismo que el procedure volcar?

Una rutina a la que se le pasase los 5 parámetros de volcar y ejecutase las operaciones oportunas.

No tendría que ser todo lo que aparece en el procedure, sólo los dos bucles para pintar linea a línea.

Saludos.

[radastan]

Si lo ves viable, ¿podrías hacer una rutina en C/M que hiciese lo mismo que el procedure volcar?

Una rutina a la que se le pasase los 5 parámetros de volcar y ejecutase las operaciones oportunas.

No tendría que ser todo lo que aparece en el procedure, sólo los dos bucles para pintar linea a línea.

Saludos.

Es que el procedimiento que dices es... dibujar un sprite previamente cargado en memoria, nada más. Es decir, justo lo que estoy programando.

[badaman]

Es que el procedimiento que dices es... dibujar un sprite previamente cargado en memoria, nada más. Es decir, justo lo que estoy programando.

Entiendo. Te explico el porqué de la petición.

Si bien, grosso modo, las rutinas que estás preparando hacen lo mismo que yo pido, tu código es mucho más amplio y menos específico. En él soportarás máscaras, lecturas de fondos de pantalla, rotación de bytes...

La idea es poner, junto con el código en SuperBASIC que mostré en el hilo del osusq, unas pocas líneas que sean su correspondiente en C/M y que sirvan como introducción y aprendizaje.

Con esta base no sólo se entenderá mejor tus nuevas rutinas para Sprites, sino que se animará a los que lean el hilo o el documento en la web a inciarse poco a poco en esto de acceder a la pantalla.

Y de paso le resolvemos el volcado rápido al juego.

[radastan]

Es que el procedimiento que dices es... dibujar un sprite previamente cargado en memoria, nada más. Es decir, justo lo que estoy programando.

Si bien, grosso modo, las rutinas que estás preparando hacen lo mismo que yo pido, tu código es mucho más amplio y menos específico. En él soportarás máscaras, lecturas de fondos de pantalla, rotación de bytes...

¿Y si te digo que todo eso en un 68008 es una pollada? es que no sabes lo que cambia el cuento respecto a un ZX Spectrum, es la mar de fácil, y la rutina tampoco creas que va a ser super extensa, entiende que colocar una máscara aprovecha las mismas subrutinas que la de poner un sprite, sólo cambian unas cuantas líneas.

De todas formas te pasaré una rutina de sprites sin máscara supersimple.

[sejuan]

Ondia que guapo. Así lo mismo nos dá el venaso y le metemos mano al Ql, que ya toca ya!

[afx]

Si lo que hay es un texto que no llega a ser un manual, pero que merece la pena rescatar, lo reflejo en:
Utilidades > Documentos
(Esto es un poco la idea que dices)

Si, es más o menos lo que digo. Concretamente: la sección Utilidades > Documentos > Programación ¿no podría estar a más alto nivel para no profundizar tanto en el árbol de navegación? (tal vez desde el menú principal). ¿Y dentro de "Programación" no se podría incluir temáticas concretas (por lenguajes, por temas, ... ) aglutinando en ellas lo que ahora está disperso por otras secciones?. Así todo lo referente a programación estaría de un nivel hacia abajo.

A lo mejor es mucho curro y no merece la pena, ... pero bueno, ahí queda la propuesta.

Saludos.