¿Seguimos con el rollo de la pirateria?

Bajarse un juego del emule NO ES PIRATERIA. ¿Otra vez? Bajarse un juego del emule NO ES PIRATERIA. ¿Otra vez?, ....

Si alguien se dedicara a copiar juegos y a venderlos en el "plof manta" para lucrarse el mismo me quejaria :P, como me quejo de que cada back-up en dvd de mi trabajo me cueste más por que le tengo que pagar a unos impresentables que dicen ser los representantes de la "industria de la cultura" ... pues por mi que se metan su industria por donde les quepa, y ojalá les reviente y se queden con los c*j*n*s colgando.

Espero no haberme pasado  (twist)  

 Apoyo la moción: muy grande el Tim Sweeney. Y no solo por como programa, que ya de por si es una puta birgueria.

 Un editor para lo que tu quieres, y las funciones que te permitan crear y cargar tu formato es lo que solo tienen algunas compañias de juegos para móvil.

Es un trabajo laborioso, pero efectivamente, como tu comentas, te da una ventaja tecnologica brutal respecto a los demás. Si creas un buen sistema no dudes que habrán bastantes compañias que estén interesados en comprarte la tecnologia, es más, acudirán a ti como moscas a la miel (por no hablar mal).

Pues nada, suerte con tu cruzada tecnologica!!  B)  

 Una pregunta, ¿la imagen estaria animada?

De todas formas creo que es la representacion mas apropiada para el problema. Lo que pasa es que igual te supone demasiado coste dibujar muchos fragmentos de cada personaje, sobretodo si hay varios de ellos en pantalla.
La mejor manera de hacerlo, si no estan animados los personajes, seria montar la imagen (en una nueva imagen) final antes de dibujarla, pero esto presenta varios incovenientes que ya se mencionarón en el otro "famoso hilo" que mencionamos en post anteriores sés y yo.

Si quieres hacerlo bien create una herramienta que, de manera visual rollo Jpanel y usando el ratón, te permita crear objetos como rectangulos que delimiten regiones de la imagen. Podrias permitir editar valores como la posicion respecto a un punto central del personaje, una cadena asociada (para la utilidad que les quieras dar), etc. Después lo puedes guardar directamente a un archivo binario. En j2se es facil y te asegura un mayor grado de compatibilidad a la hora de compartir código con la aplicación MIDlet.

Otra opción es copiar las coordenadas (miradas a ojo en tu editor de imagenes) y propiedades en txt o un xml (con un formato que le quieras dar) y luego te creas tu aplicacion que lea el fichero y lo pase a un binario.

Bueno, o como quieras  :lol:

Bueno, un saludo, me voy a comer  (genial)  

 Yo me decanto también por tener un mapa off-screen que tenga información sobre las colisiones o cualquier otro "efecto físico del escenario". Así podrias tener un "physic layer" por llamarlo de alguna manera, donde cada tile tenga información de la posición relativa de colision respecto al tile, etc. (lo que ha comentado zupervaca antes), y además cualquier propiedad especial que pueda tener el tile en cuestion (lava que quema, estar por debajo/superfice de agua, etc..).
Si el tamaño de los tiles es potencia de 2, saber que tile corresponde a un punto es muy facil y rapido, solo tienes que realizar el desplazamiento n a la derecha de la coordenada original (donde n es la potencia de 2).

El tema de plataformas y otros objetos moviles es sencillo de optimizar si puedes mantener los objetos ordenados por sus coordenadas. Por ejemplo (lexicograficamente) por coordX y/o por coordY.
Si mantienes en un array (o lista enlazada en su defecto podria funcionar muy bien, las STL son muy utiles en estos casos) todos los objetos que puedan interactuar entre ellos, al buscar las posibles colisiones puedes reducir el numero de comprobaciones, ya que:
- Si recorremos el array (lista en su defecto) de forma ordenada cada uno de los elementos solo podrá colisionar con los objetos anteriores o con los posteriores hasta llegar a uno con una coordX mayor que nuestra coordX + anchura. En eeste momento el bucle se rompe y podemos seguir con el siguiente elemento. Un ejemplo en pseudocódigo podria ser:

Código [Seleccionar] Expand

for (int i = 0; i < tam_array; i++) {
   for (int j = 0; j < tam_array; j++) {
       if (i == j)
           continue;

       if (colisiona(array_objs[i], array_objs[j])
           interacciona(array_objs[i], array_objs[j]);

       if ((array_objs[i].x + array_objs[i].w) < array_objs[j].x)
           break;
   }
}


Algunas anotaciones sobre esta idea:
+ se llama tanto a interactua(i, j) como a interactua(j, i);. Si esto no es lo requerido, es decir, basta con llamar a una de las dos funciones, podemos modificar el código para evitarnos estas comprobaciones.
+ ¿Se podria optimizar más?, puede, realizando particones espaciales quizás, o manteniendo punteros que relacionen los objetos con los tiles que ocupan como se proponia en un principio (pero cuando se muevan dichos objetos el coste de computación aumenta).
+ La ordenación. Esto supone un coste extra, pero puede ahorrarnos mucho más dependiendo de la organización (y tb cantidad de sprites/objetos/enemigos/etc) del nivel actual. Si se opta por almacenar los datos en un array se podria sacar provecho del qsort, aunque otros algoritmos podrian venir mejor si tenemos en cuenta que los objetos que se muevan no se desordenarán demasidas posiciones (por normal general) de la que ocupaban en el frame anterior.

Nueno, y con esto y un bizcocho ...
Espero que te haya servido de ayuda
Y si alguien detecta un fallo en el planteamiento o una posible optimización estaria muy interesado en escuchar vuestra opinión al respecto.

Un salu2

PS: al final el pseudo-código se ha quedado más bien en C-ódigo :P

EDIT: acabo de leer esto

Ademas cuando se inicia este juego el player empieza a caer y cae tres veces por lo menos y es porque el incremento de posicion sobre pasa dos tiles y claro lo que hay por medio no lo detecta y es como si no hubiera nada y por eso cae.

Mi idea era la de poner a todo aquel que colisione en una misma capa asi cuando compruebo colisiones me evito comparaciones innecesarias. Otra cosa que tengo duda es como hacer para detectar colision en un tile solo por un lado. Tiene que ver algo la posicion por la que entro en el bloque?

A ver, en mi opinión:
1) lo de comparaciones innecesarias se solucionaria con el método propuesto anteriormente para los objetos moviles (colisiones entre si).

2) Te conviene guardar la posicion anterior de tus sprites o la velocidad en su defecto. Con esto podrias saber por que lado del tile colisionas. Además de poder interpolar las coordenadas para saber si has atravesado algo. Sule venir bien un bresenham modificado (algoritmo que sirve para dibujar lineas pixel a pixel) para recorrer este trayecto, y además es muy rápido.

 

... No quiero ni pensar si estuviera de moda chuparsela mientras uno hace el pino.

Pero si no se puede hombre!!
weno, yo no lo sé, no lo he probado ... esto ...    :blink:  .... uff que tarde!!

ale, pues nada, atalego si eso

 A mi también me gustado mucho. Los gráficos son flipantes  (genial)

Suerte con el proyecto!!!!!!!

 Jejeje, d pm. Mola mogollón. 8.3 !!!!!! Peazo puntuación.  (ole)  

 argg! un troll!!!! hechizo flecha llameante!!!! ataque con arco élfico antiguo!!!
O_O  ups, parece que juego demasiado ultimamente

Xuti H lo de dividir una imagen en varias en tiempo de ejecucion ¿no consumiria mucha memoria? Habria que tener cargada en memoria 30 pequeñas imagenes (si tuvieramos 30 casillas en el tileset)

Si, consumiria más memoria por la cabeceras del PNG, 8kb cada imagen creo recordar que se comento anteriormente por estos foros ... pero puede que ganes velocidad.
EDIT: y para que no comenceis a atacarme - lo de la cabecera es en el jar seguro. Puede que en memoria principal vaya de otro modo, sobretodo dependiendo del dispositivo, cada uno es diferente.
Ciertamente los problemas más típicos con la asociación memoria-imagen están en los Nokia. Es muy facil encontrar que un telefono nokia no libere NUNCA de forma adecuada la memoria que ocupaba un objeto Image. Ya puedes poner la referencia a null, hacer 1001 Garbage Collectors, golpear insistentemente el móvil contra la mesa, .... es lo que hay.
Lo de tener setClip y drawRegion escritas a la vez es una buena idea, ya que comentando y descomentando un par de lineas puedes cambiar de modo, entre midp1 y 2.  (ole)  Pero claramente funcionará más rápido (al menos tendria que hacerlo) drawRegion en los MIDP2.
Son solo consejos, ya que la verdad del juego para móvil es que hay así como unos 1000 modelos diferentes de dispositivos. Cada uno de ellos irá peor en una cosa :( encontrar el equilibrio entre tamaño del jar, velocidad del juego y no quedarte sin memoria principal = ufffff (nooo).

En cuanto a la pregunta de chechocossa creo que si que es por el tema de tener tiles animados (concretamente si la api tiene que buscar los pixeles de la imagen que corresponderian al current-tile de esa animación). Pero no sabria como solucionarlo, muy probablemente que funcione o no en un móvil dependerá de como haya implementado la api para java el fabricante de este dispositivo. Personalmente no utilizaria tiledLayer. Ya sé que es un coñazo tener que implementarte un sistema de mapeado de tiles, colisiones, etc. pero si realmente quieres que la cosa vaya en moviles con MIDP2, utiliza drawRegion, y adelante.

Y hablando de mini-tutos y cosas de estas. Yo dejé hace bastantes meses un COTW que estaba haciendo sobre este tema precisamente. Nunca lo acabé y (logicamente) nunca lo subí, a ver si saco tiempo y me pongo ...

Un salu2 y no os insulteis muxo :P

 dios josete!!
haya donde leo un mensaje tuyo veo lo mismo!!! tranquilo que no seremos responsables de acabar con la moral humana (entre otras cosas porque eso no existe) con nuestros entreteniemientos electronicos para degenerados.

Los fines de semana la gente se mete en sitios ...

Ya sabemos que era una ironia, gracias.

 Creo que la cosa se ha dicho ya 10^100000000 veces.
¿Para q c*ñ* servirán los numeritos esos de las cajitas?

 

El ejemplo de apalear un perro no es de lo mas acertado... cuando era chico NO EXISTIAN los videojuegos y conocía a mucha gente que se dedicaba a apalear perros, gatos y lo que se le cruce...

Como que no!!!!!!!!
Los videojuegos han sido y serán siempre la causa única e ineludible de la violencia.
Desde Caín, Abel, y toda la tropa. El tráfico de blancas, el imperialismo, las mafias, ...., todo, absolutamente todo es causa directa de la violencia producida por el consumo de videojuegos.
Los videojuegos se cuelan en nuestras casas y pervierten a nuestros hijos. Mientras nosotros confiados les dejamos horas y horas frente al monitor para no tener que establecer una relación normal con ellos: ya sea hablar, jugar o interesarse por los gustos y aficiones de estos.

DIOSSSS!!!!!!! A donde nos va a llevar esto!!! Me voy ahora mismo a misa a rezar por nuestras almas pecadoras!!!

PS: La violencia es violencia. Los videojuegos son videojuegos. Y los fachas, c*br*n*s e h*j*sd*p*t* en general no necesitan jugar a videojuegos para intentar j*d*r a los demás. En ultima instancia necesitarian un sistema muchisimo menos hipócrita que realmente pueda ayudarlos a no tener que vivir en contínua lucha contra si mismos.

Edit: en cuanto al tema de que la violencia que remueve la conciencia. Como todo, la gente ha de autocensurarse. Que haya un videojuego en el mercado que promueva el sexismo (como los hay y muchos) no debe ser razón para que lo compres, juegues, o consideres en absoluto que es "bueno". Por la misma razón, porque uno juegue a este videojuego, o sea el que lo haya creado, no quiere decir que seas sexista.
Esto parece el síndrome de "lateledicesiemprelaverdad". Una empresa hace un estudio de mercado y "averigua" (los estudios de mercado como toda esa mierda es mentira) que la gente compra más videojuegos de violencia y tias con "curvas". La empresa potencia a mil este aspecto en sus siguientes lanzamientos. Como la empresa es la "ostia" la gente se compra sus juegos porque "seguroquesonlosmejores". La pescadilla se vuelve a morder la cola y volvemos a empezar.

 mmm, weno, creo que este tema se ha tratado unas cuantas veces en otros hilos.
Otro hilo...

Con el MIDP 1.0 no puedes dibujar trozos de una imagen, a no ser que utilices SetClip para definir la parte de esta que quieres dibujar. Pero esta ultima opción es un poco lenta. Aun así se utiliza si no tienes que cambiar muchas veces el Clip.
Para un fondo con mapeado de tiles creo que será bastante lentilla. Aun así siempre podrias probar a ordenar los tiles por numero, quiero decir, minimizar el coste de SetClip dibujando seguidos todos los tiles con el mismo numero.
Quedaria algo así:

Código [Seleccionar] Expand

1 + Cambiar de numero de tile.
2 + Usar setClip para este tile.
3 + Dibujar todos los tiles con este numero.
4 * SI quedan más tiles volver a 1 SINO FIN

Otra opción bastante comentada y que resulta ser la más rápida es particionar tu tileset en imagenes independientes para cada tile individual. Para solventar el problema de memoria (debido al espacio que ocupan las cabeceras de los PNGs) en el .jar deberias realizar esta partición en tiempo de ejecución, creando imagenes individuales a partir de tu tileset, aquí si deberias utilizar setClip para particionar la imagen general.

De todas formas aquí hay más problemas, si utilizas el ultimo método no podrás tener transparencia en tus imagenes, ya que la perderás al particionar la imagen general. Las alternativas son:

1 - utilizar las apis especificas de algunos modelos, que te permitirán crear imagenes con fondo en transparente en vez de fondo blanco.
2 - (esta es la mejor, xo la más difícil y costosa) Crear un formato propio para almacenar la información de las imagenes. Más tarde cuando leas el recurso que contiene la información deberás cargarlo en memoria con "Image createImage(byte[] imageData, int imageOffset, int imageLength)".

Sin duda alguna, para mi, la mejor es la ultima formula. Con esta puedes llegar a tener un control total de como tienes la información almacenada, puedes crear espejos de imagenes a partir de los datos de un solo archivo, puedes cambiar la paleta de los graficos antes de cargarla en memoria, etc, etc, etc. El incoveniente es que necesita un "poquito" más de trabajo, conocimientos y paciencia ;)

Bueno, salu2, espero que esto te ayude.  

 

En lo del libro no estoy de acuerdo. Quien puede preferir un pdf al papel? :huh:

Creo que nadie... pero a la hora de querer consultar algo rapidito en un libro de verdad, se echa en falta el f3 :)

La verdad es que me resulta infumable los manuales que consulto de C/C++ en formato electrónico... cada uno que me resulta interesante lo imprimo y encanuto xD.

Papel o pdf  :huh:
....

..........
jejejejejeje
:D  

 

desde luego mostrarles un juego... de hecho es el proyecto final del master ;-)

pero si alguien se curra un juego, con master o sin el, es la mejor tarjeta de presentacion

O uno, o tres, o cuatro ... Posiblemente diferentes (no todos plataformas, rollo tetris o fps, se entiende, ..) y tambien para plataformas diferentes, pero que no sean muy dificiles de probar. Por ejemplo Win32, J2ME, PSP, GBA, ... los emuladores, es lo que tienen ...

Salu2