Hola a todos, saludo a los sonámbulos, noctámbulos, los que acabais de llegar de juerga, fans de las chicas desnudas, adictos al teletienda y forofos del "llama y gana" y del Randú (y videntes en general):
Dadas las horas que son, es normal que esté pensando tonterías, pero bueno, yo lo dejo caer y luego...
Me preguntaba si sería posible y sencillo renderizar un scroll (de start_scroll) en un mapa que creemos nosotros con new_map en lugar de uno interno (si no recuerdo mal, los scrolls usaban internamente un mapa sobre el que se dibujaba ¿o era una sdl_surface?).
La pregunta clave ¿qué usos se le da a esto? darnos las ventajas de hacer todas las transformaciones posibles de los mapas: size (zoom), size_y (achatamiento a pantalla partida, como en sonic 2), angle (rotaciones, como especiales en Sonic 1), alpha, blendops... Y una que puede ser altamente interesante: textura para los modo7. Actualmente, el modo7 depende de un único mapa (de 8 bits) NO ciclico, y el tamaño de los niveles depende directamente del tamaño del mapa (y la memoria ocupada se dispara). Además, el modo7 podría beneficiarse próximamente de un futuro nuevo motor de scroll tileado made by un tio que debería ir al psiquiátrico, y creo que (si funciona) las limitaciones de tamaño serían historia (sólo el doble de lo necesario para ver).
Además, no creo que haya que hacer demasiados cambios a este lado del código: usando el propio start_scroll, en el parámetro que indica la región podríamos indicar la ID del mapa en memoria, y no habría conflictos, dado que sólo se pueden usar 10 regiones (valores [0,9]) y los mapas parten del número 1000 (valores [1000,...]).
¿Viabilidad?
:P
si que estas loco... :D
a la pregunta... el scroll no se dibuja internamente en ningun mapa ni ningun surface... se dibuja derecho a la pantalla...
La idea es algo loca :o, pero va bien encaminada, creo que al scroll le faltan esos detalles que comentas como size o angle... Creo que ya lo he comentado alguna vez.
Ahora recuerdo que en mi juego de aviones (Sardines can in roids) quise poner un scroll normal con nubes y otro scroll en modo 7 con más nubes, pero no me funcionó... ¿Debería funcionar algo así o es físicamente imposible? Igual fue fallo mío :-\ la cuestión es que al final lo dejé pasar.
No se, yo una vez usé un proceso que haga de scroll, lo único que hacía era cambiarle el punto de control 0 de posición y de ahí le giraba o lo escalaba.
Windgate: el modo7 es altamente puñetero. Sólo funciona en 8 bits y con algunos condicionantes. Hacer el Drajon Lol me supuso algunos disgustos. Por ejemplo, la textura externa que se repite hasta el infinito, supuestamente debe tener medidas potencias de 2 (2, 4, 8, 16, 32...) pero aun usando un mapa de 64x64 sólo repetía los 32x32 primeros pixels... y en el port de GP2X no se puede cambiar el modo de 16 bits a 8 sin que se cuelgue (no se si por el M7 o por otra cosa).
Incluso recuerdo que allá, por la 083b, le comentaba a Slaité que la cámara no rotaba alrededor del proceso target, un extraño temblor por colocar los sprites en valores enteros de pixel cuando en M7 los pixels de cerca son más anchos, que a cierta altura se colgaba... cosas así. No me extraña que quisiese quitarlo.
Laghengar: se te ha olvidado un detalle importante, la repetición... por no hablar de las ventajas de los procesos con el ctype=c_scroll.
Splinter: no se, debió confundirme en su día leer esta línea:
gr_blit (0, &r, x+cx, y+cy, data->flags1, scrolls[n].graph)
Al ver el último parámetro me dió por pensar que se tenía un mapa pintado, y que se le pasaba al bliter (¿se llama así?) para que lo dibujase en la pantalla. Le he dado un vistazo muy rápido ahora y he visto que el bliter lo dibuja en la región... pero no lo he entendido muy bien (este C es más complejo de lo que yo se, y necesitaría un par de horas para entenderlo).
Si encima Bennu ha cambiado por ahi...
Si no se puede, pues nada, ya buscaré otra forma de hacer los modo7 inmensos. Ya veremos si puedo hacer el "FZero" para gp2x/wiz con sólo 8MB