Estoy intentado crear una clase para leer ficheros binarios (formato propio) con informacion sobre geometria 3D (tri-mesh).
public class clsGeom
{
// Consts --------------------------------------
public const int C_GEOM_ID = 0x4D4F4547;
public const int C_GEOM_VER = 0x1;
public const int C_GEOM_FLAG_HASNORMALS = 0x1;
public const int C_GEOM_FLAG_32BITINDICES = 0x2;
public const string C_GEOM_EXT = ".geo";
// Structures ----------------------------------
public struct TGEOM_Header
{
public int id;
public int ver;
public int nSubsets; // num subsets
public int nFaces; // number of faces
public int nVtx; // number of vertices
public int nTC; // number of texture coordinates
public int nColors; // number of colors
public int flags; // bit 0 - has normals
// 1 - use 32 bit indices
// 2..31 - not used yet
public int reserved; // must be 0
}
/* ... */
public struct TGEOM_3S
{
public float x;
public float y;
public float z;
}
/* ... */
// Properties ----------------------------------
public TGEOM_Header header;
// Methods -------------------------------------
public void LoadFromFile(string _fn)
{
// Create the reader for data.
FileStream _fs;
int moco;
// open file
_fs = new FileStream(_fn, FileMode.Open, FileAccess.Read);
BinaryReader _r = new BinaryReader(_fs);
// read header
header.id = _r.ReadInt32();
header.ver = _r.ReadInt32();
header.nSubsets = _r.ReadInt32();
header.nFaces = _r.ReadInt32();
header.nVtx = _r.ReadInt32();
header.nTC = _r.ReadInt32();
header.nColors = _r.ReadInt32();
header.flags = _r.ReadInt32();
header.reserved = _r.ReadInt32();
/* ... */
// close
_r.Close();
}
/* ... */
}
El problema lo tengo al leer la cabecera (por ejemplo). Y es que me parece muy cutre leer dato a dato, ademas de que me huelo que tiene que ser lento de c*j*nes. Sin embargo, las webs que he encontrado que hablan del tema
(1) (2), usan código unsafe y por ahora quiero evitar usarlo (por lo de no coger "malos" habitos desde el principio).
Lo mismo me pasa cuando voy a leer el array de vertices (un array de elementos TGEOM_3S) .... ¿como se supone que tengo que leerlo?
En fins,.. me quitan los punteros, el SizeOf,... el reverso tenebroso del unsafe me llama :ph34r:
no te preocupes, la lectura del fichero tiene cache y va a toda leche, yo para leer una estructura lo que suelo hacer es una funcion estatica en la propia estructura que pasandole un stream me devuelve una nueva creada con los datos leidos
saludos
editado: tambien si quieres puedes hacer un constructor pasandole el stream, cuestion de gustos
Hola,
lo mismo te vale también (si lo que lees y escribes es serializable) usar un BinaryFormatter para escribir y leer con Serialize y Deserialize. Un saludo!
Vicente
Cita de: "zupervaca"no te preocupes, la lectura del fichero tiene cache y va a toda leche, yo para leer una estructura lo que suelo hacer es una funcion estatica en la propia estructura que pasandole un stream me devuelve una nueva creada con los datos leidos
No si eso ya me lo imaginaba.
Pero imaginate que tengo que leer un archivo con 1000 vertices.
Si cada vertice tiene solo 3 componentes (X,Y,Z), eso son 3000 asignaciones.
for idx = 0 to header.vertex.count-1 do
{
buffer[idx].x = _r.ReadFloat();
buffer[idx].y = _r.ReadFloat();
buffer[idx].z = _r.ReadFloat();
}
Acostumbrado a leer todo el buffer de una tacada y meterlo en un puntero... pues como que me parece cutre y seguro que es mucho mas lento.
Tendre que investigar lo que comenta vicente.
Ahora es cuando llego yo y meto la puntilla de los punteros del C jejeje :P
despues de los post anteriores no he podido resistirme....
es broma eh? no os lo tomeis a mal :rolleyes:
CitarPero imaginate que tengo que leer un archivo con 1000 vertices.
Si cada vertice tiene solo 3 componentes (X,Y,Z), eso son 3000 asignaciones
ya eso es cierto, pero es la unica manera de hacer codigo seguro que es lo que se busca con c-sharp, ademas ten seguro que aunque puedas leer varios vertices al mismo tiempo nadie te asegura que las estructuras de los vertices esten alineadas a 1 byte con lo que podrias llegar a perder datos, solo en c++ se puede cambiar esta alineacion, el serialize no te librara de hacer las asignaciones individuales a cada valor del vertice, tu otra solucion es usar unsafe, pero no creo que sea bueno acostumbrarse a algo que puede que en un futuro se elimine.
saludos
editado: se me olvido poner un codigo de ayuda para leer los vertices, teoricamente el c-sharp deberia corregir todo para que siempre funcionara, pero es algo experimental, ademas de que los datos del fichero de vertices de un md2 son de un byte
VertexMD2[] vertexs = new VertexMD2[head.NumVertices];
byte[] datos = new byte[head.NumVertices * 5];
file.Read(datos, 0, head.NumVertices * 5);
datos.CopyTo(vertexs, 0);
return vertexs;
asi puedes leerlos todos al mismo tiempo, pero ya te digo que los vertices en el fichero de un md2 son de un byte con lo que la alineacion no importa, el "* 5" es que no se puede usar sizeof si no es unsafe ;)
juaz acabo de darme cuenta que es x,y,z,lightNormalIndex con lo que es *4 y no *5 :lol:
Desde que descubrí la serialización no he vuelto a hacer loaders... basta con hacer:
Object mi_objeto;
mi_objeto.serialize("bleh.mu");
y punto. No tiene C# implementada la serialización ?
Una cosa que me ha hecho gracia que ha dicho zupervaca sobre la lectura cacheada, que supongo que habrá querido decir buffereada. Que yo recuerde no he visto ninguna implementación de lectura de ficheros que no la lleve (incluso FILE y sus fread, etc).
Si que tiene serialización. Para marcar algo como serializable se usa el atributo [Serializable]. Luego si tienes un array de vértices lo serializas y ya lo tienes guardado de una tacada. Para leerlo lo deserializas y de otra tacada. Sencillo sencillo (supongo que las estructuras son serializables también, que no he probado...).
Para serializar se usa el BinaryFormatter. Pego un poco de código de VB.NET (es un clone usando serializable). Debería ser fácil de entender:
Public Overridable Function Clone() As Object Implements ICloneable.Clone
Dim formateador As BinaryFormatter
Dim memoria As MemoryStream
formateador = New BinaryFormatter
memoria = New MemoryStream
'Nos serializamos y volvemos a poner el puntero de lectura/escritura al principio
formateador.Serialize(memoria, Me)
memoria.Seek(0, IO.SeekOrigin.Begin)
'Nos desserializamos para conseguir la copia
Return formateador.Deserialize(memoria)
End Function
Hola,
Otra cosa: si quieres hacer una enumeracion de las estilo C/C++ esas que cada valor es una potencia de dos para poder usar el OR, puedes usar el atributo [Flags] (o [Flag] no recuerdo) en la enumeración y te lo hace solo. Algo como:
[Flags]
public enum CosasRara
{
C_GEOM_FLAG_HASNORMALS,
C_GEOM_FLAG_32BITINDICES
}
Un saludo!
Vicente
Una cosa que me ha hecho gracia que ha dicho zupervaca sobre la lectura cacheada, que supongo que habrá querido decir buffereada. Que yo recuerde no he visto ninguna implementación de lectura de ficheros que no la lleve (incluso FILE y sus fread, etc).
pues no entiendo el motivo de por que te ha hecho gracia, un cache es un buffer, no se si sabras que leer 64kb en disco es lo mismo que leer 1byte, con lo que cuando lees un byte el sistema de archivos lee 64kb y si lees continuo sin usar posicionamientos aprovechas esa cache, solo queria decir eso, el serialize de esa clase object lo que hace es un read sobre toda la estructura y me imagino que sera de c++, pero aqui se habla de c-sharp y no c++, en c++ todos sabemos leer una estructura del tiron
saludos
editado: si vas a usar estructuras para probar el serialize que nos comenta vicente ten cuidado con ellas, son muy peligrosas, ya que para pasarlas entre funciones debes usar ref o te hara una copia enterita
Cita de: "zupervaca"
pues no entiendo el motivo de por que te ha hecho gracia, un cache es un buffer, no se si sabras que leer 64kb en disco es lo mismo que leer 1byte, con lo que cuando lees un byte el sistema de archivos lee 64kb y si lees continuo sin usar posicionamientos aprovechas esa cache, solo queria decir eso, el serialize de esa clase object lo que hace es un read sobre toda la estructura y me imagino que sera de c++, pero aqui se habla de c-sharp y no c++, en c++ todos sabemos leer una estructura del tiron
saludos
Vicente ha explicado bien lo que yo decía de serialize que es lo que preguntaba, supongo que no lo habrás leído.
Me hace gracia porque a dado la impresión (__a mi__) que lo dices como una caracteristica novedosa de C#, de ahí el comentario, que iba en un tono desenfadado, no con la intentción de mofarme de nadie (que hay que aclararlo todo).
En cuanto a la caché, estamos de acuerdo, una caché puede ser un buffer, pero es igual que si dices que un ferrari son 4 ruedas y un chasis :). Con respecto a los 64 kb, pues no sé, dependerá de la arquitectura y de miles de cosas, pero es obvio que cuando vas a disco, no vas solo a por unos bytes. Todos conocemos el principio de localidad de referencia creo yo.
Con respecto a lo que dices de la clase object, si te refieres a la que he puesto yo, era un ejemplo, no me rerería a ningún lenguaje ni ninguna clase en concreto, era una especie de pseudocódigo para ilustrar mi pregunta y a la vez mostrar el uso que le doy yo a serialize.
veamos el problema que tiene lord no es leer una estructura del tiron, es leer muchas a la vez como se hace con el fread de toda la vida, eso con c-sharp en principio no se podra hacer por motivos de estabilidad y seguridad, cuando creas un array de vertices, solo has creado un array de punteros a vertice, deberias de recorrerlos todos y crearlos, si creas un array de bytes (que es como se hace en c++) no podras realizar la conversion de byte[] a Vertice[] ya que el jit te dira nanai de la china, si quieres leerlo todo del tiron debes usar unsafe, si quieres ir a la tendencia de c-sharp lee dato a dato, no obstante prueba el serialize que nos indica vicente, pero deberas realizar las asignanciones igual
saludos
En este caso no me refería a caraterísticas concretos de C#, las que desconozco, quería centrarme en que para formatos propios de datos, las típicos de guardar partida o similares, es muy interesante el concepto de serialize, en el cual tu guardas el estado de tu objeto independientemente de cual sea el objeto, y lo recuperas sin preocuparte absolutamente de nada. Para el programador es mucho más cómodo usar eso que programarte tú el exporter/importer.
En este caso puede que no sea el más adecuado ya que puede que ese fichero de mesh lo use en un importador de un programa de modelado y el formato en el que lo guarde el serializer no sea el más sencillo y funcional a la hora de leerlo y, por supuesto, de exportarlo.
Hola,
Si List o ArrayList o un array son serializables no hay que asignar nada: tu metes el array a capon en el fichero y lo lees a capón del fichero ;) Si serializas los vértices uno a uno, pues los desserializas (o como leches se escriba) uno a uno, pero si es el array entero, pues ya está ;) (como lo haga por debajo ni idea).
Respecto a lo que dice ethernet tiene razón, si es un formato que luego tiene que leer otro programa pues chungo usar el serialize (aunque puedes hacerte tu propio serializador si quieres, .NET trae también además del binario el de XML, que seguramente será más humano de intentar parsear desde fuera).
Un saludo!
Vicente
Efectivamente hacer un serialize de toda la clase no me interesa, pq el fichero como bien comentais tiene un formato que no quiero cambiar y se genera con herramientas que nada tienen que ver con c#.
Lo del arrayList que comenta vicente, si que parece ser lo que me interesa. Ya que, aunque me da igual leer la cabecera del fichero campo a campo, lo que no quiero es leer el "vertex buffer" a lo tonto como en el código de ejemplo que antes.
Mielda.... nada, que lo de serialize no me sirve... no me habia dado cuenta pero ya me lo estabais diciento... (nooo)
Estaba haciendo unas pruebecillas de escribir un array en un fichero y veo que me pone "cosas raras" dentro del fichero...
...Version=1.0.2042.31070, Culture=neutral, PublicKeyToken=null...
La madre que lo pario (grrr)
No me puedo creer que algo tan sencillo pueda estar tan complicado.... ¿no hay forma humana de leer un array de vertices sencilla en este lenguaje o que? (grrr) (grrr) (grrr)
pues segun vayas programando mas y mas te daras cuenta que el c-sharp no esta bien pensado ;)
Cita de: "zupervaca"pues segun vayas programando mas y mas te daras cuenta que el c-sharp no esta bien pensado ;)
Pues a duras penas acabo de empezar (asco)
Recuerdo haber visto código en C# que leía los mapas de quake3 y utilizaba unos métodos para leer las estructuras de la misma forma que se hace en C/C++. Eso sí, creo recordar que utilizaba bloques de código no seguro.
Por desgracia no recuerdo dónde lo ví. :D
Saludos.
Cita de: "BeRSeRKeR"Eso sí, creo recordar que utilizaba bloques de código no seguro.
Entonces no te preocupes, codigo no seguro para hacer lo que quiero lo he encontrado, pero prefiero no usarlo por ahora.
Por cierto, en el engine teneis codigo no seguro?
Creo que las únicas secciones donde hay código no seguro es en dos métodos del wrapper para Newton.
Saludos.
Hola,
se me ocurren varias alternativas:
a ) has probado las 3000 asignaciones esas? Tan lentas son?
b ) hazte un programa en C++, lees el fichero (eso es muy facil no?) y lo reescribes en SOAP (esto ya no se si es muy fácil). Leerlo así está tirado en C# (es el serializador XML). También lo podrías leer luego en Java por ejemplo.
Yo diría que además de ser problema del C#, es problema del formato ;) Un saludo!
Vicente
P.D.: lo del serializador SOAP no lo he probado, pero eso dice la teoría :P
Cita de: "zupervaca"pues segun vayas programando mas y mas te daras cuenta que el c-sharp no esta bien pensado ;)
Hola,
lo diseñó el mismo tio que diseñó el Delphi. Supongo que ese hombre sabe lo que se hace... ;) Un saludo!
Vicente
Citar
a ) has probado las 3000 asignaciones esas? Tan lentas son?
No. No las he probado. Mi "alma" coder se niega a escribir "eso".
Citar
Yo diría que además de ser problema del C#, es problema del formato
Bwuaaaahahahahahahaha! :lol:
Estas de coña, no? Sabes cuantos formatos de fichero existen similares ?
Citar
lo diseñó el mismo tio que diseñó el Delphi. Supongo que ese hombre sabe lo que se hace... wink2.gif
Adoro el Delphi. Programo en Delphi.
Pero si no encuentro una forma "decente" y "safe" de leer ficheros como ese en c#, algo esta mal en ese lenguaje.
Cita de: "Lord Trancos 2"Bwuaaaahahahahahahaha! :lol:
Estas de coña, no? Sabes cuantos formatos de fichero existen similares ?
Hola!,
nop, no lo estoy: es un formato viejo pensado para lenguajes viejos ;) Un saludo!
Vicente
P.D.: lo cual no quita que el formato sea útil, solo digo que ahora con lo que se lleva el XML (por ejemplo), pues los nuevos lenguajes estos (Java, C#), están pensados para trabajar con eso, no con formatos más de ficheros de texto y tal.
Yo no sé si lord habrá terminado su juego y estará optimizando, pero me surge la eterna duda: cuando se debe empezar a pensar en la optimización? Es realmente tan importante mejorar las cargas? sería mejor utilizar ese tiempo en mejorar otros aspectos más visibles para el usuario como la jugabilidad?
Me resulta curioso ver como la gente piensa en optimizar con asm y cosas de ese tipo. En mi opinión lo primero es tener algo jugable, lo siguiente, mejorarlo y si sobra tiempo, optimizar el código, pero desde luego como ultimísimo recurso. Creo que cuando una persona lleve 20 años programando juegos se puede permitir el lujo de optimizar "al vuelo".
mis dos céntimos XD
Vicente
Me parece muy bien que c# este horientado a xml y tal... pero luego nos quejamos de que si tal o cual programa me va lento en mi flamante sextium 8 a choporrocientosmil teraherzios.
Entiendo que los nuevos lenguages esten diseñados pensando en la productividad y la estabilidad por encima de la eficiencia, pero de ahi a ralentizar absurdamente (safe mode) la lectura del monton de formatos binarios que hay en este mundo,... me parece una barbaridad. Si algo tan básico no se puede hacer de forma mas o menos eficiente, apaga y vamonos.
ethernet
Nooooo.... que va. A mi juego aun le queda un largo trecho. Amen, de que esta hecho en Delphi y no en c#. Estas dudas sobre c# son simplemente pq estoy aprendiendolo ahora, y claro, quiero saber la forma correcta de hacer las cosas; la forma cutre (la que puse de ejemplo) ya la conocia.
Coincido contigo en que lo primero es tener algo jugable y no perder el norte con otras cosas. Pero no creo que hagan falta 20 años de experiencia para que a la hora de cargar un array de vertices te permitas el "lujo" de hacerlo de una tacada y no de vertice en vertice :P
---
En fins... que me veo que al final me tocará hacerlo en plan guarro o usar unsafe mode... <_<
¿Nadie con una idea revolucionaria de última hora que permita hacerlo "como dios manda"? :rolleyes:
Yo estoy con Vicente. C# no está pensado para cosas del pasado y le cuesta....Por eso todos los nuevos formatos de fichero están cambiando....Sin embargo, siempre puedes utilizar Managed C++ o código unsafe para estas cosas. Ciertamente decidir que el C# es bueno o malo por el cargador de formatos antiguos....
si tus modelos son del 3dsmax puedes usar el script que hice para crear ficheros y guardar datos en formato xml desde maxscript, esta en mi web por si quieres descargartelo y usarlo para lo que tu quieras, incluso limpiarte el kks con el :D
en mi caso el modelo de pruebas que estoy haciendo (quitando el md2 cutre que tengo para probar rollos) es en formato xml exportado desde el 3dsmax, no obstante en este formato cuando se lee del disco se estan realizando asignaciones sin parar, con lo que es lo mismo ;)
saludos
Cita de: "Haddd"Ciertamente decidir que el C# es bueno o malo por el cargador de formatos antiguos....
Hombre, teniendo en cuenta que acabo de empezar a aprender c#, y me encuentro limitaciones como esta... pues es obvio que mas putaditas me voy a encontrar. Yo no he dicho que c# sea malo, todavia no lo conozco lo suficiente para juzgarlo, pero para mi, empieza a ganar puntos negativos.
Hola,
Citar
Me parece muy bien que c# este horientado a xml y tal... pero luego nos quejamos de que si tal o cual programa me va lento en mi flamante sextium 8 a choporrocientosmil teraherzios.
No se si has trabajado mucho con XML... Tan lenta es la serialización SOAP como para que no te valga? (lo has probado?). .NET usa XML a todos los niveles, por ejemplo, en ADO.NET, y no me parece que sea un acceso a bd nada lento (o por lo menos de momento no he encontrado problemas de rendimiento...).
Respecto a las asignaciones, no se, no te cuesta nada mirar si ese tiempo de carga es tan inaceptable como para no hacerlo así (para mi mejor eso que el unsafe... Pero bueno, para gustos colores).
Citar
Hombre, teniendo en cuenta que acabo de empezar a aprender c#, y me encuentro limitaciones como esta... pues es obvio que mas putaditas me voy a encontrar. Yo no he dicho que c# sea malo, todavia no lo conozco lo suficiente para juzgarlo, pero para mi, empieza a ganar puntos negativos.
Esto sería como si vinieras de C#, estuvieras acostumbrado a trabajar con serialización de objetos y de repente usaras C++ y tuvieras que cargar un objeto Serializado... O lo de transformar un objeto a SOAP en C++, que supongo que no será muy dificil porque por algún sitio habrá una clase de alguien que se ha tenido que pegar con eso, pero así de serie te puedes querer hasta morir para hacerlo a manita...
Pero bueno, que cada cual trabaja mejor con lo que está acostumbrado, eso es de cajón ;) Hasta que no cambies el chip le vas a encontrar muchos "puntos negativos" me temo. Un saludo!
Vicente