Pinball Action Remake

[FreeYourMind]

hheheheheh, te estas liando  ;D

Eso es lo que ves en la imagen que he sacado, si eso funciona pero no es lo que quiero, lo que quiero y que tiene que funcionar tambien en la Wiz (porque en PC lo hace) es esto:

Code Select Expand

import "mod_video";
import "mod_screen";
import "mod_map";
import "mod_debug";

begin

   scale_resolution=01960240;
   set_mode(224,256);

   put_screen(0,load_png("fondo.png"));

   loop
       frame;
   end

end


[SplinterGU]

o te entendi mal u obviamente no te va a funcionar, wiz no tiene modo 196x240, por eso te queda espacio negro.

creo que tenes un error de concepto:

- wiz no soporta ni 196x240 ni 224x256.
- set_mode establece el modo real, o sea, los pixels que podes dibujar.
- scale_resolution, establece el tamaño del modo de video que se vera.

resumiendo:

scale_resolution tiene que ser 03200240 para que te quede todo completo, te guste o no, ahora puede que no te sirva eso, pero eso es otro tema.
set_mode tiene que ser el mismo que usas en PC.

si te entendi mal, por favor explicame de nuevo.

[FreeYourMind]

Ahora si has entendido, pero entonces te hago 2 preguntas, la más sencilla primero :)

1- Que modos soporta la Wiz ?

2 - Porque utilizando el emulador mame, estos modos si son soportados ?
Si juegas al Pinball action verás que soporta el modo original, 224x256, como la wiz tiene de altura 240, verás que el juego es recortado ligeramente arriba y abajo porque sobran 16 pixels que salen fuera de pantalla  ;)

[DCelso]

Solo uno 320x240.

A lo mejor lo suyo sería que además de scale_resolution hubiera otra global mantain_aspect_ratio que ajustara la pantalla a la coordenada más cercana a scale_resolution ( en este caso 320x240) pero sin perder la relación de aspecto y centrando el resultado final, justo como lo hace MAME.

[FreeYourMind]

Mame lo hace así ?!

Pero en Mame la región del juego tiene exactamente la resolución original (salvando el corte vertical que sobra para fuera de la pantalla) ?

Ajustar la pantalla a las coordenadas mas cercanas !? Centrar la region del juego en el medio de la pantalla ?
Es que la resolución 320x200 es aún peor que 320x240 porque estrecha aún mas el juego.
Lo que quiero es evitar (mas bien la opcion tambien) que la región del juego se alargue tanto en la horizontal.

Eso que dices lo haria Bennu internamente en una función ?

En general no he entendido muy bien lo que pretendes, eso de hacercarse a 320x200 no es lo que quiero, es justo lo contrario, un resultado igual al de Mame o aún mejor, o sea, la resolución 196x240, ya que con esta resolución mantengo las proporciones del original y el juego se ve en toda la pantalla, sin cortes en la vertical.

[DCelso]

A ver, por lo que tengo entendido el mame hace lo siguiente.
Imagínate un juego original que es 1240x600.
pues si tienes el mame en resolución automáticia busca las resoluciones posibles de tu gráfica y encuentra 1240x768.
pues pone tu pantalla en esa resolución, mete 84 filas negras, mete la pantalla 1240x600 y finalmente metre otras 84 filas negras,
en total tienes una pantalla 1240x768 con dos franjas negras en la que dentro verás centrada tu pantalla original 1240x600

Pues ahora imagínate un juego original que es 1240x800.
Claro, no cabe en 1240x768, busca a ver si hay otra resolución mejor, y no la encuentra. Pues entonces rescala la pantalla original 1240x800 manteniendo su aspecto así que obtiene esta 1190x768, pues esta vez mete franjas a la izquierda y a la derecha y ajusta en 1240x768 la pantalla reescalada 1190x768.

[FreeYourMind]

O sea por sencillas palabras, en la Wiz, para este juego, lo pone a 320x240, pero dentro de la región de pantalla ya ha hecho un recalado del juego a la resolución original y lo ha adaptado a la area que tenemos disponible, que són los 320x240 pero pintando franjas negras en las areas no usadas.

La diferencia sencillamente es esta: En mame tenemos la resolucion soportada de 320x240 con el juego rescalado dentro, mientras que bennu lo que hace es rescalar el juego directamente a una resolución soportada por la maquina.

Púes bien, Splinter creo que ya te estoy pidiendo demasiado hehehe, hay dos cosas que estoy como loco para que implementes, una es este ajuste igual al que hace Mame (que por suerte utiliza código libre para hacerlo y esta disponible), y lo otro el el poder rotar la imagen en 90º hacia la izquierda o derecha.

Que gustazo imaginar mi juego con 4 modos de video seleccionables al inicio:

1 - Fullscreen (toda la pantalla como lo tengo ahora)
2 - Original screen (igual a mame)
3 - Rotación hacia la derecha
4 - Rotación hacia la izquierda


ESto esta en tus planes Splinter ?  ::) :P

[DCelso]

hombre, también te lo podrías implementar tu en bennu usando size y flag de todos los procesos.
Por ejemplo
global
   resolucion = 100;
process proceso1
begin
   size = resolucion;
   //bucle tipico de procesos
end

process proceso2
begin
   size = resolucion;
   //bucle tipico de procesos
end

Asi, cambiando resolucion a 50, verás todos tus graficos la mitad de pequeños.

[FreeYourMind]

Ya te explique ayer eso. Que cambiarlo por código se puede, pero implica muchas cosas, no sólo lo que pones, eso sólo afecta los gráficos, pero y la lógica ?

Hay muchas condiciones que se basan en las coordenadas x, y de la pantalla, y eso tambien habria que cambiarlo porque la resolución seguiria siendo la misma. Fijate lo engorroso que seria todo el código, ten en cuenta que la version es multiplataforma, incluyo aparte de esta adaptación a Wiz, la version PC, version en la cual no necesito esto, y todo va en el mismo programa.

Ya tengo el código cada vez mas engorroso con tanta condicion, hacer esto por código ya seria el caos total.
Prefeiro no sacarlo en la Wiz que hacer esto.

Si tuviera que hacer estas cosas en mi anterior port de Skull, tampoco lo habria hecho, y fijate que tengo un juego multiplataforma con varias opciones de resolucion dependiendo de la maquina en que se ejecuta.


Mr Matsusaka por ejemplo, utilizaba el mismo prg para todas las versiones, pero para cada una comentaba o descomentaba partes del código al compilarlo y generaba .dcb's distintos. Eso muchos veces hacia que compilara con fallos para un dado SO porque se olvidaba de algunas partes.
En cambio yo prefiero compilar un unico dcb para todos los so pero con condiciones que hagan el switch.
Admiro el curro y paciencia de Matsusaka al compilar, pero mi intento es dejar el código lo más limpio y organizado posible en un dcb multiplataforma.

[DCelso]

Sí, a mi personalmente me gusta más tu forma.

Pero bueno, si hubieras pensado en eso desde el principio, podrías haberlo hecho autoreescalable (x = pos_x /resolucion) o cosas asi, de todas formas es muy guarro el usar coordenadas para saber donde están las cosas, para eso se encarga collision , si no quieres usarla por problemas de rendimiento, te haces un customcollision con detección de cuadrados na mas o algo así.

[FreeYourMind]

El usar las coordenadas puede parecer guarro pero teniendo en cuenta el rendimiento es lo mejor, lo uso precisamente para evitar colisiones inecesarias  ;)

[DCelso]

Bueno nose, lo suyo primeramente es no complicarse y hacer el código lo más facil, intuitivo e inteligible posible con todas las funcionalidades que ofrece la api de bennu.
Luego , una vez resuelto el problema o juego, si ves que el rendimiento es malo, pues ir optimizando poco a poco haciendo funciones o lógicas sustitutivas a las que bajan el rendimiento.
Porque si empiezas desde el principio a hacer funcionalidades complejas y no estructuradas terminarás repitiendo código y haciendo ininteligible el código como para poder modularizarlo o modificarlo en un futuro :D.

Así que por ejemplo para el caso de detecciones pues yo lo primero que haría sería usar collision y al final del juego si ves que el rendimiento es verdaderamente malo pues sustituirlo por otra función más ràpida que haga mas o menos lo mismo.
Muchas veces no usas algo porque crees que es poco eficiente en rendimiento y cuando verdaderamente es autosuficiente para satisfacer tus necesidades de rendimiento.

[FreeYourMind]

Hay muchas formas de hacer las cosas, lo que no vamos es a discutirlas  :D
Lo unico que tengo claro, es que el rendimiento es algo a tener en cuenta desde la primera linea de código que picas, aunque muchas veces no lo notes porque las maquinas cada vez son mas potentes, el rendimiento de un ordenador es la suma de todas sus aplicaciones.

Ten en cuenta que si ejecutas sólo tu juego en tu pc, igual el juego te va de maravilla y no notas un malo rendimiento. Pero imagina que usas mas programas de fondo, como gestores de descargas, etc. Pues ahí si que puedes notar mas la diferencia y llevarte la sorpresa de que tu juego ya va a tiros. Pues optimizando las cosas 'auqnue no lo necesites' es de las cosas mas importantes en la informatica, es por eso que muchas aplicaciones triunfan y otras no.
Muchas aplicaciones han tenido que volver a ser programadas desde cero principalmente por este motivo, nunca has oido decir que la proxima version de determinada aplicacion ha sido rehecha desde 0 ? Preguntale a Bomber cuantas veces ha reecho cosas que ya tenia por varios motivos, y este sin duda ha sido uno de ellos.

Arreglar algo ya con una gran base se vuelve una tarea compliada, y aunque muchas cosas se puedan optimizar despúes, otras ya ni se intentan optimizar porque ocupan una parte considerable de la aplicación, y para eso es mejor volver a empezar  ;D

[BoMbErLiNk]

224x256 es el tamaño nativo del juego ? Puedes hacer la rotación por software, haciendo la simulación de la pantalla en un mapa de esas dimensiones, el tablero es permanente por tanto no necesitas pintarlo en el mapa, puedes rotarlo manualmente como gráfico único,  teniendo el mapa generado puedes anular todo el pintado de graph, los pones a 0 después de pintarse en el mapa y antes de llegar al frame.

Con el mapa generado podrías girarlo con angle, con flags, meterle diferentes size_x, size_y..

No debería ser excesivamente lento, así hice el ejemplo de la lupa a mayor resolución, con fondos, etc..

[FreeYourMind]

map_block_copy a cada frame dices ?
Eso lo pensé pero de momento lo descarto, porque si Splinter lo hace internamente en C seria mucho mejor.
Si el ya imagina que con C podria ser lento, ya me imagino hacerlo con código Bennu...