Jump to content
IGNORED

Malloc and collision sprites


Recommended Posts

I've been programming for the Atari Lynx for a little while. 

It's fun, but I run into a small problem. I want to dynamically allocate and free collision sprites.

I'm aware that the collision offset is -1 relatively to the sprite. My collision sprite type is defined as follows

 

typedef struct {
	char collindex;
  	SCB_REHV sprite;
  	void *next;
} sprite_t;

 

This all goes well, when all the sprites are statically allocated and I set tgi_setcollisiondetection(1);

It also goes well if I dynamically allocated the sprites (simple linked list) and tgi_setcollisiondetection(0);
Once I set collision detection on, however, it doesn't seem to work. 

 

Is this some memory alignment issue or how the heap allocates?
Is there any boiler plate code for this?

 

Sincerely,

Rob

Link to comment
Share on other sites

It's something along these lines:

 

sprite_bomb *bombs = 0;

void create_bomb()
  {
          sprite_bomb * prev = 0, *current = bombs;
          sprite_bomb * bomb = (sprite_bomb*)malloc(sizeof(sprite_bomb));
          create_sprite(bomb);
          bomb->sprite.hpos = 10; 
          bomb->sprite.vpos = 10; 
      
          if(bombs != 0){ 
                  while(current != 0){ 
                          prev = current;
                          current = current->next;
                  }
      
                  prev->next = bomb;
          } else {
                  bombs = bomb;
          }
          bomb->next = 0;
  
  }

void create_sprite(sprite_bomb* shot){
      shot->sprite.sprctl0 = BPP_1 | TYPE_NORMAL;
          shot->sprite.sprctl1 = REHV;
          shot->sprite.sprcoll = 4;
          shot->sprite.data = singlepixel_data;
          shot->sprite.hsize = 0x0100;
          shot->sprite.vsize = 0x0100;
 }

and then in the main loop I draw somewhere:
 

sprite_bomb * bomb = bombs;

while(bomb != 0){ 
                  tgi_sprite(&(bomb->sprite));
                  bomb->sprite.vpos += SPEED;
                  bomb = bomb->next;
 }

 

Link to comment
Share on other sites

I do not recommend to use malloc/free. If you need the maximum number of bombs, then you need to reserve this memory anyway. malloc/free tend to fragment the memory over time.

And: SCB has a link, so you can save memory by using this one and draw all bombs with a single call.

Link to comment
Share on other sites

Thanks for the suggestion. I did not think this through at all, I just thought allocating and freeing 'actors' would be the way to go.

 

5 minutes ago, 42bs said:

And: SCB has a link, so you can save memory by using this one and draw all bombs with a single call.

Can you explain this a bit more? I guess you mean that you just change the vpos and hpos or something? And keep an array of that, instead of creating many SCB instances? (note: the bomb snippet I use here is just a trivial example to illustrate of the trouble I'm having).

Link to comment
Share on other sites

I was pointed out years ago on this forum when I ventured into the same direction that you're better off writing your own collision detection routines for 2 reasons:

- using the sprite collision supported by the Lynx is computationally expensive (maybe its only related to the tgi implementation, I wouldn't know)

- the collision detection will fire even if there's only a 1 pixel overlap between two objects, which might not be preferred, depending on what you're trying to build

 

Other than that, you might have found this post already, but I'll just place it here:

 

https://atarilynxdeveloper.wordpress.com/2012/12/09/programming-tutorial-part-10collisions/

 

Link to comment
Share on other sites

I fully agree to what others say here. RAM is very precious, ROM is not.

 

So I would design the levels so, that nothing but the stuff needed by the levels is in memory at playing time. Try to get rid of EVERYTHING you don't need in RAM while playing.

 

In On Duty I created massive segments that contained the bitmaps, sprite structures and code. All in just one segment. It does not matter if you get a few copies of your sprite in ROM as long as you have plenty of RAM available. Taking the path to micro-manage bytes just wastes RAM.

  • Like 1
Link to comment
Share on other sites

On 7/6/2020 at 5:10 PM, mr_woggle said:

Thanks for the suggestion. I did not think this through at all, I just thought allocating and freeing 'actors' would be the way to go.

 

Can you explain this a bit more? I guess you mean that you just change the vpos and hpos or something? And keep an array of that, instead of creating many SCB instances? (note: the bomb snippet I use here is just a trivial example to illustrate of the trouble I'm having).

In your example, you made the meta structure and linked it. But SCB itself has a link. And you also can set a flag in the SCB to ignore a sprite. Then you can draw all sprites with a single call. Instead following the meta-next ptr and draw each sprite on its own.

 

Link to comment
Share on other sites

  • 4 weeks later...

I'll also recommend you the "linked sprite list" approach, as it's way faster to draw a single chain of SCB than to make many tgi_sprite calls.

 

You can read many details about this topic in the following post, where Nop90 managed to greatly improve the framerate of his game by using SCB links:

 

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...