Lo que quiero decir, es que no soy dios, ni esto me da de comer, ni tengo un presupuesto detrás, ni tengo material de primera mano, ni cuento con personal cualificado, ni estamos hablando de una PS3...
¿Tu que quieres? ¿Que haga un juego que imite completamente a Guitar Hero, pero con un mayor reto tecnico y ademas lo haga yo solito?
Hombre, yo no me he puesto a destripar el juego comercial, para ver el formato de las canciones, pero me apostaría que tiran de PCM para el audio y no utilizan ni MP3, ni OGG... que solo con eso, ya supone una merma de recursos importante para una maquina para PS2.
Pero es que por entrar en detalles que tu no tienes en cuenta...
¿te has fijado que si estas tocando una nota larga en mi juego, si sueltas el boton, la puntuacion deja de contar, pero no se interrumpe el sonido?
En el juego original, si que pasa y te voy a contar el motivo por el que yo no puedo hacerlo.
Veras, en PS2, se pueden utilizar por hardware, dos pistas PCM de sonido, lo cual sería perfecto para el juego, pues nosotros tenemos dos pistas PCM (una vez descomprimidoel audio) que hay que mezclar y en caso de fallo, seria tocar el mezclador para que el audio en una, dejara de oirse de forma casi instantanea.
El problema es que yo soy desarrollador oficial y no cuento con el SDK de SONY, si no que tiro de librerias internas, que pueden contener bugs o no tener implementadas todas las funciones.
Yo no se que será, pero cuando tenia la V3, la librería solo soportaba una pista PCM, mientras que en al menos la V7, ya podia usar dos pistas PCM.
Ese detalle, ya me limita para poder cortar el sonido de inmediato o a la hora de modularlo con la barra de vibrato, que en vez de atacar el volumen de la pista de sonido, tengo que proceder a hacerlo en los samples de audio (lo cual se come recursos tambien).
Ademas, como hay una lectura de audio y una descodificacion de por medio, eso me obliga a tener que usar un loop de audio un tanto amplio, de 80 ms, pues de hacerlo mas corto, me encontraría con cortes en el sonido cada dos por tres.
Esto provoca que cuando cometes un fallo, el sonido no se corte de inmediato, o cuando modulas con la barra de vibrato, haya un retardo apreciable. No hay que ser un lince para ver, que en estas condiciones, si al soltar el boton en una nota larga, diese una orden de interrumpir el sonido momentaneamente al mezclador, éste llegaria con un retardo de unos 80 ms y tal vez suprimiese el sonido de una nota tocada posteriormente y equivocase al jugador (soltar una nota larga, es un semifallo en Guitar Hero, penaliza en los puntos e interrumpe el audio, pero no afecta a los multiplicadores)
Fijate la que se arma, tan solo por no poder acceder a los dos canales PCM, a pesar de que las cosolas que tengo, SI que disponen de la libreria correcta que me permitiría tener la vida mas facil... a costa de que un porrón de gente no puediera utilizar el juego, claro.
Ahora bien, tu te centrabas en el modo Multijugador, aunque supongo que te refieres a LOS modos multijugador (varios= crear varios juegos y mas lio en el programa :/) ¿no?.
Veamos, yo no tengo la posibilidad de probar con otra persona el GH, para poder copiarlo en detalle , etc, pero supongo que cuando hablas de implementar uun modo de a dos personas, te refieres a que uno toca el bajo y otro la guitarra ¿no?
Pues caray, resulta que yo pista de guitarra, si que puedo tenerla en cuenta, aunque en la mayoria de las canciones no exista y no sea mas que una copia burda de la misma cancion, pero ¿de bajo? ¿tengo siquiera la pista MIDI del bajo en las canciones para poder hacer eso?
Supongamos que si: Pues bien, debo suponer que tengo una nueva pista de audio a mezclar, en formato Ogg, para tocar los cojones...
Pero espera, resulta que cuando estaba haciendo el juego, tuve unos ligeros problemas jugables: resulta que el programa utiliza programacion multihilo, pero eso no significa que es que a la PS2 le haya crecido un CORE nuevo y yo pueda disponer de el para acelerar los procesos.
No, lo que significa, es que mientras un hilo está ocupado leyendo un fichero, suele estar bloqueado hasta que le llegan los datos, y yo estoy pidiendo un porron de datos suficiente, para poder mantener la velocidad de lectura (sobre todo en CDROM) y al mismo tiempo garantizar que el decompresor tiene datos para comer.
Tambien supongo, que el descompresor tarda un tiempo variable en proporcionarme los samples, asi que tengo una perturbacion temporal bastante grave, si trato de sincronizar los graficos, la lectura del PAD,, etc, pues el bucle tarda entre 0 y 80ms de tiempo entre los distintos loops.
Para solucionarlo, se recurre a crear un hilo de programa, con una prioridad mas alta, unido a la interrupcion VBLANK.
Esto significa que 50 o 60 veces por segundo, este hilo toma el control. Al ser de una prioridad mas alta. no puede ser interrumpido por el otro y sin embargo, el interrumpe de forma inmediata a ese u otros hilos que pudieran estar trabajando.
Eso me garantiza la estabilidad de tiempo que tiene el programa, me permite leer el PAD de forma regular y actualizar los graficos con suavidad, pero puesto que es un hilo prioritario, que interrumpe al de la lectura, no hace falta ser ni siquiera ser desarrollador de programas, para entender que cuanto mas tiempo nos entretengamos aquí, mas perjudicamos el hilo de lectura/descompresion/ control de efectos de sonido, que esa es otra: mis librerias no son multithread, como si son las oficiales y tengo que tener MUCHISIMO CUIDADO con las llamadas RPC, si no quiero entrar en un agujero negro...
El caso es que el hilo de los graficos, penaliza al de la lectura y ahora estamos suponiendo, que graficamente, representamos dos mastiles y el doble de notas, para reproducir 3 pistas en formato Ogg, mientras movemos todo lo demas tambien.
Pero espera, que estaba diciendo que tuve problemas al principio, cuando estaba en el bucle de juego y reproduciendo DOS pistas de audio.
El problema quiza lo hubiera podido solucionar, volviendo mas compleja la lectura, cacheandola mediante un software y leyendo mas datos. Como hay que tener en cuenta el CDROM, tenemos que tener en cuenta los saltos de la lente, si queremos leer dos ficheros distintos con el audio.
Esto produce un retardo apreciable (ya ni te cuento leer de tres ficheros...) , que se puede solventar utilizando una lectura avanzada y compleja... o de otra forma mas sencilla.
La forma mas sencilla (la que implementé) consiste en leer una de las pistas por completo y almacenarla en memoria RAM, para así solo tener que proceder a una unica lectura desde CDROM o el dispositivo USB y evitarme un trafico de datos doble y a saltos.
Eso si: si el Ogg mide 4 MB, eso es lo que se va a chupar de RAM, que serian digamos 8MB si hubiera una pista de bajo de por medio (eso si, espero que no haya ninguna de 8 MB, porque me comeria la mitad de la RAM, entre las dos, solo para hacer de almacen de las canciones, duplicando a su vez el tiempo de las cargas (que serían eternas, casi

))
Incluso pongamos este caso: juego Multijugador que usa un unico mastil, con dos pistas Ogg, pero donde la pieza, se toca un tiempo por un jugador y un tiempo otro. Si uno de los dos jugadores falla, el control pasa al siguiente y gana el que mas puntos logra.
Veamos, se me ocurre que cada jugador deberá tocar las notas de alguna forma.... ¿debo suponer que los jugadores pueden disponer de dos guitarras, dos PAD's u dos teclados?
En caso de utilizar dos teclados, me tocará modificar el driver de teclado para que sea capaz de leer dos teclados a la vez,porque yo lo valgo
![toma [tomaaa]](/images/smilies/nuevos2/tomaa.gif)
, pero lo evidente es que eso necesita una cierta cantidad de tejido detrás que permita configurar los controles para dos jugadores y lleva modificaciones en el programa que no consisten en añadir dos lineas de código nuevas y ya está, que es que vosotros veis las cosas desde una perspectiva de pedir las cosas como si fuera lo mas facil del mundo hacerlo y no costase nada de trabajo....
Pero ¿quieres saber lo mas gracioso? Que despues, todo ese curro, lo disfrutas tu y tus colegas y no el creador del programa
PD: Llegará el momento en que libere el código, la gente lo mirará, vera que para empezar, está compilado con un compliador muy antiguo, en C puro y duro, que utiliza librerias que solo pueden ser utilizadas con dicho compilador, que no usa ps2sdk, que el codigo es complejo y dificil de entender, que hacer las cosas no es tan facil como hablar, que te puedes cargar la estabilidad y fluidez del programa añadiendo cualquier tonteria y veremos entonces quien es el valiente que se pone a mejorarlo, mas allá de cambiar dos imagenes de fondo y dos pijadas faciles de hacer, que aumentaran el programa de los 500KB que ocupa ahora, a 4MB y estará la mitad de la peña mosqueda, porque no lo pueden utilizar en la memory card y encima la mitad de las canciones petan, por falta de memoria. Eso sí, pondrá un logo muy bonito que diga: Hecho por fulano, sustituyendo la fea, pero compacta (y muy practica) fuente de letras que yo uso y mi firma.
Si es que por pedir....