Karoshi MSX Community
23 de Octubre de 2017, 10:09:58 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 ... 16
1  Development Boards (English) / Suggest a Game / Re:Pole Position : 22 de Abril de 2016, 09:14:32 pm
Hi!

I think that, from the theoretical point of view, this kind of games in MSX could be programmed with different approaches:

1) The underexplored approach: NAMTBL-based scenario (yes, like Hyper Rally or Antarctic/Penguin Adventure). It has potential: just see Outrun Europa (Sega Master System). It minimizes the amount of RAM-VRAM transfers and does not use any sprites (like GP World did, by example). The drawbacks are that the tileset must be carefully designed and the rendering algorithm can impact the speed of the final result.

2) The way most of the ZX Spectrum conversions did: per scanline. The main problem of this approach in the MSX is the huge amount of RAM-VRAM transfers, killing the performance, even if the CLRTBL is untouched (monochrome games). I still think that it is posible to get this working at a decent speed playing with NAMTBL, CHRTBL and CLRTBL, reducing the gameplay zone and aiming for "flat" surfaces. And, of course, lots of coding tricks to "mimick" the math formulas to calculate the road path. Maybe the best possible in MSX(2) would be something slightly behind Top Gear Pocket/Rally (Game Boy Color)...

And that for just the scenario... Wink
2  Foros de Desarrollo (Español) / Desarrollo / Re:Nuevas dudas sobre programación en ensamblador : 11 de Octubre de 2015, 10:21:11 pm
Pues lo he estado pensando y me he dado cuenta de que, efectivamente, como almacén de gráficos puede ser bastante fácil usarlo. Pseudocódigo:
Código:
; (código en las páginas 1 o 2)
; Subrutina (CALL) para volcar gráficos desde la página 3
; param hl, de, bc: igual que LDIRVM
LDIRVM_DESDE_PG3:
    ; ... código para poner ROM en PG3 (se perderá la pila)
    jp LDIRVM_PG3
SALIR_LDIRVM_PG3:
    ; ...código para restaurar RAM en PG3 (se recuperará la pila)
    ret

; (código en la página 3)
LDIRVM_PG3:
    ; ...rutina similar a LDIRVM con OUTs y djnz
    jp SALIR_LDIRVM_PG3 ; sustituye al ret porque no hay pila

; (datos en la página 3)
    .db ...
(todo esto lo digo sin haber mirado si efectivamente esas tres rutinas (poner ROM, restaurar RAM y LDIRVM) se pueden hacer efectivamente sin nada de RAM)
3  Foros de Desarrollo (Español) / Desarrollo / Re:Nuevas dudas sobre programación en ensamblador : 09 de Octubre de 2015, 07:17:12 pm
Un juego en cartucho puede tener hasta 64k sin necesidad de mapper. Las páginas 1 y 2 estarían siempre ahí y la página 0 se podría alternar con la BIOS sin problema alguno. La página 3 pisaría la RAM, por lo que se puede usar para mantener cosas que no necesiten de RAM para ser usadas-
Una pregunta, SapphiRe, ¿realmente se llega a usar lo de poner ROM en la página 3? Es decir, teóricamente todo "encaja", pero en la práctica supongo que: o bien juegas con dónde hay RAM y dónde está la pila (porque en cualquier momento puede haber ROM en cualquiera de las páginas), o bien haces algo que realmente no necesite RAM ni para volver... y ahí es donde a mi imaginación le cuesta llegar. ¿Qué se puede hacer ahí?

Es más, yo pensaba que las ROMs de 64kB lo que hacían era permitir paginar en alguna de las otras páginas.
4  Foros de Desarrollo (Español) / Desarrollo / Re:Manejo de tiles en Basic : 08 de Octubre de 2015, 08:24:36 pm
Buenas!

No sé muy bien a qué te refieres exactamente cuando hablas de "animar", pero aquí van unas cuantas sugerencias:

La primera es que pokees el sistema para que el BASIC crea que estás en SCREEN 1: con esto puedes hacer LOCATE, PRINT y PRINT USING, que es bastante cómodo, rápido y compacto. Como efecto colateral, puedes cambiar el color de tinta y fondo de los primeros cuatro caracteres con una única instrucción COLOR. Si colocas ahí "algo" que puedas "animar" cambiando colores (ejemplo simplón: estrellas que parpadeen, "llamas" en un ciclo 9-8-9-11... algo así), lo puedes aprovechar.

Si lo que quieres es animar caracteres reemplazando la tabla de patrones y/o colores... VPOKEs. Pero vas a andar justito. Quizá como mucho un caracter cada frame e ir alternando. Dependerá mucho de a qué velocidad necesite ir tu juego (mucha (acción) vs "poca" (puzzle)).

Si lo que quieres es animar el fondo sustituyendo caracteres en la tabla de nombres... VPOKEs o LOCATE+PRINT si te cuadra que esté todo más o menos junto. Incluso puedes incluir secuencias de escape en la cadena (en plan abajo, izquierda, izquierda) para, con un único PRINT, reemplazar un fragmento que no sea horizontal.

Otra opción (que nunca he usado) es dibujar la pantalla con una tabla de nombres y volver a poner el BASIC en modo SCREEN 2. Ahora, las instrucciones gráficas (DRAW, LINE, etc.) funcionarán como si dibujaran en la tabla de patrones, de modo que si pintas con DRAW en donde estaría el caracter "A", te modificará todas las "A"s que tengas en ese banco.

Si lo que quieres es volcar pantallas (de un mapeado) entonces lo mejor es, por goleada, una rutinilla ASM que te haga un LDIRVM (y si ya que te metes le añades compresión... pues lo bordas Cheesy).
5  Foros de Desarrollo (Español) / Desarrollo / Re:Nuevas dudas sobre programación en ensamblador : 05 de Octubre de 2015, 07:37:58 pm
Yo no he llegado a intentar hacer MegaROMs, pero creo que te lo puedo explicar de forma sencilla con la memoria no mapeada. No hay volcado ninguno (o no tiene por qué haberlo). Voy a simplificar mucho así que lo mismo luego vienen "los que saben de verdad" y me crujen un poco, pero espero resultar instructivo.

Imagina una cuadrícula de 4x4:
- Cada fila es una página (0, 1, 2 y 3, que empiezan en $0000, $8000, $C000 y $E000 respectivamente).
- Cada columna sería un "slot": una columna llevaría la ROM del ordenador (BIOS + BASIC), otra llevaría la primera cartuchera, otra la segunda cartuchera y la última tendría la RAM.

Ahora bien: el ordenador sólo puede leer 4 casillas de la cuadrícula, una de cada fila. Pero puedes elegir qué es lo que se ve:
- BIOS-BASIC-RAM-RAM: típico al arrancar el ordenador sin cartuchos. Puede haber más RAM pero estaría "escondida" detrás de la BIOS y el BASIC.
- BIOS-ROM-ROM-RAM: típico de un juego de 32K que utilice la BIOS. El BASIC y la RAM (si la hay) están "escondidos".
- BIOS-BASIC-ROM-RAM: típico de un juego de 16K (o de una BASIC ROM).

¿Qué es cambiar de página? Imagina un juego de 48K que utilizara la BIOS. En algún momento necesitará cambiar la página 0 de BIOS a su ROM, copiar o descomprimir datos de una fase o músicas o lo que toque, y volver a poner la BIOS para seguir como antes.
Un MegaROM lo que te permite es tener muchas más posibilidades "propias" (es decir, de tu juego) para alguna(s) de las páginas. Simplificando mucho de nuevo, imagina que tu MegaROM tiene en la página 1 el código del juego y luego tienes varias páginas 2 con las diferentes fases: podrías ir poniendo una u otra según correspondiera. O tener datos comprimidos (que sacarías a RAM) y así podrías tener ahí el bucle principal del juego, etc.
6  MSXdev Game Development Contest Boards (English) / MSXdev '14 / Re:[[**Entry**]] "World Rally" (by theNestruo) : 21 de Julio de 2015, 10:49:12 pm
Gracias por tus palabras, Pitpan...

Tuve muchos errores de planteamiento al principio que me costaron mucho tiempo y esfuerzo, hasta el punto de tener que reescribir prácticamente todo: por ejemplo, empecé con gráficos en isométrico... y cuando al final tuve el scroll siguiendo la pista me di cuenta de la obviedad de que la imagen botaba (porque la cámara se movía en horizontal y en diagonal alternativamente cada frame).
Ahora mismo lo más costoso de hacer es reescribir las rutinas de control del coche. Se programaron y afinaron con el primer tramo (varias veces también, porque empecé con 8 direcciones y hubo que rehacerlas para meter 16). Cuando ya estaba todo funcionando y me pude poner a hacer más tramos, descubrí que con curvas enlazadas o zonas sin mucho sitio entre curva y curva simplemente no quedan bien Sad No sé cómo replantearlo para que "visualmente" funcione; y lo peor es que hay que escibir el código de control entero para saber qué feeling da todo junto.

La verdad es que era un proyecto personal al que tenía muchas ganas y mucha ilusión; no descarto acabarlo algún día, pero a corto plazo no lo veo :/
7  MSXdev Game Development Contest Boards (English) / MSXdev '14 / Re:[[**Entry**]] "World Rally" (by theNestruo) : 20 de Julio de 2015, 05:40:56 pm
Hi!

The development of this game can be considered now "delayed indefinitely" (sorry guys!).
But, as I don't want to lose what was done, full source code and assets have been published at github: https://github.com/theNestruo/msx-wrally

What is in the TO DO list (as far as I remember):
- rewrite car control routines
- design the missing stages, add detail to the existing ones, create new tiles and graphics, etc. (Tiled)
- polish intermission sequences
- sfx (and remove the placeholder sounds stolen from Road Fighter)
- music
- ending sequence
- ...

Happy ASM reading!
8  Asociacion Amigos del MSX (AAMSX) / Información General / Re:Demo Sydney Hunter and the caverns of death : 02 de Julio de 2015, 05:02:52 pm
¡Bravo!
¡Este juego me encantaaa! angel
¡Reservadme un cartucho desde ya mismito!

Creo que ya lo comenté en su momento pero es bastante truculento tanto con los sprites como con los escenarios. Parece que no, pero lleva las restricciones gráficas del MSX bastante al límite y, cuando intenté ponerle las manos encima, llegó un punto en el que casi no sabía ni cómo planteármelo para que fuera mínimamente viable. ¡Y ahora llegas tú y en dos meses tienes una demo jugable! ¡Eres un crack!

Por cierto, pcx2spr+ salió precisamente de intentar procesar el spritesheet de este juego, jejeje. ¿Lo has utilizado o has ido por otro camino?
9  Foros de Desarrollo (Español) / Informacion General / Re:"Muerte por exceso de trabajo" en Karoshi : 25 de Abril de 2015, 10:26:28 pm
Buenas!

Yo puedo hablar por la parte que me toca. Lógicamente cada uno tendrá su historia, pero creo muchas de ellas irán por el mismo camino. Es bastante lo que tú dices: el tiempo libre escasea. Hay temporadas que más, hay temporadas que menos. Y a veces puedes dedicarle tiempo a esto, y otras veces están tan saturado que se lo acabas dedicando a otros hobbies más sociales y menos exigentes (en el sentido de que no siempre tiene uno la cabeza para programar).
En cuanto a abandono, yo he intentado que no sea así, colaborando cuando he ido pudiendo (en mi caso: pcx2msx/pcx2spr, algunos snippets, un par de fuentes de letras...).
Yo para "levantar" esto propongo que nos toque una buena lotería a todos, lo suficiente como para dejar el trabajo, o contratar una asistenta, o lo que corresponda en cada caso, y pegarnos unas buenas viciadas de las de antes a programar, pixelar y forear Smiley
10  Foros de Desarrollo (Español) / Desarrollo / Re:Conversor para gráficos monócromos : 03 de Diciembre de 2014, 06:03:12 pm
En los nuevos PCX2MSX, entre las opciones que hay para elegir qué colores quieres que sean tinta o fondo, tienes -hl y -lh (high/low y low/high respectivamente) para indicar color más alto/bajo de frente y más bajo/alto de fondo... pero además en el caso de hl fuerza que 0 y 1 sean siempre fondo (aunque el patrón sea 0xFF) y en el caso de hl fuerza que el color 15 sea siempre frente (aunque el patrón fuera 0x00).

Así que si puedes tener la imagen en PCX y que el índice del color de la tinta sea 15 (o que el fondo tenga índice 0 o 1) te puede valer Smiley
11  Foros de Desarrollo (Español) / Desarrollo / Re:MSXtiles devtool v0.9b : 01 de Noviembre de 2014, 03:08:31 pm
Hola.
He visto el hilo y, aprovechando que estaba en casa de mis padres, te lo he ido a probar en este PC (que tiene XP). Al arrancar dice que "ha detectado un problema y debe cerrarse", pero ni siquiera me aparece un botón de detalle Sad
Así que nada, esta vez no os puedo echar un cable :/
12  Foros de Desarrollo (Español) / Desarrollo / Re:mover sprite : 18 de Octubre de 2014, 02:23:41 pm
En la web de Dimension Z Games (la web de Pepe Vila) lo tienes:
http://www.dimensionzgames.com/?page_id=178&did=3
13  Foros de Desarrollo (Español) / Desarrollo / Re:mover sprite : 15 de Octubre de 2014, 06:12:34 pm
Si se te ha "acabado" el tutorial de Pepe Vila, yo te recomendaría que le echaras un vistazo a lo siguiente:
- Karoshi Open Source: Classic Pong y Classic Minesweeper (en este mismo foro). Son juegos "pequeños", el código está muy bien estructurados, tiene una legibilidad envidiable y seguro que puedes aprender montones de historias de ahí (¡gracias Pitpan!).
- Jumping (el juego de Pepe Vila). Es un juego más grande, así que puede que te cueste un poco hacerte con su código de buenas a primeras. Pero está muy bien documentado y, al ser también de Pepe Vila, sigue el mismo estilo de código al que te han acostumbrado los tutoriales (¡gracias Pepe!).
No hace falta irse mucho más lejos para tener código didáctico y de calidad Grin

Yo hace tiempo andaba como tú y abrí un hilo llamado "rincón del novato en ensamblador" o algo así. Recuerdo que subí un mini-Pang! con el que, precisamente, había hecho pruebas de mover sprites, colisiones con los bordes y colisiones entre ellos. Seguramente sea el peor sitio para fijarse, porque era novato y no sabía muy bien lo que hacía... pero a lo mejor te vale.
Para el tema de colisiones entre sprites mira en la sección de snippets que me suena que hay un snippet de, precisamente, cómo mirar colisiones entre objetos (escrito por nanochess, si no recuerdo mal).

¡Ánimo!

Edit: no había visto tu última pregunta.
El scroll inicial de los cartuchos de Konami se hace escribiendo la tabla de nombres (es decir: son caracteres). No sé si con volcados vía LDIRVM o escribiendo posiciones concretas con WRTVRM.
Si utilizas Windows, prueba el emulador meisei (de hap, sólo MSX1) porque tiene un visor de VRAM que resulta ideal para ver cómo están hechos los juegos (y combinado con la pausa, el rebobinar, y el ralentizar/acelerar... es la caña para aprender cómo están hechas un montón de cosas)
14  Foros de Desarrollo (Español) / Desarrollo / Re:sumar 32 a de : 15 de Octubre de 2014, 06:01:45 pm
Imagino que estarías intentando hacer ld de,hl, porque ld hl,de sí que existe Smiley
Hay muchos listados de instrucciones de Z80; a mí me resulta muy cómodo tener a mano éste de la MSX Assembly Page: http://map.grauw.nl/resources/z80instr.php y, para medir tiempos de rutinas enteras, BiT de Jannone: http://msx.jannone.org/bit/
Quizá no sea el mejor listado del mundo (no habla de cómo quedan afectados los flags ni nada de eso), pero para hacer una búsqueda rápida y ver si la instrucción que quiero poner existe me resulta bastante práctico.
15  Foros de Desarrollo (Español) / Desarrollo / Re:sumar 32 a de : 15 de Octubre de 2014, 06:14:02 am
  push bc
bucle:
  pop de

Creo que el problema de tu rutina (al margen de optimizaciones como la que te recomienda kabish) puede estar ahí: metes el contador (bc) en la pila y luego intentas sacar lo que supongo que es un puntero (de) de la pila... pero como acabas de hacer un push bc, en realidad estás recuperando en de el valor del contador.
Prueba sin el par pop de/push de.
Páginas: [1] 2 3 ... 16
Impulsado por MySQL Impulsado por PHP Powered by SMF 1.1.21 | SMF © 2013, Simple Machines XHTML 1.0 válido! CSS válido!