funciones sp_GetCharAddr

[luckpro]

Buenas, hacia tiempo que no entraba por aquí, pero también hacia tiempo que no hago nada para zx. Estoy intentando hacer un jueguecillo y me ha surgido una duda que buscando en google me ha dado 0 resultados jejejeje. A ver si vosotros me podéis dar luz sobre este tema.

Quiero algo muy simple, saber que carácter esta en una dirección de la pantalla concreta, por ejemplo, si yo pongo esto para pintar una frase en la pantalla

print_str (1, 23, COLOR_BLANCO_FOREGROUND, "RIGHT");

quiero una función como esta:

getCaracter(1,23);

y que me devuelva un char con 'R'

simple verdad? pues no tengo cojones de hacerlo.

He visto vuestro pdf tutorial:
http://www.mojontwins.com/warehouse/splib2-tutorial.pdf

y veo que existe la función sp_GetCharAddr pero no me da lo que esperaba o no se usarla bien. Lo mismo esta función no es lo que yo creo que es.

Alguien la ha usado o sabe como funciona?

Gracias de antemano

[na_th_an]

[luckpro]

Estupenda respuesta, luego pruebo a ver si funciona desde fuera, porque meterla dentro tiene pinta de ser un lío considerable.

Aunque ya me ha picado la curiosidad, cuando me comentas que la función esa devuelve la dirección a la "celda de caracter", por simple curiosidad, ¿que hay en esa dirección de memoria? ¿que información contienen esos bytes? Te lo pregunto porque yo me imaginaba (iluso de mi jejeje) que spectrum guardaba 2 bytes por cada caracter de la pantalla, 1 byte para decir que letra/simbolo debe imprimirse y otra para el color/atributo, pero veo que no es así de simple no?

Muchas gracias, me va a ser de gran ayuda.

[na_th_an]

El Spectrum no tiene memoria de tile, sino usa un framebuffer que describe los pixeles y sus colores (en dos "archivos" diferentes). Es lo que se llama el "Display File". Splib simula esa "memoria de tile" por software, imitando cómo funcionan los procesadores gráficos de muchas consolas y ordenadores como la NES, la Master System o el MSX.

La función sp_GetCharAddr te calcula la dirección en RAM donde empieza la celda de caracter que le pases en los parámetros. Leyendo de esa dirección obtendrías el byte que representan los 8 pixels (en monocromo) de la primera fila de la celda de 8x8. Para obtener la siguiente, habría que sumar 256 a esa dirección, y así hasta tener las 8. Esto es debido a como se organiza el "Display File". Aparte, habría que leer el byte que describe los colores que toman esos pixeles, pero ese cálculo es más trivial: 22528 + x + y * 32.

Splib emplea una capa de abstracción y mantiene un buffer aparte en el que almacena qué caracter de los 256 que maneja hay en cada celda. Luego, cuando un trozo de la pantalla cambia (porque pongas nuevos tiles o porque un sprite se mueva por ahí), "construye" la imagen que ves sobre el Display File obteniendo información de su buffer, de los gráficos de los tiles, y de los gráficos de los sprites.

Lo que intentamos hacer es leer directamente de este buffer. La otra opción (que es la que, por ejemplo, tomó el diseñador de la ROM de BASIC del Spectrum) sería leer 8 bytes del display file y buscar a qué caracter corresponden de la tabla de caracteres, lo cual sería infinitamente más lento (¡por eso la función SCREEN$ de BASIC es tan lenta!).

Sobre hacer funcionar esto, en realidad incluirla en splib2 no sería tan complicado. El problema es que los fuentes de splib2 no se llevan bien con las últimas versiones de z88dk y hay que sudar un poquito. Creo que la versión de splib2 que usamos todos la compilé con la versión 1.7 o 1.8 de z88dk, ¡sí que ha llovido! A unas malas, sólo tengo que buscar en los cajones y sacar esa versión vieja. Si no lo puedes hacer funcionar, busco un hueco.

[luckpro]

Joder, explicado a la perfección, no tenia ni idea de que funcionase así.

Vamos todo esto viene por intentar ahorrarme tener dos arrays de 32x24 con todos los caracteres y colores, pensé que si ya estaba en la RAM en algún sitio pues me lo ahorraba. En cualquier caso podría usar el array igualmente para los caracteres y sacar los colores con esa formula que me has puesto (así solo gastaría 768 bytes).

Muchas gracias por ofrecerte para modificar la lib, pero no te quiero hacer perder tiempo en esto. Ya me las apañare con lo que pueda.

Infinitas gracias. Me ha quedado todo mucho más claro. A ver si consigo hacer algo chulo...

[na_th_an]

[luckpro]

[na_th_an]

[luckpro]

DOH!, no tiene reloj, pues entonces normal que se quedase pillado ahí jejejeje . En este caso concreto no me valdría contar los frames, porque precisamente lo que quiero controlar es el tiempo entre frame y frame para que no se ponga el juego demasiado rápido.

Dependiendo del input del jugador y de varios factores más, el código hace más o menos cosas y claro, en el mejor de los casos, el juego puede embalarse un poco, de ahí que quisiera hacer un pequeño delay en esos momentos para que la velocidad fuese estable todo el tiempo y no marear al jugador con diferentes velocidades.

Creo que lo mejor será que el código ejecute siempre las mismas cosas (más o menos) para asegurarme que va a la misma velocidad.

Estoy usando la churrera, pero como no me hace falta el control de niveles, ni los 4 sprites, ni los scripts, esos trozos de código los he comentado y he agregado mis cosillas. Así aprendo cositas nuevas. La idea es hacer un shoot em up alineado a carácter, no creo que me salga muy bien, pero bueno lo voy a intentar por lo menos

Ya te iré contando como va. Te tendré que poner en los créditos porque la ayuda que me estas dando no tiene precio jejeje.

[na_th_an]

Si quieres meter delays en los cuadros de juego más cortos, lo suyo es que montes un ISR que cuente interrupciones, así te garantizas 50 incrementos por segundo y puedes usarlo para temporizar. Al principio de cada cuadro de juego pones el contador a cero, y al final de tu bucle de juego haces un while que espere hasta que tome el número fijo que decidas.

Montar un ISR no es difícil, si sigues los pasos que salen en la documentación de splib2 lo sacas seguro. Si no, puedes mirar como está hecho en la versión 128K de MK1 o MK2.