[DEBATE] Sistemas de escenarios para juegos.

[Geca]

No veo que quieres debatir, pero bueno.

Solo un reparo, el sistema de sprites no dejan de ser tiles al final, aunque sean tiras de una punta a otra de la pantalla tanto en el eje xx con en el yy.

A mi me gusta que se utilicen todas las tecnicas, ten en cuenta que el sistema de tiles o sprites solo ha nacido debido a la limitacion de estas maquinas, si no hubieran limitaciones igual ni al día de hoy se habia recurrido a eses ssitemas.

Lo de crear un mapa a lo bruto gigante es muy bueno si tienes recursos para ello, pero si te das cuenta a veces con el fin de rellenar todo el mapa le estas poniendo tiles manualmente, o sea, repitiendo sin fin las mismas partes graficas para crear el suelo por ejemplo xDDDD

Usar un mapa completo puede ser muy jugoso si te lo curras todo al detalle y haces que centimetro a centimetro este tenga siempre graficos y detalles distintos
Eso es lo único que puede hacer que usar un mapa completo sea mas aliciante que crear tiles, ya que todo el mapa seria distinto en su contenido cosa que no tendria sentido hacer por tiles.

[shao]

antiguamente no quedaba mas remedio que hacer las cosas eficientes, para un alto rendimiento en ordenadores que eran una ponzoña,
y comiendote la cabeza como liberar memoria de aqui hacer que esto sea mas rapido aka.
actualmente creo que la gente no tendria que seguir siendo tan fanatica para hacer un juego de newbies pero claro depende del juego y si te pide usar tiles

mi opcion ideal es usar escenarios dibujados al completo (fondos,primeros planos y asi...)
y usar tiles para colocar enemigos o items y algun tile para la pantalla de alguna cosa en concreto

yo estoy de acuerdo con la opinion de kozka, a parte siempre veo que la gente se preocupa demasiado por la memoria ram, pero cojones todo el que sea medio jugon con un pc hoy en dia tiene 2-4 gigas (de esas alrededor de 800 se quedan para win 7 y si no tienes nada mas abierto (que deberia ser asi) y solo tienes el juego pues fijate si tienes memoria disponible) de ram y me parece que va super sobrado para hacer correr los juegos que vemos por aqui y mas aun si esta bien optimizado (carga solo los mapas, sprites, sonidos etc.. necesarios cuando es necesario), sobre todo los que se hacen por aqui en 2d, asi que a lo de la ram le suelo dar poca importancia (por que tampoco mi juego va a tener 300 megas en un momento determinado ocupando ram, de momento..).
por otra parte como dice cictec yo tampoco he terminado de entender el sistema que usa neogeo.

[PAMERCO]

otra forma es tener, en lugar de tiles pantallas dibujasdas de la resolucion final, por ejemplo 640x480 tantas como sea tu decorado e ir cargando y descargando.... a la velocidad que carga Gemix no se nota, o si acaso un "minimo" tiron cuando carga/descarga (depende de la resolucion, supongo) pero no se nota apenas, en el juego de naves que estaba haciendo, utilizaba algo asi, por que en esa version de GEMIX, no estaba implementada las trasparencias en los scroll de 32 bits, y utilizaba "tiles" de 800x600 para crear un mapa enorme, tenia un fondo muy largo y como primer plano pantallas que cargaba y descargaba....y iba de lujo, luego ya cambiamos el sistema e hicimos un solo mapa, que se repetia ciclicamente, por que no conseguiamos quitar una linea que me aparecia entre alguna de las pantallas¿?y emprincipio estaban bien situadas y lo hice igual pero con un solo grafico a repetir ( así solo se veria la separacion una vez ) y desaparecio el problema, por lo que supusimos que era un problema o de la implementacion o que al cargar y descargar se descolocaba, nunca supimos que pasaba.
el scroll era solo lateral, y guardabamos las pantallas en una estructura, lo que haciamos era cargar la pantalla, que veias y la pantalla que no veias inmediatamente al lado de la otra, cuando se iniciaba el scroll empezabas a ver la otra pantalla, cuando la pantalla primera ya no se veia, la borrabamos, cargabamos la siguiente y la situabamos al lado de la otra..... y asi, el scroll era automatico, y no habia mapa de durezas, pero iba de lujo, y se encargaba de todo un par de funciones

[Geca]

En el otro hilo ya he dejado patente el error de pensar siempre que la memoria ya sobra por tener la ultima maquina del mercado.
Mi portátil con 2 gigas se me hace pequeño, incluso ejecutar un juego pequeño le afecta bastante, porque en backgorund ya tiene toda la memoria casi a tope por culpa de los gestores de descargas xD

[erkosone]

Yo a lo que me refiero es a que en este hilo haya una participación un poco mas tecnica.

Señores, cuando sea posible la programación via Gemix en Android, Ipad´s y similares.. tener un tope de 64 o 128 megas de ram puede ser un problema para portar algun juego.

Por eso lo que yo queria es que por ejemplo, CicTec, Gino, y los demas que están detras de gemix, se mojaran un poco y nos contaran la cantidad de recursos que hacen falta para ejecutar cada sistema.

Por poner un ejemplo:

Que usa mas CPU?? 1 proceso grande o 100 procesos equivalentes en tamaño al grande?

Cual de los dos utiliza mas memoria ram?

En el supuesto caso de un gran mapa para el decorado, y otro gran mapa para las durezas:
Utiliza mas CPU un mapa mas grande? mas memoria está claro que si.
Se tarda mas tiempo de CPU en calcular una colision con mapas grandes que con pequeños?


El hilo es para ver realmente que tiene mas performance a la hora de utilizarlo en montar escenarios.

[necro_vampire]

Tambien hay que tener en cuenta que un pc es hard multiproposito, en cambio el hard dedicado es mas rapido con los mismo recursos...

[erkosone]

Claor jeje, para eso están las librerias de hard.

OpenGL y DirectX.



El tema es saber que sistema rinde mejor en Gemix con resoluciones grandes o con resouciones pequeñas, con tiles, con Sprites.
Eso que comentas de cambiar el SCREEN seria un modo de usar SPRITES, siempre y cuando sea transparente al gamer.

[SimulatorOne]

yo mis primeros juegos los creaba con un map super gigante
-consume memoria ram
-Es mas rapudido de processar.
-Un mapa entero x nivel.
-consume mas especio en discoduro.

el primer juego que use el sistema de titles(por processos congelados)
fue el PUSH

un buen truco para exprimir el maximo rendimiento a los processos que SOLO pintan, y no hace nada.
es congelarlos.

Process GRaph_temp(file,graph,x,y,z,angle,flags,size,ctype);
begin
signal(id,s_freeze);
frame;
end

Eso cogela el processo, y asi el core de Gemix, ya no depende de trabajar.

no es lo mismo que esto:

Begin
loop
frame;
end
end

Eso si que hace dependiente del kore de gemix, que realize ese loop infinito, volviendo a pintar.


oie,


has probado con DRAW_GRAPHIC
si tubiera ctype=c_scroll se pudiera pintar graficos sin tener que usar processos.
Ya lo sugeri que los DRAWs se puediera pintar en SCrolls
pero dice cictec que no tiene sentido o que no es posible.

Para poder pinar un mapa titleada, que mas rapido que DRAW_GRAPHIC y DRAW_BLOCK.
Antes que un processo este presente en memoria,aun que este cogelado.

siempre es mas complicado programar un sistema de tiles, que usar un mapa gigante, con su mapa de durezas.

Yo lo hice para estos 2 juegos: PUSH y Maria Plataform.
y son juegos que tienen como 5 años de antiguedad cuando los programe, en otro leguage divlike en su tiempo.

Los juegos que estan montados por titles son muy complicados,realmente, para comprobar colisiones y etc.
pero puedes combinar 2 cosas.
Mapa de titles + mapa de durezas(grafico gigante)

El PUSH no usa ningun mapa de durezas, ni nada de eso.
es 100% processos.
y usando un scroll infinito.

El Maria Platafor es una combinacion entre pintar por processos + mapa de durezas.

[GINO]

Erkos todo eso que dices depende de muchos factores. Por lo general tener más procesos tira más de CPU como es lógico. Ahora bien también depende mucho de la situación. Más memoria depende también, si los tiles son repetidos pues tienes menos gráficos y menos memoria, si no tienes más memoria, etc. etc.
Para lo de los mapas grandes pues lógicamente cuanto mayor es el mapa más cuesta pintarlo, porque pintas una región del mismo a la que cuesta más acceder en memoria cuanto mayor sea esa área de memoria (el gráfico).
Collision también depende como sea la colisión... pero por lo general también cuesta más con mapas grandes.
Pero todo eso que comentas erkos son cuestiones de pura lógica que además puedes comprobar tu mismo con un simple test.

Además te digo de nuevo que en gemix el sistema de tiles y el de sprites se implementarían igual, así que a priori dan el mismo rendimiento. Ahi ha usas uno u otro dependiendo más de lo que quieres hacer que del rendimiento.
Esa distinción entre modo tile o modo sprites tiene sentido solo hablando de los hardwares de las consolas que tenían modos específicos para tileados. En gemix usas siempre sprites, así que estarías usando el modo sprites. Una cosa es que esos se repitan o sea una imagen grande troceada.

[shao]

En el otro hilo ya he dejado patente el error de pensar siempre que la memoria ya sobra por tener la ultima maquina del mercado.
Mi portátil con 2 gigas se me hace pequeño, incluso ejecutar un juego pequeño le afecta bastante, porque en backgorund ya tiene toda la memoria casi a tope por culpa de los gestores de descargas xD

bueno, entonces quiza deberias comprar un pc mejor para jugar a dicho juego, jajaja.
es broma!