[SOLUCIONADO] [Consulta]Tile Map.¿Mejor std::vector o array?

[vangodp]

Hola compañeros¿Como os va?

Tengo ganas de hacer un pequeño jueguito 2d basado en tilemap. Quisiera saber sus opiniones sobre la efectividad sobre usar std::vector o arreglos. O si creen que hay otro medio mejor soy todo oídos

¿Tengo entendido que los arreglos son ligeramente más rápidos que los vectores, pero realmente vale la pena usar arreglos? ¿O sera mejor usar vectores?

Estoy en C++ claro. Si tienen alguna idea de como armar un tilemap de forma efectiva me gustaría oír que opinan, ya que ni idea de como empezar XD

Suerte y muchas gracias.

[razpeitia]

Mantenlo simple, usa arreglos hasta que necesites lo contrario.

[eferion]

Los contenedores de la STL son una buena idea cuando no se sabe a ciencia cierta la cantidad de elementos que vamos a utilizar. El contendor entonces se encarga de la gestión de la colección por nosotros, lo cual es de agradecer porque te permite eliminar mucho código y centrarte en otros aspectos más importantes de tu código.

Sin embargo, ceder esa gestión tiene un precio, y es que tenemos que ceder en la gestión de la memoria. Si es necesario, el contendor redimensionará el arreglo interno sin preguntarnos, lo cual consume tiempo de ejecución y es algo que hace sin avisarnos.

Si se sabe que el contenedor va a necesitar almacenar X elementos, se puede llamar a "vector.reserve( X )", de tal forma que el contenedor se asegurará que su arreglo interno disponga de al menos esa capacidad para evitar reallocs innecesarios.

Si el tamaño es fijo también puedes optar por usar "std::Array", que es un contenedor especializado para un tamaño fijo.

Yo, personalmente, prefiero usar los contenedores, ya que se usan exactamente igual que los arreglos con la ventaja de que te puedes despreocupar de la gestión interna de esos datos. Además, la implementación de los contenedores suele estar bastante optimizada, luego es complicado que un código propio pueda competir en términos de rendimiento.

Sobre este último párrafo una aclaración: la STL tiene varios tipos de contenedores. Si se necesita un rendimiento óptimo hay que saber elegir el contenedor adecuado, ya que cada uno está pensado para un uso determinado y eso hace que todos tengan unas ventajas y unos inconvenientes que hay que tener en cuenta.

Yo es que soy partidario de no reinventar demasiadas veces la rueda... si algo ya existe no necesito volver a crearlo. Prefiero invertir mis esfuerzos en hacer la parte de la aplicación que no está hecha y que nadie me va a ayudar a hacer.

[vangodp]

Iniciado por razpeitia

Mantenlo simple, usa arreglos hasta que necesites lo contrario.

Eso creo que debo hacer, pero como no se si es lo mas acertado... XD
Gracias por responder. =)

Y gracias eferion por tan completa respuesta.
En principio es para un mapa de tamaño fijo pero el poder re dimensionar quizás me sirva luego mas adelante, por eso pregunto, no tengo mucha experiencia con las STL XDD

Gracias mil (y)

[eferion]

Iniciado por vangodp

En principio es para un mapa de tamaño fijo pero el poder re dimensionar quizás me sirva luego mas adelante, por eso pregunto, no tengo mucha experiencia con las STL XDD

Si tu idea es, por ejemplo, mapear un tablero, puedes hacerlo de varias maneras. Por ejemplo con un mapa anidado:

Código C++:

std::map< int, std::map< int, std::string > > tablero;
 
// Acceso a la coordenada 3, 4
tablero[3][4] = "aqui va el bicho";
 

En el ejemplo estamos sacrificando algo de rendimiento en beneficio de la legibilidad... pero también podemos optar por el rendimiento sacrificando un poco la legibilidad del código:

Código C++:

std::map< std::pair< int, int >, std::string > tablero;
 
// Acceso a la coordenada 3, 4
tablero[ std::make_pair( 3, 4 ) ] = "aqui va el bicho";
 

Esta segunda opción es más eficiente porque la llamada "make_pair" es mucho más ligera que tener mapas anidados, que era lo que sucedía en el primer ejemplo.

Por supuesto, esto se puede encapsular en un objeto para que su uso sea algo más natural:

Código C++:

class Tablero
{
  public:
 
   /* ... */
 
   std::string& Valor( int fila, int columna)
   { return _datos[ std::make_pair( fila, columna ) ]; }
 
  private:
 
    std::map< std::pair< int, int >, std::string > _datos;
};
 
int main( )
{
  Tablero tablero;
  tablero.Valor( 3, 4 ) = "Aquí va el bicho";
  std::cout << tablero.Valor( 3, 4 );
}
 

[razpeitia]

Te recomiendo usar arreglos por un par de razones.

1. Usualmente el tamaño del mapa no cambia en tiempo de ejecución.
2. Tu eres responsable del manejo de la memoria.
3. Hoy hay overhead al acceder a un elemento.
4. Incluso si el mapa es grande, no ocupas tenerlo todo cargado en ram al mismo tiempo.
5. De hecho habrá un numero de titles determinado que solo van a poderse dibujar en la pantalla.

Juegos como snake, arkanoid, tetris, ajedrez, tienen mapas pequeños, pero otros juegos como rpgs tienen mapas mas grandes, los cuales usan otras técnicas para no cargar todo el mapa en RAM a menos que tengas suficiente RAM.

[eferion]

Iniciado por razpeitia

2. Tu eres responsable del manejo de la memoria.

Sobre este tema hay varios frentes diferentes. Yo prefiero no tener que estar bajando constantemente a este nivel... para eso me pongo a programar en ensamblador y controlo hasta las interrupciones del procesador.

Si tengo que hacer una reserva a nivel local dentro de una función por ejemplo, prefiero embutirla en un unique_ptr que dejar el puntero crudo. El overhead es despreciable, no tengo que preocuparme del delete y, si se provocan excepciones no se crean lagunas de memoria.

Por supuesto, cada uno tendrá sus prioridades, yo prefiero centrar mis esfuerzos en que la aplicación funcione correctamente más que en desesperarme por las lagunas de memoria... sobretodo si se trabaja dentro de un grupo grande de trabajo.

Iniciado por razpeitia

3. Hoy hay overhead al acceder a un elemento.

Implementación del operador de indización de la clase vector:

Código C++:

reference
      operator[](size_type __n) _GLIBCXX_NOEXCEPT
      { return *(this->_M_impl._M_start + __n); }
 

Varios detalles sobre la función:

* Está implementada en la cabecera, luego en "release" será implementada como "inline"
* Hace los cálculos mínimos para cargar el puntero a la posición pedida. No se puede optimizar más.

Conclusión: overhead 0 o insignificante.

Iniciado por razpeitia

4. Incluso si el mapa es grande, no ocupas tenerlo todo cargado en ram al mismo tiempo.

No estoy para nada de acuerdo con este punto.

Me explico: Que tengas un mapa en vez de un arreglo no quiere decir que tengas que tener todo cargado en memoria... además, los contenedores de la STL pueden manejar también punteros en vez de elementos por valor; luego las posibilidades de configuración son amplísimas.

Un contenedor, bien elegido, es prácticamente idéntico a tener un arreglo... con la ventaja de que te puedes despreocupar de parte del código porque sabes que va a funcionar.

Pero claro, esto lo dice alguien que es partidario de usar los contendores :D

[amchacon]

Una ventaja que tiene los vectores frente a los arreglos esque en la depuración puedes usar la función at.

Es igual que los operadores [] pero lanza una excepción si adcedes fuera de rango. Muy útil para detectar desbordamientos de array.

1. Usualmente el tamaño del mapa no cambia en tiempo de ejecución.

Lo cual no es excusa, simplemente es usar el contenedor adecuado. El contenedor Array tiene un tamaño constante por ejemplo:
http://www.cplusplus.com/reference/array/array/

2. Tu eres responsable del manejo de la memoria.

Mala idea, el código de las STL está probado, libre de bugs y optimizado a más no poder. Pero el tuyo no, es muy fácil que te salga un memory leak y acabe siendo peor.

También puedes hacer algo combinado y es crear los elementos dinámicamente con unique_ptr:
http://www.cplusplus.com/reference/memory/unique_ptr/

De esa forma, tu decides cuando haces "delete" en el objeto. Pero si se te olvidara ya lo hace el unique_ptr por defecto (ojo, el unique_ptr es para elementos individuales, para arreglos hay que usar la STL array).

3. Hoy hay overhead al acceder a un elemento.

Despreciable respecto a una implementación a mano.

4. Incluso si el mapa es grande, no ocupas tenerlo todo cargado en ram al mismo tiempo.

5. De hecho habrá un numero de titles determinado que solo van a poderse dibujar en la pantalla.

Eso lo puedes hacer igual con un contenedor STL.

[vangodp]

Los contenedores me atraen pero claro.. Estoy muy verde aun con los contenedores.

Intentare hacer con los contenedores y veré si pillo algo de practica con ellos, aun que no descarto tener que hacer con arreglos por mi inexperiencia. XD

Justamente por eso consulto( Por el trabajo excesivo), a lo mejor me cuesta mas trabajo si no trabajo de forma correcta.

Gracias a todos por contestar.

[eferion]

Iniciado por vangodp

Los contenedores me atraen pero claro.. Estoy muy verde aun con los contenedores.

Si no usas los contenedores nunca vas a usarlos con soltura.

[amchacon]

Mantén abierta la página de la documentación en el navegador:
http://www.cplusplus.com/reference/stl/

[razpeitia]

Iniciado por amchacon

Una ventaja que tiene los vectores frente a los arreglos esque en la depuración puedes usar la función at.

Es igual que los operadores [] pero lanza una excepción si adcedes fuera de rango. Muy útil para detectar desbordamientos de array.

O_O usa valgrid, te ayuda a detectar memory leaks y este tipo de errores.

Iniciado por amchacon

Lo cual no es excusa, simplemente es usar el contenedor adecuado. El contenedor Array tiene un tamaño constante por ejemplo:
http://www.cplusplus.com/reference/array/array/

Solo para tener at, swap y otros métodos?
Para que me agrege overhead y me complique el manejo de memoria al ponerlo en heap?

Iniciado por amchacon

Mala idea, el código de las STL está probado, libre de bugs y optimizado a más no poder. Pero el tuyo no, es muy fácil que te salga un memory leak y acabe siendo peor.

Como te dije antes, existes herramientas para detectar memory leaks, segmentation fault, etc...

Y STL no esta libre de bugs, solo checa el bug tracker https://gcc.gnu.org/bugzilla/buglist...ormat=advanced

Mira el motor de quake engine 3, no usan stl. Principalmente porque saben que están haciendo.

Iniciado por amchacon

También puedes hacer algo combinado y es crear los elementos dinámicamente con unique_ptr:
http://www.cplusplus.com/reference/memory/unique_ptr/

De esa forma, tu decides cuando haces "delete" en el objeto. Pero si se te olvidara ya lo hace el unique_ptr por defecto (ojo, el unique_ptr es para elementos individuales, para arreglos hay que usar la STL array).

Posiblemente le ayude, en otros escenarios. Pero en un mapa usualmente solo lo cargas al iniciar y lo eliminas al salir. Y si usas stack en lugar de heap no ocupas liberar la memoria.

[amchacon]

Iniciado por razpeitia

O_O usa valgrid, te ayuda a detectar memory leaks y este tipo de errores.

Es otra opción, pero es ganas de reinventar la rueda *_*

Iniciado por razpeitia

Solo para tener at, swap y otros métodos?

Para liberarte del manejo de memoria, para usar los métodos ya creados en cada clase STL y para reutilizar código ya hecho.

Si tienes que usar una Cola. ¿Te haces una class Cola o usas queue? Pues la segunda opción es la más rápida y sencilla.

Iniciado por razpeitia

Y STL no esta libre de bugs, solo checa el bug tracker https://gcc.gnu.org/bugzilla/buglist...ormat=advanced

Ok dejemoslo en casi sin bugs. Desde luego va a tener menos que una implementación que hagas sobre la marcha.

Iniciado por razpeitia

Mira el motor de quake engine 3, no usan stl. Principalmente porque saben que están haciendo.

De hecho el motor del Quake es un bichaco lindo de elogio.

Pero eso no cambia nada, yo también podría ponerte ejemplos de juegos hechos en ensamblador. Y no por ello sería la mejor opción a día de hoy, esque si se siguiera ese ejemplo también sería absurdo usar Java o C# *_*

Iniciado por razpeitia

Para que me agrege overhead y me complique el manejo de memoria al ponerlo en heap?

Iniciado por razpeitia

Posiblemente le ayude, en otros escenarios. Pero en un mapa usualmente solo lo cargas al iniciar y lo eliminas al salir. Y si usas stack en lugar de heap no ocupas liberar la memoria.

En el stack no hay problema y es lo más sencillo. Pero si lo vas a cargar en el stack esque el mapa no es muy grande que digamos.

A partir de 100.000 elementos yo ya pienso en pasar cosas al heap, así no corro riesgo de desbordar la pila. Y con el uso de las STL me libero de la tarea de administrarla.

[lareto]

Hola; me cuelo en la discusión con una cita de Herb Sutter (en C++ Coding Standards 101 Rules Guidelines and Best Practices):
"Why juggle Ming vases? Avoid implementing array abstractions with C-style arrays, pointer arithmetic, and memory management primitives"

Sus argumentos a favor de vectores y strings se refieren al manejo automático de memoria, facilidades de la interfaz, compatibilidad con el modelo de memoria del C, chequeo de errores para debug, no representan demasiado gasto en eficiencia, incentivan las oportunidades de optimización (en la implementación de la stl). Y por supuesto, considera aceptable el uso de arrays de estilo C cuando las dimensiones son fijas y conocidas en tiempo de compilación.

Desde el C++11 existe el std::array (antes boost::array), que es un wrapper de array de estilo C, de tamaño constante:
http://en.cppreference.com/w/cpp/container/array

[vangodp]

Sin querer desate una guerra santa de los contenedores/arreglos jaja.

Solo quería saber algunas ideas y ya me lo han proporcionado muy buenas.

Como se trata de mi primer jueguito, voy intentar usar los contenedores a modo de que me sirva de practicas, para así poder tener una opinión propria sobre los contenedores de STL ya que nunca se me ha presentado una necesidad real de tener que usarlos. Pero por supuesto si no consigo o lo veo complicado no me queda mas remedio que usar el arreglo de toda la vida. XD

Lo siento el raleo, pero es bueno escuchar opiniones adversas. Todas las opiniones me parecen buenas... Unas mas que otras eso si, pero muchísimas gracias a todos.

Doy por concluido el tema.

¡gracias, sois grandes! ;)

[eferion]

Todo el rato pendiente del hilo... Y cuando me voy a casa sale la parte interesante...

[razpeitia]

Iniciado por amchacon

Es otra opción, pero es ganas de reinventar la rueda *_*

Como dije antes, concuerdo en que hay escenarios donde vector o array serian útiles, pero al menos no para este.

Iniciado por amchacon

Para liberarte del manejo de memoria, para usar los métodos ya creados en cada clase STL y para reutilizar código ya hecho.

También, puedes no reutilizar todo ese codigo, que te aseguro que mucho no lo utilizara porque es simple mapa en un juego. Incluso le podría dar opción de usar solo C.

Iniciado por amchacon

Si tienes que usar una Cola. ¿Te haces una class Cola o usas queue? Pues la segunda opción es la más rápida y sencilla.

Ya use la clase queue que hay en std, pero luego te das cuenta que no es threadsafe y terminas implementado la tuya usando un mutex :\ o usando algún queue que sea threadsafe de alguna otra librería.

Iniciado por amchacon

Ok dejemoslo en casi sin bugs.

Iniciado por amchacon

Pero eso no cambia nada, yo también podría ponerte ejemplos de juegos hechos en ensamblador. Y no por ello sería la mejor opción a día de hoy, esque si se siguiera ese ejemplo también sería absurdo usar Java o C# *_*

Muchas optimizaciones hoy en día en juegos se hacen en ensamblador. Hacer todo en una abstracción mas alta te lleva al dilema de cuando es mas conveniente uno y otro.

Iniciado por amchacon

En el stack no hay problema y es lo más sencillo. Pero si lo vas a cargar en el stack esque el mapa no es muy grande que digamos.

Puedes ajusta el tamaño del stack. Incluso si no quieres que ocupe espacio en el stack, lo puedes poner como static. Después de todo lo vas estar pasando entre varias funciones.

Iniciado por amchacon

A partir de 100.000 elementos yo ya pienso en pasar cosas al heap, así no corro riesgo de desbordar la pila. Y con el uso de las STL me libero de la tarea de administrarla.

100,000 elementos es muy arbitrario. 100,000 bytes (100Kb) no es lo mismo que 100,000 uint64 (800Kb) o tal vez una estructura mas grande.

Lo cual es muy poca ram considerando que una computadora de escritorio actual 1GB de ram es un chiste.

[amchacon]

Iniciado por razpeitia

También, puedes no reutilizar todo ese codigo, que te aseguro que mucho no lo utilizara porque es simple mapa en un juego. Incluso le podría dar opción de usar solo C.

Me refería al código del contenedor STL, que no hace falta escribirlo.

Iniciado por razpeitia

Ya use la clase queue que hay en std, pero luego te das cuenta que no es threadsafe y terminas implementado la tuya usando un mutex :\ o usando algún queue que sea threadsafe de alguna otra librería.

No es excusa para no reutilizar código:

Código C++:

template<class T>
class queue
{
   std::queue<T> cola;
   std::mutex cerrojo;
 
   public:
 
     void push(const T &elemento)
     {
           cerrojo.lock();
           cola.push();
           cerrojo.unlock();
     }
     
     //!empty()
     T pop()
     {
           cerrojo.lock();
           a = cola.pop();
           cerrojo.unlock();
           return a;
     }
 
     T size() const
     {
           return cola.size();
     }
 
     bool empty() const
     {
           return cola.empty();
     }
}
 

Un ejemplo de implementación que se podría hacer. Reutilizando código como te dije (primera máxima de la ingeniería del software).

PD: La implementación no es perfecta, es solo un ejemplo de código hecho sobre la marcha.

Iniciado por razpeitia

Muchas optimizaciones hoy en día en juegos se hacen en ensamblador. Hacer todo en una abstracción mas alta te lleva al dilema de cuando es mas conveniente uno y otro.

Quizás en algún caso muy puntual, pero dudo que se haga de forma habitual.

Hoy en día se programa en más alto nivel que nunca, no es raro ver un juego hecho enteramente en Java (android) o con un motor gráfico (Unity con scripts en C#).

Además la diferencia entre ASM y C ya no es notable. Los compiladores han mejorado muchísimo en optimización los últimos 20 años, un buen programador de ASM todavía le saque algo (10-20%?). No vale la pena liarse para tener una mejora constante, al final lo que importa es tener un buen algoritmo más que un lenguaje cercano a la maquina. Eso si que se nota.

Iniciado por razpeitia

100,000 elementos es muy arbitrario. 100,000 bytes (100Kb) no es lo mismo que 100,000 uint64 (800Kb) o tal vez una estructura mas grande.

Lo cual es muy poca ram considerando que una computadora de escritorio actual 1GB de ram es un chiste.

El stack por defecto suele rondar 1 mb. De ahí mi aproximación.

No entiendo como prefieres tocar las opciones del compilador (no portable) que usar memoria dinámica (solución portable). Le has cogido manía a la memoria dinámica y no sé porque.

Iniciado por razpeitia

Incluso si no quieres que ocupe espacio en el stack, lo puedes poner como static. Después de todo lo vas estar pasando entre varias funciones.

Las variables static son peligrosas salvo que estas tengan un valor constante. Pues si no las mantienes controladas puede producir efectos laterales (funciones que con la misma entrada te genera un resultado diferente).

[lareto]

La cuestión original era si convenía usar arrays (disculpas, tengo una especie de alergia a la palabra arreg.. ahgjj! Sput. -disculpas) o std::vector para implementar un "tile map" (que francamente no sé qué es; más disculpas); pero bueno, se derivó hacia temas éticos generales...

En el último post que estoy viendo (de razpeitia) se dicen un par de cosas con las que no estoy de acuerdo, y me parece una lástima que queden así. En particular, me parece especialmente erróneo el comentario (sonrisas, en realidad) sobre los bugs en la STL.

Por un lado, la STL es parte del estándar C++, mientras que los bugs son de la implementación de la libstdc++ de gnu. Detalles semánticos al margen, en la lista esa conté 288 bugs. Muy impresionante.

No tengo idea de la magnitud o el significado de cada uno de ellos, pero supongamos que el número me resultara suficientemente elocuente como para formarme una idea sobre la conveniencia o no de usarla..., y quizá quedarme con lo que parece una conclusión general, mejor un "C con clases", más eficiente y, sobre todo, libre de todos esos 288 bugs.

Ahora, que la biblioteca estándar de C de gnu (glibc) tenga 386 bugs, ¿debería impresionarme en forma proporcional? En fin, en todo caso, el sarcasmo es un pésimo argumento.

El otro punto que creo que está errado es lo que parece una crítica a la std::queue (o, bueno, el contenedor que resulte estar adaptando) por no ser "threadsafe", cuando en realidad lo criticable sería que sí lo fueran. Si interesa el tema podríamos discutirlo.

[razpeitia]

Iniciado por amchacon

Me refería al código del contenedor STL, que no hace falta escribirlo.

Claro que me refiero al STL, hay un montón de código que no utilizara. Ya sea como métodos de clases que solo ocuparan espacio.

Iniciado por amchacon

No es excusa para no reutilizar código:

Un ejemplo de implementación que se podría hacer. Reutilizando código como te dije (primera máxima de la ingeniería del software).

Incluso reutilizando queue, caes en mi punto original, implementas tu propia versión thread safe. Porque STL no te ofrece esa opción.

Incluso si lo reutilizas, ahora tienes bugs tuyos mas los del STL.

Iniciado por amchacon

Además la diferencia entre ASM y C ya no es notable. Los compiladores han mejorado muchísimo en optimización los últimos 20 años, un buen programador de ASM todavía le saque algo (10-20%?). No vale la pena liarse para tener una mejora constante, al final lo que importa es tener un buen algoritmo más que un lenguaje cercano a la maquina. Eso si que se nota.

Incluso si tienes un buen algoritmo, optimizar partes en ensamblador sigue siendo una practica común en el desarrollo de video juegos.

Iniciado por amchacon

El stack por defecto suele rondar 1 mb. De ahí mi aproximación.

Eso depende el sistema operativo y arquitectura.

Iniciado por amchacon

No entiendo como prefieres tocar las opciones del compilador (no portable) que usar memoria dinámica (solución portable). Le has cogido manía a la memoria dinámica y no sé porque.

Solo son opciones, si fuera una aplicación CRUD con diferentes clases de registros, cargándolos de alguna base de datos. Ahí si valdría la pena usar memoria dinámica. No para implementar titles de un mapa (al menos que sean mapas gigantescos, que no creo que vayan a ser grandes).

Iniciado por amchacon

Las variables static son peligrosas salvo que estas tengan un valor constante. Pues si no las mantienes controladas puede producir efectos laterales (funciones que con la misma entrada te genera un resultado diferente).

Las variables static NO son peligrosas, la ignorancia de como usarlas si. Y esos efectos colaterales (que creo que es lo que quisiste decir). Es simplemente eso, desconocimiento.

Mi punto es:
Usa arreglos, son simples, funcionan, hacen bien su tarea, no pierdas tiempo y muévete a la siguiente tarea. El la parte de grid o titles, es solo una pequeña parte de todo el juego.

Si, por alguna razón tu juego empieza a crecer y empiezas a tener limitantes, usa la memoria dinámica.

Pero ese es mi consejo, no hagas over engineering de las cosas que son simples.

[vangodp]

..."tile map" (que francamente no sé qué es; más disculpas); pero bueno...

Vale... Lo admito. Omiti una 'd' en el titulo XD es TiledMap, mi ingles es fatal Pero es que no hay una traducción al español o por lo menos no la conozco yo XDD.

A efectos un TiledMap es eso: Es una especie de patrón que son simples enteros, y que se usan a la hora de hacer el mapa para un juego basado el lucetas o baldosas.

Es decir:
se toma esto:

...Para hacer esto:

Pero en el fondo no es mas que esto:

Puede tener un tamaño definido o se puede generar sobre la marcha. Aun que ese ultimo ya no me sera ni una pizca de fácil crear, ya que la generación aleatoria de mapa será algo así como la caña en programación, de momento esta muy lejos de mi realidad. XDD

Pero creo que estas de broma cuando dices que no sabes... Será que es por mi falta de ortografía inglesa XD. Solo te digo que no soy ninguna especie de jefe redactor, y que tanto mi ingles como mi español y también mi portugués son así de lindos XDD

Saludos.

[lareto]

Iniciado por vangodp

Pero creo que estas de broma cuando dices que no sabes...

Hola; no, no era broma. Ahora que me lo dices y veo tu ejemplo, lo entiendo. También me he puesto a buscar cómo podría decirse en castellano, y me encontré con que "tile" viene a ser "mosaico", así que "tiled map" es un mapa hecho de taracea (las piecitas de un mosaico).

Y a juzgar por el lío que se ha armado, me parece que no soy yo el único que no sabía que es un tiled-map...

[chisme] Viendo mosaicos, me encontré con este mosaico del siglo IV de chicas en biquini en una villa de Sicilia:
https://commons.wikimedia.org/wiki/F...ale_Bikini.jpg [/chisme]

[vangodp]

Hola; no, no era broma. Ahora que me lo dices y veo tu ejemplo, lo entiendo. También me he puesto a buscar cómo podría decirse en castellano, y me encontré con que "tile" viene a ser "mosaico", así que "tiled map" es un mapa hecho de taracea (las piecitas de un mosaico).

Asi es.. Es algo en principio muy simples, pero no se engañe que el tamaño puede abrumar. Basta ver juegos como minecraft que tienen un tamaño 'infinito'. Pero claro solo se carga como unos 20 cubitos en todas las direcciones ya al moverte va generando nuevos y borrando los que queden atraz, hay una opcion que te permite digamos que ver mas lejos que lo que hace es que aumenta la cantidad de cubos que puedes ver. Ademas no se cargan cubos que no puedes ver....
En fin, parece algo que a primera hora es sencillo, pero todo depende que lo cuanto quieres liarte. jajaj

Y a juzgar por el lío que se ha armado, me parece que no soy yo el único que no sabía que es un tiled-map...

Es normal. No tienes por que saberlo todo, si no te va lo de programar jueguitos pues a lo mejor te suena chino, y unido a mi falta de ortografía mas jaja. Pero es que si se hace de modo bien echo reduce el tiempo de carga, que dependiendo del tamaño del mapa se agradece.

[chisme] Viendo mosaicos, me encontré con este mosaico del siglo IV de chicas en biquini en una villa de Sicilia:
https://commons.wikimedia.org/wiki/F...ale_Bikini.jpg [/chisme]

¡Mejor, mejor! jajajaj

[eferion]

Iniciado por razpeitia

Claro que me refiero al STL, hay un montón de código que no utilizara. Ya sea como métodos de clases que solo ocuparan espacio.

Discrepo ligeramente.

Un ejemplo lo tenemos precisamente en los contenedores por el simple hecho de ser templates. Cuando el compilador se encuentra un template no lo compila directamente, sino que espera a encontrarse usos del template y entonces crea las especializaciones pertinentes... pero que el compilador especialize un template no quiere decir que toque todo el template... puede suceder que únicamente compile aquellas funciones que se requieren en el programa... si un template tiene 1.000 funciones pero solo usas 4 el compilador puede decidir eliminar el resto del código.

Por otro lado, no creo que sea preocupante que el código tenga algunos cientos (o incluso miles) de líneas de código que no se usan. El consumo de espacio que esto representa es ridículo y no afecta al rendimiento.

Iniciado por razpeitia

Incluso reutilizando queue, caes en mi punto original, implementas tu propia versión thread safe. Porque STL no te ofrece esa opción.

Los contenedores no son, por el momento, thread safe por que la STL se centra en el rendimiento. La lógica thread safe penaliza el rendimiento y no es necesaria en la inmensa mayoría de los desarrollos. Encapsular un contenedor para que éste cumpla con tus requisitos en entornos multihilo añade prácticamente el mismo overhead que programarte tu propio contenedor, con la ventaja añadida de que tienes menos código que mantener.

Iniciado por razpeitia

Incluso si lo reutilizas, ahora tienes bugs tuyos mas los del STL.

Veamos:

• Tu programa se apoya sí o sí en la STL para realizar determinadas tareas. No se si el número de programas que evitan la STL llegará al 0,01% del total.
• Tu programa hace uso de funciones del sistema operativo, que tampoco están exentas de fallos...
• Tu programa acaba haciendo uso de librerías externas... que acabas eligiendo tú... y que también tienen su propia colección de fallos

No creo que decir que la STL tiene bugs sea un argumento de peso dadas las circunstancias.

Además, te puedo garantizar que en el proyecto en el que trabajo... una suite con más de 10 millones de líneas de código que usa la STL, Qt, OpenCascade, exceed, flex, boost... y así hasta un centenar de librerías externas... aún no nos hemos topado con ningún bug en la STL que tire por tierra el código ya realizado.

Iniciado por razpeitia

Incluso si tienes un buen algoritmo, optimizar partes en ensamblador sigue siendo una practica común en el desarrollo de video juegos.

Este tipo de optimizaciones no están al alcance de cualquiera. Mantener código en ensamblador es una tarea bastante compleja porque requiere tener en cuenta muchísimos detalles a nivel de hardware. No hay más que ver el presupuesto que tienen muchos juegos comerciales.

Además, ese nivel de optimización no suele ser para nada necesaria en juegos caseros... los programadores tienen la mala costumbre de querer que sus juegos vean la luz antes de morir de viejos jejejeje

Iniciado por razpeitia

Solo son opciones, si fuera una aplicación CRUD con diferentes clases de registros, cargándolos de alguna base de datos. Ahí si valdría la pena usar memoria dinámica. No para implementar titles de un mapa (al menos que sean mapas gigantescos, que no creo que vayan a ser grandes).

En c++, usar memoria dinámica puede ser tan sencillo como utilizar la pila. De hecho, cuando una función recibe un parámetro por referencia o un puntero a tí te es imposible saber si ese elemento está en el stack o en el heap... de hecho, te es indiferente.

Por otro lado, por mucho que uses la pila, si no eres capaz de encontrar el equilibrio adecuado a la hora de pasar elementos a funciones (por valor, referencia, puntero) el rendimiento va a ser muchísimo peor que si directamente usas punteros y memoria dinámica en toda tu aplicación.

Iniciado por razpeitia

Las variables static NO son peligrosas, la ignorancia de como usarlas si. Y esos efectos colaterales (que creo que es lo que quisiste decir). Es simplemente eso, desconocimiento.

Todavía no he encontrado a ningún gurú de C++ que las defienda... más bien todo lo contrario. Y estos son algunos de los argumentos:

• Se pierde la relación de dependencia
• Las variables globales se pueden solapar con las locales... el compilador no te va a avisar y vas a encontrarte con errores bastante puñeteros
• El orden de construcción es totalmente aleatorio, lo que puede suponer un problema
• El orden de destrucción es aleatorio, de echo puede suceder en entornos multihilo que una variable global se destruya cuando todavía queda algún hilo hijo vivo. No digo que pase siempre... pero es algo que puede pasar

Iniciado por razpeitia

Mi punto es:
Usa arreglos, son simples, funcionan, hacen bien su tarea, no pierdas tiempo y muévete a la siguiente tarea. El la parte de grid o titles, es solo una pequeña parte de todo el juego.

También podríamos decir:

Usa contenedores de la STL, son simples, funcionan, hacen bien su tarea, te ahorras código, su funcionamiento es óptimo, evitas pegarte con la gestión de la memoria, ...

Iniciado por vangodp

Asi es.. Es algo en principio muy simples, pero no se engañe que el tamaño puede abrumar. Basta ver juegos como minecraft que tienen un tamaño 'infinito'. Pero claro solo se carga como unos 20 cubitos en todas las direcciones ya al moverte va generando nuevos y borrando los que queden atraz, hay una opcion que te permite digamos que ver mas lejos que lo que hace es que aumenta la cantidad de cubos que puedes ver. Ademas no se cargan cubos que no puedes ver....

Es algo más complicado que eso. Tienes que separar la información del mapa de la representación gráfica. Tener el mapeo de un millón de cubos de minecraft en memoria no debería suponer ningún reto para un equipo normalito. Como ejemplo, imagina que la clase "Cubo" almacena la siguiente información:

Código C++:

struct Cubo
{
  int posX, posY;
  int tipo;
};
 

En este ejemplo se necesitan 12 bytes por cada cubo, 12 millones de bytes en total o 11,5 MB de memoria.

El problema se encuentra en la parte geométrica... y es que forzar a la tarjeta gráfica a calcular la representación de 1 millón de cubos, cuando el 99% de los mismos van a estar ocultos sí o sí puede ser un trabajo titánico para la tarjeta gráfica.

El juego en estos casos suele cargarse la geometría de todos los cubos que estén a X distancia de la cámara, de forma que le ahorras una cantidad ingente de trabajo a la tarjeta gráfica.

[amchacon]

He llegado a un punto muerto con razpeitia. Pero ha sido un interesante debate :)

Iniciado por eferion

Los contenedores no son, por el momento, thread safe por que la STL se centra en el rendimiento. La lógica thread safe penaliza el rendimiento y no es necesaria en la inmensa mayoría de los desarrollos. Encapsular un contenedor para que éste cumpla con tus requisitos en entornos multihilo añade prácticamente el mismo overhead que programarte tu propio contenedor, con la ventaja añadida de que tienes menos código que mantener.

Creo que la razón de que no sean thread safe esque la librería de threads apareció en el estándar C++11. Por lo que es todavía muy reciente, pero no me extrañaría que en los próximos años saliesen las "STL Threadsafe".

[eferion]

Iniciado por amchacon

He llegado a un punto muerto con razpeitia. Pero ha sido un interesante debate :)

Si, es agradable poder defender una postura y que te la rebatan :)

Iniciado por amchacon

Creo que la razón de que no sean thread safe esque la librería de threads apareció en el estándar C++11. Por lo que es todavía muy reciente, pero no me extrañaría que en los próximos años saliesen las "STL Threadsafe".

Cierto, aunque viendo lo que cuesta cambiar cosas en la STL, me da que va a llevar unos años tener este tipo de contenedores disponibles.

[vangodp]

Es algo más complicado que eso. Tienes que separar la información del mapa de la representación gráfica. Tener el mapeo de un millón de cubos de minecraft en memoria no debería suponer ningún reto para un equipo normalito. Como ejemplo, imagina que la clase "Cubo" almacena la siguiente información:

Si... Si es en un mapa de minecraft si. ¿Pero no se carga todos esos un millón de cubos?

Creo que solo se carga "la cara" de los cubos que sean "visibles", o eso tengo entendido, me parece que lo implementaron hace algún tiempo esa técnica en minecraft. Eso ya lo había visto en el motor 'source' de steam, me olvide el nombre de la tecnica, pero creo que llevan muchos juegos en 3D, por eso se que en un mapa 3D no es sencillo para nada. Pero oye... Un juego pequeñito en 2D a lo mejor logro hacer algo¿No?

No me desanimes con lo de los "equipos normalitos" que toy yo solo y me hace mucha ilusion. jajajaj

[razpeitia]

Iniciado por vangodp

Pero oye... Un juego pequeñito en 2D a lo mejor logro hacer algo¿No?

No me desanimes con lo de los "equipos normalitos" que toy yo solo y me hace mucha ilusion. jajajaj

Esto es exactamente, por lo que recomendé arreglos, por lo prácticos que son.

No te desanimes, muchos juegos creados en los 80 y principios de los 90 fueron desarrollados por una sola persona. Usualmente en ensamblador. Esto fue la época de oro de los vídeo juegos. Después llego el inicio del apple store y fue como la segunda época de oro, donde los desarrolles podían crear sus propios juegos y vivir de eso.

De hecho aquí tienes material para que puedas empezar:
http://www.losersjuegos.com.ar/referencia/ejemplos

Existen ejemplos en C, C++ y Python.

[kutcher]

Iniciado por vangodp

¿Tengo entendido que los arreglos son ligeramente más rápidos que los vectores, pero realmente vale la pena usar arreglos? ¿O sera mejor usar vectores?

Recuerda que la optimización prematura es la raíz de todos los males, suponer que es mejor usar array de C porque son mas rapidos es caer en un error, mas bien esto depende mucho de las cincunstancias en donde las utilizas.

Sin embargo, un std::vector tiene una serie de atributos que potencialmente hace que sea más lento que un array de C:

- Un vector no almacena sus datos en posiciones de memoria continua. Los punteros al principio y al final del vector se almacena en una ubicación diferente a la de los propios datos.

- Un vector siempre asigna memoria para sus datos en el montón. La asignación en el montón es más lento de la asignación en la pila.

Estos son algunos puntos por los cuales considero que en determinados casos un array de C seria mas rapido respecto a un std::vector, pero como ya dije esto depende del momento en que decidamos utilizar uno u otro

Un Saludo

[eferion]

Iniciado por vangodp

Si... Si es en un mapa de minecraft si. ¿Pero no se carga todos esos un millón de cubos?

En memoria te entra ese millón de cubos y varios millones más. Y no es algo que tenga que ralentizar el equipo. Es lo que te comenté... una cosa es la información lógica de los objetos que componen el escenario del juego y otra diferente es la geometría que llevas a la escena.

Para que el juego funcione de la forma más eficiente posible tienes que intentar que la geometría que llevas a la escena sea la mínima. Si puedes evitar la carga en escena de un objeto porque está tapado por otro, le evitas a la tarjeta gráfica la realización de bastantes cálculos... pero claro, eso es algo a implementar si ves que el juego se traba.

Iniciado por vangodp

No me desanimes con lo de los "equipos normalitos" que toy yo solo y me hace mucha ilusion. jajajaj

¿Desanimarte? ¿Por decirte que puedes ocupar 20 MB de RAM en 2 millones de cubos de minecraft sin problemas de rendimiento? No creo que te desanimes por eso :)

Iniciado por kutcher

Un vector no almacena sus datos en posiciones de memoria continua. Los punteros al principio y al final del vector se almacena en una ubicación diferente a la de los propios datos.

Tu puedes declarar un vector tal que:

Código C++:

std::vector< int* > vectorDePunteros;
 

En cuyo caso, efectivamente, los punteros estarán alineados y luego la ubicación física de los int puede estar en cualquier sitio... pero tambien puedes hacer

Código C++:

std::vector< int > vectorDeEnteros;
 

En cuyo caso los enteros están en posiciones de memoria consecutiva.

Es más, en cualquiera de los dos casos, el overhead con respecto a usar un arreglo tipo C es mínimo, de hecho en una de las respuestas puse el código de la implementación que trae mingw... lo dicho, el overhead tiende a cero compilando en modo release.

Iniciado por kutcher

- Un vector siempre asigna memoria para sus datos en el montón. La asignación en el montón es más lento de la asignación en la pila.

Es más lento... depende. Si guardas tipos básicos si, ahora, si tienes que estar metiendo en la pila objetos más pesados que además tienes que andar pasando como parámetros o funciones a otras funciones la situación se empieza a difuminar.

Se puede decir que la carga y descarga de datos desde la pila es más rápida... ahora en cuanto al acceso indirecto debido a punteros y referencias... teniendo en cuenta que los equipos actuales cachean la memoria por las condiciones de localidad y demás...

Que sí, que será más rápido... pero a veces esa rapidez es irrelevante y le solemos dar con frecuencia más importancia de la necesaria.

Iniciado por kutcher

Estos son algunos puntos por los cuales considero que en determinados casos un array de C seria mas rapido respecto a un std::vector, pero como ya dije esto depende del momento en que decidamos utilizar uno u otro

Yo aun no he requerido una potencia de cálculo tal que me haya visto obligado a usar un array de C en vez de un contenedor. Entiendo que habrá alguna situación en la que se de el caso... pero vamos, de momento no he visto el caso ni programando CADs ni máquinas de inspección por ultrasonidos en tiempo real.

Un Saludo