10 June 2018, 23:27 | #61 |
Registered User
Join Date: Sep 2007
Location: Stockholm
Posts: 4,332
|
Actually, Blitz has a ShapesHit and a RectsHit command to do that in few lines of code, this thread is just about possible optimisations by writing your own collision detection routine.
|
11 June 2018, 01:24 | #62 |
Phone Homer
Join Date: Jun 2006
Location: 5150
Posts: 5,773
|
Amos you have Bob collision commands that work quick and tell you what Bob hit what Bob can you do this in Blitz?
Though I don't think this was ever really used in commercial games they tended to go for Boxing. |
11 June 2018, 02:28 | #63 |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
If you use ShapesHit, yes. Not very fast, as I bet not very fast on Amos too and that's why they go for "Boxing"...
|
11 June 2018, 02:39 | #64 |
Phone Homer
Join Date: Jun 2006
Location: 5150
Posts: 5,773
|
iirc it's seamless with Bobs in Amos but doesn't work so well with Sprites and scrolling thats why I never used it.
|
11 June 2018, 03:18 | #65 | |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
Quote:
Blitz manual is really a mess |
|
11 June 2018, 08:32 | #66 |
Banana
Join Date: Jul 2016
Location: Darmstadt
Posts: 1,213
|
Blitz is pretty low-level, I'd be surprised if the language overheads were significant compared to the execution time of 1000+ arithmetic operations and conditional branches.
|
11 June 2018, 15:29 | #67 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 839
|
My take on how to do it (designed for assembler):
Take smallest object you want to check against, pick highest value of width or height, round up to next power of 2 (call this A). Divide screen width by A, round up to next power of 2 (call this B). Divide screen height by A, round up to next power of 2 (call this C). Make a grid as a B*C array of single linked pointers. For every object find which place in the grid the upper left corner belongs to and link in a pointer to the object. (Simple AND and shift operations.) In the end check player against all objects in all the grid squares it can overlap. |
11 June 2018, 16:19 | #68 | |||
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 525
|
Quote:
However, I just realized that in the example code that I gave, I may have done it in the wrong way. So here again... Code:
for f =0 to num_enemies ex = enemyx(f) for g = 0 to num_bullets bx = bulletx(g) if ex > bx - 8 if ex < bx + 8 ey = enemyy(f) ; makes normal variables by = bullety(g) if ey > by - 8 if ey < by + 8 collide() endif endif endif endif next next This is because I think that in many collision checks it only does one IF check and nothing more, which means that here for example bx = bulletx(g) in many cases gives speed boost for only the first "bx check", which is actually a "slow boost", because in this trick you always need at least 2 speed boosts in order to gain speed. So in this example, I would probably remove all those variable changes, except the ex = enemy(f) at the top; only for that I am 100% sure it adds a lot of speed, but the others may actually slow things down. --- Also, if possible, you should design the main object control loop in a way that only in the beginning you do this variable change trick, and then you put the variables back only after the whole main loop has finished. So if your loop looks like this: MOVEMENT AI LOGIC (if any) TEST COLLISION BLIT repeat until all objects done Then the modified loop might look something like this: enemyx = enemyx(f) enemyy = enemyy(f) MOVEMENT AI LOGIC (if any) TEST COLLISION BLIT enemyx(f) = enemyx enemyy(f) = enemyx repeat until all objects done This way the only time when the variable change happens is at the beginning of absolutely everything, so that you don't need to do this stuff at every sub routine. The variable changes themselves take some time, so it's best to minimize the amount of times when this happens. And also it helps if you name the "fast variables" with names that are similar to the Array/Newtype variables that you are changing, so ObjectX(n) simply becomes ObjectX = ObjectX(n). For Newtypes at least the name can be exactly the same, I assume that the same is true for normal arrays. --- Quote:
Quote:
|
|||
11 June 2018, 17:21 | #69 | |
Banana
Join Date: Jul 2016
Location: Darmstadt
Posts: 1,213
|
Quote:
Imagine a 20x16 byte array, each cell representing a 16 pixel tile. Write into that byte the shape number (or sprite number) representing the object, 0=empty. As an object moves, check if the destination cell is occupied, and if so, by whom. Destination cell = (x >> 4, y >> 4). It limits movement/collisions to the cell size though. Small cells take up more memory. Last edited by E-Penguin; 11 June 2018 at 17:41. |
|
11 June 2018, 20:52 | #70 | |
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 525
|
Here is one more idea:
Add four more variables for the bullets: bulletLeftSide, bulletRightSide, bulletUpSide, bulletDownSide. Use these variables to store the X and Y locations of the bullets hitbox walls. Update these variables every time when a bullet moves. So 8 bullets move, and after every move you update 4 variables, so it's 8*4 = 32 operations. And after this is done, then this routine: Code:
if enemyx(f) > bulletx(g) - 8 if enemyx(f) < bulletx(g) + 8 if enemyy(f) > bullety(g) - 8 if enemyy(f) < bullety(g) + 8 collide() endif endif endif endif Code:
if enemyx(f) > bulletLeftSide(g) if enemyx(f) < bulletRightSide(g) if enemyy(f) > bulletDownSide(g) if enemyy(f) < bulletUpSide(g) collide() endif endif endif endif And because we had 30 enemies checked against 8 bullets, then we save 30*8*4 = 960 operations. And even in the case where just one IF was checked (the case of the fastest non-collision) , we save 240 operations. This should give a massive speed boost. --- Quote:
Here is what I know of this evil command. I think that the default Blitz DisplayAdjust is just this: DisplayAdjust CoplistNumber,0,0,0,0,0 This gives a normal 320 pixel wide screen, which is also the same if you dont use this command at all. But here is a DisplayAdjust to get a 288 pixel wide screen: DisplayAdjust CoplistNumber,-2,8,0,16,-16 That works for my AGA shmup demo at least, and it gives some 10% to 15% boost to bob drawing speed in comparison to a full 320 pixels screen. Notice that those values I have found out through random shotgunning and guessing how this command works. Also notice that if any of the larger AGA display fetch modes are activated, then that has an big effect on this command. But on A500 you don't have worry about this. For the Slice library things are much more simple, because you just give the screen width in the Slice command (just make sure it's a value that can be divided with 16) . This is why I actually often use the Slice library when doing stuff for the A500. |
|
11 June 2018, 21:05 | #71 | |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
Quote:
When you suggest to have a smaller display... if instead of having a less wide display, I just avoid using all screen vertically (Say, instead of using the 320x256 resolution, I go for just 320x200), will this help me get that DMA time too? Or it makes no difference? |
|
11 June 2018, 21:12 | #72 |
Banana
Join Date: Jul 2016
Location: Darmstadt
Posts: 1,213
|
No expert but I think the width is important for DMA as the screen is drawn per line. A thinner display means less time fetching for the next line. Whereas a PAL display contains 256 lines whether you draw to them or not.
|
11 June 2018, 21:17 | #73 |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
That's what I thought too, but better asks for people who know their shit better than me
|
11 June 2018, 22:43 | #74 |
Registered User
Join Date: Mar 2016
Location: Australia
Posts: 881
|
Don’t forget that your code is still running across all vertical lines (including the v-blank), so especially if your code is running out of chip ram then not having useless blank data copied to the screen will give you more time for CPU regardless of if it’s vertical or horizontal.
The visual DMA debugger is great for this kind of thing, especially when combined with marking important timing events with a background palette change. |
12 June 2018, 14:37 | #75 | |
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 525
|
Quote:
Blitz manual also recommends that you reduce the screen size if you want more speed, here is a quote from the manual: " Decrease the size of the display. During a frame, the display slows down the processor and blitter. A smaller display increases the amount of time given to the processor and blitter. " This is the reason why almost all commercial games run on reduced screen sizes. A full 320*256 looks cool, and if you can get that to run at 50 FPS then great. But if you want more speed, then a little bit of size can be sacrificed. Examples of games that have a 288 pixels wide screen: Elfmania, Risky Woods, Midnight Resistance, Battle Squadron, X-out, Agony, Amnios, and many more...X-out actually uses a visual trick that tries to hide this by making the score panel wider than the actual game area. Some other examples would be Z-out and Turrican 2 that have 304 pixel screens, and Hybris and Mega Typhoon that have just 256 wide screens. |
|
12 June 2018, 15:58 | #76 |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
Vertical shmups actually benefit from less horizontal space. On hybrid it makes a lot of sense to have a smaller screen. Considering most of that game uses just sprites, probably the coder chose a smaller display more for a gameplay than a speed benefit.
|
12 June 2018, 16:47 | #77 |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,334
|
If you're using lots of colours, you also need to reduce the display width in order to use all the sprites. I can't remember exactly where the cut-off is, but sprite channel 7 will disappear on a full-width display when you reach a certain number of bitplanes.
|
12 June 2018, 17:49 | #78 |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
On a 3x3 dual playfield you lose channel 7
|
12 June 2018, 23:05 | #79 |
Registered User
Join Date: Jan 2014
Location: Belgrade / Serbia
Age: 41
Posts: 999
|
|
12 June 2018, 23:25 | #80 |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
Yes, same to me, that's why my game "Roadtrip" shows some small graphics glitches when running on OCS (At least on Winuae, I have no OCS machine to test, just an A600 )
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
SetCol/DoColl-How to test collisions with different sprites against different colors? | Shatterhand | Coders. Blitz Basic | 1 | 12 January 2017 18:51 |
Quickest code.... | Galahad/FLT | Coders. Asm / Hardware | 10 | 01 January 2017 17:23 |
[REQ:ASM] Sprite collisions basics | jman | Coders. Tutorials | 5 | 03 September 2011 00:07 |
What is the quickest way | Doc Mindie | support.WinUAE | 6 | 17 October 2007 21:15 |
Disable Sprite Collisions | DeAdLy_cOoKiE | Retrogaming General Discussion | 4 | 24 March 2006 17:56 |
|
|