gtBASIC

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
wbushby
Posts: 208
Joined: 16 Jul 2021, 10:59

Re: gtBASIC

Post by wbushby »

I think I will then it will be easy to handle a sprite shutdown
wbushby
Posts: 208
Joined: 16 Jul 2021, 10:59

Re: gtBASIC

Post by wbushby »

Back onto manual writing after a dose of programming
wbushby
Posts: 208
Joined: 16 Jul 2021, 10:59

Re: gtBASIC

Post by wbushby »

Right now I use images saved as image.tga at 24 bits. My current project has a lot of image files using a large amount of memory even though I am using a limited set of colours. Are there different image types or loading parameters I can use that will reduce the memory usage per image ?
I assume the internal storage is one format regardless of the file format loaded but you may have catered for colour restrictions to reduce memory usage.
at67
Site Admin
Posts: 647
Joined: 14 May 2018, 08:29

Re: gtBASIC

Post by at67 »

I have a set of unfinished blit and tiling routines for ROMvX0, that will allow for 2, 4 and 8 colour compression per tile/blit; I've also toyed with a Gigatron specific version of DXT1, (but it's too slow even in native code and doesn't offer any significant advantages for the Gigatron's RGB:2 format).

When they will be released, not sure :/

Yes, the internal format is one byte per pixel, RGB:2, i.e. the native 6bit pixel format of the Gigatron, (2 bits per colour component).
wbushby
Posts: 208
Joined: 16 Jul 2021, 10:59

Re: gtBASIC

Post by wbushby »

I was hoping I could use 4 bit colour internally as an option which would allow 2 pixels per byte. It is just that with large sprites built from 2, 4 and 5 sprite images my memory is rapidly disappearing.

I am sure I can fit the rest of the game in. I have 27 k left and may have to reduce the gorilla size and movement to conserve memory.
wbushby
Posts: 208
Joined: 16 Jul 2021, 10:59

Re: gtBASIC

Post by wbushby »

Can you point me to an explanation of this code:

' Defines the amount of contiguous RAM needed for blit stripes, (in this case 15*6 + 1), min address and search direction
_blitStripeChunks_ 15, &h1FA0, &hFFFF, ascending

I have assumed that this reserves RAM for BLIT images. I am getting crashes when I add more BLITs when I attempt to display them so I am assuming that I am running out of reserved memory.

I am looking for what determines the <minimum address> and <maximum address> and <num chunks>.

Before I put in the above code I was getting error:

Memory::printFreeRamList() : Expected 30158 : Found 30158
Keywords::LOAD() : 'Main:125' : syntax error, use 'LOAD BLIT, <filename>, <id>, <optional flip>, <optional overlap>' : LOAD BLIT, Images/Alice1.tga, ALICE1, NoFlip
Keywords::loadBlit() : 'Main:125' : getting blit memory failed for stripe 3 : LOAD BLIT, Images/Alice1.tga, ALICE1, NoFlip

I have several BLITs of size 36 X 34 and 42 X 34 pixels
at67
Site Admin
Posts: 647
Joined: 14 May 2018, 08:29

Re: gtBASIC

Post by at67 »

wbushby wrote: 24 Apr 2023, 13:05 Can you point me to an explanation of this code:

' Defines the amount of contiguous RAM needed for blit stripes, (in this case 15*6 + 1), min address and search direction
_blitStripeChunks_ 15, &h1FA0, &hFFFF, ascending
Marcel's original sprite routine, (that I call a blit), is only capable of blitting images of 6xn pixels, this means if you have a blit that is larger than 6 pixels wide, (lets assume divisible by 6 to make it easier to understand), then you need multiple stripes for the complete blit.

e.g. A blit of 18x24 would need 3 stripes of 6x24. It's more complex than just this, but the only other real limitation is that each of these stripes must fit in a 256 byte page, i.e. the stripe cannot cross a page boundary or exceed 256 bytes in size. So lets say you had a really tall blit of say 18*60, this would once again be split into 3 stripes of 6*60, but then these stripes would also then be split into chunks as 6*60 > 256.

The starting address, ending address and direction of allocation are chosen based on whether you developing for a 32K RAM system, 64K RAM system and how where and how big your code and data is.

e.g. On a 32K RAM system with a very simple demo that has no code, no data and no strings in the 0x08A0 to 0xFFFF offscreen segments, then your blit config line could look like this:

Code: Select all

    _blitStripeChunks_ 15, &h08A0, &h7FFF, ascending

15*6 = 90, an offscreen segment has a maximum of 96 bytes, why can't we do 16? Because we need an end of stripe byte, (negative of the stripe height, see https://github.com/kervinck/gigatron-ro ... ctions.txt "Blit sprite in screen memory").

e.g. On a 64K RAM system your blit config line could look like this:

Code: Select all

    _blitStripeChunks_ 42, &h08000, &hFFFF, ascending

42*6 = 252, the extra 32k of RAM has full 256 byte pages that are free for data.

TDLR: for your example I would try something like this:

Code: Select all

_blitStripeChunks_ 34, &h08000, &hFFFF, ascending
You must also make sure that your LOAD BLIT commands happen first, before all other memory allocation, e.g. DIM's, DEF's, other types of LOAD's, etc; this way the memory manager will allocate memory for your blits first and fit all the other smaller allocations around them. If you do the LOAD BLIT's last, then memory can become too fragmented, (even though there potentially plenty of it left)
wbushby wrote: 24 Apr 2023, 13:05 Before I put in the above code I was getting error:

Memory::printFreeRamList() : Expected 30158 : Found 30158
Keywords::LOAD() : 'Main:125' : syntax error, use 'LOAD BLIT, <filename>, <id>, <optional flip>, <optional overlap>' : LOAD BLIT, Images/Alice1.tga, ALICE1, NoFlip
Keywords::loadBlit() : 'Main:125' : getting blit memory failed for stripe 3 : LOAD BLIT, Images/Alice1.tga, ALICE1, NoFlip

I have several BLITs of size 36 X 34 and 42 X 34 pixels
You are most likely getting this error because the LOAD BLIT commands are not the first statements in your code, they should come before any real code is executed, i.e. as discussed previously you really can't have LOAD commands in sub routines using GOSUB or PROC. So right at the top of your file directly after your pragmas is where you should do your LOAD's, I usually put them in a module file and then load that module directly after the pragmas.

P.S. If you have more than a total of 48 blits, then you need to use the _maxNumBlits_ pragma to specify how many, the blit routines use multiple LUT's and they need to be allocated correctly, e.g. PucMon does this:

Code: Select all

'use this after _runtimeStart_ to specify maximum number of blits if you have more than 48
_maxNumBlits_ 62
wbushby
Posts: 208
Joined: 16 Jul 2021, 10:59

Re: gtBASIC

Post by wbushby »

Thank you Ari, that clarifies a lot. I will add a section into the manual I am writing as I am at graphics in the manual at the moment.
wbushby
Posts: 208
Joined: 16 Jul 2021, 10:59

Re: gtBASIC Sprite Memory

Post by wbushby »

I am getting an error when trying to allocate memory for a sprite that is 9 pixels by 16 pixels. There should be enough space for this size sprite.

I have allocated memory with this statement:

CONST vtX = &h0600
DEF BYTE(vtX, 0, 1, 120) = 0
Attachments
screen.jpg
screen.jpg (134.43 KiB) Viewed 751 times
at67
Site Admin
Posts: 647
Joined: 14 May 2018, 08:29

Re: gtBASIC

Post by at67 »

Sprites are hard coded to use the offscreen segments of both pages of memory, this means from 0x08A0 to 0x7FA0 for page 0 and 0x80A0 to 0xFFA0 for page 1, this means that the maximum number of combined rows of data in your sprites is 120+128, (not including PATTERN's, just LOAD SPRITE commands). It had to be done this way for speed, arbitrary sprite copies supporting transparency from both src and dst would be more than twice as slow in native code.

So if you are using more than 120+128 rows in all your sprites, then you will get this error message; also if something else has been allocated in these areas, then it could be much less than 120+128. e.g. if you do your LOAD BLIT's first, they will probably end up in this offscreen memory, stealing potential sprite memory.

So, you need to do all your LOAD SPRITE's before your LOAD BLIT's and then if you run out of memory for your LOAD BLIT's, you will need to decrease the BLIT chunk size.

e.g. if you have the following:

Code: Select all

_blitStripeChunks_ 34, &h08000, &hFFFF, ascending

LOAD SPRITE's

LOAD BLIT's
and now you run out of BLIT memory, then that means there is no contiguous memory left in the system to support 34 row blits, you would need to reduce the number 34 in small amounts until all the LOAD BLIT's will load.

The Gigatron's memory map is convoluted and becomes very easily fragmented, it's very easy to run out of RAM when attempting to load a resource because the resource is asking for a contiguous area of memory that doesn't exist, even though the total amount of free RAM might be much larger.

All your LOAD's have to be prioritised with these limitations in mind, generally SPRITES always go first, then BLIT's, then MIDI or MUSIC, then DIM's, DEF's, (unless it's a crucial system DEF, that should be first), then your vars and code.

All this needs to be documented :/
Post Reply