Some questions - Algunas dudas

[miguetelo]

Buenas tengo algunas dudas que me están surgiendo mientras estoy probando MPAGD.

1. ¿Las listas de Data tienen un límite de números por data? DATA x, x, x... En un tutorial de Minilop dice que tras cada DATA va una lista máxima de 16 números (separados por comas) como máximo, pero en su tutorial el Shoot'emup tras los data hay más de 16 números.
2. Cuando miro la memoria utilizada en Tools me dice que estoy usando 17500 aprox pero ya estoy sin memoria y al compilar se cuelga. Se supone que todavía queda bastante para utilizar ¿no? todavía no he incorporado ninguna música ni pantalla en memoria.
Muchas gracias

-------------

Hello, I have some questions while I am testing MPAGD.

1. Do Data lists have a number limit per data? DATA x, x, x... In a Minilop tutorial it says that after each DATA only is allowed to put there a maximum list of 16 numbers (separated by commas), but in its Shoot'emup tutorial there are more than 16 numbers after the DATA command.
2. When I look at the memory used in Tools it tells me that I am using approximately 17500 but I am already out of memory, and when i compile it, the game crashes. There's still plenty of memory left to use, right? I have not yet incorporated any music or screen in memory.
Thank you so much

[mas]

Hi there,
a couple of quick answers.

1. Other than Minilop's tutorials, I don't recall seeing a maximum number of items you can have in a DATA statement (also, I use spaces rather than commas to separate my data).

eg.

DATA 0 1 1 1 1 0 1 0 0 0 0 0 1 0 1 0 1
DATA 0 1 0 0 1 0 1 0 0 1 0 0 1 0 1 0 1
DATA 0 1 0 0 1 0 1 0 0 1 0 0 1 0 0 0 0
DATA 0 1 1 1 1 0 0 1 1 0 1 1 0 0 1 0 1
DATA 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
DATA 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0 0 0
DATA 0 0 1 1 0 0 0 0 0 0 0 0 0 1 1 0 0
DATA 0 0 1 0 0 0 0 1 1 0 1 0 0 0 1 0 0
DATA 0 0 1 1 0 0 0 0 0 0 0 0 0 1 1 0 0
DATA 1 0 0 0 1 1 1 1 1 1 1 1 1 0 0 0 1
DATA 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
DATA 0 0 1 0 1 0 1 0 0 0 1 0 1 0 1 0 0
DATA 0 0 0 1 1 1 0 0 0 0 0 1 1 1 0 0 0
DATA 0 0 0 1 1 1 0 0 0 0 0 1 1 1 0 0 0
DATA 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0


I tend to split my data as to what it is doing; in this instance it's representing "dead player" data, with each DATA line being a line that would be interpretted and output to screen in some fashion. It might be that a previous version of MPAGD or AGD had the 16 item restriction. It could also be a limitation of one or other of the engines.

I would say, arrange the data in such a way it makes sense to you when you re-read your code. I expect the engine doesn't care too much and will just render everything as values in memory at compile time, so one DATA block or ten DATA blocks probably look the same. (Other people who know more about the MPAGD engines can probably confirm / give more information along those lines.

2. The "memory estimate" only really covers the things it says, ie. Blocks, Sprites, Objects, Screens, Sprite Positions. It doesn't (appear to) include memory used for messages or the code you've written for the events in the game (or any user assembler code imported into the game). The maximum memory available for both the engine + game is only 39095B (39K) and it is surprising how fast that goes sometimes.

There are alternative builds of MPAGD that can access additional memory (and allow you to build a 128K game). I've not tried them (yet) but Ramon has a good version on itch.io to download and is an active member of these boards and extremely helpful.

To be honest, the only way to find out how much space your game is currently taking is to export it to a tape and look at the size of the code block (you can do this with tools like the ZX BlockEditor utility). Pretty much though, if you are getting errors (usually "label not found") in the blue console window, this is a clear indicator that you have gone past the limit of available space. Minilop does have a few tutorials on optimizing and recovering space (mostly it's cutting down the number of sprites, replacing text with messages... and other things).

With my games so far I find that between 15,000 and 22,000 is where the out of memory issues start hitting - this does differ from game to game and the amount of code I have written to do things. I do have a recollection there might be a restriction on the maximum size of the source files (i.e. each of the events) but I can't see that written in the manual and I'm not sure where I saw it. Probably on these boards somewhere.

I don't know if I've been any help at all there. Hopefully some of my rambling was useful.
M.

(using google to translate to Spanish)

Hola,
un par de respuestas rápidas.

1. Aparte de los tutoriales de Minilop, no recuerdo haber visto una cantidad máxima de elementos que pueda tener en una declaración de DATOS (además, uso espacios en lugar de comas para separar mis datos).DATA 0 1 1 1 1 0 1 0 0 0 0 0 1 0 1 0 1
DATA 0 1 0 0 1 0 1 0 0 1 0 0 1 0 1 0 1
DATA 0 1 0 0 1 0 1 0 0 1 0 0 1 0 0 0 0
DATA 0 1 1 1 1 0 0 1 1 0 1 1 0 0 1 0 1
DATA 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
DATA 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0 0 0
DATA 0 0 1 1 0 0 0 0 0 0 0 0 0 1 1 0 0
DATA 0 0 1 0 0 0 0 1 1 0 1 0 0 0 1 0 0
DATA 0 0 1 1 0 0 0 0 0 0 0 0 0 1 1 0 0
DATA 1 0 0 0 1 1 1 1 1 1 1 1 1 0 0 0 1
DATA 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
DATA 0 0 1 0 1 0 1 0 0 0 1 0 1 0 1 0 0
DATA 0 0 0 1 1 1 0 0 0 0 0 1 1 1 0 0 0
DATA 0 0 0 1 1 1 0 0 0 0 0 1 1 1 0 0 0
DATA 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0

Tiendo a dividir mis datos en cuanto a lo que está haciendo; en este caso representa datos de "jugador muerto", siendo cada línea de DATOS una línea que se interpretaría y se mostraría en la pantalla de alguna manera. Podría ser que una versión anterior de MPAGD o AGD tuviera la restricción de 16 elementos. También podría ser una limitación de uno u otro de los motores.

Yo diría que organice los datos de tal manera que tenga sentido para usted cuando vuelva a leer su código. Supongo que al motor no le importa demasiado y simplemente representará todo como valores en la memoria en el momento de la compilación, por lo que un bloque de DATOS o diez bloques de DATOS probablemente tengan el mismo aspecto. (Otras personas que saben más sobre los motores MPAGD probablemente puedan confirmar/dar más información al respecto.

2. La "estimación de memoria" sólo cubre realmente las cosas que dice, es decir. Bloques, Sprites, Objetos, Pantallas, Posiciones de Sprites. No incluye (parece) la memoria utilizada para los mensajes ni el código que has escrito para los eventos del juego (ni ningún código ensamblador de usuario importado al juego). La memoria máxima disponible tanto para el motor como para el juego es de sólo 39095B (39K) y es sorprendente lo rápido que a veces va.

Existen versiones alternativas de MPAGD que pueden acceder a memoria adicional (y permitirle crear un juego de 128K). No los he probado (todavía) pero Ramon tiene una buena versión en itch.io para descargar y es un miembro activo de estos foros y extremadamente útil.

Para ser honesto, la única forma de saber cuánto espacio ocupa actualmente tu juego es exportarlo a una cinta y observar el tamaño del bloque de código (puedes hacerlo con herramientas como la utilidad ZX BlockEditor). Sin embargo, si recibe errores (generalmente "etiqueta no encontrada") en la ventana azul de la consola, esto es un indicador claro de que ha superado el límite de espacio disponible. Minilop tiene algunos tutoriales sobre cómo optimizar y recuperar espacio (principalmente para reducir la cantidad de sprites, reemplazar texto con mensajes... y otras cosas).

Con mis juegos hasta ahora, encuentro que entre 15.000 y 22.000 es donde empiezan a aparecer los problemas de falta de memoria; esto difiere de un juego a otro y de la cantidad de código que he escrito para hacer las cosas. Recuerdo que podría haber una restricción en el tamaño máximo de los archivos fuente (es decir, cada uno de los eventos), pero no puedo ver eso escrito en el manual y no estoy seguro de dónde lo vi. Probablemente en algún lugar de estos foros.

No sé si he sido de alguna ayuda allí. Esperemos que algunas de mis divagaciones hayan sido útiles.


(hope google was accurate and didn't just call everone a Camel or something) :-)

e.g.

[miguetelo]

Thank you mas i understand.
the key is to save memory and keep it simple, if you can.
I can see the size of the tap generating it with the export option and get an idea of it.
Your answer has been very helpful although you have called everyone a camel
I think with my english i could also call everyone a camel hahaha
Thank you!!

[mas]

:-D
Glad I was able to help. With MPAGD it's always a trade off; do you put your effort into complex code or nice graphics (etc.) I tend to have a "core" idea of what I want to achieve, but I would always want more sprites/animations and graphical effects than the amount of available memory allows :-)

Good luck!
M.