How did nes and old PC games handle collisions and keeping objects outside of each other's hit box?
Nowadays they just use boilerplate physics engines

>>11864802 (OP)
They programmed them idk

Each object had at least two pixels on each of its four sides. So for example, if you're moving left, you check if the left-bottom and left-top pixels are going to overlap some bounding box. If so, figure out how far into the box you are overlapping, and cut your velocity vector down to size so that the object sits flush against the bounding box.

>>11864802 (OP)
if (abs(obj1.x - obj2.x) < [some number] && abs(obj1.y - obj2.y) < [some other number]) {
collision = true;
}

Just do that in assembly

>>11864814
This is closer to my approach in unity while automatically refusing to use rigid bodies
>>11864825
This is also quite elegant , I like it a lot

>>11864829
>automatically
Autisticaly

>>11864834
Nothing autistic about it, the default Box2D physics in Unity is dogshit for making most 2D games, and you're expected to roll your own physics if you want more precision. Though these days they also have a new feature called Rigidbody2D.Slide that does all that for you.

>>11864825
There's a faster way to check rectangle overlaps given the upper right and lower left corner of each rectangle. This should be a specific result of https://en.m.wikipedia.org/wiki/Hyperplane_separation_theorem
Basically OP you gotta know your euclidean geometry

Fuck off, frog posting retard.

>>11864881
Cool, something to chew on. I'll try to work through some examples on paper tomorrow
>>11864885
*Shrugs"

>>11864802 (OP)
standard aabb collision function, but if you have a lot of objects on screen at once it can get particularly cpu intensive
in my homebrew game i just check at 30fps, even frames check collisions between player hurtbox and enemy hitboxes, odd frames check collisions between player hitbox and enemy hurtboxes
but checking collisions between every single object on screen is O(n^2) so a lot of old games with busy scenes do what doom does, really great video on it:
https://www.youtube.com/watch?v=-IYz6-KnvWU&t

@11864885
mental illness
https://desuarchive.org/_/search/text/Fuck%20off%2C%20frog%20posting%20retard/

>>11864936
This seems like a good explanation of it, alongside how to implement. They also go into more detail of what happens with rotatated rectangles:
https://code.tutsplus.com/collision-detection-using-the-separating-axis-theorem--gamedev-169t

The basic idea is that the only way for two (non rotated) rectangles in the plane to intersect is if their projections to the x axis overlaps and their projections to y axis overlaps.

>>11864802 (OP)
are you dumb? they did it the same way a physics engine does it. This is very basic game programming

>>11865020
Post game

>>11865023
go back to middle school and learn about vectors

>>11864802 (OP)
The coordinates of your character are stored as a sub-pixel value, and calculated this way.

Only when the graphic routines come to parse the coordinates and draw them to screen do they get turned into integers so that they can be assign an actual pixel value on screen.

>>11864802 (OP)
>store object coordinates
>add a routine that says
>>check an area X pixels wide and Y pixels tall around object"
>>if another object is in within said area go to collision routine
>>if not bail out
>repeat the process every frame

In what way? If you look at 2D games enemies have a hit box that can hurt the player, but both the enemy and player can frequently pass through one another. They often don't have hard collision with one another unlike the player and the level itself. Sometimes they'd not only have a hit box, but something the player collides into and cannot pass through with certain enemies or bosses so you can't just damage boost through something. There's a lot of complexity with the design of the player and enemies in 2D games that probably isn't mentioned much. It'd be interesting to see how it evolved in games.

at least on the atari you could do a sort of hardware level check for overlapped pixels, but generally 2d games have always just used aabb which is practically free anyways

The MSX, Sg-1000 and all its offshoots up to the game gear had pixel perfect collision in the TMS9918 hardware but it was a memory hog so most games just used hitboxes. One of the games notable for using the hardware collision was the shitty Alf game. Interestingly it was found that the Mega Drive for some reason treats the SMS left border as a sprite, which can cause glitches in backwards compatibility mode.

>>11864804
This.
I have never had a Ouija board in my house, and I NEVER WILL. There are just some things you should never mess with.

>>11864802 (OP)
Doom and Mario 64's complete source code is out there, fully documented, and there are multiple youtube videos that explain exactly how collision works explaining all the code.

I think the GTA3 era games have pretty well documented collision too if you want something a little bit later and more complicated.

>>11864802 (OP)
The way they were programmed to do it. Because everyone wasn't just using a handful of "boilerplate physics engines" there were many different ways. I'm sure some retarded people even used some of the retarded """solutions""" provided ITT. There was no shortage of low skill homebrewers on the PC.

>>11866323
>I'm sure some retarded people even used some of the retarded """solutions""" provided ITT
The actual method developers used (aabb) has already been posted several times itt

>>11864829
>elegant
>just hardcode a bunch of ifs and loop for every existing object bro
Lol, lmao even.

>>11866659
>The actual method developers used (aabb)
This is some peak Dunning-Kruger. There were literally dozens of different methods devs used back in the day.

>>11864802 (OP)
>How did nes and old PC games handle collisions and keeping objects outside of each other's hit box?
A loop and xy or xyz cordinates it depends what era you mean, More modern games are main basic betor math and matrix multiplication

Heres a listing of old basic gaes for you to glance at.
https://ia801302.us.archive.org/21/items/sixty-programs-for-the-sinclair-zx-spectrum/sixty-programs-for-the-sinclair-zx-spectrum.pdf

Try porting one to python and then C if you want to learn. This is what 9/10/11/12/13/14 year old kids were doing in 1982 on commodores, ataris, spectrums, TRS80s etc typing in all that stuff and debugging it to make a game run. A lot fo the wqent on to write the games you have known and loved

>>11866659
>tards have posted several times itt
Indeed

>>11866868
Fair, I should've said "a" instead of "the". My point is though it's a common and easy way to check rectangle collision that was used at the time. SMB uses it to see if you hit an enemy/hammer/etc (with some extra checks for vertical wrapping): https://gist.github.com/1wErt3r/4048722

>>11866862
Obviously there's some steps involved in deciding /which/ objects to check collisions for, but in the original Zelda this is in fact how they do it: https://github.com/aldonunez/zelda1-disassembly/blob/master/src/Z_01.asm

>>11867038
Post cock

If Mario = hit
Men - 1
ez

For Street Fighter 2 you had three rectangles that determined where your character could be hit (for head, torso and legs), one rectangle that determined where you are attacking (if it overlaps the opponent's previously mentioned rectangles, that counts as a hit) and one rectangle that determines the "solid" part of the character that makes them push against each other. These would all change shape and position depending on your current action.

>>11865172
>no game

>>11867285

the Atari 2600 does pixel perfect hardware collision between all pairs of objects, including the playfield. with 5 objects plus playfield that's 15 pairs, and sure enough the CX registers have a total of 15 bits. it's one of the few nice things with it
most of the time games just use bounding boxes anyway, as other anons have said

Pretty much every system with hardware sprites could trigger interrupts on collision.