En efecto, pero... ¿no era este hilo para reflexionar en como mejorar el concurso? Es que parece que lo quieres cerrar de raíz.


Es que también entiendo que nadie había dejado de programar por escribir.

Siguiendo con el offtopic... ¿Que es el LotCheck  ?

TNI no ha llegado por muy poco con un proyecto, seguramente para final de este mes este ya listo.

Bueno, exactamente son obligaciones, y las sugerencias y recomendaciones "también" se convierten en obligaciones. Es algo, desde mi punto de vista, fantástico. Puesto que si cumples todas las exigencias los juegos NO fallan. Pueden ser mejores o peores, tener bugs menores, pero no suelen dar problemas con la consola. Y esto evita a Nintendo muchos quebraderos de cabeza.

Ya te digo, por mucho que nos joda a los programadores cumplir esas exigencias, que ESTAN MUY BIEN DETALLADAS y vienen con muchos ejemplos, a la larga es lo mejor.

Por eso decia, que sería fantástico tener un lotcheck serio en MSX. Es que en la época comercial me huelo que los lotcheck los hacía cada compañía por separado y la propia compañía ya se aseguraba de que su juego funcionase en todas las máquinas que cumplían los requerimientos. Ya que si no lo hacían era mala propaganda para la propia casa.

Pues no estaría nada mal hacer algo así, porque beneficiaría a toda la comunidad, aunque, evidentemente, sería aplicado o no después por los programadores. Concretamente, sería la forma de zanjar de una vez por todas el tema de la "compatibilidad" de la que hablan las bases de MSXdev. Si en lugar de hablar de compatibilidad en abstracto pudiera concretarse en una serie de aspectos de obligado cumplimiento, sería tan fácil como decir SÍ cumple o NO cumple. Evidentemente, el problema recaería entonces en fijar el contenido concreto de forma objetiva.

Volviendo a los tiempos históricos, si no recuerdo mal, en una MSX-CLUB (sigh!) se comentaba el caso de un juego producido físicamente en cartucho por una compañía japonesa de software que, después de fabricar un lote completo, descubrió que el juego no era compatible y tuvo que retirarse antes de entrar en el circuito comercial. Evidentemente, me fío poco de los comentarios "a pelo" de la MSX-CLUB, pero sabemos que es un riesgo que existe.

Ramones, sé que andas tapado de trabajo, pero ¿crees que podrías hacer una propuesta en este sentido? Eres nuestro hombre "tolerancia cero" para temas de compatibilidad, que es - entiendo yo - como deben hacerse estas cosas. Compatibilidad comprende muchos conceptos, pero una única evaluación: es compatible o no lo es, por lo que sí que ha llegado la hora de ponernos serios con esto y tener, al menos, un principio de acuerdo en este sentido.

Los puntos claves en cuanto a compatibilidad - en el sentido de que son los que generan más problemas - son básicamente el manejo de memoria, el acceso directo a VDP/PSG y otros dispositivos, la entrada/salida a disco, y la gestión de diferencias entre generaciones de MSX (VDP, CPU, RAM) y diferentes versiones nacionales (frecuencias, teclados). Evidentemente, sería reformular los planteamientos del hilo de Desarrollo Compatible. En cualquier caso, se debería indicar qué hacer y cómo hacerlo, claro está. Y dejar muy claro lo que NO se debe hacer, léase modo mixto, asumir los puertos 98h y 99h, asumir RAM en posiciones dadas, etc. ¿Con ejemplos y contraejemplos de buena y mala praxis?

Y si no, como algunos recordarán, siempre nos quedará el microcódigo 

Logicamente en el caso del MSX, el programador decide qué hacer con su programa. En el caso de Nintendo y otras compañias como Microsoft o Sony estas obligaciones tienen más sentido porque son ellos mismos los que realizan los masters finales de los productos. Y ellos son los que mandan a las distribuidoras el producto final. Así que, ellos deciden (en el caso de Nintendo) si te aceptan o no como developer suyo, si te aceptan el proyecto o no, y luego si pasas sus requerimientos. Si cumples todo eso (que no os podéis ni imaginar lo complejo que és porque no creáis que aceptan a cualquiera), pues sacas el juego.

En el caso del MSX, por ejemplo A MI que yo no presento en el Dev, y que distribuyo por mi cuenta, y no habiendo un "ente" que controle todo (que si todo esto fuese sería podría ser la MSXA), pues lógicamente me hago yo mi propio Lotcheck... y ya me aseguro de cumplir o máximo que "se".

Peeeero... para un concurso como el Dev... es que debería de ser obligado. Ya expliqué qu eno tiene por qué ser tan severo como para eliminar una entrada (a no ser que sea 0% compatible) pero si puede servir para bajar puntos a la hora de calificarlo.

Aunque como ya sabes, y bien dices yo soy de "tolerancia 0". Si no va, paso, no juego. Y si yo organizase el concurso se lo devolvía directamente al grupo EXPLICANDO POR QUÉ no ha pasado "el Lotcheck del Dev" (esto es muy importante) y le pediría una versión corregida.

Esto implicaría que habría 2 fechas de entrega. Una límite para presentar a "preLotCheck" y otra final donde se juzgarán los juegos que han pasado todos los requerimientos.


Pero es que creo que lo que dice el Dev no es abstracto. Es una obligación: COMPATIBLE. Otra cosa es que luego no se sepa, no se quiera, o se haga la vista gorda ante esa compatiblidad. No hay nada que definir Edu. Ser compatible es ser compatible con las especificaciones del Dev y del programa. Fin.



Si, era un Ninja algo... pero es un caso diferente. Aquí lo que les paso es que lo ponían y supongo que ni arrancaría. Que pudo ser un problema de programación o de producción.


Ando, como bien dices, hasta arriba si. ¿Hacer una propuesta? Es que la propuesta es sencilla, como te digo: O es compatible o no lo es. Entiendo que para que la gente supiera como hacerlo compatible, habría que especificar, como dices en otro mensaje, qué cosas y que no cosas puedes hacer.

Si partimos de la base de un Rom sencillito, que no use más de 16k de Ram, el problema de la Ram está totalmente solucionado. Si la gente programa su Rom empezando en página 1 (04000h-07FFFh), y usa la rutina STANDARD DEL TH para posicionar los otros 16k, también se garantiza que el juego irá en todos los slots y subslots.

Y si la gente no usa disco y añade COMO PRIMERAS DOS INSTRUCCIONES DE SU PROGRAMA esto:

di
im 1
ld sp,0F380h

Acabamos de crear con estas 3 tonterías un ROM que:

- Funcionará en todos los slots y subslots
- No tendrá problemas con la memoria y la pila


¿Tán difícil ha sido?

Fijate. Algo tan básico como esto, que es una tontería YA NO SE CUMPLE. Y creo que esto es el primer sitio donde atacar.

Luego la "parte 2" viene con los extras:

- Quiero usar más RAM: Aprende a buscarla
- Quiero usar el VDP a toda leche: Si es MSX1, lee el valor de la Bios y luego haz tus rutinas de escritura y lectura en VRAM, metidas en Ram para poder parchear los out por lo que leas. O bien, usa instrucciones del tipo  in/out(c) o bien usa la bios.

- Accesos a puertos: Aquí estamos ante algo confuso. Para cumplir el "minilotcheck" que explican los TH, excepto el acceso al VDP para correr más todo lo demás ha de ser por Bios... tema complejo puesto que todos accedemos al teclado/psg directamente, o por lo menos lo hemos hecho alguna vez.... Aquí habría que pensarlo bien. Ya os digo, yo lo del teclado lo cumplo (pues uso la tabla de teclas que lee la Bios), pero no cumplo la lectura de joysticks, ratones, psg... Este tema me parece complicadísimo de poder "limitar".

- Quiero usar extras como FM Pac, MoonSound, SCC... : De nuevo estamos en el "aprende a buscarlo bien".

Pero todo esto, el mayor problema que tiene es que es COMPLICADO de detectar. Es fácil si se tiene mucho equipo para probar como es mi caso, ver si va o no van determinados temas. Y con la experiencia ya aprendes directamente qué ha pasado. Pero... ¿cómo se yo que usa puertos que no se permitan, etc etc... SIN EL CODIGO? Hay cosas donde el openMSX se "chiva" (por ejemplo lo del PSG) pero otras cosas... pufff...

Aquí es donde está, como digo lo más peliagudo y difícil. Pero bueno, si se podrían hacer unas cosas "muy básicas" como las que he nombrado, que son sencillísimas de probar y pueden determinar si el juego es aceptado o no en el concurso.

Esto lo soluciona, Nintendo que es lo que conozco ahora más, obligándote  usar sus librerías. Así de simple. Que viene a ser como obligarnos a usar la BIOS. Pero obligando a usar la BIOS, aún así, puedes hacer el juego incompatible si no cumples las primeras premisas que he explicado.


Ahora bien, esta es una pequeña propuesta. También te digo que ya me OFRECI a testear cada uno de los juegos del Dev antes de ser presentados, hace muchos días ya... y todavía espero la respuesta por parte del Dev Team. Vamos que no, que molesto, que fastidio mucho con estas cosas y que no... por que no.

Y sin embargo SIGO testeando y diciendo las cosas que están mal para que se arreglen. Soy masoquista pero .... no tanto.

Lo que vengo a decir, es que si hacéis unas premisas, necesitais unos tutoriales de como hacer las cosas, y alguna cosa más, os ayudo, os doy los tutoriales y podría preparar un ejemplo. Pero no contéis conmigo para que haga de Lotcheck puesto que no ... eso. Que no, que ya me ofrecí y se me ignoro, y no me gusta ser pesado.

Tengo poco tiempo y prefiero aprovecharlo en mis juegos (uish, tanto hablar con Dioniso y casi es lo que dijo él).