Karoshi MSX Community
22 de Noviembre de 2017, 07:32:56 am *
Bienvenido(a), Visitante. Por favor, ingresa o regístrate.

Ingresar con nombre de usuario, contraseña y duración de la sesión
Noticias:
 
  Inicio Ayuda Buscar Calendario Ingresar Registrarse  
  Mostrar Mensajes
Páginas: [1] 2 3 ... 12
1  Foros de Desarrollo (Español) / Desarrollo / Re:MegaRoms : 09 de Noviembre de 2015, 09:22:30 am
Genial. Gracias Mortimer, nanochess. Me pongo a probarlo!
2  Foros de Desarrollo (Español) / Desarrollo / Re:Código fuente de Zombie Near : 06 de Noviembre de 2015, 01:40:25 pm
Gracias por compartirlo!
3  Foros de Desarrollo (Español) / Desarrollo / Re:MegaRoms : 06 de Noviembre de 2015, 01:27:14 pm
Entonces, si uso ASCII 16K, escribiendo en $6000 y en $7000 cambio el bloque. Los bloques en la ROM van seguidos. Si es un cartucho real, entiendo que hay un circuito que detecta esas escrituras y hace el cambio de página.

Pero si va en un emulador, hasta ahora un fichero ROM de 32Kb tiene las dos páginas de 16Kb. Un MegaRom de 128Kb tendría los 128Kb seguidos. El mapper lo debe soportar el emulador. ¿Cómo sabe el emulador qué mapper usa mi juego?
4  Foros de Desarrollo (Español) / Desarrollo / Re:MegaRoms : 05 de Noviembre de 2015, 08:07:22 pm
Gracias Mortimer, nanochess! Lo tengo mucho más claro. Aunque hoy tengo un día muy liado y no puedo ponerme a digerir bien la información. Mañana lo miro detenidamente, consulto el enlace y miro si lo tengo claro del todo.

5  Foros de Desarrollo (Español) / Desarrollo / MegaRoms : 04 de Noviembre de 2015, 01:52:49 pm
Buenas!
Pensé que programando en ensamblador nunca llegaría a crear un MegaRom porque para mi, debería estar muy justificado el usar tanta memoria. Bueno, pues lo justifico y me meto en ello  Smiley

Estoy bastante perdido con el tema. Siempre he pasado de puntillas con el tema de Slots  y subslots, ciñéndome a hacer copy/paste de rutinas de detección de slots o el tema de las ROMS de 48Kb (gracias Ramones). He buscado información, he leído sobretodo el tema de slots/subslots de Konamiman, Ramones, jltursan, y referencias a Megaroms de Nerlaska, Jos'b y más.

Me encantaría tener más tiempo para ordenar el follón de conceptos que tengo ahora, pero bueno, ya sabemos todos como vamos de tiempo...
Agradecería una guía o unas respuestas a preguntas concretas para ver si puedo acelerar el tema:

- Entiendo que hay 4 páginas con 4 slots/página con 4 subslots/slot = 64 paginas * 16Kb/página = 1024Kb posibles. ¿Es así?
- No entiendo cómo va montada una ROM usando slots y subslots. Si en 0x4000 tengo mi página 1 del slot 1 donde tengo mi rom y quiero activar mi página 2 en 0x8000, pues lo entiendo. Pero si esta página tiene subslots, ¿cómo van organizados en la ROM? ¿En qué direcciones de memoria las debe poner el ensamblador?
- ¿Qué es un mapper? ¿Es un circuito personalizado que permite acceder a una estructura personalizada de slots/subslots? ¿Por eso hay tantos tipos? ¿Por eso los debe soportar el emulador, porque es hardware?
- ¿Por qué hay mappers con páginas de menos de 16Kb? Si activo una página, entendía que se activaban los 16Kb...

Sé que el excelente asMSX gestion Megaroms y se que hay tutoriales para SDCC. Pero cambiar ahora de ensamblador me llevará tiempo y prefiero ya puestos a gastarlo, que sea para entender el funcionamiento interno de los MegaRom.

Gracias por vuestro tiempo.
6  Foros de Desarrollo (Español) / Desarrollo / Re:Conversor para gráficos monócromos : 03 de Diciembre de 2014, 03:07:09 pm
Buenas. En la versión última que tengo de nMSXtiles hay una opción que es "Reorder Colors" en el menú "Tiles Tools" que puede que te sirva.

Has de importar la imagen en formato PNG pero para ello antes debes crear un fichero "paleta" (un fichero PNG normal). Cuando el programa importa el PNG mira el color del píxel y se va al fichero "paleta" y busca entre los 16 primeros píxels a cuál se corresponde. Entonces, si el color leído es el mismo que el color del fichero paleta en la posición 8 por ejemplo, pues será un rojo de MSX. Y así... Por tanto, antes has de confeccionarte un fichero paleta. Como dices que es a dos colores, creas un fichero paleta (recuerda que es un fichero PNG normal), captura el color (por ejemplo con GIMP) negro utilizado y lo pones en el píxel 0 del fichero paleta. Y capturas el color blanco y lo pones en el píxel 15 (si empiezas a contar por 0).

Creas un nuevo proyecto, Importar, te pide primero el fichero paleta y luego el fichero a importar. Si todo ha ido bien, en los bancos de tiles te saldrá la imagen. Entonces, le das a la opción "Reorder Colors" y te pondrá todos los pixels blancos juntos. Parece lioso lo del fichero paleta pero si entiendes el funcionamiento, es trivial.

Si no encuentras otra cosa y no te sale, envíame el fichero y te creo la paleta.

nMSXTIles v0.8.5-> https://www.dropbox.com/s/gbzaacvcfc5ycbp/nmsxtilesv0.8.5.zip?dl=0
7  Foros de Desarrollo (Español) / Desarrollo / Re:Código automodificable : 11 de Julio de 2014, 03:22:57 pm
Okk. Lo que sí veo es que siempre ocupa el mismo ancho, que sí que es de esperar. Gracias.
8  Foros de Desarrollo (Español) / Desarrollo / Re:Código automodificable : 10 de Julio de 2014, 06:22:36 pm
Decía que sale el rectángulo del mismo tamaño y en el mismo sitio. Y bueno, en el mismo sitio exacto no.

Si hago:

Código:
Loop
  HALT
  Borde=blanco
  noop
  noop
  noop
  Borde=negro
  jp Loop

Sale una línea en la parte baja pero no siempre comenzando en el mismo píxel exacto, aunque sí del mismo tamaño cuando sale. Se repite un patrón en la que comienza en un píxel, en el siguiente refresco desplazado y en el siguiente refresco no sale. Esto con el openmsx al 1% de velocidad. Con el bluemsx sale algo parecido pero no en el mismo sitio que el open. Y en un MSX real... pues a ver si luego puedo montarlo y lo pruebo que estoy intrigado.

¿Es normal que no salga siempre en el mismo sitio, cosa que no entiendo, o es cuestión del emulador?
9  Foros de Desarrollo (Español) / Desarrollo / Re:Código automodificable : 09 de Julio de 2014, 09:36:45 am
Gracias por las respuestas. Veo que la ganancia no es muy significativa entonces.

Para ver como vas de tiempo, el truco más sencillo y visual creo que es cambiar el color del borde, ya que cambiar ese registro en el vdp hace que inmediatamente el borde empiece a dibujarse en el color indicado. Así que incluso le puedes poner incluso a cada rutina un color distinto y tienes una visual de cómo van los tiempos en el borde.

Me parece superinteresante. Es algo que había oído pero no me había puesto. Así que he hecho unas pruebas y veo que el tiempo que me ocupa una rutina parece fijo porque el rectángulo que se dibuja en pantalla es siempre del mismo tamaño. Pero noto que a veces me sale más arriba y a veces más abajo... Todo esto en un emulador.

Hago:

Código:
Loop:

//Cambio fondo a blanco
 ld a,15 ;color
 out [$99],a
 ld a,7+128
 out [$99], a

 //Rutina

 //Cambio fondo a negro
 ld a,0 ;color
 out [$99],a
 ld a,7+128
 out [$99], a

 HALT
//Escribo en VRAM
jp Loop


En el VBLANK el VDP va dibujando el fondo. Entonces en el momento que le digo que cambie el fondo, ¿lo sirve al momento? Porque entonces no entiendo bien porqué no me sale siempre el rectángulo en la misma posición. Sí que sale siempre en la misma zona (inferior o superior según las pruebas) pero no siempre exactamente en la misma línea.  Huh (Todo esto partiendo de que he comentado casi todo el código y lo que calculo a cada pasada en teoría es siempre lo mismo.)

Edito: Perdón, perdón, como lo estaba probando sin sonido tenía el pequeño detalle que estaba el player funcionando de fondo  Spank

Sale perfecto, igual tamaño y mismo posición. Genial.
10  Foros de Desarrollo (Español) / Desarrollo / Re:Código automodificable : 08 de Julio de 2014, 08:01:39 pm
Yo personalmente procuro leer el numero de puerto en la BIOS <ld   a,(7)>, y lo paso al registro c <ld   c,a> antes de "outear" Cheesy
Sin automodificable, vaya. No suelo ir tan apurado como para tener que afinar tanto. Normalmente si necesitas ir tan apretado es que algo falla en el diseño del juego.

Ok, así lo hago. Respecto al diseño, pues seguro que es mejorable. Pero me refiero a que si con "el diseño perfecto" muevo n elementos en pantalla, y haciendo tres apaños así consigo mover n+x elementos, pues mejor, independientemente del diseño  Wink

Pero no me he puesto a medir exactamente el tiempo que ocupo entre interrupciones y el que me queda libre (porque no se hacerlo con exactitud básicamente). Entonces no se si estos apaños tampoco darían para mucho. Por eso preguntaba si es una práctica habitual, en cuyo caso supongo que sí se gana, o no lo es tanto por lo que creo entender.


11  Foros de Desarrollo (Español) / Desarrollo / Código automodificable : 08 de Julio de 2014, 04:04:30 pm
Desarrollando Náyade he prestado mucha antención a los accesos a memoria, para minimizarlos lo máximo posible en operaciones que se repiten mucho, como la colisión de cada disparo con cada enemigo, nave con cada enemigo, etc. Se trata de encontrar un buen balance entre velocidad y espacio: usar funciones con sus parámetros y sus accesos a RAM o si esas funciones son cortas, duplicarlas con los parámetros fijos y convertirlas en macros. Bueno, no descubro nada nuevo.

Pero veo situaciones como al escribir a VRAM en que no se puede asumir que los puertos 98 y 99 sean para todos los MSX, en que se podría consultar el valor, modificar la rutina al inicio y así ya no hay que consultarlo cada vez. Y a partir de aquí se me ocurren un montón de "bizarradas" para rascar algún acceso a memoria.

Mi pregunta es: ¿Es una práctica habitual? Konami por ejemplo, ¿lo solía hacer? A cada uno nos atrae un motivo para programar para MSX. A mi me hace gracia hacerlo dentro de las limitaciones/costumbres de la época (con todas las comillas que queráis, porque ahora tengo emulador, debugger, etc).

Es obvio que debería copiar a RAM la rutina.

Pues eso, ¿es una prática habitual? ¿Lo usáis los developers? ¿Se usaba?

Edición: Sí, he quitado el offtopic  Tongue
12  MSXdev Game Development Contest Boards (English) / MSXdev '14 / Re:Pretty Kingdom is the MSXdev'14 WINNER! : 03 de Julio de 2014, 03:47:43 pm
We can agree more or less with Jon's decision but I think it's good to keep in mind that who is adding, creating and dedicating efforts (and not breaking) for the MSX scene is Jon.
13  MSXdev Game Development Contest Boards (English) / MSXdev '14 / Re:Pretty Kingdom is the MSXdev'14 WINNER! : 03 de Julio de 2014, 08:36:08 am
Congratulations to the winner.

I don't know Ramones but I respect a lot his work. When I saw he was voted I was very interested in his opinion. When I read the votes I thought "come on... I think it's not necessary to be so destructive. There are no evil submiting this games." I think he can offer more than this to the MSX but, eh! he has no obligation! All this words are to say that then I thought: I don't want to continue making games for MSX. As a child, I know. It's funny because I have been (internally) so critical with developers that, for one or two persons, claim in many forums that they leave MSX development, like (sorry for them) an angry child. But yesterday I understood them a bit more.

But I've been thinking about it and no, I'm not a child. I'm starting to finish MSX games and I like it. Of course I want to do games for people play them. If a lot of people say that they are a shit, I will do other things, of course. But for two or three persons I will not leave it. Well, two or three in MSX community maybe are a big percent Tongue ... You understand...

No idea of what you have with ramones but changing deadlines and rules on going as you did ... please...

I can understand your disagreement. But congratulations for your good work in Uridium. For me the important are the promotion of the game, the good opinions and the bad-constructive opinions. In fact, I compiled the bad-constructive opinions to improve the game ("No game" is not a constructive opinion, sorry   Wink . It not helps but I already know there is no obligation in help).

Congratulations for the organization of the contest. Maybe I'm not agree with some decisions but this does not detract from the good work.
14  MSXdev Game Development Contest Boards (English) / MSXdev '14 / Re:MSXdev'14 - VOTING THREAD : 02 de Julio de 2014, 10:29:08 pm
The point is: if you give an 8 to PrettyKingdom, Zero, Gorgeous, Nayade... what shoud you give to the classic games that defined the msx? Maybe a 16?
What shoud you give to old megaroms? 32?
Wink
For me you are right. But as I was talking in a conversation on saturday in the RU, I have voted with points relative to the level of the games in this contest. 9 for the best an so on. Sure if I have voted keeping in mind all the games you say, the points were other. But the rules doesn't  specified relative to what had to be points. And sure many people has voted like this.

On the other hand, sorry for present the game to the contest. Seriously. I was thinking to present it or not but I thought it was playable, it was one entry more to the contest and after many hours of work, it was a good chance to obtain feedback. Well, learning from mistakes!
15  Asociacion Amigos del MSX (AAMSX) / Información General / Re:Recordatorio 45RU MSX, este sabado! : 27 de Junio de 2014, 12:17:23 pm
Estaría muy bien poder grabar en vídeo las charlas  Roll Eyes . Yo intentaré ir pero no creo que pueda quedarme a las charlas y son interesantes. Ya sé que pedir es fácil...
Páginas: [1] 2 3 ... 12
Impulsado por MySQL Impulsado por PHP Powered by SMF 1.1.21 | SMF © 2013, Simple Machines XHTML 1.0 válido! CSS válido!