Ah jeeze, I've been called out.
I was following this thread to see what you guys came up with so I wouldn't have to work as hard if I ever wanted to make slopes again.
In my project I was working on I didn't have to turn gravity off or anything. You could jump off slopes and I even had objects bouncing and rolling off slopes though that was still pretty janky. It was all very complicated. My player did still flip between running and falling animations too. I figured it was because his horizontal movement was faster than gravity was pulling him to the slope. So it was like he was skipping steps going downhill and I was fine with that.
I did all the slope stuff in 4.1.5 and it spanned across a bunch of different scripts so it would be hard to compile and show what I did. It got pretty messy I think. I also haven't spent a lot of time learning how 4.5.9's tile collisions differ from the old one, but I'll see if I can explain some of the stuff I did.
First, the references that got me pointed in the right direction.
info.sonicretro.org
I modified the collisions routine to include a point at the center bottom of every object. When an object was colliding with a solid floor tile the collision routine would eject the object up to the top of that tile. My tile script was just
lda #%01011000 ;say it's on this kind of angle
sta tile_solidity
but in the eject routine I made a "special eject"
lda temp2 ;check if bottom center collided with special tile (tile_solidity of tile colliding with bottom center point is in temp 2 at this point)
and #%00001000 ;could use #%00001000 to indicate whether to use a special eject table and the top four bits 00 to f0 to determine which table to use
bne SpecialEject
SpecialEject:
;get the special eject table pointer, store it to Y register
lda temp2 ;(Still tile_solidity)
and #%01110000
sta temp
++
lda Object_x_hi,x ;xHold_hi
clc
adc mtemp3 ;horizontal center of object
and #%00001111
ora temp
tay
;look up the special eject point for this pixel from the tables
;compare y location and eject point to see if you need to eject (So if you are just falling into that tile you don't immediately pop to standing on the slope)
lda tileY
and #%00001111
sta temp1
cmp Special_Tile_Eject_Tables,y
bcs DoSpecialEject
DontSpecialEject:;(or eject at all)
rts
My table looked like this.
Special_Tile_Eject_Tables:;7 possible types numbered from #$00 to #$70
;00 _iii_ #%0000 1000
.db #$08, #$08, #$08, #$08, #$08, #$08, #$08, #$08, #$08, #$08, #$08, #$08, #$08, #$08, #$08, #$08
;10 _0o_ #%0001 1000
.db #$00, #$01, #$02, #$03, #$04, #$05, #$05, #$07, #$08, #$09, #$0a, #$0b, #$0c, #$0d, #$0d, #$0d
;20 _0i_ #%0010 1000
.db #$00, #$00, #$01, #$01, #$02, #$02, #$03, #$03, #$04, #$04, #$05, #$05, #$05, #$07, #$07, #$07
;30 _io_ #$0011 1000
.db #$08, #$08, #$09, #$09, #$0a, #$0a, #$0a, #$0b, #$0b, #$0b, #$0c, #$0c, #$0d, #$0d, #$0d, #$0d
;40 _iii_ ;not really in use yet but need something to take up the space
.db #$08, #$08, #$08, #$08, #$08, #$08, #$08, #$08, #$08, #$08, #$08, #$08, #$08, #$08, #$08, #$08
;50 _o0_ #%0101 1000
.db #$0f, #$0e, #$0d, #$0c, #$0b, #$0a, #$09, #$08, #$07, #$05, #$05, #$04, #$03, #$02, #$01, #$00
;60 _i0_ #%0110 1000
.db #$08, #$07, #$07, #$05, #$05, #$05, #$04, #$04, #$03, #$03, #$02, #$02, #$01, #$01, #$00, #$00
;70 _oi_ #%0111 1000
.db #$0f, #$0f, #$0e, #$0e, #$0d, #$0c, #$0b, #$0b, #$0b, #$0a, #$0a, #$0a, #$09, #$09, #$08, #$08
So for example in the image, the tile solidity was #%01011000, and the center point I marked with a yellow pixel is #$01 pixels in, that means, according to the table that instead of ejecting to the top of that tile, it ejects #$0f down from that.
In that code base there was also a bit to flip if your object was supposed to be on the ground, so that was flipped when the object was ejected onto a slope.
There were obviously drawbacks to all my changes. I think I ended up having to make more collision points below the object bounding boxes adding up to maybe 7 points. All of those checks slowed things down even more when a few objects were onscreen. I had to add more checks and conditions if my player was ascending a slope and bumped into a wall or ceiling forcing him to duck. (that's why the table above skips #$06, that's where he got stuck). Also, I don't remember exactly why, but you always had to have a solid or jump through tile below every slope tile for things to work right. I think for just a pixel you have to go into a blank tile so one foot had to be standing on a solid jump through tile or else the object would bounce or something. Because of those solid tiles next to/below all of the slope tiles that means the bottom corners of the object's bounding box would always be colliding with a solid, so you have to tell it to ignore that but the top corners still need to check for solids or else you'll run yourself inside a wall if the slope goes right up to it.
That's kind of how it always works though, isn't it. You get the big idea mostly working and then spend a lot of time patching up all the little things so everything works just the way you want it. Or design around the limitations you've made for yourself.
Anyway, I hope this gives you guys some ideas. I don't know how much modification would have to be done to get something like this working in 4.9.5. I know the tile_solidity variable isn't even used, at least not with that name. Good luck!