Tutorial de programación de videojuegos con Bennu

[SplinterGU]

no se, pone el codigo...

[Drumpi]

Tened en cuenta que el teclado tiene seis pines para mandar la información. Supongo que la combinación de la diagonal y alguna tecla especial no se pueden enviar a través del cable, por lo que, salvo que modifiqueis todos los teclados del mundo, jamás podréis usarlo.
Lo que pasa en WIZ y con todos los mandos, es que estos no siguen un "estandar" (intentad diseñar un HW que maneje el porrón de teclas que tiene un teclado y que dure toda la vida, y que sea suave...) y se diseñaron para poder pulsar todas las teclas sin conflictos.
No es Bennu, ni Fenix ni DIV, es el propio teclado, y pasa con TODOS los programas del mundo, y lo dicho, yo lo comprobé jugando a emuladores (imagianos 3 jugando al Secret of Mana)

[SplinterGU]

jejeje... no, no, no se usa 1 cable por tecla... el teclado es un procesador que responde a comandos y envia comandos de forma serializada... la comunicacion es serializada... asi que no importa la cantidad de cables...

http://www.bbdsoft.com/keyboard.html

http://pinouts.ru/Inputs/KeyboardPC5_pinout.shtml

basicamente se debe al buffer interno de los teclados y a como escanea la matriz del teclado... la wiz tiene joysticks, no teclado, pero no se debe a eso... se debe al procesador que los teclados tienen... y la matriz del teclado es multiplexada, pero en ocaciones se confunde/anulan algunas teclas si se pulsan muchas juntas, todo depende en que fila/columna del escaneo estan...

pero hay buenos teclados que no tienen problemas con esto... pero esto es el eterno problema de los teclados de pc... yo recuerdo cuando pase del spectrum (donde se podian pulsar todas las teclas juntas a la vez y reconocerlas) al pc me tope con este grave problema (y hablo de la epoca del XT...)

no queria entrar en tantos detalles tecnicos que para muchos no tienen sentido... pero bueno...

[Windgate]

¿En espectrum se podían pulsar todas las teclas al tiempo y funcionaban a la vez? lol

Cierto lo del buffer de teclado, a saber qué tipo de buffer tienen las basuras que compramos made in China y lo que son capaces de enviar cuando se aporrean las teclas... En cualquier caso es lo que hay, todo el mundo tiene un teclado con esas mediocres características, así que habrá que tenerlo en cuenta a la hora de programar supongo...

En cualquier caso, no sé si con algún proceso basado en ascii o similar, hay juegos como GTA en los que la diagonal y el espacio son capaces de responder a la vez.

[SplinterGU]

claro, porque en el spectrum no habia procesador ni buffer, ni nada... ahi se pulsaban las teclas y se leian como si fueran un joys, o sea, si no leias una tecla la perdias...
en los pc, lo que se quizo hacer es que no se pierdan las pulsaciones... por eso el teclado trabaja en un modo donde el byte mas significativo del scancode (codigo de la tecla pulsada) esta a 1, cuando se pulsa la tecla, y luego se pone a 0, cuando se suelta... no estan informando las teclas todo el tiempo solo cuando ocurren los deltas/eventos...

en el spectrum vos leias el estado del port, y cada bit indicaba que columna (o filas, se dividian en 8 filas con 5 columnas cada una) tenian alguna tecla pulsadas (o era al revez, columnas/filas) y con otro port, podias indicar que fila querias escanear, con lo que podias determinar exactamente que teclas se pulsaba, y barrer todo el teclado completo.

depende de la combinacion de teclas, algunas teclas no van con otras...

[Windgate]

Por lo que tengo entendido la entrada/salida de teclado, como de otros periféricos, puede funcionar por encuesta o por interrupción.

En el Espectrum por lo que dices supongo que funcionaba por encuesta, el procesador cada ciertos ciclos consultaba el estado del teclado, ¿No?

Ahora son por interrupción, le llega al procesador una interrupción de tecla pulsada, con un retraso inapreciable, y se gestiona... En sus tiempos me explicaron que de las posibles interrupciones la del teclado era de las más prioritarias.

En cualquier caso, el teclado es una forma "sucia" de hacerlo, lo que me fastidia es el tema de esos juegos que sí que admiten respuesta a varias teclas... ¿La función key() no está basada en ascii, verdad?

Si algunos pudieron programar algo capaz de interpretar más teclas simultáneas tendremos que hacerlo, no debería ser tan difícil, cosas más grandes se han visto aquí xD

PD: Habla un caballero que acaba de llegar de fiesta y no conoce la implementación de la función key()

[SplinterGU]

no, la funcion key no usa ascii, usa lo que decis deberia hacerse... o sea, las interrupciones y todo eso...

veo que no me explique bien... una cosa son las interrupciones de teclado (PC) y otra es el controlador del teclado (hardware y software contenido dentro del teclado)... el teclado es como un aparato externo, con su logica y firmware... es como si fuera una pequeña pc... tiene un buffer interno y el guarda las pulsaciones... cuando se comunica con la pc, envia las teclas que tiene en su buffer (hay todo un protocolo de comunicacion, pero bueno, a grandes rasgos es asi)... y puede que ese buffer se llene con lo que no puede enviar las teclas o incluso hay combinaciones de teclas, que dependiendo de la mayor o menor complejidad del hardware del teclado puede cancelarse entre si algunas pulsaciones de otras...

es un poco complejo, pero creeme que se hace todo lo que se puede hacer...

[Drumpi]

Ya se que no es un pin por tecla, sino que se usan para enviar datos binarios de 6bits.
No estoy puesto en el cromagnon de los teclados, pero se que ahora se envían los datos en serie y se guardan en un buffer del PC, y este a su vez puede mandar ciertos comandos al teclado (por ejemplo, encender los leds de mayúsculas). Puede que sea culpa de la transmisión por el cable (que no detecta correctamente el cambio de dato) o puede que de la matriz que reconoce las letras, pero eso no es solucionable por código: hay que abrir físicamente el teclado y modificar la placa de circuito y los componentes.

Solución: usar cursores y letras, así tienes hasta seis o siete pulsaciones, creo, y si omites el uso de cursores y teclas especiales creo que puedes añadir dos más.
Si no recuerdo mal, usábamos para el
P1: ikjl vbnm
P2: 8546 (teclado munérico) repag, avpag, inicio, fin
P3: wsad zxcv
Si no usábamos más de tres botones a la vez podíamos jugar sin problemas (o sea, que ibamos sin correr a todos lados y combatíamos casi quietos :D)

[Windgate]

A mí me sigue picando la curiosidad por juegos como GTA que responden a combinaciones de teclas que mis videojuegos no responden ???

¿Hay alguna forma de vaciar el buffer de teclado después de cada FRAME? Desde ensamblador imagino que se podría vaciar.

El tema no me preocupa demasiado la verdad, pero si vuelve a asaltarme la curiosidad ya sacaré un hilo :P

[syous]

 ;D ;D ;D ;D ;D

hola una curiosidad

cuando acabes los temarios vas a crear un unico archivo pdf recopilatorio es que me me gustaria imprimirlo todo de golpe no por fasciculos y encuadernarlo

[Windgate]

Cuando iba por el tema 10 o así me dí cuenta del problema... Imagino que "enchufar" cada .doc / .odt uno con otro no será complicado y se mantendrá el número de página de forma correcta... De hecho ESPERO que haya alguna opción para hacerlo de forma automática.

En cualquier caso si no la hay lo haré a mano, qué remedio :P

Gracias por la sugerencia xD

Por cierto, no dije que he ya empezado con tema 20 y siguientes, pero no he terminado de subir los últimos videojuegos de ejemplo, también he hecho alguna corrección, especialmente en los últimos temas, el 18 por ejemplo estaba incompletísimo, ha pasado de tener 2 páginas a tener 6... Todavía no lo he subido, esta noche si saco un rato lo subo.

(No le digáis a mi jefe que he entrado aquí, ahora mismo estoy trabajando... ::))

[Windgate]

Hasta el tema 20 ya está subido todo, al videojuego de ejemplo del tema 20 le falta añadir un detalle pero lo dejo en Beta de momento, esta tarde si tengo un rato lo termino.

Los nuevos temas ya son de 6 páginas mínimo y ya se están empezando a reaprovechar los .prg que guardaba cuidadosamente para la ocasión, ahora empieza lo divertido :P

Como principal novedad, en el tema 20 ya se trabaja con módulos .prg y con ficheros .fpg separados, para facilitar el reparto de tareas y el reaprovechamiento de recursos en proyectos sucesivos.

Los siguientes temas son cruciales, pero recién los he empezado, todos llevan su .prg asociado para facilitar la historia y no codear excesiva-mente:

Tema 21 - Sonido
Tema 22 y 23 - Animación I y II
Tema 24 - Mapas de durezas
Tema 25 - Gravedad

[josebita]

Windgate, ahora que le hemos cogido el truquillo a mandar ficheros por mp, mándame los odts de esto pa que los vaya traduciendo con tiempo, ok?

[Windgate]

Te puedo mandar los .doc (¿Se puede decir .doc aquí? xD), tengo la costumbre de guardar en .doc para que algunos seres humanos normales puedan acceder fácilmente a lo que escribo...

Hay un temita Josebita, y es que todavía no doy por definitivo el contenido del tutorial y de hecho hoy hablando con un alumno me he planteado seriamente adelantar la parte de efectos de sonido.

Lo que ocurre con ésto es que sería una pena que te pegases ahora la currada de traducir todo para que más adelante tengas/tengamos/tenga que darle alguien otra corrección a todo el tutorial.

¿Estás seguro de que quieres ponerte ya con la traducción o te voy pasando los temas desde el 1 a medida quevea que está todo OK y puede ser release?

(Ahora mismo recuerdo que en el tema 1 habría que hacer una adaptación a los 32 bits... Cómo joden esas cosas... :-[)

[josebita]

Vete pasándomelos poquito a poco cuando los consideres definitivos. Si hay que añadir algo, supongo que no será demasiado trabajo.