Using more than 64 GRAM cards.

[PuzZLeR]

Greetings. Again I ask for a little help. (You've all been great so far, thanks.)

 

I've done some searches, but haven't yet found, what I believe to be, a "safe" way of doing this, meaning without any problems down the road (such as with real hardware, etc.). But, I know that there are ways.

 

As an example, say you have drawn, and entered into your program, some 96 GRAM cards, 16 each into labels gramchars1 to gramchars6. That's 150% the "allowable" amount. (Call them 00-95 respectively if so).

 

At the beginning, you load the first 64 cards. (That's gramchars1, gramchars2, gramchars3, gramchars4.)

 

wait
define DEF00,16,gramchars1
wait
define DEF16,16,gramchars2
wait
define DEF32,16,gramchars3
wait
define DEF48,16,gramchars4
wait

 

To keep it simple, say, later in the program, such as for a future level, you only need the last 64 (32-95, or gramchars3, gramchars4, gramchars5, gramchars6).

 

Then you load those.

 

wait
define DEF00,16,gramchars3
wait
define DEF16,16,gramchars4
wait
define DEF32,16,gramchars5
wait
define DEF48,16,gramchars6
wait

 

This is assuming that this overrides the previous loading of cards 0-63. I'm testing, and looking to do this back and forth too, for several times in the program. Even different combinations as well, say even later in the program, such as, say, with gramchars1, gramchars2, gramchars5, gramchars6.

 

wait
define DEF00,16,gramchars1
wait
define DEF16,16,gramchars2
wait
define DEF32,16,gramchars5
wait
define DEF48,16,gramchars6
wait

 

Just looking for a little feedback on this if I'm "safe".

 

Thanks so much! ?

Edited January 22, 2021 by PuzZLeR
Corrected something here to 32-95.

[PuzZLeR]

And, having said the above example, here's my REAL question:

 

Can I draw, AND retain, more than 64 cards in my program, say 96, or even 200 or so, SAFELY as long as I'm only using 64 at a time?

 

Thanks again.

 

 

[carlsson]

I believe the answer is yes to both questions. Actually what you have in your program are not GRAM cards but bitmap definitions that you load (define) into GRAM, 16 cards at a time. You can think about if you would do a slideshow of bitmapped images as long as you define your images in such way that none would exceed 64 GRAM. Then you could load one image at a time, and then load the next one etc until your ROM is full (42 kilodecles = 84 kilobytes).

 

What you might want though it to optimize which banks of bitmaps you want to use for which GRAM cards so you might have two or three "banks" static, and two dynamic that you would change over the course of the game, to not have to reload so much graphics if you anyway need some of the same cards.

[PuzZLeR]

Hey Carlsson. Thanks for your response. Sounds good!

 

2 minutes ago, carlsson said:

Actually what you have in your program are not GRAM cards but bitmap definitions that you load (define) into GRAM, 16 cards at a time. You can think about if you would do a slideshow of bitmapped images as long as you define your images in such way that none would exceed 64 GRAM. Then you could load one image at a time, and then load the next one etc until your ROM is full (42 kilodecles = 84 kilobytes).

 

This makes sense. Yes indeed.

 

4 minutes ago, carlsson said:

What you might want though it to optimize which banks of bitmaps you want to use for which GRAM cards so you might have two or three "banks" static, and two dynamic that you would change over the course of the game, to not have to reload so much graphics if you anyway need some of the same cards.

 

Absolutely. My example was just for simplicity and only being hypothetical, as in reality it could be quite different. It's a project management routine all the way, and I (think I) know what I'm doing here.

 

?

[+DZ-Jay]

The 64 GRAM cards limitations actually means that there is enough space in graphics memory to hold 64 8x8 cards.  Think of those spaces as variables:  If your program had 64 variables defined, your program could have any number of values in DATA statements, but you can only load 64 of them at a time into your variables.  The DATA statements reside in your read-only memory (ROM), and they are inert until your read them and assign them to a variable.

 

The same thing happens with graphics memory (GRAM).  Essentially, GRAM is an array of 64 cards.  you can have as many graphic card definitions stored in DATA statements in your program, but you can only load 64 at a time.  At any point in time, your program is free to load any card into any of those 64 slots, so you are not limited to loading a complete set of 64 in one go.

 

So, if you have levels with different screens, you can store in your ROM the data for all those cards, and at the right point in your program load them as necessary.  If one level only needs to change a few of the cards, then you can do that too.

 

Just remember:  GRAM slots are just like variable slots in memory:  they are there for you to update as necessary, in any order or number.  You just have only 64 slots at one time.

 

    -dZ.

Edited January 22, 2021 by DZ-Jay

[PuzZLeR]

DZ_Jay, thanks for the excellent explanation as well. I understand it perfectly, and my question's been answered. ?

 

I also feel a bit relieved, and happy to hear this answer, as I know I'd run out of GRAM soon enough if it was only 64. It's good to hear that you can have more than 64 in your stash, and the usage of up-to-64-at-a-time-only is a "limitation" I'm good with with just a little management on my side.

 

In other words too, I'm fully understanding of the difference between STORING and USING these cards. Usage: up to 64. Storage: More than 64 is Ok.

 

Thanks! ?

 

 

 

Edited January 22, 2021 by PuzZLeR
Missed a sentence.

[skywaffle]

One solution to reduce some of the cards you are using, would be to use DEFINE VARPTR to update individual cards for character or enemy animation, as opposed to storing all of these at one time.

 

Doing this not only frees up more grams for levels, but allows for much more complex animation.  It's also nice to use DEFINE VARPTR for pulling in graphics for stage bitmaps as you need them. 

 

Attached is an example.

 

definevarptr.bas

Edited January 22, 2021 by skywaffle

[skywaffle]

Here is a more complex example.  Only 8 cards are used.  Up and down animate the character.

 

In other projects, I will have an offset table for stage bitmaps, so during level initialization, it can grab the appropriate bitmaps based on the stage's offset.

 

 

pop_climb5.bas

[carlsson]

Yeah, efficient and creative use of VARPTR could fill at least half a book on IntyBASIC Programming Vol 2.

[+cmadruga]

Completely agree with you guys on the use of VARPTR. It's hard to get it at first, but it is such an unlocker.

Looking at examples definitely helps... I started getting it after reading the source for Deep Zone and trying it on my own.

[+DZ-Jay]

8 hours ago, skywaffle said:

Doing this not only frees up more grams for levels, but allows for much more complex animation.  It's also nice to use DEFINE VARPTR for pulling in graphics for stage bitmaps as you need them.

 

Hmm ... I do not see the difference.  All VARPTR does in that context is treat the label heading the dataset as an array, which you can then use to compute an index into it to load an individual cell.  There's no magic, and it is definitely not different -- or more efficient -- than just putting individual labels in each of those data objects and calling them by name with a count of "1."

 

Computing an index into an array of animation cells is one way of doing it.  It could also be a state machine, in which case, labels could suffice as well.

 

I do not see how using VARPTR "frees up more grams for levels" ...

Edited January 22, 2021 by DZ-Jay