Tutorial programacion Megadrive - SGDK

Disculpa bertobp, de hecho estaba leyendo esa web, aunque sigo sin saber como poner caracteres raros, ahi te explican que la medida son tiles 8x8 pixeles.

Otra cosa que me trae loco es el Code::Blocks las palabras que no forman parte del codigo por ejemplo un comentario que escribo

//Esto es un comentario

Me viene subrayado en rojo y me mareo que no veas, alguien sabe decirme como quitar eso? llevo un rato mirandolo pero no logro dar con la opcion.

nolddor escribió:Otra cosa que me trae loco es el Code::Blocks las palabras que no forman parte del codigo por ejemplo un comentario que escribo

//Esto es un comentario

Me viene subrayado en rojo y me mareo que no veas, alguien sabe decirme como quitar eso? llevo un rato mirandolo pero no logro dar con la opcion.

Tienes que desactivar un plugin, en concreto vas a Plugins->Manage Plugins->SpellChecker->Disable. Si tiene otra utilidad la perderás, pero la verdad es que a mí también me fastidia tanta rayita roja

Para lo otro que preguntabas, en la carpeta \sgdk\doc\html tienes ayuda (en inglés claro) con todas las funciones con sus argumentos. Abres el index.html y vas abriendo lo que quieras ver. Lo de la 'ñ' no lo había probado nunca, habrá que echar un vistazo.

y Hasta ahora como escribias la ñ o caracteres especiales como ! o letras acentuadas??

Es cierto, como programo todo en inglés no me había dado cuenta. Habrá que esperar a pocket_lucho o alguien que sepa cómo meter caracteres especiales.

Hace mas de 1 año que no uso el SGDK y no recuerdo con exactitud... se que los programas compilados con SGDK usan 70 u 80 tiles de la VRAM para dibujar los caracteres, solo numeros 0-9 y letras de la a-z y A-Z, nada de caracteres especiales, acentos...

Pues muy fácil, si observáis con el genskmod la vram, vereis en que posición se guardan los tiles de la fuente. Simplemente la sustituis por la que os interese y en algún carácter que no use mucho, como []#$& etc... ponéis ñáé o lo que queráis. Luego simplemente cuando vayáis a escribir pues ponéis Ca#a (si habéis puesto la ñ en vez de #) y listo, por pantalla saldrá Caña.

O la otra opción es que os escribáis vosotros una función para dibujar texto que se ajuste a vuestras necesidades, no es tan complicado, se mira el fuente de las sgdk y se modifica la que viene... Yo es que desde que terminé el oh mummy ya no toco las sgdk, estoy harto de cambios continuos que te rompen el código cada vez que actualizas la versión, etc.

Por eso lo de los tutos está complicado, es que no las sigo y ya no se lo traen ni dejan de traer

Gracias pocket_lucho, a ver si luego saco un rato y lo hago.

Una pena que no uséis ya el SGDK, supongo que tenéis vuestras buenas razones pero para mí es la única manera de programar para la Megadrive al ser en C y no en ensamblador u otros lenguajes que o no domino o me dan mucha pereza. Los tutos de aquí me dan la base para ir probando algunas cosas, luego otras las puedo sacar yo pero se me hace todo mucho más lento, y otras no sé ni por donde empezar...

Pues pocket es una pena yo habia empezado con idea de ir haciendo poco a poco algo, estudie algo de C en el módulo y bueno en realidad lo que se programar es php pero si no vas a continuar con los tutos.. me dejas un poco cojo antes de empezar si quiera

JAJAJA.

Bueno, ya hay cierta base en los tutos con los que partir... y que no siga con los de sgdk no significa que no siga con otros cuando me funcionen bien las rutinas

Pues si hay algo por ahí en C o similares mejor que SGDK que rule

Bueno lucho esperamos con ansia tus manuales ya sean de SGDK o de lo que sea tengo un proyecto en mente tipo puzzle pero claro eso será dentro de mucho mucho... de momento toca studiar.
Iré mirando esto de vez en cuando para ver si hay algo nuevo.

Manveru Ainu escribió:Pues si hay algo por ahí en C o similares mejor que SGDK que rule

Mejor es el compilador SGCC, pero las librerias te las tienes que currar tu.
El SGDK es un SDK para la MD de proposito general, para hacer cosas de forma mas rapida.
Cuando SGDK se os quede corto, tendreis que ir a la vieja escuela; opcodes, registros de las CPUs, manejar las interrupciones del bus, etc... y con eso hacer librerias para el proyecto que os interese

bertobp escribió:Mejor es el compilador SGCC, pero las librerias te las tienes que currar tu.
El SGDK es un SDK para la MD de proposito general, para hacer cosas de forma mas rapida.
Cuando SGDK se os quede corto, tendreis que ir a la vieja escuela; opcodes, registros de las CPUs, manejar las interrupciones del bus, etc... y con eso hacer librerias para el proyecto que os interese

Gracias bertobp por la info, siendo así apuraré lo que pueda el SGDK y cuando no pueda avanzar más tendré que dejarlo porque yo de programación a tan bajo nivel soy tan ignorante como poca paciencia tengo

Manveru Ainu escribió:

bertobp escribió:Mejor es el compilador SGCC, pero las librerias te las tienes que currar tu.
El SGDK es un SDK para la MD de proposito general, para hacer cosas de forma mas rapida.
Cuando SGDK se os quede corto, tendreis que ir a la vieja escuela; opcodes, registros de las CPUs, manejar las interrupciones del bus, etc... y con eso hacer librerias para el proyecto que os interese

Gracias bertobp por la info, siendo así apuraré lo que pueda el SGDK y cuando no pueda avanzar más tendré que dejarlo porque yo de programación a tan bajo nivel soy tan ignorante como poca paciencia tengo

Cuando el SGDK se te quede corto es que ya sabrás mucho de programacion y si controlas del hardware de Megadrive, no te será dificil... todo a su momento jejeje

jejeje si, supongo que será así. A ver cómo me va, pero desgana un poco ver que empiezas con ésto cuando la gente que controla hace tiempo que lo tiene abandonado por cosas mejores

A ver si alguien me hecha un cable porque llevo toda la tarde dandole vueltas y no hay manera:

¿¿Esto es asi??
PRIORIDAD ALTA > PRIORIDAD BAJA
SI LA PRIORIDAD ES IGUAL PLANOA > PLANOB
SI PRIORIDAD Y PLANO SON IGUALES EL ULTIMO COMANDO PREVALECE

Siguiendo esas pautas, que a priori creo correctas, segun este codigo:


Deberia aparecer en pantalla mi tile de color ROJO(7,7) y AZUL(8,7).
Sin embargo aparecen los dos de Color ROJO.... :S

Manveru Ainu escribió:Pues si hay algo por ahí en C o similares mejor que SGDK que rule

Bueno, digamos que cojo solo lo que necesito de las sgdk, rutinas de por aquí, de allá, alguna cosa en ensamblador... siempre intentando seguir una sintaxis parecida a las sgdk, por lo que os animo a que sigais con ella. Ahora mismo está en creación por lo que es una tonteria ponerla aqui pq pasado mañana será distinta... y tiene bugs

Es que, pongamos un ejemplo, VDP_drawText de las sgdk, los tiles tienen que estar en un sitio en concreto (1192 en la vram creo), solo dibuja en el plano A, solo cadenas... mi VDP_drawText dibuja en el plano que le diga, cogiendo los tiles en la dir que yo le digo, etc...

Pero vamos, que la sacaré por supuesto! Es lógico que cuando vas aprendiendo se te vayan quedando cortas unas libs y las vayas ampliando tu según la necesidad, empecé en basic... luego fui a sgdk... y ahora pues me las escribo yo xD

nolddor escribió:Deberia aparecer en pantalla mi tile de color ROJO(7,7) y AZUL(8,7).
Sin embargo aparecen los dos de Color ROJO.... :S

Supongo que será que al ejecutar el VDP_fillTileMapRect cambias la prioridad del tile 8,7 en el plano B a baja, por lo que queda debajo del rojo. Si quitas esta llamada o si cambias las coordenadas para que no coincidan con las de las caras roja y azul verás que funciona bien.


Gracias por los consejos pocket_lucho, intentaré ir poco a poco aunque me va a costar mucho avanzar sin tus geniales tutos. Tampoco soy de que me lo den todo masticado, pero bueno ojalá saques unas buenas rutinas para los que no tenemos esos conocimientos. Mientras tanto iré aprendiendo sobre la marcha a ver a dónde llego

El tema de la prioridad de los planos... tiene mandanga xD

Si ambos tienen prioridad baja, el B va detrás del A, si ambos la tienen alta, lo mismo. Si uno la tiene alta y el otro baja, el de la alta estará delante del otro. Los sprites si la tienen alta estarán por encima de todo y si la tienen baja, estarán debajo de cualquier plano que la tenga alta. Yo esto ahora mismo lo estoy usando en lo que estoy haciendo ahora para tener el plano A detrás del B, ya que el plano window (que se comporta como una zona del A que no hace scroll) me interesa para el marcador.

Lo interesante de esto, es que las prioridades de un plano pueden ir a nivel de tile, no del fondo completo, en un mismo plano puede haber tienes con prioridad baja y alta. Un ejemplo de esto podria ser el primer nivel del shinobi arcade, cuando vamos por el suelo el sprite tiene la prioridad alta y se dibuja encima de todo. Si subimos al tejado, pasa a tenerla baja y se dibuja por debajo de la barandilla. En siguientes niveles se ve incluso mejor cuando se pasa a estar detrás de rejas

Manveru Ainu escribió:Supongo que será que al ejecutar el VDP_fillTileMapRect cambias la prioridad del tile 8,7 en el plano B a baja, por lo que queda debajo del rojo. Si quitas esta llamada o si cambias las coordenadas para que no coincidan con las de las caras roja y azul verás que funciona bien.

Ese es el problema que se ve rojo y debería de verse AZUL que de los tres tiles que coinciden en el punto 8,7 es el unico que tiene prioridad alta,

El rojo tiene prioridada baja y el gris del VDP_fillTileMapRect también...

Segun pocket_lucho es así a ver si el sabe explicarme porque no se muestra el azul que es el que tiene prioridad alta.


VDP_setTileMap(APLAN, TILE_ATTR_FULL(PAL1, 0, 0, 0, 1), 8, 7); // ROJO PRIORIDAD BAJA PLANO_A
VDP_setTileMap(BPLAN, TILE_ATTR_FULL(PAL3, 1, 0, 0, 1), 8, 7); // AZUL PRIORIDAD ALTA PlANO_B <<--

// Rellena un cuadrado de 2x1 del tile 1 con paleta gris en la posición (7,7)
VDP_fillTileMapRect(BPLAN, TILE_ATTR_FULL(PAL0, 0, 0, 0, 1), 7, 7, 2, 1); // GRIS PRIORIDAD BAJA PLANO_B


O es que SGDK (o la propia MD) no es capaz de comparar tres tiles en una misma posición?

nolddor escribió:

Manveru Ainu escribió:Supongo que será que al ejecutar el VDP_fillTileMapRect cambias la prioridad del tile 8,7 en el plano B a baja, por lo que queda debajo del rojo. Si quitas esta llamada o si cambias las coordenadas para que no coincidan con las de las caras roja y azul verás que funciona bien.

Ese es el problema que se ve rojo y debería de verse AZUL que de los tres tiles que coinciden en el punto 8,7 es el unico que tiene prioridad alta,

El rojo tiene prioridada baja y el gris del VDP_fillTileMapRect también...

Segun pocket_lucho es así a ver si el sabe explicarme porque no se muestra el azul que es el que tiene prioridad alta.


VDP_setTileMap(APLAN, TILE_ATTR_FULL(PAL1, 0, 0, 0, 1), 8, 7); // ROJO PRIORIDAD BAJA PLANO_A
VDP_setTileMap(BPLAN, TILE_ATTR_FULL(PAL3, 1, 0, 0, 1), 8, 7); // AZUL PRIORIDAD ALTA PlANO_B <<--

// Rellena un cuadrado de 2x1 del tile 1 con paleta gris en la posición (7,7)
VDP_fillTileMapRect(BPLAN, TILE_ATTR_FULL(PAL0, 0, 0, 0, 1), 7, 7, 2, 1); // GRIS PRIORIDAD BAJA PLANO_B


O es que SGDK (o la propia MD) no es capaz de comparar tres tiles en una misma posición?

Supongo que al hacer el VDP_fillTileMapRect sobreescribes el tile 8, 7 del plano B con prioridad alta con el 8,7 gris con prioridad baja, así que sólo estarías comparando el tile rojo del plano A con el tile gris del plano B.

Muchas gracias, tienes razon el VDP_fillTileMapRect lo que hace es sobreescribir el plano que tu le digas, aunque lo que esté escrito en ese mismo plano tenga prioridad mas alta.

Ahora si todo funciona como debiera.

SE ATREVE ALGUIEN?!! a seguir esto con algo más por ejemplo colisiones entre sprites o integracion de audio??? a ver si alguien se pone y le hecha un rato y nos ilustra a los menos afortunados.

Hombre, lo de las colisiones hay que hacerlo 'a mano'. Pongamos el sprite del jugador de 32x16 pixels, cuya estructura tendrá una x y una y. Pongamos otro sprite, un proyectil, de 8x16 con su x y su y.

La colision podria ser:

if( jugador.x > proyectil.x ) && (proyectil.x+8 < jugador.x + 32){
if( jugador.y > proyectil.y ) && (proyectil.y+16 < jugador.y + 16){

Aqui se ejecutaria lo necesario en caso de colision
}
}

Se podria hilar más fino reduciendo la 'caja' de colision haciendola más pequeña. Pero no hay más. Por el tema del audio, en las mismas sgdk viene un ejemplo ya de como meter audio, lo de como hacerlo ya si no entraría aquí, es como un tutorial de hacer sprites con photoshop... pero vamos, con tfm maker o vgm maker que son trackers para ello.

Duda rápida, ya tengo el entorno de desarrollo funcionando y con mi primer Hello World listo, la duda me viene en que me aparece como que el checksum de la rom generada es incorrecto (usando el Kega Fusion), ¿hay alguna manera de solucionarlo? ¿realmente importa que el checksum no sea el correcto?

Puedes parchear la ROM con uno de estos programas:

- GenSuite (http://mi.tsdx.net.ve/genSuite/gs_en.htm)
- FixChecksum (http://www.romhacking.net/utilities/342/)

Lo que no se decirte en que afecta que el checksum este mal o bien puesto.

El checksum es imprescindible para que arranque en la Megadrive... en emuladores no hay problema ya que se salta el checksum

esto es muy interesante, parece que ya no actualizan con nuevo tutos, no? es una pena

Como creais vosotros la imágenes para que las reconosca dp el SGDK porque yo con el photoshop mas meto en la carpeta res y no se ven, en cambio cojo la de ejemplo de la luna y funcionar perfectamente asi que no se como crear el bmp con 16 colores.

Usais algun programa especifico???

jmmanson escribió:esto es muy interesante, parece que ya no actualizan con nuevo tutos, no? es una pena

Con lo que hay aqui tienes mas que de sobra y si llegas a entender y usar todo o gran parte, estas mas que preparado para probar a hacer un juego o mas bien primero alguna demo/prueba. Otro aspecto muy muy pero que muy importante es meterse a estudiar C a fondo, pues sgdk no deja de ser un enlace intermedio que facilita el acceso al hardware de megadrive pero la programacion va ser como la de cualquier otro programa en c.

nolddor escribió:Como creais vosotros la imágenes para que las reconosca dp el SGDK porque yo con el photoshop mas meto en la carpeta res y no se ven, en cambio cojo la de ejemplo de la luna y funcionar perfectamente asi que no se como crear el bmp con 16 colores.

Usais algun programa especifico???

En el primer mensaje están los tutos. Lo puedes hacer con el Gimp siguiendo mi tutorial, aunque sólo sirve para Genres creo recordar, pero lo mejor es que lo hagas como indica pocket_lucho usando imagenesis y megagfx.
Un saludo.

Pues yo no consigo por ningun metodo que me lea bien la imagen, o no me sale o me sale basura por pantalla pero no la imagen.

He probado poniendola en la carpeta res con el genres y hacerlo a mano con imagenesis+megagfx y nada.... o soy mu torpe o yo q se.

¿Has seguido este párrafo del tutorial, paso a paso correctamente? Por cierto no tienes que meter las imágenes en la carpeta res sino que debes cargarlas en el código directamente, copiar-pegar el contenido del txt que genera el megagfx.

pocket_lucho escribió:Tambien existe la herramienta imagenesis que conoceréis si mirasteis el tutorial de basic de theelf, la pega es que el formato que exporta no nos sirve pero vamos a ver como solucionarlo. Abrimos la imagen (file, open image), elegimos el tipo de conversión (si queremos optimizar los tiles -> mode, 15 color 4bpp 1 plane 8x8 tiles optimized, si es un sprite tendremos que cambiar el orden x-y... lo veremos en el tutorial siguiente sobre estos últimos), el color transparente (enable transparency, select transparent color). Pulsamos Actions -> Quantize Now y tendremos la imagen convertida a la paleta de megadrive y lista para exportar. La paltea si la podemos exportar sin modificarla con Export Palette Data y eligiendo como salida C, el mapa de tiles lo mismo, ya veremos como usarlo en posteriores tutoriales. El problema son los tiles, para usaremos el pequeño conversor que he escrito, el megagfx. Exportamos los tiles como basic y nos fijamos en el número de tiles que se han generado, lo pegamos en el fichero output.txt que viene en el rar que adjunto, pulsamos run.bat, elegimos un nombre para el vector de salida y por último la cantidad de tiles a covertir que vimos al convertirla en imagenesis. Se generará un fichero llamado tiles.txt, cuyo contenido podréis copiar sin problema en vuestro código y que será completamente compatible con las funciones de manejo de tiles de las SGDK.

si si lo de meterlo en la carpeta res, es por hacerlo por ese método , haciendo eso paso por paso me sale basura en la pantalla pero no la imagen que deberia salir.

Si lo has hecho bien debería funcionar... Mira si has puesto bien las dimensiones o el número de tiles que has cargado en memoria, y que nada los sobreescriba. ¿Has sacado a paleta con el imagenesis y la has cargado en el código? Pása el código por aquí para echarle un vistazo si quieres.

Si es mas facil que todo eso, a ver el ejemplo de tiles de meter el archivo moon.bmp en la carpeta res...

Si meto la imagen bmp del tutorial osea la luna azul funciona si meto la mia no, osea que el problema es que la imagen no la estoy guardando en el formato adecuado pero es que no se como hacer para que la coja el sgdk, la he guardado con el imagenesis, con el gimp con el photoshop pero nada q no la admite....

Básicamente lo que no se es dada una imagen en png jpg gif o lo q sea pasarla a bmp de 16 colores 4bits/pixel

Pues no sé qué decirte. Tengo por ahí código de Sonic que empecé y está con el Genres con una tabla de sprites hecha con el Gimp, como en el tutorial que hice y que pocket_lucho puso en el primer mensaje del hilo. Mira si se te ha pasado algún detallito, como marcar o desmarcar alguna casilla o algo así que suele pasar.

Recuerdo que yo también me comía la cabeza porque no había manera de meter imágenes sueltas directamente. Al final lo que hacía era pasar lo que sea a código y cargarlo directamente.

Ahora que caigo, si usas Genres no debes meter las imágenes en la carpeta res porque las carga el SGDK por defecto y luego tú con el Genres. Crea una carpeta cualquiera, mete ahí las imágenes y luego modificas el archivo resource.rc en consecuencia.

No lo stoy haciendo con genres, lo estaba haciendo con la carpeta res pero ni asi ni de ninguna forma jajjaa empezar algo y que lo mas basico no te salga... mal empezamos jajajaa..

En fin nose... a ver que veo por ahi.

Ah como comentaste antes que habias probado poniendo la imagen en la carpeta res con el genres.
Si bueno lo que te ponía en el otro mensaje que acabo de editar, que yo recuerdo que me comía el coco porque no me pillaba las imágenes, que si ésto o lo otro. Luego seguí con el Genres que no da problemas con el Gimp y sin problema. Al final lo mejor es meterlo todo como código con imagenesis + megagfx, y si acaso es algo sencillo estilo tabla de sprites con cada uno de ellos del mismo tamaño pues Genres y va que chuta, que vamos también es fácil con el código de los sprites pero bueno para ir empezando me fue de lujo.

con genres es que me dice que no esta definida la variable, aunque si estadefinida osea que creo que tampoco coge bien el bmp y por eso no es capaz de compilar.

metiendola en res o no se visualiza o se visualiza con basura

y mediante codigo directo imagenesis + megagfx se me ve basura...

osea que soy de lo peor...

nolddor escribió:con genres es que me dice que no esta definida la variable, aunque si estadefinida osea que creo que tampoco coge bien el bmp y por eso no es capaz de compilar.

metiendola en res o no se visualiza o se visualiza con basura

y mediante codigo directo imagenesis + megagfx se me ve basura...

osea que soy de lo peor...

Si yo te contara las cosas y despistes por los que pasé...

Con el Genres es muy sencillo, comprueba que el resource.rc esté bien y tenga sus parámetros bien. Recuerda que los tiles tienen unas dimensiones máximas.

Con el código tienes que saber bien cómo funciona la vram y cómo se cargan los tiles en función si en el imagenesis lo pusiste como Sprites (arriba->abajo y luego izquierda->derecha) o no (izquierda->derecha y luego arriba->abajo). ¿Se te ve basura, se te ven los primeros tiles bien y el resto basura o se te ven los tiles "desordenados"?

Manveru gracias por tu ayuda, el rc no tenia el intro necesario de más para que funcione,.... con los otros dos metodos no funciona pero con ese sí asi que utilizaré ese...

Ahora viene algo mas complicado....

Suponiendo que tenga un conjunto de tiles que formen la palabra "prueba" como hago para que se vaya desplazando hacia la izquierda automaticamente (y cuando llegue al tope hacia la derecha), o si tiene movimiento lo tendría que tratar como un sprite???

Para desplazarlos, en la función VDP_setTileMap en lugar de poner un valor fijo para la coordenada x pones una variable que se actualiza en cada ciclo del while en función de cómo quieres que se comporte.

A ver si alguien de aqui tiene un hueco y pone algo de info sobre como en una imagen que tenga patrones repetidos no cargarlos en memoria dos veces,...

por ejemplo una imagen simetrica la parte derecha y izquiera en realidad son iguales...

Porque me quedo muy rapido sin espacio en la VRAM por no utilizarla de forma optimizada.

Si lo que quieres es mover un objeto o varios a la misma velocidad, te basta con incrementar o reducir la variable x. Cuando llegue a un valor (que no recuerdo ahora, tras salir de la pantalla) volverá a aparecer por el otro lado de la pantalla. Para hacer distintos planos de scroll tipo parallax scrolling, no recuerdo exactamente bien como era pero te lo dejo así un poco de memoria mientras veo un ejemplo que hice hace tiempo.

Por lo que tengo por aquí tenías que configurar el tipo de scroll con la función VDP_setReg(0x0b, 0x0X). El primer argumento indica que vamos a configurar el modo de scroll, el segundo indica cómo será el scroll horizontal: 0x00 por cada tile, 0x02 por cada línea (8 tiles) o 0x03 para mover todo el plano entero. También se puede usar para el scroll vertical pero no llegué a aprender cómo, para ésto usaba VDP_setVerticalScroll(plano, desplazamiento), donde "plano" es el plano que se moverá y "desplazamiento" es el número de tiles que se desplazará.

Volviendo al scroll horizontal, tienes que crear un array con las posiciones verticales de cada plano de scroll que quieras mover y luego un segundo array con las posiciones horizontales de cada plano de scroll. Estas posiciones irán cambiando como queramos en cada iteración del bucle cada cierto tiempo, por ejemplo condicionándolas a que se actualicen si una variable temporal cumple si mod 1 = 0, mod 2 = 0, mod 3 = 0... consiguiendo así que se muevan a distintas velocidades. Entonces ejecutamos la función void VDP_setHorizontalScroll(u16 plan, u16 line, u16 value) para cada par posicion vertical/horizontal.

Se puede hacer más automático, para ello cogí un ejemplo de SpritesMind y lo retoqué para sólo tener que llamar una vez a una función pasando ambos arrays, por si tienes curiosidad te la dejo tal cual, una función que estuve probando para mover 40 planos distintos. Ni siquiera sé si está bien hecho (intento ayudarte pero no soy un experto ni mucho menos...) pero bueno funcionar funcionaba por si quieres probar:

Gracias aunque habia editado el mensaje porque primero quiero depurar la VRAM, se que con imagenesis si le das la opción optimize te quita los tiles repetidos el problema es que si una imagen de 3 tiles tiene uno repetido me crea un tile data de dos tiles, pero claro no sé el que falta donde va, ni que posición tiene q tomar como referencia para indicar que es duplicado,....

Sí, a mí me pasaba igual, el que los tiles tengan que estar contiguos en la vram y el quitar los duplicados no son dos cosas compatibles. Supongo que la única solución es dibujar los tiles uno a uno por separado...

Le voy a preguntar a lucho a ver si el tiene alguna solución mas factible que ir escribiendo uno a uno los tiles de forma ordenada xD sin tener que añadir a la VRAM los duplicados.

Porque claro el imagenesis me da un datatile optimizado pero no me dice ni cual es el que esta repetido ni con cual se repite osea que es un trabajazo para un tile grande hacerlo uno a uno..... más que nada por buscar a pelo tu como montarlo....

Con el SGDK no creo que se pueda. Yo lo pregunté no sé si aquí o en SpritesMind y me dijeron que no. Todas las funciones que cargan tiles tienen como argumento la posición inicial en la VRAM y el número de tiles a cargar a partir de ella, lo que fuerza a que sean contiguas en memoria.

nolddor escribió:Le voy a preguntar a lucho a ver si el tiene alguna solución mas factible que ir escribiendo uno a uno los tiles de forma ordenada xD sin tener que añadir a la VRAM los duplicados.

Porque claro el imagenesis me da un datatile optimizado pero no me dice ni cual es el que esta repetido ni con cual se repite osea que es un trabajazo para un tile grande hacerlo uno a uno..... más que nada por buscar a pelo tu como montarlo....

Ese problema no existe con los editores de tiles y mapas, tipo Tile Studio, tUME,... yo he programado en otras plataformas como GB y GBA y con los editores tu creas a mano tu tileset y luego vas creando el mapa usando tus tiles. Es una limitacion que siempre vi en este tutorial de Megadrve, el Imagenesis esta bien para pantalas de presentacion, demos y tal... pero no para mapas

A ver si lucho nos explica como lo hace él,.... xk para crear un mapa como tu bien dices bertop no es fáctible vaya tienes que pegarte una paliza que da miedo.