Me ha quedado un título muy rimbombante :)
Mi duda es la siguiente. Como he comentado en el hilo sobre mi miniengine TWSE (la siguiente versión va viento en popa (uoh) ), parece que DX7 tiene un bug tal que si intentas playear un archivo midi cuya ruta tenga más de 130 caracteres, da error (curiosidades de la naturaleza :) ).
La probabilidad de que dicha ruta supere los 130 caracteres es pequeña (casi todo el mundo instala en "C:\Archivos de programa\Nombre del programa\", lo cual no se acerca ni de lejos a los 130), pero claro, ya se sabe que hay que programar siempre pensando en que el usuario te va a p*tear :), así que he pensado en implementar una solución sencilla. Cuando llamo a la función de playear midi, compruebo si la longitud de la ruta es mayor de 130. Si lo es, copio el midi a una carpeta temporal cuyo nombre sepa que será menor de 130, y playeo este midi en vez del original.
Y después de todo ésto, mis dudas son:
-¿Tenéis una idea mejor?
-¿Creo la carpeta temporal en "c:\MiCarpetaTemp", a lo bestia? Por cierto, "c:\" es siempre un disco duro, ¿no?
-¿Creo la carpeta temporal en Directorio de windows + "\MiCarpetaTemp", hallando el Directorio de Windows con la API GetWindowsDirectory?
Es una pregunta un poco tonta, pero me gustaría saber qué opináis, como programadores y como usuarios.
A mi me parece buena idea.
Pero yo usaria la carpeta temporal del sistema (GetTempPath).
Vaya... se me adelantó Lord Trancos -.-
Si no tienes la posibilidad de cargar desde memoria el MIDI, entonces la solución de Lord Trancos parece la más adecuada.
Saludos.
La carpeta temporal del sistema, en algunos sistemas como w2000 suele estar en :
"c:\Documents and Settings\nombre de usuario\Configuración local\temp"
así que puede variar de longitud. Lo mejor sería que testearas primero lo que ocupa la ruta temp, y si es demasiado larga, usar la del sistema, es más guarro, pero muchos programas lo hacen.
un saludo
¿Pero q se supone q es pa leer un midi que incluyas tu con tu juego/aplicacion no?
Si es pa eso, con poner la ruta a partir del exe valdria no?
por ejemplo:
- tienes el juego/aplicacion instalado en c:\juegos\caca de vaca\
- El .exe esta en c:\juegos\caca de vaca\caca.exe
- Abres un midi de c:\juegos\caca de vaca\midis indicando el path \midis\vaca.midi
Si dices de abrir un midi q no incluyas tu y q no sepas la ruta cambia la cosa.
Puede q no haya entendido el problema :S
Saludos! B)
Y si usas directx 9?
yo para el motor que tengo y que me lee los zips descomprimo en el mismo directorio de la aplicacion y luego lo elimino cuando he hecho lo que quiero con el, asi te aseguras de evitar fallos de caches, archivos temporales, etc de windows
saludos
Mi primera idea también fue usar GetTempPath, pero me daba como resultado algo de la forma "C:\DOCUME~1\ADMINI~1\CONFIG~1\Temp\", que se corresponde con "C:\Documents and Settings\Administrador\Configuración local\Temp", lo cual me planteaba dos problemas:
1- No estaba seguro de si DX7 trabajaría bien con rutas en formato 8.3 . Hoy he hecho la prueba y aparentemente no tiene ningún problema, pero claro, me faltaría testearlo en otros sistemas...
2- La dirección equivalente en formato largo, como bien dice fiero, es de longitud variable y, aunque no es excesivamente larga, podría ser un poco arriesgado.
Por estos dos motivos pensé en usar la carpeta de windows, que suele ser "c:\Windows", "c:\Winnt", o semejantes. Bien, supongo que alguien puede haber instalado Windows en "c:\Te voy a escribir la ruta más bonita, y más larga, del mundo, porque tengo ganas de j**er de lo lindo a tewe76, etc, etc, etc, hasta el infinito y más allá", pero ésto ya lo veo muy improbable :D
En conclusión, la idea de fiero me parece adecuada. Testeo la ruta original, que no, pues la Temp, que no, pues la Windows, que no, pues a saco en "c:\papapapa".
Citar
- tienes el juego/aplicacion instalado en c:\juegos\caca de vaca\
- El .exe esta en c:\juegos\caca de vaca\caca.exe
- Abres un midi de c:\juegos\caca de vaca\midis indicando el path \midis\vaca.midi
Ya, nsL, pero la cosa no funciona así :). Yo a DX le tengo que pasar la ruta completa del archivo, no le sirve la relativa respecto al ejecutable.
CitarY si usas directx 9?
Pues tienes razón, voy a pasar mi engine DX7 a DX9. Tendré que reescribirlo por completo, aumentaré los requisitos mínimos del sistema, reduciré en un 80% la cuota de mercado de mis juegos share, pero todo merece la pena con tal de hacer que los usuarios que instalen mi juego en una ruta extrañamente larga, puedan disfrutar del placer de escuchar un midi, con su alta calidad musical, sin falta de tener que ensuciar su sistema con asquerosas copias temporales de archivos. Tienes razón, straT, me has hecho ver la luz, no sé cómo no me he dado cuenta antes. ¡Viva DX9! ¡Muera DX7! :D :D
Citaryo para el motor que tengo y que me lee los zips descomprimo en el mismo directorio de la aplicacion y luego lo elimino cuando he hecho lo que quiero con el, asi te aseguras de evitar fallos de caches, archivos temporales, etc de windows
Sí, es lo lógico. Lo que me pasa a mí es que el problema no es necesitar archivos temporales, sino necesitar que su ruta no supere los 130 caracteres.
Bueno, lo dicho, original->temp->win->c:\, creo que haré éso.
Gracias a todos.
Y si el fichero en cuestión está en c:\algolargodepelotas\fichero.mid...
¿Porqué no hacer un chdir( "c:\algolargodepelotas\" ) y luego cargarlo con la ruta relativa ("fichero.mid")?
¿Por qué utilizar DX? ¿Has mirado las funciones MCI del api de windows?
A veces nos complicamos con DX u otras librerias y en el API de win95 hay funciones muy útiles. En las MSDN está este ejemplo:
Playing a MIDI File
The following example opens a MIDI sequencer device, verifies that the MIDI mapper was selected as the output port, plays the MIDI file specified by the lpszMIDIFileName parameter, and closes the device after playback is complete.
// Plays a specified MIDI file by using MCI_OPEN and MCI_PLAY. Returns
// as soon as playback begins. The window procedure function for the
// specified window will be notified when playback is complete.
// Returns 0L on success; otherwise, it returns an MCI error code.
DWORD playMIDIFile(HWND hWndNotify, LPSTR lpszMIDIFileName)
{
UINT wDeviceID;
DWORD dwReturn;
MCI_OPEN_PARMS mciOpenParms;
MCI_PLAY_PARMS mciPlayParms;
MCI_STATUS_PARMS mciStatusParms;
MCI_SEQ_SET_PARMS mciSeqSetParms;
// Open the device by specifying the device and filename.
// MCI will attempt to choose the MIDI mapper as the output port.
mciOpenParms.lpstrDeviceType = "sequencer";
mciOpenParms.lpstrElementName = lpszMIDIFileName;
if (dwReturn = mciSendCommand(NULL, MCI_OPEN,
MCI_OPEN_TYPE | MCI_OPEN_ELEMENT,
(DWORD)(LPVOID) &mciOpenParms))
{
// Failed to open device. Don't close it; just return error.
return (dwReturn);
}
// The device opened successfully; get the device ID.
wDeviceID = mciOpenParms.wDeviceID;
// Check if the output port is the MIDI mapper.
mciStatusParms.dwItem = MCI_SEQ_STATUS_PORT;
if (dwReturn = mciSendCommand(wDeviceID, MCI_STATUS,
MCI_STATUS_ITEM, (DWORD)(LPVOID) &mciStatusParms))
{
mciSendCommand(wDeviceID, MCI_CLOSE, 0, NULL);
return (dwReturn);
}
// The output port is not the MIDI mapper.
// Ask if the user wants to continue.
if (LOWORD(mciStatusParms.dwReturn) != MIDI_MAPPER)
{
if (MessageBox(hMainWnd,
"The MIDI mapper is not available. Continue?",
"", MB_YESNO) == IDNO)
{
// User does not want to continue. Not an error;
// just close the device and return.
mciSendCommand(wDeviceID, MCI_CLOSE, 0, NULL);
return (0L);
}
}
// Begin playback. The window procedure function for the parent
// window will be notified with an MM_MCINOTIFY message when
// playback is complete. At this time, the window procedure closes
// the device.
mciPlayParms.dwCallback = (DWORD) hWndNotify;
if (dwReturn = mciSendCommand(wDeviceID, MCI_PLAY, MCI_NOTIFY,
(DWORD)(LPVOID) &mciPlayParms))
{
mciSendCommand(wDeviceID, MCI_CLOSE, 0, NULL);
return (dwReturn);
}
return (0L);
}
Yo creia que las que tenian el bug eran las MCI y que DirectX nuevos los corregia para sistemas operativos viejos.
NukeDX (creo) tiene bien solucionado este problema y el codigo es abierto, puedes mirar ahí la solución que proponen.
Saludos
Pues qué tontería, pero al final la mejor solución es la de sés :)
Ya me la había planteado, aunque había dado por supuesto que no funcionaría. Pero a raiz de tu comentario me dió por probarlo y, efectivamente, ¡funciona! (ole)
Genial, mucho más sencillo.