Página 24 de 28

Re: Noticias Mojon Twins

Publicado: Jue, 22 May 2014, 14:19
por radastan
Vamos a ver, he tocado donde has dicho, si hago "make" me hace la cinta sin problemas... pero las teclas no van, siguen con AWSD.

Es que es rarísimo.

Re: Noticias Mojon Twins

Publicado: Jue, 22 May 2014, 14:24
por na_th_an
A ver si has tocado en la otra rama de #if. Hay dos definiciones de teclas seguidas, es en la de abajo:
$this->bbcode_second_pass_code('', ' // Define keys and default controls
#ifdef USE_TWO_BUTTONS
keys.up = sp_LookupKey('w');
keys.down = sp_LookupKey('s');
keys.left = sp_LookupKey('a');
keys.right = sp_LookupKey('d');
keys.fire = sp_LookupKey('m');
key_jump = sp_LookupKey('n');
key_fire = keys.fire;
#else
keys.up = sp_LookupKey('n');
keys.down = sp_LookupKey('s');
keys.left = sp_LookupKey('a');
keys.right = sp_LookupKey('d');
keys.fire = sp_LookupKey('m');
key_jump = sp_LookupKey('w'); // CUSTOM!!
#endif')

Sobre la cinta, sí que se te genera un TAP, pero ese TAP en los +2A no funciona guay.

También asegúrate de que estás probando la cinta que es :)

Re: Noticias Mojon Twins

Publicado: Jue, 22 May 2014, 15:30
por radastan
Aquí tienes la versión inglesa con QAOP MN.

Re: Noticias Mojon Twins

Publicado: Jue, 22 May 2014, 15:35
por radastan
Versión española.

Por cierto, a mi me salta con Q con esta definición de teclas. Curioso.

PD: ambos ficheros son con la V1.1

Re: Noticias Mojon Twins

Publicado: Jue, 22 May 2014, 15:51
por na_th_an
Sí, esta preparado para saltar tambien con ARRIBA, para los que les guste agarrar un buen joystick. Gracias, tio, publicalo tú, el mérito es tuyo. Si quieres enlazo a tu post desde WOS.

Re: Noticias Mojon Twins

Publicado: Jue, 22 May 2014, 16:19
por alxinho
Por qué hacéis lo de usar WASD? ¿Os va mejor al programarlo o algo así o es porque estáis hasta los cojones del OPQA? :lol:

Re: Noticias Mojon Twins

Publicado: Jue, 22 May 2014, 16:27
por angel
$this->bbcode_second_pass_quote('alxinho', 'P')or qué hacéis lo de usar WASD? ¿Os va mejor al programarlo o algo así o es porque estáis hasta los cojones del OPQA? :lol:


Porque es más cómodo que OPQANM :D

en este juego necesitas dos botónes, uno de salto y otro de disparo. Y en la fase de nadar necesitas arriba para nadar arriba :D

Re: Noticias Mojon Twins

Publicado: Jue, 22 May 2014, 16:38
por Nightwolf
Es que además con el OPQA se pierden dedos por ahí :D

Re: Noticias Mojon Twins

Publicado: Jue, 22 May 2014, 19:53
por jcgamestoy
Buenas a todos :D lo primero un poquito de presentación me llamo Juan Carlos y soy de por aquí abajo a la derecha (Alicante).

Bueno queria comentar un poquito el tema del "ULA Snow" porque así entre programadores si nos ayudamos un poquito mejor.

Estoy haciendo un nuevo emulador de spectrum y de todo esto he aprendido un poquillo estos últimos meses.

Cuando he leido lo del fallo de Ninjajar (PEAZO JUEGO) de la ULA Snow al principio no lo he entendido, pero luego probándolo en mi Emu en ciernes me he dado cuenta de que el sample de "morir" no suena igual en un +2 que en un +2A

Aunque desde fuera lo parezcan el spectrum 128k / +2 y los spectrum +2A/B +3 Internamente se parecen muy poco.

Pero bueno para el que no tenga ni pajolera idea de lo que estoy hablando voy a intentar explicarlo lo mas fácil que pueda:

Todos los spectrum tienen unas zonas de su memoria que funcionan más lentas que el resto, en el 48k es muy fácil, la memoria lenta es la que va de 0x4000 a 0x7fff, básicamente donde esta la pantalla. Esto es así porque dos dispositivos no pueden acceder a la RAM a la vez y en esta zona de memoria el z80 (la cpu) y la ULA (podríamos llamarlo la GPU) se "dan de ostias" por quien accede primero. El tío Sinclair tomo la opción de que mandaba la ULA (porque sino en la pantalla pasarían cosas raras) así que el z80 se frena al acceder a esta zona de memoria.

En los 128k la cosa se complica un poquito más, los 128k están divididos en 8 módulos de 16k cada uno numerados del 0 al 7, los pares son rápidos (0,2,4,6) los impares lentos (1,3,5,7 porque la pantalla siempre esta en el 5 o en el 7).

La gran "putada" viene en los +2A / +3 ya que en Amstrad se ve que estaban aburridos y dijeron "vamos a reinos un rato de estos", total que cambiaron y los rápidos son el 0,1,2 y 3 y los lentos el 4,5,6 y 7.

Cuando hacemos una rutina muy dependiente del tiempo (como reproducir un sample o leer el cassette etc...) es importante ponerla en uno de los comunes rápidos (el 0 y el 2) o bien detectar antes si es un +2 o +2A y cambiar los bloques lo que puede ser una tortura china.

Como ejemplo de esto si cargáis el "Carrier Command" en un buen emulador como FUSE en un +2 o en un +3 veréis como en el +2 la música se oye bien y en el +3 se oye más lenta (Me pase una semana para darme cuenta de que esto no era culpa mía).

Todo este rollo es lo que en "inglis pitinglis" se llama Contended Memory. Y creo que es lo que le pasa a Ninjajar con el sample. More info jere ;) http://www.zxshed.co.uk/sinclairfaq/index.php5?title=Contended_memory

En cuanto al "Snow Effect" es otra cosa aun peor que solo le pasa al 48k/128k/+2, y es que si ponemos el registro I (Que no sirve casi para nada) entre 0x40 y 0x7f el z80 y la ULA se lian del todo y empieza a verse pixeles raros por toda la pantalla. Podeis ver aquí un video https://www.youtube.com/watch?v=4FIUCIyMSD4

Bueno os dejo que voy a jugar a Ninjajar que estoy enganchao Un Abrazo

Re: Noticias Mojon Twins

Publicado: Jue, 22 May 2014, 20:13
por na_th_an
... Y sobre $C0, como es el caso de Ninjajar.

El registro I se utiliza en el modo IM2, que es el que usamos nosotros para que salte una interrupción cada 20ms y ahí llamemos al player. Es por eso que la música de Ninjajar se escucha siempre a la misma velocidad sin importar la contención del modelo donde se ejecute (incluso los clones rusos como Pentagon o Scorpion). Nuestra rutina de servicio de interrupción necesita I = $F0 para ser accesible y de ahí viene el problema.

Como siempre que paginamos/usamos las otras páginas de RAM es para obtener datos almacenados y en momentos puntuales, las interrupciones están deshabilitadas y nos podemos permitir poner momentaneamente I = 0, lo que soluciona el problema la mayor parte del tiempo. No es una solución óptima, pero sí lo suficientemente buena. Ya nos han reportado que la nieve se reduce al mínimo en hardware real :)

Sí es cierto lo del sample, que está en RAM1. Tampoco es algo que nos preocupe demasiado, la verdad, como para tener que andar montando pifostios y autodetectando modelos :) En los 128/+2 se escucha un poco más grave (y levemente más distorsionado) que en los +2A o en los Pentagon/Scorpion (que no tienen contención), pero tampoco nos molesta :D

¡Bienvenido al foro!