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 »

So, reading your explanation above.

Would it be better if I cut the large images (34 pixels high) into 2 images of 17 pixels in height?

It seems to me this would increase the chance of finding contiguous memory.
at67
Site Admin
Posts: 647
Joined: 14 May 2018, 08:29

Re: gtBASIC

Post by at67 »

There's no need to do that, the BLIT routine will automatically split up the image into contiguous chunks of whatever you specify, obviously it will become a little more inefficient as more individual native calls will need to be made internally to get the full image on screen; just set the number so that the LOAD BLIT's work and you'll be fine
wbushby
Posts: 208
Joined: 16 Jul 2021, 10:59

Re: gtBASIC

Post by wbushby »

I have a question ? I need to make an image move slowly off screen upwards. Could you add the ability to show a partial piece of the sprite so that memory is not corrupted by drawing a sprite off screen ?
The only other option is to make several slightly smaller and smaller sprites to show the effect but this uses up limited resources.
wbushby
Posts: 208
Joined: 16 Jul 2021, 10:59

Re: gtBASIC Sprite Memory

Post by wbushby »

My application loads 34 BLITs then attempts to load 8 sprites. It fails on the 8th sprite with the following message.
' couldn't allocate memory for sprite 8'

I was loading 36 BLITs but removed 2 that were 36 X 34 pixels each and it still won't load the 9 X 18 sprite no 8.

This makes me think the memory issue is not the BLITs loaded ahead of the sprites.

I have reserved memory for sprites with this statement:

CONST vtX = &h0600
DEF BYTE(vtX, 0, 1, 120) = 0

Is there something I can do to correct this issue as I need a few more sprites
Attachments
spritememory.jpg
spritememory.jpg (133.38 KiB) Viewed 786 times
at67
Site Admin
Posts: 647
Joined: 14 May 2018, 08:29

Re: gtBASIC

Post by at67 »

You need to LOAD the SPRITE's before the BLIT's. most likely what has happened is that the BLIT's have taken some of the SPRITE's memory. Also, with the 64k model the maximum number of rows for all SPRITE's, is 120 + 128; have you exceeded this number?
wbushby
Posts: 208
Joined: 16 Jul 2021, 10:59

Re: gtBASIC

Post by wbushby »

I have used 204 rows so there are not many left. (More info for the manual).

I removed all large BLIT and then I could then add more sprites so it is the BLITs stealing sprite memory.

I will work out a happy balance of BLIT and SPRITE. There is a large SPRITE flicker issue on the SPRITE DRAW - SPRITE RESTORE set of commands that hopefully I can eliminate.
wbushby
Posts: 208
Joined: 16 Jul 2021, 10:59

Re: gtBASIC

Post by wbushby »

Is there a way to stop the erasure and redrawing of specific sprites with the SPRITE DRAW - SPRITE RESTORE commands ?

Even though the sprites have not moved they appear to be erased and redrawn each loop.
at67
Site Admin
Posts: 647
Joined: 14 May 2018, 08:29

Re: gtBASIC

Post by at67 »

There isn't, SPRITE's are designed to emulate real hardware sprites as much as possible, i.e. they are capable of restoring any background, static, dynamic, other sprites, blit's, bullets, etc.

If you want a sprite that doesn't redraw/refresh based on spatial state, (i.e. movement), then just use a BLIT that has an embedded background.
wbushby
Posts: 208
Joined: 16 Jul 2021, 10:59

Re: gtBASIC

Post by wbushby »

The problem is I am trying to reduce my large BLITs and use the SPRITE/PATTERN process instead as this will fit in memory. I have changed over and it all fits but the flicker is annoying

I have a couple of ideas that might figure this out
wbushby
Posts: 208
Joined: 16 Jul 2021, 10:59

Re: gtBASIC

Post by wbushby »

I was able to get all the graphics into the app by breaking the large images into strips of narrower subsets and adjusting the graphics so there were common areas that could be used across multiple images.
This works well in the emulator. Hopefully I will be able to test on a real gigatron soon as my new man cave is sloowwwly coming to fruition.
This exercise has been interesting. I actually miss the creativity you needed 40 years ago to fit ever expanding application requirements onto memory limited machines back then.
Post Reply