View Single Post
Old 14 August 2019, 12:46   #66
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,364
Quote:
Originally Posted by zero View Post
I meant you can pipeline the generation of the grid address on an A1200... Although I'm starting to wonder if I was right, I forgot there is no swap.w op-code.
If you're referring to the 68020 concurrency features, they're relatively limited in capabilities. It's true that stuff in the cache can execute while the bus is busy, but only up until the result of any memory access is needed by the CPU and it still will take time to execute code in the cache - though using fewer cycles than it normally would (notably, it is possible for some instructions to be 'free', but this is a fairly rare occurrence).
Quote:
But actually there is a better way to do it that I thought of. You have to calculate basically the same thing for the blitter anyway. It needs a memory address, i.e. a 16 pixel block aligned address. So you have done a lot of the work already.
You don't really calculate the same. The grid is basically two shifts, one 'and' and an 'or' (plus storing the result). The Blitter is basically one multiply, one shift and an add (plus the BLTCON and register stuff). I do agree that you can use the result of that one shift if the grid happens to be 8 pixels wide to get the X part of the grid coordinate without further calculation, though. That said, most optimised Blitter routines use a fair amount of registers so it remains to be seen if it's possible to actually integrate this without needing more memory accesses than just doing it separately.

Trying to do this while setting up blits is not a bad idea per se. I'm just not so sure it really fits as well as you think. Then again, I'm always open to new ideas so if you have a better one than I did - I'm all ears.
Quote:
I'm wondering if with clever alignment of the screen bitplanes you could optimize it even further.
I don't see it myself, but perhaps it is possible. What do you have in mind?
Quote:
In Gradius the collision detection for the player's ship favours the player. You never die when a bullet definitely didn't touch you. Sometimes you can survive when a bullet grazes the ship. That became a standard feature of Japanese shumups, with the player having a tiny hit box way smaller that the ship sprite.
I'll grant you that usually, the collision detection in Gradius (PCE) seems to work just fine.

However, at times it really did feel rather arbitrary. Some bullets would graze me without registering a hit, others would seemingly graze no 'deeper', but would kill me. This is a consequence of a grid based system. It's inaccurate, which leads to similar situations not resulting in the same outcome.

Don't get me wrong, the game is rather enjoyable. But when compared to other games in the genre, the collision detection is just not as good and this does sometimes make it less fun or more frustrating to play.

Note that this is completely separate from the small hitboxes used in shoot em ups. That feature was not inspired by Gradius and it's grid system. It came into being when bullet/enemy counts went up in games and was put in to keep games playable and as a bonus, added the thrill of a near miss.
Quote:
If you require pixel perfect collision detection to "trust" a game then you must not trust very many games. Almost no classic 2D games have perfect detection.
I don't require pixel perfect collision detection. I generally only require consistent collision detection. And many games have that. Sure, they very occasionally might glitch (see Super Mario Brothers), but by and large you know what will happen and when.

A grid system can't do easily this, because it's detected collisions change based on completely arbitrary factors.

You've mentioned Pacman here and it is one of the few games that truly use a grid system well. It works so well because its map is highly structured and movement is restricted. This means that a checks can be done using a grid and still be fairly accurate. It's also a game where the player does not have weapons which further limits the amount of 'perceived weirdness'.

Again, I'm not saying a grid based system definitely is a bad idea or that it can't work. I'm merely trying to point out that it has pros and cons and that both of these are relevant, not just the pros. Note that this goes for all types of collision detection, not just grid systems.

Last edited by roondar; 14 August 2019 at 13:14. Reason: Shortened my wall of text a bit.
roondar is offline  
 
Page generated in 0.04356 seconds with 11 queries