Compresión de .s y rendimento del simulador

[blas_dani]

Hola:

Me he dado cuenta que cuando obtengo los .s del gmax para las 444, estos tienen un tamaño mucho mayor que si los descomprimo y comprimo con el shape file manager (hablo de hasta un 10% del tamaño) o con alguna otra utilidad.

Entiendo que el simulador sabe trabajar con los .s comprimidos y que por lo tanto, cuanto menor tamaño de estos más rendimiento y menos espacio en memoria, no?

Pero si el simulador debe descomprimir los .s para mostrar el vagón, locomotora o lo que sea, necesitarà más tiempo para descomprimirlos... si estos estan muy comprimidos, no?

La pregunta es: como influye el tamaño de un .s en el rendimiento del simulador? puede esto condicionar el número de objetos en un tile? o el rendimiento del simulador al mostrar un tren (los saltos)?

Entiendo que contra más pequeños sean los .s mejor...

Saludos.

[javierav]

Hola.

Es díficil responder a tu pregunta sin saber como funciona el motor gráfico o simplemente el juego. Partimos de la base que el MSTS sabe interpretar tanto un archivo comprimido como sin descomprimir. Tenemos entonces dos posibilidades:

a) El motor gráfico usa internamente los archivos comprimidos. Entonces si usamos archivos descomprimidos el juego deberá comprimirlos, lo que se traduce en tiempo y carga, minúscula, pero existente.

b) Usa los archivos descomprimidos. Si los ponemos comprimidos el software deberá descomprimirlos, que cargará de una operación más al juego.

Desconozco que es lo que se hace exactamente al comprimir, no sé qué es lo que hace para comprimirlo ni cómo. Lo que si sé es que en el mundo de la programación en 3D se necesitan conocer coordenadas de puntos y vectores. Si esa compresión lo que hace es reducir todo a la mínima expresión (las coordenadas y demás), sin duda el simulador cargará más rápido porque le será más fácil leer los datos. Por contra si está sin comprimir deberá aparte de procesarlos, parsealos, es decir, sacar la información que necesita de todas esas líneas, con lo que consume más tiempo de proceso y recursos. Esto es lo que pienso bajo la lógica, pero ya digo que sin saber a ciencia cierta como funciona.. poco se puede afirmar.

Saludos.

[Arru]

Una pregunta:

¿De donde se baja el shape manager? ¿Para que sirve?

[francotrenes]

EL Shape File manager, comprime solo para que la distribucion del addon on sea liviana, no para que sea mas liviano en el juego, una vez que instalas un .S comprimido, el juego lo reconstruye la primera vez que jugas y luego queda del tamaño original, algo identico a lo que hace el juego cuando carga los .RAW de las rutas que se ejecutan por primera vez.
Carga los RAW, los genera, y luego ya tenemos la ruta pesadisima en el estado que el autor la tenia antes de comprimirla para que sea mas "liviana" su disribucion.-

Saludos, Franco.

[osses]

Hola,

¿De donde se baja el shape manager? ¿Para que sirve?

Arru, con el Shape File Manager se puede comprimir y descomprimir los archivos .s, y se puede tambien abrir los archivos .s con el wordpad, modificar las dimensiones de los objetos, modificar el aspecto de las texturas…

Descargas y ayudas en inglés :

http://steam4me.railpage.org.au/trainsi ... m_faq.html

en francés :

http://www.activitysimulatorworld.net/L ... r_2.3x.htm

Saludos a todos.

[Marc]

Con los ficheros .s, .w, etc. lo lógico sería que los cargase más rápido en formato binario (comprimidos) que en texto (descomprimidos). Con las texturas ocurre algo asimilar, muchas texturas están comprimidas de acuerdo al formato DXT, que es un formato de Direct3D, y eso agiliza su carga.

[Victor]

Sin embargo es una pena que MTS no implemente mapas debump. Espero y deseo que Kuju tenga el detalle de implementar la posibilidad de crear mapas de bumps y asignarlos a los objetos.

El problema vendrá con la compresión intrínseca del formato DXT1. Se trata de un formato de archivo cuya compresión lossy está orientada para bitmaps tales como imágenes de texturas cuya diferenciación entre píxeles es bastante elevada. Sin embargo esto no sucede así en imágenes de normal maps, hay ejemplos y explicación del funcionamiento de las mismas en un hilo del compañero Josep.

El formato DXT5, que acepta imágenes con canal alfa, combina la información del mismo con la información del canal R (rojo) y de esta manera consigue afinar la definición para crear un mapa de normales que aportan una calidad increible.

Saludos