Karoshi MSX Community

El MSXdev'06 ya ha finalizado. Ahora los jueces se tendrán que poner las pilas para valorar cada una de las entradas para decidir el ganador y que se lleve el Turbo-R- Además, ya sabéis que todo aquel que haya participado con un ROM de 32KB, tiene como premio un Griel's Quest for the Sangraal EX en cartucho!: la organización del concurso se pondrá en contacto con los autores para pedirles la dirección, y así poder hacer el envío ;).

Bueno, a lo que nos ocupa. LOS JUEGOS :D :D :D

1. Operation Wolf (Toybox)
2. Traffic Jam (Imanok)
3. Penguin Café (The exMSXcafé Team)
4. Los Jardines de Zee Wang Zu (Jos'B)
5. I.N.E.R.T.I.A (Andrea Rossetti)
6. Sudoku (dvik & joyrex)
7. Skate Air (Yermani Soft)
8. Beepertron (Dioniso)
9. Night City (Yermani Soft)
10. Monster Hunter (Nerlaska Studio)
11. BeeZ (Darkstone)
12. Malaika Prehistoric Quest (Karoshi Corp.)
13. Mecha Taisen on Planet Oldskool (DamageX)
14. Word Invaders (SapphiRe Soft)
15. Grid Wars (Emma Six)
16. Daedalian Opus (Karoshi Corp.)
17. Pointless Platform (TNI)
18. RNFF (Infinite)
19. Pointless Shooting (TNI)

Podéis bajaros los juegos y leer más aqui: http://msxdev.msxblue.com , y este hilo lo dejo abierto para comentarios acerca de juegos y valoraciones sobre este año y lo que ha dado de si el MSXdev'06.

FELIZ AÑO NUEVO A TODOS! :) :) :)

Genial !!! 19 juegos más, se puede afirmar que esta Dev ha sido gloriosa, y si no hubieran caido 7 juegos habria sido tremendisima (aparte que se hubiera batido record), pero bueno, siempre queda la emoción de ver esos juegos acabados  :D
Yo por mi parte he decidido montar un miniconcurso para los foreros de karoshi (con permiso de los administradores, si no ya sabeis: me baneais) en un hilo aparte: EURODEV´06.. Participad Bellacos que hay premios!! ;)

A ver con que nos sorprendes! ;), ya sabes que puedes utilizar estos foros como soporte a tu propuesta sin problemas!. A no ser que te estes planteando algo exclusivo MSX2...  :spank: :D :D :D

Pues qué casualidad... yo he puesto también una encuesta en Konamito.com para elegir vuestro juego favorito... podéis participar y  así entre todos hacemos las quinielas. Lástima que no haya premio para los participantes, pero durante este 2007 alguna sorpresita en forma de concurso puede asomarse por ahí :D

Los ganadores en cualquier caso de la MSXDev hemos sido los jugones... gracias a todos por mantener abierta la fábrica de sueños ;)

Con sus más y sus menos, el resultado final de esta Dev ha sido más que positivo. Unos comentarios:

* Karoshi, seguís con vuestros juegos redondos, con un acabado profesional. Enhorabuena por el estupendísimo Malaika, y un puntazo el Daedalian Opus. Pero... ¿qué ha pasado con el Speedjet Racers?
* El Grid Wars es un juego sencillote y sin pretensiones, pero me parece bastante entretenido.
* Como dijo alguien... qué se habían tomado los de TNI antes de hacer sus "Pointless *.*"?? Ya no pregunto los de Infinite, que está claro lo que se toman. Aún así, el RNFF tiene una gracia y se nota un trabajo detrás. El Pointless Platform incluso puede jugarse... pero... el Pointless Shooting? Eso qué es?
* ¿Habéis podido jugar al Mecha Taisen? A mi no me sale de la pantalla de entrada o de la presentación por mucho que pulse espacio.

Bueno, empezaría ahora a contaros qué juego me ha gustado más y tal, pero creo que mejor me reservo para la Eurodev.

Es que según he leido, sólo va con mando o joystick... Todavía no lo he probado, porque esta noche he currado y hoy voy de tarde y estoy usando BlueMSX "tal como está"...  :P (mierda de fiestas y rotaciones, ademas, me he dejado el reproductor MP3 en casa, asi que esta noche no podré probar los juegos)


Le falta el "Insert Coin" para ser una auténtica recreativa de "necesito una partida rápida, pero divertida". Una sorpresa.


Un saludo,

Salva

El Mecha solamente va con joystick ;) ¿Qué les costaba incluir el teclado para manejarlo? :(

Pues sí, la verdad. Yo no tengo joystick, así que difícilmente podré jugarlo.

Bueno, pues ya que he probado hoy los juegos de la dev (salvo el Monster Hunter, que probé el otro día), hago a modo de resumen mi valoración: .... ¡sois unos mostros!  ;D

Jo, con el Words me he quedao un poco así  8) porque pensaba que ya nadie podía sorprender y aún menos en screen 0... ¡metedura de pata la mía!

A los pobres de Jon y Robsy les compadezco puesto que -además de hacer un juego soberbio- se van a pasar los próximos seis meses explicándome cómo han hecho ese scroll  ;D

El Penguin Cafe es muy gracioso y el concepto muy adictivo. Toma, nada de pasapantallas ni nada, aquí se le saca todo el jugo a un juego de una sola pantalla, como los clásicos de toda la vida. Y es que cuando hay un buen concepto y una magnífica factura, pues otra joya a la saca  :D

El beepertron es otra frikada de Dioniso, y menos mal que no tuvo más tiempo entre faena y faena con las alemanas  ;D que si no nos casca otra maravilla técnica... ejem, ¿TT-Virus con emulación completa de SID, por ejemplo? ;)

Los dos juegos de Germán superándose, al grano y acción sin parar, y aunque necesita un grafista desde luego me parecen mucho mejor que los del año pasado, que ya me parecían buenos  :D

Del Monster no comento pues ya lo hice, y además el grafista creo que anda metido en cosas de pedofilia, drogas y asuntos turbios...  ;D

Los Jardines es al parecer la ópera prima de Jos, espero que no sea la ópera última, porque por este camino ya para el año que viene el c.m. no tiene secretos, y ya se sabe lo que pasa entonces... adicción y buena factura, sí señor  :D

El Traffic Jam no sé por qué, inmediatamente lo identifiqué 100% con el MSX... calidad, estilo de juego, gráficos, vamos que me gustó mucho mucho  :D

El Mecha no he podido hacerlo funcionar, ya veré qué pasa con él...  :-[


Ahora la cuestión es... tengo dos carpetas de roms: una con todos los juegos clásicos y otra con los de las devs. Con esto del nuevo OCM, este resurgir que supuso la primera dev en cuanto a juegos... ¿no os parece que estamos en una nueva edad dorada? A mí estos juegos me parecen incluso superiores a los clásicos, y no es moco de pavo, que gente amateur en su casa haga producciones en casos superiores a lo más granado de aquel entonces...

¿No os parece que se está creando un monstruo y empieza a estar fuera de control?  ;D

Bueno, ya os daré la brasa luego con los proyectos que teníamos el socio y yo en mente... todos siguen adelante, pero hablaré un poco ya que no hay nada presentado, ¿te parece, socio?

Pues al César lo que es del César:

1.- Enhorabuena para todos los participantes del concurso. Participar es ya motivo de satisfacción y de orgullo para todos los concursantes. Aunque se haya dado en llamar "concurso", en realidad aquí ganamos todos. Además, el número de juegos es considerable y los hay con mucha calidad. La comunidad entera gana.

2.- Enhorabuena para los organizadores de MSXdev'06. Aunque su labor pueda parecer sencilla para los espectadores, os asegura un servidor que no és así: hay muchísimo trabajo tras las bambalinas. Les tengo que agradecer especialmente que recogieran el testigo de MSXdev y que hayan conseguido profesionalizarlo hasta el nivel actual. Han hecho un gran trabajo y es de justicia darles las gracias a Jon, Benôit y Sjoerd. No nos olvidemos de ellos, que son los que han hecho posible el concurso.

3.- Enhorabuena a todos los MSXeros de buena voluntad que han desempolvado sus joysticks para batirse con los bytes frescos producidos para MSXdev'06. Y gracias a todos por el feedback dado a los autores. Insistiré una vez más: desarrollar un juego, incluso uno sencillo, supone una inversión muy considerable en cuanto a horas dedicadas. Y no nos dedicamos profesionalmente a esto, por lo que esas horas hay que sacarlas de otras actividades, por lo que supone siempre un sacrificio de tiempo libre. El "feedback" es el único sueldo que nos llevamos, así que no escatiméis el mismo. Y sed sinceros: el propósito del feedback es ayudarnos a mejorar de cara a posteriores desarrollos.

4.- Y ahora sólo queda esperar a la nueva convocatoria, que esperemos que venga prontito, MSXdev'07. Por lo que se ha podido ver, el tema de "ampliar" los requerimientos, que parecía tan y tan imprescindible a algunos, tampoco ha tenido un impacto tan significativo en los juegos. Es decir, sólo hay 3 juegos con mapper sobre un total de 19 entradas, y de estos, sólo 2 que ocupen el tamaño límite, 128 KB. Hay que decir también que el tamaño "favorito" ha sido el de 32 KB, quizás porque era el tamaño "con premio". De todos modos, me da a mi que algunas entradas habrían entrado en algo menos de tamaño (pista: probad a comprimir con ZIP las ROMs para haceros una idea de su "complejidad" y tamaño real).

A todos, felicidades por la parte que nos toca. Y feliz año nuevo: si el producto final de MSXdev'06 sirve como augurio para el año nuevo, creo que va a ser un gran año  :D

Que pedazo de cabr.. ;D ;D ;D, pues lo que te decia, que me alegro un monton verte de nuevo por los foros!!! ;D A partir de hora te voy a llamar ALMENDRO! , el que vuelve a casa por navidad  ;D ;D ;D

Por favor!, faltaria más!.. duro con ellos  socio!  2gf:)  ;)

Bueno, pues al final no ha estado tan mal la cosa, no?? 19 juegos está muy, pero que muy bien. Paso a valorar un poco la última hornada, después de haber probado los juegos mínimamente.

-Malaika Prehistoric Quest:
Era uno de los juegos que más curiosidad me despertaba, ya que todos tenemos en mente el buen hacer de los chicos de Karoshi y este iba a ser su primer juego con scroll. La verdad es que, una vez visto el juego y sabiendo cómo se ha conseguido el scroll y tal, te das cuenta de que detrás del juego tiene que haber un montonazo de horas de diseño gráfico para hacer que sea posible, o sea, que técnicamente está muy, pero que muy bien. Lo que pasa es que yo, quizás prefiera sacrificar la suavidad en el scroll para tener mayor riqueza gráfica (como la que se ha derrochado en la pantalla de la intro, que me parece estupenda) y jugabilidad, que creo que es de lo que ha flojeado un poco (todo, a raíz del scroll pixel a pixel, claro).

La música y efectos no están mal y acompañan bien al juego. Musicas cortitas pero que, al cambiar con cada 'mundo', no agobian.

Total, que el juego está chulo, pero el dedicarse tanto a la técnica, ha hecho que el resultado final tenga un puntito de 'sosete'.

-Mecha Taisen on Planet Oldskool:
Los juegos de estrategia nunca han sido lo mío, así que a nivel de jugabilidad, no creo que sea el más indicado para valorar este juego. Los gráficos del escenario que he visto es gráficamente simplote, aunque molan los gráficos grandes de los robots (y hecho de menos que cada uno tenga su gráfico pequeño). La música, pues bueno... es todo el rato la misma, pero no se hace cansina, que ya es mucho para este tipo de juegos.

-Word Invaders:
Una frikada del 15, a la que aún no he podido jugar  ;D. Me viene a la mente aquella versión del tetris de Matra en la que se jugaba escribiendo palabras.
 
-Grid Wars:
Una sorpresa, porque detrás de unos pocos y pequeños gráficos, se esconde un juego que me ha enganchado un buen rato. Hacen gracia estos conceptos tan simples y tan entretenidos. Quizás le falte un poquito de suavidad en los controles, pero es divertido.

-Daedalian Opus:
Otra sorpresa. No conocía este juego y realmente es curioso. Después de probar la versión de GB he visto que está muy bien convertido y ha ganado muchísimo gráficamente. Una gran conversión hecha en muy poco tiempo. Para los amantes de romperse el coco pensando. Edu, me imagino a tu novia enganchadísima!  ;D

Pointless Platform:
Una versión del 'The Falling Tower' (que me encanta) pero venida a menos... además, o yo no me entero del todo bien de cómo se juega, o llego a sítios donde no se llega a ninguna otra plataforma saltando.

RNFF:
Una ida de olla en toda regla, que esconde un juego entretenido con ciertos detalles que están bien. La música está chula, muy al estilo de Wolf. Es curioso cómo ven todo esto de las drogas los holandescos, al estar el tema legalizado y tal.

Pointless Shooting:
Un concepto simple que puede engancharte, lo que pasa es que gráficamente es pobretón y el nivel de dificultad sube demasiado poco a poco, así que cuando llegas un rato jugando y subiendo más y más puntos, llega un momento en el que te cansas. Si hubiesen hecho mejores gráficos y hubiesen ajustado la progresión de la dificultad, estaría mucho mejor.

Y con esto y un bizcocho...

Pues muchas gracias, Imanok. Viniendo de ti, es todo un cumplido  ;)



Pues yo creo que el scroll le da mucha jugabilidad, en lugar de quitarsela. Es decir, estoy totalmente de acuerdo en la riqueza gráfica, está claro que quien sea un enamorado de juegos con muchos gráficos Malaika no es para el, ya que las restricciones obligan a utilizar un numero limitado de tiles. Pero, en mi opinión, es pérdida gráfica va en beneifico de la jugabilidad, que se multiplica al ganar en la suavidad de control que te ofrece un scroll de esas características.

Más que por el scroll, que creo que hace que la jugabilidad sea mayor, creo que el problema está en el diseño de los mapeados. Lo cierto es que les dediqué mucho tiempo, pero estamos en lo de siempre... es muy dificil diseñar y planificar mapeados que enganchen y con una dificultad creciente y bien balanceada: aún así estoy contento con el resultado en los mapas, ya que jugar una partida entera de principio a fin no es para nada aburrido!. Eso sí, recomiendo jugar en MSX real, y a ser posible con un pad  ;)



Thanx. De nuevo, intentando ir a la zaga del Super Mario de NES... pocas tiles, musiquillas cortas, pero intentando crear un algo "coherente".



De nuevo, no creo que la técnica sea lo que haga al juego "soso". Gráficamente no tiene muchos menos gráficos que Super Mario Bros. de NES, musicalmente tampoco está mal, y el control creo que va bastante fino... es el tema del diseño general de pantallas y demás, que al final es el hilo conductor del juego. Eso es lo que diferencia a Karoshi de una compañía profesional de videojuegos: eso si, espero con el tiempo seguir mejorando, ya que desde el Saimazoom, después Infinity y ahora Malaika, creo que mis producciones dentro de Karoshi van por buen camino.

Y por supuesto, el próximo juego también tendrá un scroll similar ;). Tras ver el resultado en Malaika, voy a apostar por los scrolles así, que le voy a hacer, soy un vicioso, ya lo sabes ;)

Bueno. Lo cierto es que yo tampoco conocía este juego hasta hace 3 semanas, así que te puedes imaginar como ha sido el ritmo de desarrollo: brutal. Aun así, el concepto es sencillo pero no por ello menos interesante. Reconozco que soy puzzlero por naturaleza, así que me van este tipo de juegos, la verdad.

Para la GB hay una serie de juegos casi desconocidos que podrían ser muy bienvenidos para MSX. Todo es cuestión de investigar un poquillo y ver qué puede hacerse.  :P

Pero vamos, que ahora me toca un descansillo del ensamblador, que estoy baldado, como casi todos los MSXdeveros de última hora  :-\

Totalmente de acuerdo, no creo que se necesite cargar la pantalla de graficos para hacer un buen plataformas, el éxito del Super Mario Bross , desde mi humilde opinión fue debido a su jugabilidad y al diseño de los niveles no a sus gráficos. Precisamente en el diseño de las pantallas es lo que encuentro que cojea un poco el Malaika, las encuentro un poco simples.. pero sólo se trata de una primera impresión, tampoco quiero emitir un juicio hasta que no haya saboreado el juego por completo. Sobre todos los demas aspectos del juego me quito el sombrero una y mil veces. ;)

Eres una maquina nen! ¿3 semanas?.. la virgen! :o. Mis felicitaciones por la criatura, nadie se lo esperaba y creo que este juego es uno de los bombazos de la Dev, el acabado es increible. Como dice Darth, Juegos como este, el  Malaika o muchos otros de la Dev, son de un nivel muy por encima de la media de la epoca dorada del msx. Y si konami hubiera tenido progamadores que les sacase juegos como el D.Opus en 3 semanas hubieran llegado hasta el RC 800 y pico  ;)

Una pregunta qe se me ha olvidado hacerla antes, Robsy ¿ De cuantas pantallas consta el D. Opus?, la primera partida que le heche me llegue a la 10 de golpe y ahora por que con el curro no tengo tiempo pero cuando pueda lo retomo (es para saber cuantas horas me quedan de vicio  ;D)

Pues tiene en total 42 niveles. Todos bastante asumibles hasta el número 12, que tiene miga. De ahí en adelante, infierno máximo, hasta llegar la pantalla 42, para la que hay más de 16.000 combinaciones, de las que sólo una es la buena ;)

La versión europea de GB tenía sólo 36, así que tenéis bonus :D

Ah! Se me olvidaba decir que los passwords de la versión europea ni de la versión japonesa funcionan en la versión para MSX.  :P

¡Serás cabr*n! ;D

KNM
¡pillado!

Jarl!..  :o pues lo veo dificil dificil.. (con la pantalla 10 ya sude)

* ANUNCIO *

Descargarsus la nueva versión de Malaika que ya está disponible en http://msxdev.msxblue.com

Resulta que la versión inicial era un tanto dañina para los MSX al escribir en el PSG lo que no debía. Cosillas del Caruso...(robsy < :spank: > viejo_archivero). Pero ya he corregido el error y ya no hay problemas, así que, bajaros please la versión MSX-friendly, para evitar el MSX churruscadeishon (o algo así que dijo el Kun en su día) ;)

Ya ves tú!  :P

Perdona, creo que no me he explicado bien. No me refiero a la jugabilidad en cuanto al manejo del personaje (que me parece totalmente correcta)... me refería la disposición de enemigos, comportamientos, etc... ya que, a causa del alto coste de CPU que tiene el tema del scroll, has tenido que sacrificar la cantidad de enemigos simultáneos y simplificar sus comportamientos... y por ahí es por donde cojea, en vez de por el diseño de los mapas. El hecho de que haya tan pocos enemigos simultáneamente y tan similares en comportamiento y aspecto, hace que el jugador esté más atento de los mapas (y como consecuencia de su diseño) que de los enemigos en sí.

En mi opinión, los mapas están bien... como ya te he dicho, la acción y el peligro real debe venir de los enemigos.

Exacto

Eso esperamos todos  ;)

Perfecto. Lo que yo no quiero que te pase es que hagas los juegos a la holandesa... mucha técnica y demos con mil efectos, pero cojean en cuanto a la jugabilidad. Prefiero que los hagas a la japonesa... mucho más prácticos y toscos, pero jugables a tope, captas??

Tendré que encontrar entonces ese punto intermedio entre los juegos a la holandesa y a la japonesa... técnica más jugabilidad!... podríamos denominarlos juegos a la bilbaina!! (como el bacalao) :D :D

Bueno. Os dejo una breve indicación de en qué se han ido las últimas 3 semanas  :P
;----------------------------------------------------------
; PROJECT HISTORY
;----------------------------------------------------------
; 10th December 2006
;----------------------------------------------------------
; - Project started
; - Played extensively the original Gameboy game
; - Reviewed the game FAQ
; - Obtained all solutions
;----------------------------------------------------------
; 11th December 2006
;----------------------------------------------------------
; - Code started
; - Temptative logo designs
; - Blocks defined (first 7)
;----------------------------------------------------------
; 12th December 2006
;----------------------------------------------------------
; - Blocks completed (up to 13)
; - Procedures for block handling
; - Screen handling
; - Level storage and presentation
; - Hand sprite (recycled)
; - Selection mode defined
;----------------------------------------------------------
; 13th December 2006
;----------------------------------------------------------
; - Block selection procedure
; - Interrupt-driven screen updates
; - Colour configuration
; - Block mode defined
; - Block movement and rotation
;----------------------------------------------------------
; 14th December 2006
;----------------------------------------------------------
; - Block mirroring
; - Block drop
; - New keyboard layout
; - Problems with button release
;----------------------------------------------------------
; 15th December 2006
;----------------------------------------------------------
; - Button release problems fixed
; - Smooth cursor movement
; - Goal detection
; - End of level detection
;----------------------------------------------------------
; 16th December 2006
;----------------------------------------------------------
; - Obtained Dr. P graphics
;----------------------------------------------------------
; 17th December 2006
;----------------------------------------------------------
; - Obtained level change graphics
; - Smooth cursor fixed
; - Top left block problems solved
; - Bold font defined
; - Dr. P talking included
; - Vic Tokai graphic partially designed
;----------------------------------------------------------
; 18th December 2006
;----------------------------------------------------------
; - Font converted
; - Dr. P blackboard shows completed
; - Level change graphics converted
; - Level change procedure started
;----------------------------------------------------------
; 19th December 2006
;----------------------------------------------------------
; - Level change procedure progress (level 01 completed)
; - Ending graphics converted
; - Temptative in-game screen layout design
;----------------------------------------------------------
; 20th December 2006
;----------------------------------------------------------
; - Level change procedure progress
; - In-game screen defined
; - Dr. P fast-skip text added
;----------------------------------------------------------
; 21st December 2006
;----------------------------------------------------------
; - Level change procedure progress
;----------------------------------------------------------
; 22nd December 2006
;----------------------------------------------------------
; - Level change procedure progress
; - In-game graphics included
; - Dr. P texts obtained and included
;----------------------------------------------------------
; 23rd December 2006
;----------------------------------------------------------
; - Day almost off
; - Falling block designed
;----------------------------------------------------------
; 24th December 2006
;----------------------------------------------------------
; - Falling block fixed
; - Level advance fixed
; - Final level fixed
;----------------------------------------------------------
; 25th December 2006
;----------------------------------------------------------
; - Appearing text done
; - Level 5 included
;----------------------------------------------------------
; 26th December 2006
;----------------------------------------------------------
; - Karoshi logo included
; - Levels 6, 7 and 8 added
; - Password text fixed
;----------------------------------------------------------
; 27th December 2006
;----------------------------------------------------------
; - Level editor created
; - More levels converted
;----------------------------------------------------------
; 28th December 2006
;----------------------------------------------------------
; - Vic Tokai logo included
; - Final level issues fixed (animation, password, background)
; - End of level
;----------------------------------------------------------
; 29th December 2006
;----------------------------------------------------------
; - Menu screen included
; - Passwords included
; - Instructions included
; - Password selection included
; - Dr. P texts included
; - Cheat mode included
;----------------------------------------------------------
; 30th December 2006
;----------------------------------------------------------
; - Ending completed
; - Stages completed
; - Basic SFX included
;----------------------------------------------------------
; 31st December 2006
;----------------------------------------------------------
; - Additional SFX
; - Melodies included
; - Game finished !!!!
;----------------------------------------------------------

Menuda paliza  :(

Una Dev muy entrenetida, he disfrutado mucho con todos los juegos que se han presentado, algunos verdaderamente sorprendentes y tambien creando mi pequeña aportación a este mundillo tan curioso. Espero que dure muchos años este concurso.

Personalmente el que más me ha gustado ha sido, como ya he dicho en algún otro hilo, el MH, con sus defectos incluidos, creo que ha sido bastante interesante ver como alguien ha conseguido realizar un juego en C y muy jugable.

Vuelvo a tomar como ejemplo el SuperMario Bross (el 1), Hay pantallas que aparecen poquisimos enemigos, alguna tortuga que otra y casi toda la acción se la lleva el mapeado: abismos, pinchos, trampas, plataformas moviles, bloques destructibles, trampolines  lianas donde trepar etc... De hecho , los enemigos son casi casi lo menos procupante en según que pantallas. Lo que quiero decir es que si, tener una buena variedad de enemigos puede enriquecer mucho el juego, pero no es necesario, Si el diseño de los mapeados es esmerado y repleto de elementos, con 4 o 5 enemigos de caracteristicas diferentes, y estrategicamente bien colocados se puede hacer un gran plataformas.
Joer.. me he cansado sólo de leerlo  :P

Aunque eso te pasa por dejarlo todo a ultima hora ;D

He tenido tantas y tan malas experiencias en mi vida relacionadas con las matadas de última hora que se me pone hasta mal cuerpo de ver esto, de verdad :o

Acojonante!  ;D
Este puede ser el resumen de la dev, si señor, acojonante.  ;)
Lo que jode es que apenas he tenido tiempo para probar las criaturitas. Pero bueno, he visto lo suficiente como para poder felicitar a todos los participantes y organizadores y darles las gracias desde mi posición de usuario msxero. Cuando pruebe más a fondo ya daré más "fidbac" de ese, que realmente lo merece. Mola  ;D ;D ;D.

Me estoy planteando pedirles a los reyes un algo portatil que pueda emular MSX, para jugar por esos mundos de dios. Umm, si les mando un e-mail tal vez llegue a tiempo.

un saludo.

Mejoramen, te compras un MSX con disketera un cartucho regrabeibol, que es más barato y mejor.

SuperMario BROS  ;D Que manía de cambiarle el nombre al juego  ;D

Resumiendo, señores: FELICIDADES A TODOS, SOIS UNOS VERDADEROS PROFESIONALES DEL VIDEOJUEGO MSX-ERO!!!  ;D

MAGNÍFICOS trabajos, sin duda. MSXdev's forever and ever, que todo esto vaya para largo!!

P.D.1: aunque sea off-topic, necesito ayuda: desde hace más de 1 mes que tengo lista la actulización de mi WEB, y no puedo actualizarla, no puedo acceder por FTP, y sin embargo la WEB sigue activa. El dueño del server aún no me ha contestado. ¿Alguien sabe de algún host gratuito para "mudarla"?  :'(

P.D.2: ¿tengo el expreso consentimiento y permiso de los Karoshi's Dev de esta edición para poder colgar sus obras en mi WEB en cuanto pueda? (por lo menos de los aquí presentes...)


Saludos!

Ya, ya, pero me iba a ocupar un poco de más en la bolsa de la cámara, que yo me suelo pasar casi todo el día danzando por ahí... :D

En casita ya me estoy viciando con mi flamante nuevo 8280 (bueno, no de todo, ahora no me va la disquetera del PC...  :P)

¿El dueño del host no es NapalM? Ponle un mensaje público en hispamsx, por ejemplo, no se ^-^ Que raro que no te conteste.

Un saludo,

Salva

Pues sí que es raro, sí... Pero bueno, mientras tanto ya me han aconsejado otro server, la mudaré mientras tengo noticias de él... Espero que me conteste... ::)

Saludos!

 Saludos a todos.

 Después de observar los comentarios y críticas acerca del Night City y Skate Air, presento las siguientes aclaraciones:

 No entiendo ciertas opiniones contrarías como en lo referente a los gráficos o como es la rom. ¿Cual es el inconveniente de implementar una aplicación ambientada en un escenario ya creado?, si alguien quiere realizar una aplicación con el escenario del planeta Phantis ¿no puede?, y de ser así ¿en base a que?


 En relación a este comentario y parecidos hay que decir que esto es relativo, ya que si en las bases del contest hubiera algo redactado como gráficos 100% original o algo así, pués se hubieran hecho los gráficos en función a esa normativa, y con esto no quiero desestimar lo que pueda aportar un grafista.


 Me parece que la crítica a la rom de 128k, solo aparece en mis aplicaciones ya que no lo he observado en otros post, pero es que las bases del contest lo permite, y si hay disconformidades ¿porque se dice ahora?



 En cuanto a los comentarios sobre el mapper, eso de que cuesta lo mismo o "más visible" no es así. Bien, se implementaron los mappers comentados en su momento y estan publicadas las actualizaciones presentadas al contest.



 Este post es interesante desde el punto de vista de la implementación, ya que comenta que se produce un corrupción del gráfico en el rederizado y explica el por que.

 El caso es que inicialmente el renderizado se hacía llamando a una de los procedimientos de la bios, y se producía lo comentado, por lo que se implementó un procedimiento específico que incrementa la velocidad del render y evitaba el problema.

 Este procedimiento tiene implementado las pausas necesarias para que no se repita el problema. Codificar más pausas ralentiza demasiado la aplicación.

 En este punto ha habido gente que ha criticado que se realicen programas en emulador, pero se le puede preguntar a esta gente: ¿como se testea la compatibilidad de la aplicación en todas las generaciones y modelos?.

 Esa gente que se ofrece para testear, y que es de agradecer, no creo que tengan todos los tipos de sistemas.



 Bien, aunque este comentario se interpreta como algo constructivo, sería interesante que comentases cuales son los criterios para decir esto.

 La implementación del los programas siempre suele ser correcta a los criterios de programación, además de usar un lenguaje de programación en función del tipo de programa o normativa del contest.

 Aqui quiero hacer una observación, y que otras personas han hecho referencia en otro momento o lugar, y es que el uso del basic no implica que el programa o la programación sea menos correcta. Pero que se sabe, y solo hay que observar los resultados de los contest, que se infravalora.



 O sea, especificar en los creditos los recursos.

 Aquí estoy de acuerdo, pero de forma que se debe especificar todos los recursos utilizados en la elaboración de la aplicación, no solo lo que se ve: utilidades usadas, gráficos, sonidos, librerias de programas, etc.

 Por ejemplo, son muchos los que usan el photoshop y no he observado que se nombre en ninguna aplicación presentada, o el tipo de ensamblador usado, o de donde obtienen la idea, ya que hay aplicaciones que son versiones de otras, etc.

 Redactarlo todo puede ser extenso, y puede que no se especifique a todos.

 No existe una normativa oficial sobre esto, hay gente que nombran en los créditos a algunos, que suelen ser conocidos de foros o empresas conocidas y ya está. La solución está en la normativa del contest, ya vereis la gracia que le hace a algunos cuando implementen un programa en basic y tengan que decir de quien es el lenguaje de programación en los créditos.  :D

 Después está el tema legal, y aquí sería interesante que se abra un topic sobre el tema de la propiedad intelectual, ya que por ejemplo, estamos observando como se presentan conversiones que no tienen por que presentar ningún inconveniente, pero igual que hay gente en este foro que hace crítica discrecional sobre el uso de recursos, puede haber una empresa que diga que el hacer una conversión y publicarla de forma unilateral sea ilicito y exija retirarla de internet, y de esto último Robsy tiene experiencia.

 La redacción del texto legal de este topic se puede adjuntar a las bases del contest.


 Puede que halla gente que aprenda o sepa algo más con esto, no sé, pero me parece que el objetivo de la gente es la participación en el contest no la aportación cognitiva.

 Conclusión:

 Me parece que cualquier forma de hacer un programa es correcta, teniendo en cuenta que en este contest no hay ánimo de lucro.

 Es gracioso observar las críticas de si ha usado esto o lo otro, pero no sé si habeis visto el msxupdate'06, es un disco que se vendía en una reunión de usuarios y en el cual aparecian 3 programas mios, sin solicitud de autorización y ahí está.

 Por otro lado, es interesante observar la diversidad de opiniones de una misma persona, algunas contradictorias entre si, y como dan a entender que hay distintos raseros para lo mismo, con la única diferencia de quien lo hace.

 Y como ejemplo de esto, en cierto foro discreparon sobre la aplicación ganadora del msxdev'05, y que todo el mundo sabrá relacionar rapidamente con otra aplicación, aunque el personaje es de otro programa. Y aquí es donde empieza si uno es una copia, que a mi me parece que no pero es que si, que si es de otra forma, etc. ¿Que importancia tiene?, antes de hacer la aplicación ¿hay que preguntar a la gente de los foros como la quieren?, ¿lo que hace una persona tiene validez y lo mismo no tiene validez para otra?.


 Para finalizar, agradecer a aquellas personas todos los emails enviado con motivo de las aplicaciones aportadas y felicitar a todos por el evento.

 Recibir un saludo.

Ante todo, bienvenido a los foros Germán (ya era hora) ;).  Sobre esto aclarar que no creo que se haga referente a "penalizar" por el ripeado de graficos, sino a darle más identidad al juego: No es lo mismo hablar de Skate Air o Night City, que de "aquel juego con los graficos de...". A mi los dos juegos me han parecido muy divertidos, pero con un set gráfico propio hubieran ganado mucho más interes. Un saludo.

Buenas YMN, contesto la parte que me toca ...



Claro que puede. Por supuesto no es descalificable, imagino, ya que no hay nada puesto en las reglas que lo prohiba. Ahora bien, imagínate por un momento que quisieras sacar tu juego a la venta, o incluso dejándolo público, esos gráficos tendrán un (c) y podría ser (hoy en día lo dudo, pero...) denunciable.

Creo que todos recordamos el caso de Karoshi con el Gurulogic por poner un simple ejemplo.

Así pues, está clarísimo que si haces un port de un juego que no está en MSX, usarás los gráficos del original, que duda cabe, pero si haces un juego totalmente nuevo, como es tu caso ... pues lo suyo sería usar gráficos nuevos.

El mismo caso se aplica al Penguin Café, por poner un ejemplo, que también usa "caracteres" conocidos por todos.

No es una crítica, es sencillamente que si tuvieses un grafista, pues la puntuación de tus juegos subiría. Es lógico. No se puede valorar igual un juego donde se ve un trabajo totalmente nuevo en la parte gráfica, que un juego que usa gráficos "prestados".

Ahora bien, descalificable, no es, claro.


Exacto, como bien apuntas, y viendo que tu evolución es muy buena, sería recomendable que para próximos proyectos tuvieses a un grafista. :) Ten en cuenta que esta parte no es crítica negativa, si no constructiva.



Volvemos a lo mismo. Es totalmente legal tu Rom, claro que si. Lo que quiero decir es que aprecio mucho más el trabajo de quien explota el "poco sitio" para hacer un juego antes que desestimar espacio. Es una valoración personal.


Por lo que veo te has centrado demasiado en ver si es legal o ilegal tu Rom. Si fuese ilegal con las reglas, los organizadores ya la habrían descalificado. Eso no lo pone en duda nadie, hombre.

Lo que pasa es que usar Konami4 y, por lo que creo, usar C para el programa (igual me equivoco), hace que el acceso a los mismos no sea muy visible para las aplicaciones que parchean estas Roms para usarlas en una Flash, o en LOADROM.

Y esto a que lleva? Pues lleva a que con ese mapper, SOLO UNOS POCOS hemos podido ver el juego en una máquina Real, un MSX de verdad.

Es legal? Claro que si, pero por culpa de esto estás impidiendo que los users jueguen en su máquina, y se resignen al emulador.

Y si, no es culpa tuya, claro que no, es culpa de los programas que parchean las Roms, pero vamos, que desde el punto de vista programativo igual te daba usar ASCII8K que Konami4, y eso no me lo puedes negar. :)


YO soy el primero en criticar que un juego solo funcione en emulador, puesto que para mi ha de ser descalificado. Y no hay peros. El juego ha de funcionar en un MSX1 con 16k de Vram y Ram. Y si no funciona, es que no es una entrada valida. Y tu Skate, funcionaba, si, pero se corrompia.

¿Quien los prueba? Pues creo yo que los organizadores y/o jurado deben de hacerlo para evaluar este punto.

Yo tengo un MSX1 constantemente montado, y ahí pruebo todo lo de MSX1.  Y mi comentario era sencillamente para que lo arreglases, ya que es una pena que el juego estuviese mal en este punto que es corregible fácilmente.

Y claro, se de sobra que si haces las pausas que tocan, todo se va a la mierda en velocidad, pero hete aquí la gracia, si no lo haces no funciona. :)

Y no hace falta tener todos los modelos. Con tener un MSX1 con lo mínimo que aplican las reglas sobra: Que funciona ahí, todo correcto. Aunque lo correcto sería que funcionase ahí, y en TODOS los MSX, ya que hablamos de una configuración mínima. No hay que probar tantas cosas. Yo mismo, como programador tengo uno de cada y los que no, se los dejo a los testers. Y cuando todo funciona bien, es cuando se da el juego por bueno.

Además, no es tan complejo, una vez tienes hechas unas cuantas rutinas ya las dejas para siempre y garantizas compatibilidad.



No creo que nadie infravalore nada, y además, por mucho que los que por aquí escribamos hablemos da igual. El que decide es el jurado. Yo personalmente valoro si me lo paso bien o mal delante del juego. Pero por desgracia, muchos programas en BASIC no cumplen eso, no me divierten, independientemente del programa.



Pse ... yo creo que todo el mundo que participa quiere ganar, y quien diga lo contrario miente. :) El ser humano es egoista por si mismo. Y creo que Juan Luis solo te dice que cuanto más haces, más aprendes y cada vez mejoras tus programas y juegos.


Claro que si. Pero tu puedes hacer el mejor programa del mundo, y el peor juego del mundo. Repito, no creo que nadie mire lo que haces por dentro, las tripas de tu programa, lo que se mira es el resultado.

Otra cosa sería tener que analizar que es o que no es legal hacer programando... que este tema es realmente jodido y creo que se deslizan muchas "burradas" de accesos prohibidos, o formas incorrectas de hacer las cosas. Pero entiendo que esto sería complicadísimo de mirar para el jurado, aunque debería de hacerlo.

Lo bueno del MSX es que permite muchas configuraciones. Lo malo es que esto complica el saber si un programa es correcto o no. Si tuviesemos una máquina "unica" sería todo más fácil.



Ah si, el doble rasero está implícito en todo ser humano. Ahora bien, también habría que saber si realmente lo que interpretas por doble rasero, lo es o no lo es. :D



El problema es que tu eres de estas tierras, y aquel es holandés. Eso se valora mucho fuera de nuestras fronteras. :D Y por supuesto no es lo mismo que copies a Konami que copies a otra compañia. :P

Pero repito, al final el que decide es el jurado, que creo yo que, aunque pueda guiarse un poco por la opinión de los usuarios, no debería de repercutir en su decisión final, y dejar todo eso al margen.

Pues aquí te equivocas, Ramones. Lo primero que quiero es asustar y después ganar - y no busco necesariamente lo segundo pero sí lo primero (independientemente de que lo consiga o no).

El año pasado quería que mi juego gustase mucho ... y si ganaba pues mejor que mejor. Este año no quiero ganar (sé que no necesito prometerlo), tan sólo hacer algo ... diferente. Me tomo la dev como un campo experimental. No creo que haga nunca un megarom, soy amigo de las 8k (al menos, no más de 32k).

Opino lo mismo que Dioniso. Jamás he buscado ganar en la MSX-Dev'06. ¿Por qué participo entonces? Pues para devolverle al MSX los buenos ratos que me hizo pasar y el haber aprendido informática. El WI ha sido una sorpresa de última hora, pero el Namake era un juego que llevaba un par de años queriendo hacer y el QBIQS está rondando por mi cabeza desde 1990. Sólo ahora tengo el conocimiento necesario para hacer estos juegos... pero, desgraciadamente, no el tiempo... :'(

Saludos
--
Sph.

Que si que si. :) Que yo se que ahora todo el mundo dirá que no, que solo quieren participar. :D

Hombre eso de las 8k está bien. No soy amigo de valorar un programa por el tamaño que tiene. Casí que al revés. Así que si un 8k es mejor juego que un 128k, debe de quedar por encima. :)

Y SI, te aseguro que tus juegos ASUSTAN. :D El día que te dignes a cambiar los colores nadie sabrá que es un juego tuyo. Dios que dolor de cabeza dan!

:D :D

Eso es lo que te producen mis gráficos? Dolor de cabeza? ... Je, je. Increíble.

Germán: bienvenido a estos foros.

Paso a aclararte mis comentarios, por si generan algún tipo de duda:

- Tus juegos cumplen íntegramente las normas establecidas para MSXdev'06, sobre eso no hay duda, ya que la organización los ha aceptado. Mis comentarios sobre los créditos se refieren simplemente a lo que yo considero "fair play". No me parece mal reciclar gráficos de otros juegos, pero asumes un riesgo al coger elementos de juegos distintos, y es que algunas piezas "no encajen" y el juego quede falto de hilo conductor, de homogeneidad de estilo. En cualquier caso, por supuesto, es decisión tuya y -como tal- no es discutible. Sin embargo, sí que es opinable, que es lo que hemos hecho aquí. Por mi parte, si cojo algún gráfico o música "prestado", creo que estoy obligado a "decirlo", porque estamos hablando de un trabajo creativo ajeno. Sobre las herramientas empleadas, creo que no es tan necesario, dado que son "invisibles" para el usuario final y podría obtenerse el mismo resultado con CUALQUIER herramienta. Como programador del asMSX, no me aporta nada que los usuarios digan en los créditos que lo han utilizado para programar el juego. Sin embargo, sí que me aporta que utilicen la aplicación y me ayuden a mejorarla con sus sugerencias y comentarios.

- Respecto a la mejora que indico, sí tienes razón respecto a que comparaba tus entradas de MSXdev'06 con las del concurso BASIC, lo cual no es directamente una evidencia. De todos modos, también las he comparado con tus entradas para el MiniCompo en el que participaste, en el que utilizaste ensamblador, si no me engañan mis ojos. Tus producciones para MSXdev'06 están mejor acabadas. Por supuesto, el diferente tamaño también ayuda.

Metiéndome ya en la parte que no me toca, también me parece que la complejidad de los juegos que has programado no se corresponde con el tamaño final de la ROM. Es decir, estarás de acuerdo conmigo en que entre el SKATE AIR y el MONSTER HUNTER, que tienen un mismo tamaño, hay una diferencia importante de complejidad del juego. Ya sé que el sonido sampleado ocupa mucho, pero pregúntate: ¿aporta algo al juego?

Como verás, es una opinión muy personal: a mi me gusta que la programación, además de ser efectiva (que funcione adecuadamente) sea eficiente (que lo haga con el menor consumo de recursos). No es un criterio del concurso, es solo mi opinión como programador, y como tal debes entender mis comentarios. A mi me gusta llegar al máximo con lo mínimo. Y que conste que DAEDALIAN OPUS podría haberse quedado en una ROM de 16 KB sacrificando una serie de detalles. La versión presentada, aunque sea una ROM de 32 KB, podría haberse quedado en 24 KB.

En cualquier caso, Germán, no hagas una lectura negativa de todo esto que te digo: estoy encantado de que te hayas decidido a participar en MSXdev'06 con nada más y nada menos que dos juegos. Son dos juegos más que podremos disfrutar todos, así que ya sabes lo que toca: irte preparando para MSXdev'07, porque contamos contigo :D

 Pués no te acostumbres :D


 Bien David, si eres un grafista es normal que tenga para tí "más interes", y no creo que la gente, de forma genérica, recuerde una aplicación por los gráficos de forma específica, pero puede que halla alguien por ahí que si. Saludos a ti también.



 Si te leyeras el post completo antes de contestar observarías que ya se hace referencia a lo que expones.


 Por que tu lo digas vamos. Aplicando el mismo criterio se pueden hacer aplicaciones que ya existian o nuevas, independientemente de donde esten los gráficos, sonido, librería de codigo o lo que quieras.


 O la música empleada por platform o shooting, y que nadie habla. Y fijate son melodias que existen en el sistema. Pero, ¿que importancia tiene?


 Eso depende del grafista. :D. Además te vuelvo a decir que si las bases lo hubieran especificado, se hubiera realizado de otra forma.

 ¿Y eso de que la puntuación subiría?, ¿en que parte del contest habla de valoración?. Ese argumento que expones tambien es valido a la inversa y de ejemplo te vuelvo a remitir al ganador del msxdev'05, donde hay foros en los que expone el original y este, y hacen sus comentarios.


 Te vuelvo a remitir al post, eso es relativo, pero no se desestima lo que pueda aportar un grafista, en el sentido de que puede ser interesante su participación.


 Y yo te vuelvo a decir, ¿porque no te has pronunciado antes?. Lo haces cuando ya está la aplicación publicada.


 Para nada, como dice el post: se dan unas aclaraciones a vuestros comentarios, y para eso se usa las bases del contest entre otras cosas.


 Insisto, ya se publicaron unas actualizaciones sobre ese mapper, que el caso es hacer la crítica y quejarse.


 ¿Te has leido el post con atención?. Que se hacen las pausas necesarias!!!. Que usando la bios, el gráfico se corrompe igual, y eso que el render de la bios tiene las pausas implicitas. Que el render usado debe evitar el problema, independientemente que en tu ordenador no vaya, sistemas hay muchos.


 Bien, igual que haces las críticas, aporta la solución. Te puedo decir que no es de las pausas e insisto: con el nuevo render debe funcionar. Y si no, prueba a cambiar la llamada al render de la bios, y observarás que ocurre lo mismo.



 De eso nada. Te puedo decir que existe incompatibilidad a nivel de microcódigo entre sistemas. En el msxdev anterior, Robsy me envió un email comentando que una de las aplicaciones que envié no funcionaba en msx2 y era por eso. Se modificó los procedimientos assembler para que funcionara.

 Te vuelvo a remitir al post. Esos testers ¿tienen todos los sistemas y modelos?.


 Muy limitada tu forma de depurar programas. Por tus comentarios parece que solo haces comprobaciones a nivel de sistema, pero en programación existen otros errores. Puede que tu aplicación funcione en todos los sistemas, pero ¿que tester te comprueba un error colateral?, por ejemplo.


 Sé lo que quiere decir Juan Luis, pero además creo que la gente no participa por lo que vaya a aprender.


 Tu mismo lo puedes comprobar. Y en este post hay algún ejemplo.


 Esto si que es incongruente: "pueda guiarse un poco por la opinión de los usuarios".

 Se sabe que hay situaciones que no se pueden entender como las ocurridas en el basic contest, por no hablar de otras, pero los jueces deben ser objetivos y dar su valoracion en función a la normativa del contest y que no se sabe por que no se especifica como deben valorar y en base a que.


 Pués por eso mismo. El gráfico lo ves o lo que sea, pero lo otro no. Y no debes aplicar criterios distintos para una cosa y otra, ya que son recursos iguales. Y no solo a las utilidades sino a todo lo que se use para la implementación de la aplicación.


 Sigues sin decir los criterios. Haces referencia al ensamblador que ya me lo imaginaba y te remito al post, no es menos correcto un programa realizado en basic que en otro lenguaje. De todas formas, ya te lo comenté, este comentario se interpreta como algo constructivo.


 Pués claro, la idea era implementar un sampler de más calidad en audio y eso ocupa espacio. Al inicio, el programa estaba ideado para 32 o 48k, siguiendo las bases del contest anterior pero al existir otras posibilidades en este, pués se mejoró la calidad del sampler.


 Para nada se realizan lecturas negativas, otra cosa es que tu lo puedas pensar. Pero ciertos comentarios deben ser aclarados con argumentos y criterios usados.

 Recibir un saludo.

Hola Germán. Hay algunas cosas de tu mensaje que no entiendo. Es lo que tiene la comunicación telemática, que a veces da lugar a malentendidos. Pero bueno, te contesto lo que he entendido.

Tienes razón en algunas cosas, te las quería aclarar.

Primero que es totalmente cierto que NO había probado la versión nueva del juego en Mapper ASCII8K. Pero ya lo he solucionado. La he probado en MSX1.

Siento decirte que el programa sigue sin funcionar en MSX1. Se sigue corrompiendo todo exactamente igual.

Asi que, si me comentas que usabas LA BIOS para hacer esto y te fallaba, ya solo puedo hablar de otro tipo de error, puesto que la bios NO falla.

Se me ocurre que accedas al VDP con las interrupciones activadas y cuando se produce una interrupción la propia BIOS te jode el puntero. Pero bien, la BIOS si debería de tener en cuenta esto en sus escrituras.

Vamos queno se me ocurre otra cosa, pero te puedo asegurar que está mal. :(

Otro error que yo tenía.

Y bueno que comentas que me quejo de los 128k. No no, yo NO me quejo, solo que no puedo ver en tu aplicación los 128k. Y si solo es por lo que dice Edu, para meter un peazo de sample, pues estoy de acuerdo con el. Me sobra. Pero totalmente. Pos sus mismos motivos.

También me comentas que ya lo podía haber dicho antes ... pues hombre, que NO soy vidente. :) Ya me explicarás como te puedo comentar algo de tu juego sin conocerlo. :)

Por último hablas un poco de testeo de errores "colaterales". No tranquilo, para eso ya cuento con MUY buenos testers que cazan casi todo (digo casi puesto que siempre se puede colar algo).

Mi test es de máquina, pues yo ya parto de que mi programa está bien.

En fin, nada, que espero que puedas arreglar ese fallo en tu juego, la verdad es que aquí me tienes para que te lo pruebe en MSX1 las veces que te haga falta. :)

Es curioso Night funciona correctamente (por si te puede dar alguna pista). :P

 Saludos Armando. Lo que no entiendas solo tienes que plantearlo y se te explica de otra manera.


 Pero es en tu ordenador, y no dices que tipo es, ni a que frecuencia de pantalla va, ni nada. ¿En que momento se produce la corrupción del gráfico?, ¿en todo momento?


 ¿Y tu solo has llegado a esa conclusión? :P. Bromas aparte, esto ya se sabía antes de que tu comentaras nada.


 Pués no, ya que en su momento en cada render se guardaban y recuperaban los valores de los registros, por si era eso que dices, se desactivaban las interrupciones, etc, pero no.


 Debes de mirar el código antes de emitir opiniones que al final son equivocadas, como lo de las pausas. Se implementó pausas después y antes del render y no solucionaba nada. Por eso se realizó ese render específico que resuelve el problema. ¿Cual era ese otro error?


 Bien, Robsy habla de efectividad y eficiencia en la programación, pero él mismo se contradice haciendo un agravio comparativo con otra aplicación, ya que esa aplicación esta desarrollada en un lenguaje compilado, e insisto esto no debe presentar ningún inconveniente, pero según el criterio de Robsy ¿es eficiente?. Ademas, ¿quien dice que toda la rom debe ser código?


 Pués yo te lo explico, lo primero que se publica son las bases, y sorpersa! ahí puedes leer que se pueden implementar rom de 128k, y en ese momento es cuando deberías de hacer tus comentarios de como debe ser, y no cuando ya está publicada la aplicación.


 Después dices que no entiendes las cosas. Eso era y es un ejemplo de posibles errores ya que tu solo depuras a nivel de sistema. Y estoy tranquilo, no sé si tu lo estas, ya que esos testers y que tu ya comentas no te lo van a detectar todo, y el error colateral es un ejemplo de lo que no te van a detectar.


 Pués lo que te estoy diciendo desde hace algún post!!!!. Ya te lo he comentado antes, tu depuras a nivel de sistema, o llámalo arquitectura, hardware o como quieras. Y no es correcto partir de la base de que tu programa está bien, ya que se debe hacer la aplicación en función a la arquitectura, por ejemplo.


 Se agradece. Me parece que el programa es funcional como está, si tu dices que en tu ordenador no va, se podría observar donde está el problema.

 Recibe un saludo.

Hola Germán, pues nada, vamos a ver si nos aclaramos. :) Que fundamentalmente creo que te interesa más a ti, para ver si podemos solucionar el problemilla de tu programa.


No. Se produce en el juego en si mismo. El pintado la parte de juego para ser más exactos, es la parte más afectada. Cuando entras en el juego muchos tiles aparecen en negro. Y cuando juegas el scroll no se pinta bien.

El title, con su scroll de letras, el logo ... todo eso funciona correctamente.

¿Qué modelo? Pues hombre, es un MSX1, y eso te lo he dicho ya varias veces, creo que debería de sobrar, puesto que, si me ciño a lo que quieres que me ciña (las bases del concurso) el aplicativo debe de funcionar en un MSX1 con 16k de Ram, y no funciona.

Pero vamos, ya que te veo amante de datos, que son indiferentes pues estoy seguro que fallará en todos los MSX1 (menos en el SVI738 que lleva el 9938 y ahí si funcionará), es un Sony HB20P. 64k de Ram, 16k Vram.


Lo cual nos lleva a que sigues haciendo algo MAL. Si con BIOS que ahora los dos hemos llegado a la conclusión de que no falla, falla, es que el problema es del programa. :)


No, aquí es donde tu no me has entendido, aunque seguramente, viendo nuestros post, parece ser que no nos entendemos muy bien.

Me refiero a escribir en los puertos del VDP con las interrupciones activas. También es cierto que pudiese ser algún registro que no salves y te destroce todo, pero si el problema fuese ese, también pasaría en MSX2 y superior, y no pasa.

Al igual que también debería de pasar el problema en MSX2 o superior si fuese eso, pero es algo que nunca puedo saber a ciencia cierta.


Hombre, claro que lo podría hacer. Pero a veces me sobra con ver una cosa para saber por donde vienen los problemas. Además si te miro el código y te doy la solución, la cosa pierde su gracia, que ya no podría meterme con tu programa. :) Me interesa que falle, hombre.

(seguimos con las bromas claro está :D )

Te explico, si llegue a esa primera conclusión es porque YO mismo la he cagado pero MUCHO con eso. Estaba demasiado acostumbrado a que en MSX2 funcionan unas cosas que en MSX1 *no* funcionan. Y como me pasó y el problema era exactamente igual, pues emití mi juicio.

Pero bueno, ahora que lo dices ... así hablando he caído en una cosa.

¿Qué entiendes tu por "pausas" entre escrituras en el VDP? Es que igual está aquí el problema.

Un OTIR es un problemón. Según el TH del VDP esto te puede ir bien, si haces ese otir cuando la pantalla esta desactivada. Pero con la pantalla activa y fuera de VBL es un fallo seguro de corrupción.

Un OUTI, 3 cuartos de lo mismo. Tiene el mismo problema. Hace un tiempo hice un cálculo estimado simple para ver una rutina que me funcionase correctamente en todos los casos, sin preoucparme de si estaba o no en la VBL o tenía activa la pantalla.

Más o menos, así a ojímetro, calcule unos 12 o 16 ciclos entre escritura y escritura.

Resumiendo, si quiero transferir con outi (pues otir ya está descartado totalmente), lo hago así, que funciona correctamente (hablando de transferencias MASIVAS).

di
[inicialiacion]
bucle:
outi
jr nz,bucle

Un jr nz, sobra para que todo funcione. Si hablamos de pausa entre OUT y OUT, la cosa se va a unos 3 nops entre uno y otro.

Y asi te aseguro, comprobadísimo que no pierdes datos.


La verdad no se cual es el agravio comparativo. Pero puestos a mirar efectividad de código, con lenguaje compilado podría hacer simil de tus 128k con los 128k del MH de Nerlaska. El usa C y esto es una cruz por el espacio en CODIGO que usa. Y sin embargo te ha metido un RPG en 128k así. Y tu has metido un simple motor de juego, de menos de 8k en ASM, en 128k, por lo tanto a ojos de un programador se ve clara la diferencia, y Robsy lo mira con esos ojos.

Independientemente de eso, todo da un poco igual. Es un dato tiene en cuenta un programador cuando hace un análisis de otro programa, es deformación profesional. A ojos de un jugador, todo eso da igual. Lo que importa es el juego, no el tamaño que ocupa.

Y sobre todo HOY en día, y con las bases del concurso en la mano, claro. Ahora bien, si tu trabajases en una empresa de videojuegos para MSX de hace unas décadas y quisieras sacar Skate tal como lo has hecho, te aseguro que te hubiesen denegado el proyecto. Gastar el hard de un megarom con lo CARO que era en la época cuando encima no está justificado, pues no era algo muy normal.

¿O es que me puedes comparar la cantidad de "juego" y variedad de un Usas, un Salamander o un Galious, Golvellius (sigo?) que son 128k, con tus 128k?

Y si, antes de que me digas lo mismo otra vez, tu juego es totalmente legal para con las bases del concurso. Todo esto es un detalle, un comentario y no afecta para nada.


Ains ... este punto me pierde. Creo que no nos entendemos. Yo te digo, como Edu, que los 128k no están justificados, tu me dices que lo podía haber dicho antes, y yo te digo que no soy vidente y no podía saber como iba a ser tu juego. Y ahora me vienes con que está en las reglas y lo tenía que haber dicho antes.

Creo que no nos entendemos German. :) Yo hablaba como Edu, de tamaño 128k no justificado PARA TU JUEGO, no para el concurso.


No, no las entiendo, y pongo la mano en el juego que no soy el único que no se termina de aclarar con tus mensajes. :) Ya comentamos que a veces la comunicación telemática da lugar a maltentendidos y es lo que intento solventar.

A ver, no se como explicarte que yo depuro a nivel DE TODO. Y cuando el programa funciona correctamente y no tiene errores colaterales, gracias a mis testers, es cuando le hago el test de máquina para ASEGURARME que va en todas las plataformas compatibles MSX para los cuales el programa ha sido desarrollado.

¿Que parte no entiendes de eso? :D

Además, en este punto, no es tu caso, puesto que me he atrevido a mirar un poco tu código y veo qu ehaces alguna que otra burrada para seleccionar los slots del juego, ya que ignoras completamente el subslot. Hablo un poco sin poder probarlo, pero me huele que tu programa insertado en un cartucho y en un expansor de slots NO funcionará. :)

¿Ves? No es un error colateral, es un error de programa y ha de ser testeado en muchas máquinas para ver que pasa eso. La diferencia entre mi código y el tuyo es que yo YA tengo eso en cuenta y no tengo que hacer ese test AUNQUE LO HAGO. :)


A ver, aquí son habas contadas, y no hay programa en funcion de NADA. Tu debes de hacer un programa que vaya en MSX con 16k de Ram y 16k de Vram. Y PUNTO.  :) Y ese programa te irá si lo haces correctamente en TODOS los MSX. No hay más vuelta de hoja German.



Perdona tu programa NO es funcional, y te lo puedo demostrar cuando quieras.  Creo que te estás confundiendo mucho conmigo German, y con Edu y con los demás. Mi única intención es que puedas arreglar ese problema y no lo arrastres para tus futuras "aplicaciones". Aquí nadie te ha dicho las cosas para mal. Pero si tu sigues en tus 13 que todo va bien, pues adelante. No podré jugar a tus aplicaciones en mi MSX. Creo que no es eso lo que buscas, no?

El error en MSX1 no me lo invento, no saco nada con inventármelo hombre. :) Y además, precisamente estaba en mi casa Imanok anteayer cuando lo probamos y lo vio con sus propios ojos.

Repito: Sigo AQUI para que me mandes las pruebas que hagan falta, para ayudarte con las rutinas o lo que sea.

Y va a ser que yo tenía razón. Es que me has picado con que mire el código y tal. :P

Que he mirado tu código, y haces SENDOS *otir* para el render. Mal.

Sustituye eso por lo que te he explicado de outi y jrnz. Seguro que lo tenemos solucionado con eso.

:D

Mi consideración sobre el tamaño ha quedado perfectamente explicada por Ramones: me gusta que exista una proporción entre la complejidad del juego como tal y su tamaño. Y soy partidario de que en sistemas pequeños y limitados, como es el MSX, se debe optimizar al máximo el consumo de recursos (ROM, RAM, CPU). De todos modos, si quieres otros argumento de eficiencia, prueba a ver la comparación entre el tamaño de la ROM comprimida en ZIP y sin comprimir.

Respecto al "agravio comparativo" que aludes, me temo que no es tal: el GRID WARS, programado en C, me parece un juego más divertido, más MSXero y más original. Además, lo puedo cargar y probar en mis MSX1 de 64 KB sin usar hardware adicional.

Ahora abandono todos estos argumentos estériles porque cada uno es libre de programar como le venga en gana, en el lenguaje que quiera y utilizando las técnicas que prefiera, optimizando o no, comprimiendo o no, etc. A mi, lo que de verdad me revienta es que los juegos de más de 48 KB no pueden ser jugados en un MSX1 de 64 KB sin añadirle hardware adicional. Y esto no tiene nada que ver con las reglas de MSXdev, que son las que son y no he instaurado yo.

En serio, Germán, que no te tomes nada de todo esto a mal. Sencillamente no compartimos un mismo punto de vista respecto a lo que debería ser el desarrollo de videojuegos para MSX. Tú seguirás por tu camino y yo por el mío, pero en tanto sigamos produciendo juegos para MSX, todo está bien.

Respecto al tema de compatibilidad, te recomiendo que aceptes la ayuda que te ofrece Ramones para solucionar el tema de la corrupción de los gráficos del juego. En temas de compatibilidad y estandarización, Ramones es un halcón y sabe de lo que habla.

Buenas,


Ya que estamos, Ramones, podemos probarlo en mi VG8020. Si te pasas hoy por casa te lo llevas...  ::) ::) ;D ;D ;D

Yo fui testigo de los gráficos corruptos en el MSX1 Sony. En mi turboR y en el 8245 (con v9958) va perfecto, claro.

Y lo de utilizar gráficos de otros... pues en algunas ocasiones es mejor, para qué engañarnos. Tampoco es fácil encontrar buenos grafistas en el MSX. De todas formas, si encontramos uno, aprovechémoslo.  ;)

¿Y no será que esos OTIR están metidos con calzador en el VBL (si no son muy grandes, claro)?  ::).

En el foro hemos tenido auténticas charlas kilométricas acerca del tema, al final creo que se sacaron muchas cosas en claro :D

<filosófico>

Me resulta llamativa la afirmación; es curioso comprobar que con el paso de los años y con el consiguiente aumento en la complejidad del hardware y del software se ha pasado a un modelo de desarrollo en el que la aplicación debe de ser independiente de la arquitectura. Filosofía que, en cierta manera, el desarrollo para MSX compartía especialmente.
</filosófico>

 Saludos Robsy.


 Que si Robsy, que si. Pero es tu opinión y que se respeta, pero creo que se debe hablar de sistemas y cuanto más simples más eficientes son. Y la comparación del zip es improcedente en el sentido de que puede que lo que está en zip ya esté comprimido.


 Igual, es tu opinión.


 Pués eso es lo que decía!!!, ¿hay que preguntar a la gente de los foros como quieren la aplicación?


 Para nada Robsy, no sé por que interpretas eso. Y estamos en más cosas de acuerdo de las que tu te crees. Sobre lo de Armando, no es nuevo lo que dices, además de cierto.

 Recibe un saludo.

 Saludos Armando. Pués yo diría que te interesa a ti, por hacerlo funcionar en tu ordenador.



 Hombre!!, esto ya es otra cosa. Ya por lo menos haces una descripción y no te limitas a decir "esto no funciona", bien.



 Amante de datos no. Debes de decir las características del ordenador, que ya te he explicado que existe incompatibilidad a nivel de microcódigo.

 En ese ordenador debería de funcionar, no explica como haces la carga de la rom, ya que puede ser un problema del cargador, no sé.


 Demasiado categórico en tus afirmaciones. Y que es del programa es relativo, ¿quien te dice que no es por una interrupción o cualquier cosa a nivel de arquitectura de tu ordenador?, por ejemplo.



 Que no te preocupes Armando, tu aclara y ya está.

 Podrás observar en el procedimiento de render que comienza con un DI, ¿que más quieres?!!!. Y lo que te comenté de guardar los registros, se guardan todos.



 Mira que gracioso!!!  :D


 Claro, y lo exteriorisas metiendote con los programas de los demás. :P. Bromas aparte, es correcto y estoy de acuerdo con lo que haces siempre que sea constructivo, que te voy a decir.



 Pués lo mismo que tu, que al VDP le dé tiempo a realizar la escritura.



 Que sé lo que quiere decir Robsy, pero si hablas de conceptos como efectividad y pones de ejemplo un programa compilado, pués ya me dirás tu. Y que conste que el programa de Alberto es igual de correcto que cualquier otro independientemente del lenguaje usado, y te vuelvo a remitir lo que comenté sobre la gente que usa basic, por ejemplo.

 De todas formas se debe hablar de sistemas, y se sabe que cuanto más simple es un sistema más efectivo es.

 Ejemplo: en msx2 se puede realizar un scroll pixel a pixel solo usando la instrucción copy y muy poco código. En otros sistemas esto no es así, y es más complejo el desarrollo.

 Desde un punto de vista del código la aplicación de msx2 es más eficiente, usa muy poco código. Pero el sistema no es simple, es un msx2 con un procesador de video que actua de procesador satélite y libera al z80.


 Pués es lo mismo que el contest, se implementaría la aplicación en función, en este caso, de la situación de mercado. Pero tu no puedes hacer una comparación asimétrica, ya te explique que aquí no hay ánimo de lucro y cualquier forma de hacer un programa es correcta, y el ejemplo que tu planteas es otra cosa.


 Otro agravio comparativo. Pones de ejemplo a Konami, Compile, etc., con los programas de este contest!!!.



 Y yo te aclaro: creo que si, ya que con el mismo criterio se podría no justificar muchas otras aplicaciones, y no sería correcto.



 De eso nada, es correcta la implementación de la selección de slot. Y la diferencia con otros, es que insertan el código de selección de slot de konami, y después hablais de copias.


 Bien, lo que te planteaba era un ejemplo. Y eso que dices es muy parcial. Cierto que debe funcionar ahí, pero también en otros sistemas y modelos, y no porque funcione en esa configuración, ya te va a funcionar en las demás. Te puse el ejemplo de incompatibilidad a nivel de microcódigo, pero se puede hablar a nivel de puertos, etc.


 Creo que no me estoy confundiendo con nadie, ¿y eso de los demas?. Sé cual es tu intención y no sé de donde obtienes eso de "para mal", puede que de "los demas", no sé.

 No te voy a comentar que "todo va bien", pero creo que es correcto. Otra cosa es que tu creas que hay algo que no funciona y quieras que se revise, pués adelante!.


 ¿Quien ha dicho que te lo inventas?, y no es necesario que tengas a nadie, lo que tu digas me parece correcto. Por cierto, saludos a David!!!.



 Insisto, se agradece tu colaboración.



 Es que algo había que hacer para que hicieras algo más que comentar.  :P



 ¿Y a que has visto las pausas?, ¿y como las interrupciones estan desactivadas?, etc. Para que veas.

 De todas formas, esto ya es más interesante por que empiezas a aportar cosas. Lo otro son solo opiniones que se respetan aunque en algunas no se esté de acuerdo. :)

 Una sugerencia: sino te importa y si quieres seguir con el tema, esto se debería de seguir por email, ya que no creo que este sea el objetivo de este topic. Pero me da igual, es una sugerencia.

 Te envio por email la rom actualizada con lo que dices, tu diras.

 Para finalizar, agradecer tus opiniones y comentarios, que no se interpretan como algo negativo, independientemente de lo que te digan.

 Recibe un saludo.

Ahora sí que me he quedado pillado, Germán: si utilizas la instrucción OTIR (Ramones es quien la ha visto en el código, no yo), no entiendo cómo puedes forzar pausas.

Por otra parte, tu referencia a "incompatibilidades a nivel de microcódigo", aunque sea acertada, no soluciona el problema: los juegos deben funcionar perfectamente en todos los modelos de MSX con 16 KB de RAM. No vale echarle la culpa a la máquina, aunque en realidad sea así: de hecho, ésta es la razón de ser del "estándar" como tal.

Si algo NO FUNCIONA aunque sea en un único modelo de MSX, entonces no es "estándar MSX". Debe funcionar en TODOS, sin excepción.

 Tranquilo Robsy y desbloqueate  :D. Se entiende que las pausas estan entre los otir, además de otras que hay por ahí.
 Pero de todas formas, ya le he enviado la aplicación a Armando con sus modificaciones, haber que dice.


 Pués eso lo que he dicho. Que además de funcionar con esa especificación que tu das, deben de funcionar en los otros. Pero como existe la incompatibilidad comentada, además de otras, pués el programa se debe hacer en función a la arquitectura, o sea, que tiene que funcionar en todas las arquitecturas.


 Eso es. En el msxdev'05 recordaras que me enviaste un email comentando que una aplicacion no funcionaba en msx2 y si en los otros, y era por eso. Se modificó para que funcionará en msx2 y ya está.

Pues ahí, precisamente, está el error. No basta con introducir una pausa entre OTIR y OTIR, ya que lo que hay que hacer es introducir una pausa entre OUT y OUT (o entre OUTI y OUTI en su defecto). Sin esas pausas es lógico que los gráficos se corrompan al volcarlos.

 Saludos Fernando,


 Vamos a dejar que Armando testee las modificaciones.

Que va que va! :) Te equivocas. Si a mi Skate no me interesa nada, no me gusta nada de nada. :)

Solo busco que lo que hagas en el futuro y vista tu evolución como programador puede que si me interese, lo hagas correctamente. No busco otra cosa. Ayudar, nada más.



Si claro. Pero todo se basa en que tu luego te intereses o no en arreglarlo, como es el caso actual. Yo te digo que no va porque no va, y si tienes interesa ya me preguntarás que no va. :) Aunque es cierto que podría haberlo puesto desde el principio, no te quito la razón (lo que no se es si no lo dije ya, es que esto lo he hablado con varias personas y es posible que lo hiciese de viva voz).




German, deberías de fiarte un poco de mi en ese aspecto. El programa está cargado en una flashrom ascii8k. Y ejecutado desde la misma, por lo que es tan fiel como podría ser un cartucho original.

Y no hay microcódigo que valga. Si va en mi MSX, debe de ir en todos, o resumiendo, que si tienes en cuenta lo que los TH del standard dicen, salvo por error de programa, todo ha de funcionar.



Si si, mi HB20P tiene unos brutales problemas de arquitectura. Dejémonos de "palabrejos" de programación  moderna puesto que se le quedan grandes al MSX.

Mira, si tu programa no funciona, te aseguro que es culpa tuya. Y así ha sido. Puede quedar un poco agresivo, categórico, o como lo quieras definir, no te voy a contradecir en este aspecto. Ahora bien, si en ese ordenador funcionan todos los demás juegos, está claro que algo falla en el tuyo.

Dudo mucho que tu hagas "algo" (por llamarlo de alguna manera) de una manera tan especial que produzca, o reproduzca un error interno de esa máquina. :D


Podré observar ... ains ... nene, que me lo pones complejo del copón. Me toca desensamblar tu código, que para alguien acostumbrado al ASM "normal" es un poco churro ya que los desmierdes producidos por el compilador de C vuelven loco al que desensambla.

Entiendeme, he hablado MUCHAS veces sin mirar el código en muchas cosas de las que te he comentado que revises, pues son fallos genericos que todos hemos tenido alguna vez. Solo hasta que no he visto los otir, no he podido afirmar a ciencia cierta que SI era ese el fallo.


Si, pero es que el otir no se puede partir a trozos. :D Es decir, que (para seguir el rollo divertido), igual si te acercas mucho al otir puedes verlo a nivel de microcódigo y partirlo.

(bueno, igual el chiste ha quedado un poco retorcido)



¿Qué puñetas os enseñan hoy en día en la universidad? :D De verdad, menudo cacao mental os hacen. Lo flipo.

Realizar un scroll pixel a pixel con copy, no es efectivo. :D Yo lo miro a nivel global. Pues si lo haces, a pantalla completa, si, es simple, pero luego no podrás meterle un juego lento, pues será patético.

O sea que a nivel de código, la aplicación de MSX2 es más eficiente, pero a nivel de juego es un desastre. :D

Es que me aburren esas teorías modernas de códigos eficientes y leches. Lo eficiente lo que en pantalla demuestra que es eficiente. El código interno importa una puñetera mierda (hablando mal, es que hacía días que no soltaba un "mierda" en el foro, y creo que estaba perdiendo idendidad)

:D


Si, cualquier forma es correcta. Ahora bien, yo a tu juego no juego y a Grid Wars si juego. Mirandolo asimétricamente, tu juego no me importa, y grid wars si.... ¿o sería mirándolo a nivel de microcódigo?

Dios, creo que me voy a acostar, me he liado con tanta palabra. :D

(conste que intento mantener un tono de bromeo, a ver si ahora nos vamos a enfadar) :P


Claro. Es que yo quiero que TODOS los programas presentados al concurso tengan la misma jugabilidad y calidad que los de Konami o Compile.

¿Existe alguien en el foro que NO QUIERA ESO? :D Por dios! Sería lo máximo, y creo que es lo que buscan TODOS los que desarrollan para el Dev. Aprender y aprender para llegar a esas cotas de calidad.




Esto ... iba a usar la palabra mierda por segunda vez, pero creo que podría acarrear mal rollo y no lo busco. NO, tu rutina es totalmente incorrecta. :)

A ver ... que aquí te has hecho una paja mental con copia y original. La rutina de seleccion de slot, encima, viene en los TH, te dicen como tienes que hacerlo, así que Konami, pobrecita mia, no hizo nada, solo la copio de los TH.

Tu haces los siguiente:

ROM1:7898 DB A8        in   a,(A8)  ;ppi port a (pslot)
ROM1:789A F5           push af
ROM1:789B E6 0C        and  0C
ROM1:789D 07           rlca
ROM1:789E 07           rlca
ROM1:789F 47           ld   b,a
ROM1:78A0 F1           pop  af
ROM1:78A1 E6 CF        and  CF
ROM1:78A3 B0           or   b
ROM1:78A4 D3 A8        out  (A8),a  ;ppi port a (pslot)

Y que quieres que te diga? :) Que no tienes en cuenta si el slot esta o no esta EXPANDIDO, pues no te veo que toques para nada la direccion 0FFFFh.

Así que sin probarlo, de nuevo, oh valiente de mi, puedo arriesgarme a decirte que no funcionara en un slot expandido.

Tranquilo, no eres el único, programas COMERCIALES de MSX la cagan de igual manera.

La manera CORRECTA, creo que ronda por el foro en 10000 sitios, pero aún asi te la voy a pegar. :)

; -----------------------
; SEARCH_SLOTSET
; Posiciona en pagina 2
; Nuestro ROM.
; -----------------------

search_slotset:
            call   search_slot
            jp      024h


; -----------------------
; SEARCH_SLOT
; Busca slot de nuestro rom
; -----------------------

search_slot:
            
            call   0138h
            rrca
            rrca
            and      3
            ld      c,a
            ld      b,0
            ld      hl,0FCC1h
            add      hl,bc
            ld      a,(hl)
            and      080h
            or      c
            ld      c,a
            inc      hl
            inc      hl
            inc      hl
            inc      hl
            ld      a,(hl)
            and      0Ch
            or      c
            ld      h,080h
            ld      (slotvar),a
            ret



Hombre, tampoco hay mucho que aportar. Es decir, que yo te lo aporto de todo corazón por lo que te he dicho. Pero si te digo: "Oye tio, tal, esto no va", hasta ahí llega mi "trabajo" de ayuda si quisiera. El que tienes que solucionarte las cosas eres tu mismo. :)

Y no, perdona, repito lo del chiste, no he visto las pausas. Que la pausa tuya esta entre OTIR y OTIR, no entre cada iteración del OTIR que es donde hace falta. :D

(captas ahora?) ;)


Me parece correcto puesto que hemos mezclado ya demasiadas cosas. Mi dirección está en mi usuario. Puedes escribir ahí. :)



A mandar. :)

Vamos, que te ha dicho lo mismo que yo... que para eso no hace falta testear nada :P

Una preguntilla chorra, que me he quedado acongojado con el tema del microcódigo. ¿A qué llamáis microcódigo? ¿Dónde tienen microcódigo los MSX?

 Ya, ya, lo que tu digas, vaya vocabulario!!!

Esto ... German ... ¿me lo has enviado?

Lo siento, no he recibido nada. Repito, mi dirección está en el usuario.  ???

Reenvía please! :)

¿Perdón? ???

Olvídate, de verdad... :(

Edito:


Y rebuscando por el foro he redescubierto este hilo, muy ameno leerselo de cabo a rabo :D:

http://www.msxgamesbox.com/karoshi/index.php?topic=305.0

Y otro hilo muy ilustrativo es este otro del MRC:

http://www.msx.org/forumtopic6262.html

Si, el MSX si tiene microcódigo. Si tu Rom del Basic y de la Bios es más pequeña que la mia, su código es microcódigo frente a mi Rom.

:D :D :D :D

Además demostración de que si te acercas al OTIR mucho se ve el microcódigo y puedes poner pausas, la adjunto.

;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D


Acabo de ponerla como fondo de pantalla del windows... es brutal!!

Bueno, Germán, sigo sin recibir nada.

Pero ANTES de que lo hagas, he comprobado (acabo de llegar a casa, menudo día hoy) que, efectivamente, el juego no funciona en el Expansor de Slots. :(

Cambia la rutina de inicialización del slot por la que te he pegado y lo tendrás solucionado.

En cualquier caso, hay una cosa que no se, a ver si alguien me lo puede explicar:

¿Sería legal que subiese la Rom German ahora al concurso?

Creo que no, puesto que Jon también tuvo un problema y ya no le entraba (en Malaika).

Creo que abriré un hilo nuevo sobre esto. A ver que piensa el personal...

Buenas

He probado la ROM actualizada (la de mapper ASCII8ks) y efectivamente, los gfx se corrompen en mi HB20P, y no funciona en expansor de slots.

Pues hasta donde yo sé, las reglas de MSXdev son claras: los jueces sólo tendrán en cuenta las versiones de las ROMs entregadas antes de las 0:00 del 1 de Enero de 2007, es decir, todo lo que llegara hasta las 23:59:59,9999... del 31 de Diciembre de 2006. Por lo tanto, lo que llegó antes del deadline.

Las versiones posteriores, sean bugfix o lo que sea, se distribuyen desde el mismo site de MSXdev para centralizar de algún modo el tema, pero no serán consideradas por los jueces.  :P

De todos modos, mejor si nos lo aclara la gente del MSXdev TEAM.

 Ya por eso lleva todos los post que llevas sobre la aplicación, por desinterés. :D


 Se agradece, nada más. :)



 El interés es el mismo que puedas tener tu. Yo creo que tu estás interesado en que funcione, aunque ya sabes que creo que es funcional. Por eso se contesta a tus post y que esto debería de ser por email, he observado que tu estás interesado, por mucho que digas que no te gusta :D, y hay una correspondencia, eso que llamais feedback y además que me parece interesante.



 Hombre!, observaras que algo de caso te hago, no mucho pero si algo. :D


 Bien, tu diras como quieres que te diga las cosas. No se trata de incomodarte ni decir como es tu ordenador.


 No estoy de acuerdo. En el msxdev anterior hubo sanciones a distintos programas por escrituras incorrectas en un registro del psg, ¿fueron en todos los casos culpa del desarrollador?, ¿es un problema de arquitectura?.



 ¿Me estás desestimando? :D


 No sé de que hablas, ya que el proceso que estamos tratando es puro assembler, pero si te molesta déjalo. :(


 Ah, que gracioso!!!. Ya sabemos que el otir tiene implicito un bucle, y que el contador de ese bucle es el registro b, pero si te fijas el registro b siempre está a cero.


 No sé lo que enseñan hoy, me parece que ese vocabulario no.


 Pués eso!!!. No sé lo que entendeis.


 No me parece adecuado ese vocabulario en un foro público, aunque creo que son parte de las bromas tuyas, y es incomodo tratar a alguien que muestra interés asi, tu mismo.

 Si quieres que se te hable de otra forma, lo expresas y ya está. Te comento lo de antes, no se trata de que tu estes incomodo.



 Lo que a mi me importa!!!. :P. Míralo con tu vocabulario identatario, ja. :P


 Que no te preocupes Armando. :)



 Pués la llevas clara. :D
 Participa tu, y da ejemplo.


 Ya te dije por que creo que participa la gente, y me parece que no es por adquirir conocimientos. Y tu mismo tuviste que responder a algunos por aquí, de por que participaban.


 Creo que la has usado, podías haberla borrado. :D.
 Y eso de "totalmente incorrecta", para nada.


 ¿Una que?, habla por ti. :P. Ya hasta Konami copia!!!, sigue.


 Bien, ¿y quien ha dicho que el slot tiene que estar expandido?



 Uy! ya podemos estar tranquilos. :D. ¿que programas?, ¿Konami antes de ver el TH? :D



 No, en algún sitio más. Se te agradece el código, ya lo sabía. Lo que no sabía es que se iba a mirar tantos detalles.


 Es que si solo haces críticas, pués no haces nada. Eso lo hace cualquiera, es más fácil redactar un post haciendo una crítica que otra cosa, y eso no es "trabajo" ni nada.

 Y eso de quien tiene que solucionar las cosas, es relativo. Si se parte de que no hay problema, no hay que solucionar nada. Otra cosa es que halla otros que vengan con los problemas y solo eso.



 Que vas a ver!!! :P.
 Bien, si eso es así el ejemplo que tu mismo pusiste anteriormente es incompleto, solo desactivabas las interrupciones.



 Si ya me imaginaba que el asunto iba por ahí. Si alguien tiene algún problema pués que retiren la aplicación, o si alguien no quiere que participe que lo diga claramente. >:(

 Además, tu sigue riendote y faltando al respeto sobre asuntos que son ciertos como el microcódigo y otros temas, y que van varios post ya. >:(


 Pués no sé para que sigues redactando tantos post sobre el asunto. Y mi dirección ya sabes donde está también.


 Saludos Armando.

Pues no hay nada más que aclarar. Efectivamente, lo válido al concurso es todo lo enviado ántes de 2007. Todo lo demás son apaños y updates que no cuentan a la hora de juzgar el juego... nótese como el pequeño update que hice del Maliaka no ha sustituido el ROM inicial, sino que se ha añadido.

Así que cualquier update será bienvenido... eso sí, no podrá contar con ser judgada por los jueces, que ya están desarrollando en este preciso instante su trabajo de valorar las entradas.

Gracias por la confirmación, Jon!

¿Se mantiene la fecha "oficial" de comunicación de resultados? ¿O es posible que ésta se adelante/atrase por motivos diversos? La verdad es que no les cambio el papel a los jueces: hay unos cuantos juegos de la MSXdev'06 entre los que resulta difícil "elegir".

Bueno, a este respecto, me gustaría decir que aquello fue mea culpa (culpa del desarrollador). El port del replayer se hizo en enero de 2005, se estuvo utilizando en varias aplicaciones, demos y juegos a lo largo de ese año y nadie detectó nada. Se creía un código correcto, por lo que la gente lo utilizó sin pararse mucho a mirar el código. El "problema" no se detecto hasta enero de 2006, un año después!!!  ???

Creo que aquella "matanza" en la dev fue algo desproporcionada. Me gustó mucho la forma de comentar los juegos pero creo que alguien se pasó un poquito.

Bueno bueno ... vale. No te vayas a enfadar ahora hombre. :) Siempre es mejor tomárselo a broma. Creo que tengo más motivos que tu para enfadarme con tus mensajes y aquí me tienes con la sonrisa en la boca. :)

Voy a intentar explicarte lo del OTIR y OUTI en privado y lo de los expansor, que tengo la impresión de que todavía no lo has entendido. Si contesté por aquí es sencillamente porque así todo el mundo podía ver como resolver problemas que son comunes en los desarrollos, cuando uno es principiante. Todos hemos pasado por ahí, y creía que todo el mundo tenía derecho a entender como se hacen las cosas.

Pero no le demos más vueltas, ya seguimos todo por privado. ;)

(alegra esa cara hombre!)

Dioniso: creo que estás en lo cierto respecto a que el tema del uso ilegal del registro 7 del PSG fue un poco excesivo. Más que nada, porque hemos descubierto DESPUÉS que algunos de los juegos presentados tienen problemas de compatibilidad bastante más serios.

Es decir: el tema de los 2 bits más altos del registro 7 no hacía que los juegos "funcionaran mal", ni afectaba a la calidad del sonido. Lo único que hacía era contravenir una recomendación de seguridad hecha por el estándar MSX. Literalmente, que si los dos bits más altos no son 10xx xxxxb, el PSG se puede fundir  :'(

Sin embargo, se han detectado POSTERIORMENTE otros fallos que sí afectaban a la compatibilidad/jugabilidad de los juegos, tales como que no se espera lo suficiente en las copias sucesivas a VRAM, por lo que se corrompen datos gráficos en MSX1. Otros problemas detectados incluyen manejo inadecuado de slots, posible uso de instrucciones no oficiales del Z80, etc.

Por supuesto, todo esto ha sucedido en MSXdev y sucedió durante la vida comercial del MSX. ¿Supone un problema? Probablemente no, pero aquí se trata de hacer las cosas bien. Respetemos el estándar al máximo. ¿Qué somos? ¿Spectrumeros renegados? Nononono  ;)

De hecho, por mi parte creo que habría que empezar a hacer las ROMs para que funcionen con únicamente 8 KB de RAM, tal y como hacía Konami. El principal problema que supone esto es que después las ROMs pueden dar problemas al ejecutarse desde disco con un cargador, por el más que posible solapamiento de RAM de disco y área de variables del juego. Tampoco penséis que esta limitación sea tan dramática: el OPERATION WOLF, una de las grandes sorpresas de MSXdev'06, utiliza sólo 8 KB de RAM. Por lo tanto, en teoría es 100% usable en todos los MSX. Repito: TODOS. Que yo sepa, sólo hay 2 modelos de MSX fabricados por CASIO con 8 KB de RAM. Supongo que en estos ordenadores, un simple 10 PRINT "Hello, World!" produciría un Out of memory in 10. ;D

Me gustaría saber si el que detectó el detalle fue el propio jurado y la penalizacion vino a poseriori. Que menos que penalizar al que le quemó en PSG del TR.... ;D

 Pues yo no diría tanto. Esto es lo que dice: "31st December 2006: game submission deadline ".
 ¿Donde habla de actualización?. Habla de la entrega del programa y eso ya está hecho.


 Solo te falta decir el nombre :(. Si todas las aplicaciones se observaran con el mismo rigor..... >:(


 ¿Extremistas del assembler?  :D


 Lo dicho antes.



 Bien, planteaba opciones en forma de preguntas, pero si te quieres responsabilisar, tu mismo.

 Creo que se puede observar también como diseño de arquitectura, incluso de no advertencia en los manuales de explotación.

 Se puede observar como al lado del slot de cartuchos, suelen poner un mensaje de advertencia de no conectar el cartucho con el ordenador encendido. Pero en los manuales del ordenador no viene nada del problema del psg, sabiendo que un uso inadecuado del mismo, igual que los cartuchos, puede estropear el ordenador.


 Pués no lo creo, ya que no he dicho nada para que te enfades.


 Que lo tengo muy claro, más de lo que tú te crees. Pero sigue...


 ¿Que soy que?. Ya habló el experto :D. No tienes ni idea de quien soy, y me parece prepotente por tu parte emitir esos juicios de valor.


 Además ya te lo comenté, este topic no está orientado a ello.


 Que me dá igual, que ya sabemos de hace tiempo que es lo que pasa.

 Saludos Armando, espero que puedas probar y observar con las nuevas aplicaciones que los conceptos están muy claros.

Germán:

Léete mi post entero, no en diagonal. Dioniso y yo estábamos hablando de las penalizaciones de MSXdev'05. Hubo entradas de MSXdev'05 que fueron penalizadas por el tema del bit alto del registro 7 del PSG muy severamente, cuando había en realidad otros problemas que no se pusieron de manifiesto y han sido detectados posteriormente. Esto afectaba a un listado considerable de juegos, que no comentaré aquí.

A esto me refería cuando hablaba de los problemas de corrupción de gráficos, manejo de slots, registro 7 del PSG. Es decir, la última competición en la que fui organizador, MSXdev'05.

Como comprenderás, no puede haber penalizaciones publicadas sobre MSXdev'06 porque no hay veredicto sobre MSXdev'06.

Por otra parte, vuelvo a flagelarte con mi látigo en llamas, lo que yo amigablemente llamo "mi opinión": no es de recibo hablar de manuales de explotación, problemas de arquitectura o microcódigo en el ámbito del MSX. Un MSX es cualquier ordenador que ponga MSX y se atenga al estándar. Que el estándar es más laxo de lo que debería ser? Sí, es verdad. Pero el estándar mismo deposita esta reponsabilidad sobre los programadores. Todo lo que se refiere al estándar puedes encontrarlo en el MSX Technical Databook, que te recomiendo que leas. Incluye una sección muy interesante, dedicada a los programadores, para ayudarles a garantizar la compatibilidad de sus aplicaciones.

Por lo demás, sugiero que ahorremos todos tiempo dedicándonos a quehaceres más productivos, tales como programar. Tratemos de que todo sea compatible, ésa era la idea que queríamos transmitir y que no sé si hemos conseguido a lo largo de este largo cruce de mensajes.

Robsy:


 Los leo de forma correcta, y no como otros que se dedican a contestar a medida que leen.  :)


 Lo que se comentó es que se estaba realizando, otra vez, agravios comparativos.
 
 Además si te lees bien mis post, no solo los tuyos hay que leerlos correctamente  :D, observarás que no responsabiliso a Alfonso de ese error para nada. Pero que es llamativo como valoras una cosa que puede estropear el ordenador con otra que no lo hace, y que también lo reflejo en el post anterior: no existe el mismo rigor y se dice una cosa u otra según quien habla.


 Aqui solo observé lo del registro 7. Además ya que hablas de ese contest, te puedo decir y tu lo sabes bien, que en ese contest no presenté ninguna protesta ni nada sino todo lo contrario. Asi que, algo distinto hay en los siguientes.  >:(


 Ya sé que no las hay, pero que no es difícil imaginar lo que va a pasar, que hay precedentes, basic contest???   >:( >:( >:(


 Que gracioso !!!, cuidado con las agresiones que aqui también sabemos hacer eso.  :D

 Y si, creo que se puede hablar de todo lo comentado, por que existe. Y ya sabemos lo que es el standard.



 ¿Que deposita la responsabilidad sobre los programadores?, ¿donde habla de eso?. Se podría decir lo contrario y sería igualmente válido.

 Otra cosa es que sabiendo lo que hay, querais superar eso. No creo que sea responsabilidad del desarrollador, pero claro, la aplicación tiene que funcionar. En este sentido y según tu criterio, todas las aplicacione deben funcionar en todos los sistemas, pero que ya sabemos lo que pasa cuando una aplicación hace uso de características del msx2, por ejemplo. Entonces ¿de que compatibilidad hablas?

 Y el manual ese, ya lo leí o alguno parecido, no sé, pero que no te creas que todo esta documentado.


 Eso de hacer cosas más productivas, lo he dicho ya desde hace tiempo, pero puedes observar en los post de éste foro que hay gente que le divierte más hacer otro tipo de cosas.


 Que si, que ya sabemos lo que querías decir, pero que hay más que eso y que las cosas se pueden hacer de mejor forma.

 Para finalizar comentar lo siguiente:


 Y te quedas tan tranquilo !!!. Es la organización la que debe revisar los excesos de los jueces y demás irregularidades, de ésta forma no hubieran ocurrido ciertas sucesos anteriores.

 Los jueces solo pueden evaluar según las bases y no según crean ellos.

Lectura obligatoria (http://www.robsy.net/msxtech.pdf).

Habría que pasarse por el hilo de desarrollo compatible que está haciendo JLTursan. :)

Creo que después de leer el TH que explica Edu, en ese hilo hay ejemplos FUNCIONALES de como hacer las cosas.

Así que creo que nadie tiene la excusa del desconocimiento y de la falta de información.

YMN, se me está acabando la paciencia...

 ???

Ejem ... esto ... Germán ... que lo que podrías hacer es, aplicarte un poco el cuento que tu reclamabas, y si tienes algún problema con Robsy o con alguien, solucionarlo en privado, como me pedías que hiciese yo cuando te contestaba.  :-*

Creo que esto es lo que te intenta decir Jon. :)

Así que aprovechate de los privados ya que existen, tanto en el foro, como con algunos usuarios su dirección personal de mail, para solucionar los temillas.

Es que no se puede recriminar una cosa y luego no aplicarla uno mismo. ;)

 sjp:)

 Que no hay ningún problema con nadie. Otra cosa es que exprese una opinión, aunque halla gente que no le guste.
 Y yo no te solicité nada. Te comenté una sugerencia, pero que me daba igual si querias seguir con el tema en el foro.


 Bueno, ha sonado a otra cosa... :(. Será por eso que tu dices de la telemática y de entenderse.  ;)



 Que sé como hay que hacer las cosas, y algún aludido sabe que yo realizo esto así.


 Que te voy a decir, puedes dar ejemplo.



 Por cierto Armando, todavía no he recibido respuesta del último email, y es que aunque se trate el asunto como se trate, se debe responder.

 Saludos.

Hola a todos,

     Solo daros mi opinion sobre el desarrollo del msxdev. El nivel de los juegos va subiendo año a año, asi como la participacion, lo cual es una buena noticia para el msx en general. Decir que tal vez los criterios del jurado no ha quedado demasiado claro y hay algunas posiciones un tanto sorprendentes.

   Animo y a ver si el 07 sale tan bien como este ( y a ver si yo presento algo, que ya me vale ^_^!!!!)


Roberto

Hombre, k0gulator!. Pues a ver si es verdad y nos soprendes este año con alguna producción!.

Por cierto, estarás en Madrid?  ;)