Pues sí, señores. Empiezan las rebajas de verano.

Ahora que parece que el tema de portabilidad del asMSX se ha resuelto felizmente o casi (falta hacer más pruebas y quiero conseguir que funcione en Mac), les ofrezco a los usuarios del susodicho que pidan por sus respectivas boquitas lo que consideren que debería añadirse al ensamblador. Así tal cual, a medida. Se trata de "fidelizar" a los consumidores habituales para que asMSX sea cada vez más útil y potente.

En mi wishlist privado está lo siguiente:

- Versión para Mac
- Completar la documentación y traducirla al inglés (distribución bilingüe)
- Aportar más ejemplos de programas un poco más "densos" que el PONG y el MINESWEEPER
- Actualizar las herramientas de apoyo: RLEPACK sux, MSXWAV sux y PCX2MSX ultra-sux
- Incorporar las sugerencias / correcciones que se os ocurran

Ojo. Lo que me planteo es que las herramientas tipo MSXWAV y PCX2MSX queden de algún modo integradas dentro del asMSX para que pueda funcionar de forma autónoma. De hecho, parte de la funcionalidad del MSXWAV ya se ha integrado con las directivas WAV y CAS. Ahora faltaría crear el INCGFX o algo así para incorporar gráficos, pero puede ser un lío de cuidado... Me gusta el formato PNG, pero es demasiado complejo. Probablemente opte por TGA en True-Color a 24-bits, con conversión directa, con y sin dithering.

Lo dejo en vuestras manos: sugerid de forma razonada que habría que incluir o modificar. Si tenéis bug-reports, también los agradecería, dado que se perdió en el último bajonazo del foro el hilo donde se discutían estas cosillas, y no sé si quedó algo pendiente de corregir.

Por supuesto, que quede claro el objetivo del asMSX: un ensamblador específico para la programación para MSX, especialmente dedicado a la creación de video-juegos.

El PCX2MSX hace su trabajo, pero es muy limitado. Por mi parte, la funcionalidad que me gustar'ia darle es la siguiente:

- Conversi'on autom'atica de colores, con y sin dithering, desde 24bpp
- Conversi'on monocroma forzada
- Selecci'on de un 'unico color para importar sprites multiplano
- Selecci'on de "ventanas" a importar dentro del gr'afico total
- Optimizaci'on, en el sentido de eliminar los tiles repetidos y generar, por tanto, tambi'en una tabla de nombres para reconstruir el gr'afico original

Todas estas cosas, que he venido usando en mis propias producciones, las he hecho siempre "on-the-fly" con mini-aplicaciones en C programadas al efecto. Va siendo hora de juntarlo todo y tirar adelante.

En cuanto a mis dudas respecto del formato PCX, el principal inconveniente que le veo es que el Photoshop se obstina en hacerlo "al reve's" que el resto de programas. Por eso le tengo alguna man'ia...

Por mi parte, encantado, aunque dudo que pueda ocuparme del mantenimiento. En principio, todo lo que deber'ias tener para ser capaz de compilarlo en Amiga ser'ia una versi'on actual del GCC (3 o 4 valen), Flex y Bison. Con eso y un bizcocho, deber'ia funcionar. Un Make tambi'en ayudar'ia, claro...

En cuanto tenga la distro cerrada, te lo paso para que juguet'ees todo lo que quieras.

A mi se me ocurre meter la pseudo instruccion  REPEAT , aunque ahora no recuerdo si esta implementada.
Para el tema de la optimizacion de tiles yo uso unas herramientas al efecto que encontre en la pagina de retroespec en la seccion de utilidades.
No recuerdo el nombre ahora.
Pesonalmente prefiero las utilidades separadas del ensamblador como hasta ahora.

Nada mas.

Eso puede ser práctico. Este tipo de cosas las hago ahoracon un ".bat", donde llamo a PCX2MSX, bitbuster, ... y al asMSX

De todas formas, no se hasta que punto mi opinión es "relevante": sólo he usado asMSX. La gente que haya trabajado con otros ensambladores podrá comentarte más cosillas.

Un saludo

Recojo el guante como usuario habitual del asMSX y voy a intentar aportar mi granito de arena en este interesante debate.

Respecto a lo de herramientas integradas si o no, personalmente me da igual. Nada veo de malo en que estén integradas, si se quiere se usan y si no, pues no.


Y respecto a aportaciones, yo soy de la opinión de que en los tiempos que corren no deberíamos conformarnos con un ensamblador a la antigua usanza. Me explico, a mi me vendría de perlas por ejemplo funciones integradas, a modo de “print(puntero a texto)”  para imprimir mensajes en pantalla  o “print(score)” para imprimir marcadores. También tipo “put_sprite”, “define_sprite”, “pon color”. etc, etc. Dónde el ensamblador incluiría el código correspondiente, algo parecido a lo que se hace con la directiva .SEARCH.

Si esto no fuera posible, propongo que el ensamblador se distribuya con una serie de funciones útiles para los programadores. A modo de biblioteca de funciones.

Incluso si me apuras, para agilizar la programación para los que como yo no disponen de tiempo libre de forma continua, incluiría instrucciones condicionales tipo “if registro n> registro m then JP etiqueta” o para los amantes del C “if (HL<BC) ….”. Por supuesto si se incluye condiciones complejas tipo “or” y “and” ya sería perfecto.

Aunque pueda parecer un giro hacia los lenguajes de alto nivel, lo que planteo en realidad es que se podrían incluir MACROS a nivel de ensamblador para aquellas tareas que son habituales, y que en general suelen ser sencillas de programar. Combinando el ensamblador puro y duro con macros predefinidas para aquellas tareas rutinarias que no precisen de un grado elevado de optimización.
 
Y el que quiera que las use y el que no pues no.

Esta es mi propuesta-opinión respecto al ensamblador asMSX.

Como programador tanto de juegos MSX como de compiladores, opino que cuanto más compleja sea una herramienta más susceptible de que surjan errores inesperados. Abogo por herramientas simples, más sencillas de mantener.

Buenas,

Aprovecho este hilo (aunque un poco tarde) para proponer un par de mejoras para el asMSX:

Hace una semana rescate uno de mis antiguos sources que programe con el Ensamblador COMPASS. (haca ya 7 años)

Lo he estado adaptando al asMSX para poder seguir su desarrollo desde el PC usando asMSX + blueMSX.

Mientras hacia la migracion del codigo fuente de COMPASS a asMSX me he encontrado con un par de limitaciones del asMSX que serian interesantes que las soportara, estas son:

- Permitir en el comando DS (o DEFS) indicase que byte queremos que se repita n veces, en vez de obligarnos a que sea siempre cero. En el COMPASS se pone asi: DS 100,$45 (esto insertaria 100 veces el byte $45 en memoria) ahora mismo solo se pueden insertar CEROS con asMSX.

- Permitir poner los PUSH y POP agrupando uno o varios registros, por ejemplo: COMPASS permite poner en una misma linea: PUSH HL,BC,DE,BC y en otra: POP BC,DE,BC,HL, parece una tonteria, pero el codigo queda mucho mas limpio y legible... Menudas ristras de PUSHs y POPs tengo ahora en el codigo :S

- Lo ultimo es el soporte de MACROS, pero esto ya es mucho mas laborioso, por suerte mi source solo usaba una unica macro, asi que no ha sido muy duro eliminarla... eso si... quedaba mucho mas limpio con esa macro, venia a ser algo asi: escribias VDP $82,20 y la macro se extendia en los pertientes OUTs $99... parece una tonteria, pero el codigo se entendia muchisimo mejor que ahora

Sobre lo que estoy adaptando... es secreto... ya se vera cuando este terminado

Solo añadir, mis mayores felicitaciones para Robsy, por su magnifico asMSX... y todo lo que se ha currado estos ultimos años... que no es poco la verdad...