bogax Posted June 25, 2013 Share Posted June 25, 2013 This is a work in progress. Its still buggy. No provision for sprite animation or reversals. Eight pixels for each sprite one for each possible direction. Five of the 8 are checked for a possible move. Fire selects amongst the sprites. Starts with player0 and increases then wraps. Player0 is just the eight pixels (and a pixel at 0, 0 which doesn't count) (player1 also has the 0, 0 pixel) Think of the 8 pixels as an envelope or bumper into which the sprite fits. Player0 is a circle, but it could be any 8. Works reasonably well but 8 is not enough even for (some of) these simple sprites. I haven't tryed to figure it but it may be too slow to be really useful. wip_collision_prevention.bas Quote Link to comment Share on other sites More sharing options...
Cybearg Posted June 25, 2013 Share Posted June 25, 2013 Wow, that's amazing! What kind of cycle drain is this? If it's efficient, it seems like a fantastic multi-purpose collision detection engine. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted June 25, 2013 Share Posted June 25, 2013 Can it be adapted to work with any size sprite, like this one from theloon: collision_prevention_partial_cd_2013y_05m_21d_1748t.bin collision_prevention_partial_cd_2013y_05m_21d_1748t.bas We really, really, really need something where a newbie can enter the width and height of a sprite and get smooth collision prevention. Then all future games would have collision that is as smooth as an ice cube sliding over oiled glass. Quote Link to comment Share on other sites More sharing options...
bogax Posted June 25, 2013 Author Share Posted June 25, 2013 (edited) I count about 2400 cycles for the worst case. but I doubt it goes much above half that most of the time it's about 800 cycles if there's no collision and it could test in three directions if its trying to move diagonaly, although each test will get cut short of 800 cycles if there's a collision detected (and it only tests in another direction if there is a collision detected). I haven't seen it go over cycles in stella and I tried. there's stuff that could be done to speed it up a little. but I think it really needs to test more pixels per direction as far as bigger sprites I don't think that there'd be any problem with that, except it doubles the bytes needed per sprite definition now and it would (possibly) take more than that for bigger sprites the pixel data is packed now as offsets from 0, 0 relative to the sprite I don't know what the limits on sprites are. assuming they're limited to 8 pixels in the horizontal direction, that would 3 bits of the byte leaving 5 bits or 32 pixels vertically and now that I think about it I should set it up that way any way. but unpacking takes time so one way to speed things up would be to leave it unpacked but it only costs about 10 cycles per pixel checked to unpack so it wouldn't be that much maybe 5% Edited June 25, 2013 by bogax Quote Link to comment Share on other sites More sharing options...
bogax Posted June 26, 2013 Author Share Posted June 26, 2013 Here I've squeezed out or moved into the tables everything I could think of and unrolled the loop I think that gets it down to around 1600 cycles worst case But the player pixel tables are three times as big. collision_prevention.bas Quote Link to comment Share on other sites More sharing options...
bogax Posted June 26, 2013 Author Share Posted June 26, 2013 I added playfield bars that show the number of pixels tested for a move (or attempted move) 5 is the norm if there's nothing to collide with collision_prevention_w_bars.bas Quote Link to comment Share on other sites More sharing options...
bogax Posted June 28, 2013 Author Share Posted June 28, 2013 (edited) I moved some of the calculation into the pfread routine which should save a couple hundred cycles. It also saves a couple variables. But it would make the pfread routine a little harder to use for anything else, temp variables would have to be set up. I rearranged the order of the pixels check which seems to save checking one or two pixels, that should save a couple hundred cycles, at least with these pixels/sprites. I tryed adjusting the order of the pixel checking dynamically according to the direction of movement, but I think it uses more time than it saves. edit added some marks to make it easier to judge bar length collision_prevention_13.bas Edited June 28, 2013 by bogax Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted June 28, 2013 Share Posted June 28, 2013 A. Is this dependent on a certain playfield pixel height? One of the big advantages of the multisprite kernel is having 40 pixel tall playfields. B. How on earth are you changing the top row of playfield pixels?!? One of the BIG limitations of multi sprite is a static playfield Quote Link to comment Share on other sites More sharing options...
bogax Posted June 28, 2013 Author Share Posted June 28, 2013 (edited) A. Is this dependent on a certain playfield pixel height? One of the big advantages of the multisprite kernel is having 40 pixel tall playfields. Yes but I don't think it would be hard to make it adaptable. In that last version its baked into the pfread routine but i think it would just be a matter defining a constant and making it use that. although I'm not really sure what it would take. it would certainly help if it works out to a power of two which seemed to be the case for 40 B. How on earth are you changing the top row of playfield pixels?!? One of the BIG limitations of multi sprite is a static playfield heh, look at the code. It's brute force. There's a playfield for each bar length. Edited June 28, 2013 by bogax 1 Quote Link to comment Share on other sites More sharing options...
bogax Posted June 28, 2013 Author Share Posted June 28, 2013 A. Is this dependent on a certain playfield pixel height? One of the big advantages of the multisprite kernel is having 40 pixel tall playfields. This is just setup for 40 it doesn't adapt collision_prevention_40.bas 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted June 28, 2013 Share Posted June 28, 2013 Do you think it would be possible to make a program that checks the 4 corners of a sprite, ball, or missile for use with collision prevention? The user would enter the widths and heights in constants and also enter the playfield pixel height in a constant. If possible, I wonder if the user would have to enter a different width if NUSIZx is used or if the program would automatically adjust for the size difference? Quote Link to comment Share on other sites More sharing options...
bogax Posted June 28, 2013 Author Share Posted June 28, 2013 Do you think it would be possible to make a program that checks the 4 corners of a sprite, ball, or missile for use with collision prevention? The user would enter the widths and heights in constants and also enter the playfield pixel height in a constant. If possible, I wonder if the user would have to enter a different width if NUSIZx is used or if the program would automatically adjust for the size difference? In principle it could be done. You want to put every thing that you can in tables for speed. Having to accomodate on the fly changes will make the tables explode geometrically. To keep the tables from being unweildy if not just too damn big would mean calculating stuff on the fly which might be too slow. You might want dedicated routines for different possibilities (and not just things that change on the fly) which could cause the code to explode. There's an inbetween. Finding a practical inbetween might get tricky. How much of what do you want to change on the fly? I would expect NUSIZx to change. that's 32 different possibilites to accomodate. I don't think it would be impractical but I expect it's going to be sensitive to how much you expect to change on the fly and how many options you have that don't change (pfheight for example) what kernel you're using, stuff like that. Even just checking or accomodating for eg player heights and widths is going to slow you down. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted June 28, 2013 Share Posted June 28, 2013 How much of what do you want to changeon the fly? Since this would just be a collision prevention 'engine' instead of a demo or tool, the only thing the code would do is perform the four corner conversions based on the object width and height info, NUSIZx info, and pfpixel height (number of rows used) that will be provided by the bB programmer at the beginning of the code (in constants). There would be REM statements telling the programmer what constants to use for the various objects. Quote Link to comment Share on other sites More sharing options...
bogax Posted June 30, 2013 Author Share Posted June 30, 2013 What makes more sense? Individual routines for object type player, missile, ball Or a completely general routine that would check any type based on a paramter. A general routine would work better if it could find NUSIZx CTRLPF in ram Individual routines could be shorter and faster but, of course, you'd need more of them (or not if eg your were only using players) and you'd either need individual movement routines or a more complicated movement routine. If NUSIZx is going to change it/they should probably be in ram else you have a similar situation. Maybe it would make more sense to have both types of routines available so you could use whatever the situation called for. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted July 1, 2013 Share Posted July 1, 2013 My guess is that there would be constants set up for each sprite, each missile, the ball, and number of playfield rows. Here's an example of what the default constants might look like: const _p0_width = 0 const _p0_height = 0 const _p0_double_size = 0 : rem - if you want a double-sized player, use "const_p0_double_size = 1" const _p0_quad_size = 0 : rem - if you want a quad-sized player, use "const_p0_quad_size = 1" const _p1_width = 0 const _p1_height = 0 const _p1_double_size = 0 : rem - if you want a double-sized player, use "const_p1_double_size = 1" const _p1_quad_size = 0 : rem - if you want a quad-sized player, use "const_p1_quad_size = 1" const _m0_width = 0 : rem - Missile width can be 1, 2, 4, or 8 const _m0_height = 0 const _m1_width = 0 : rem - Missile width can be 1, 2, 4, or 8 const _m1_height = 0 const _ball_width = 0 const _ball_height = 0 const _Number_of_playfield_rows = 12 Now if-thens would be set up to deal with the constants. For example, if _m0_width or _m1_width is greater than zero, the program will set NUSIZx accordingly. If a constant equals zero, that means the bB programmer isn't using that object or option. After the if-thens figure out what objects or options are being used and how tall a playfield row is (in sprite pixels), more code can then check the 4 corners of objects so we'll get smooth collision prevention. Quote Link to comment Share on other sites More sharing options...
+Lewis2907 Posted July 9, 2018 Share Posted July 9, 2018 Bogax, For your programs collision_prevention_40.bas and collision_prevention_13.bas is it possible to have a version that is 32kSC or 32k. I think this would solve my problems in MultiSprite Version I am working on. I am still playing with the code and your notes on the sprite s well to learn more about. Thanks for sharing this code. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted July 24, 2018 Share Posted July 24, 2018 I hear two solutions so far: 1. Read playfield variables 2. Read a tilemap (playfield collisions as array) What about a third option in using, say, the ball to test for the next possible collision? If the ball collides where the player wants to go then don't move the player sprite. This option has problems since the ball will be playfield pixel colored. But, I wonder if there is a way to mitigate that. Quote Link to comment Share on other sites More sharing options...
+Lewis2907 Posted July 24, 2018 Share Posted July 24, 2018 (edited) I tried the ball and missile in the DPC experiments with Pac Man Eat n Run. It worked somewhat in DPC but not too well in the Multisprite. Plus my programming level eats are lot of space up. If Bogax can make these 2 current programs 8 banks. I think others can adapt it to work. Edited July 24, 2018 by Lewis2907 1 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted July 24, 2018 Share Posted July 24, 2018 I tried the ball and missile in the DPC experiments with Pac Man Eat n Run. It worked somewhat in DPC but not too well in the Multisprite. Plus my programming level eats are lot of space up. If Bogax can make these 2 current programs 8 banks. I think others can adapt it to work. Here's a demo of that kind of collision working in multi sprite. The pumpkin (player) doesn't jump. When you press FIRE a spell launches. When the spell hits a wall it warps the player there. ballcoldemo.bin Quote Link to comment Share on other sites More sharing options...
+Lewis2907 Posted July 24, 2018 Share Posted July 24, 2018 That's pretty cool. Do you mind posting the code. That's is how I have been learning and using and giving credit in my remarks, thanks. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted July 25, 2018 Share Posted July 25, 2018 That's pretty cool. Do you mind posting the code. That's is how I have been learning and using and giving credit in my remarks, thanks. My "in progress" code gives Random Terrain hives. Lemme clean it up a bit as a more complete example. But, at least you see that using the ball to detect collisions and mitigate sprite jitter is possible. Better the ball waffle back and forth after a collision than yer sprite Quote Link to comment Share on other sites More sharing options...
+Lewis2907 Posted July 25, 2018 Share Posted July 25, 2018 Okay thanks. Plus we don't want RT to go back in the "Squishy Bed" with the hives. For giggles randomly place the dim here and there out of order to work a nerve with him lol. Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted July 25, 2018 Share Posted July 25, 2018 (edited) I've been wondering about some semi-related stuff.. I remember reading that the DPC+ kernel had built-in virtual player hit detection and that the Y-value of the hit player was in temp4 after drawscreen but that the value could be a little bit wrong, is that still implemented in the kernel? I've never seen anybody use it so just seems unnecessary if it is. And I've never tampered with playfield collisions so I don't know how it's done but could you use the same technique for a moving sprite to get a hitbox that's exactly or closer to the sprites shape instead of a square? Edited July 25, 2018 by Lillapojkenpåön Quote Link to comment Share on other sites More sharing options...
+Lewis2907 Posted July 25, 2018 Share Posted July 25, 2018 From what I understand part of the issue is the mirrored playfield and there is not pfpixel as a reference point to have detection the easy way. From what I am reading and seeing using a combo ASM and Bb to get a desired effect. Waiting to see what the others can produce as a blueprint hopefully with 32k / 8 banks. Quote Link to comment Share on other sites More sharing options...
iesposta Posted July 26, 2018 Share Posted July 26, 2018 I've been wondering about some semi-related stuff.. I remember reading that the DPC+ kernel had built-in virtual player hit detection and that the Y-value of the hit player was in temp4 after drawscreen but that the value could be a little bit wrong, is that still implemented in the kernel? I've never seen anybody use it so just seems unnecessary if it is. And I've never tampered with playfield collisions so I don't know how it's done but could you use the same technique for a moving sprite to get a hitbox that's exactly or closer to the sprites shape instead of a square? I don’t know about the y-value being in temp4, but this bB DPC+ code I wrote turns 7 virtual Players into a lot more using double and triple copy, and collision works with all of them: http://randomterrain.com/atari-2600-memories-batari-basic-commands.html#ex_dpc_shooting_nusiz 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.