mr_woggle Posted July 6, 2020 Share Posted July 6, 2020 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 Quote Link to comment Share on other sites More sharing options...
42bs Posted July 6, 2020 Share Posted July 6, 2020 uuua, malloc?! Really? Ok, maybe share a snippet? Do you: sprite_t *spr = malloc(sizeof(sprite_t)); SCBNEXT = &spr->sprite; Quote Link to comment Share on other sites More sharing options...
mr_woggle Posted July 6, 2020 Author Share Posted July 6, 2020 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; } Quote Link to comment Share on other sites More sharing options...
42bs Posted July 6, 2020 Share Posted July 6, 2020 Looks ok to me, but I did not use C for 20years now Quote Link to comment Share on other sites More sharing options...
42bs Posted July 6, 2020 Share Posted July 6, 2020 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. Quote Link to comment Share on other sites More sharing options...
mr_woggle Posted July 6, 2020 Author Share Posted July 6, 2020 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). Quote Link to comment Share on other sites More sharing options...
Ninjabba Posted July 6, 2020 Share Posted July 6, 2020 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/ Quote Link to comment Share on other sites More sharing options...
LordKraken Posted July 6, 2020 Share Posted July 6, 2020 It also saves you a lot of ram I imagine to not use it Quote Link to comment Share on other sites More sharing options...
+karri Posted July 6, 2020 Share Posted July 6, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
42bs Posted July 8, 2020 Share Posted July 8, 2020 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. Quote Link to comment Share on other sites More sharing options...
drludos Posted August 2, 2020 Share Posted August 2, 2020 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: 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.