Jump to content

Mord

Members
  • Posts

    3,025
  • Joined

  • Last visited

  • Days Won

    2

Mord last won the day on March 7 2010

Mord had the most liked content!

1 Follower

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Canada
  • Interests
    Video games, programming, manga, anime, heavy metal, sonata arctica, blind guardian, assemblage 23, Vocaloid, 7800

Recent Profile Visitors

39,646 profile views

Mord's Achievements

River Patroller

River Patroller (8/9)

1.2k

Reputation

  1. If it's just a matter of letting the player get closer to the right side of the screen than it currently allows, just increase the value from 145 to something higher. 152 might work - just take the width of the sprite and subtract it from 160 to find out what value you need. If it's not quite where you want it to be try adjusting it by 1 until you get to the place you want it to be.
  2. The problem is that herox<1 only does something when herox = 0. If you go below 0, it wraps around to 255, and suddenly herox>145 triggers which teleports you across the screen. update the first line to be: if herox=0 || herox>240 then herox=1 This'll catch any instance where you've accidentally wrapped around the 0 by moving too fast. It won't affect second line of code since if you're 240 or higher, it'll get fixed to 1 before it sees the right-side check.
  3. Did you have herox set up as a fixed point variable? In the older code I was looking at, it wasn't. In the Slow the Player section, that would probably be interpreted as herox-0 instead of herox-0.8. Additionally, and probably the main issue, the check on the very top would cause the joystick to be ignored when you would be trying to wrap around I believe....
  4. Also, keep in mind if you do make the platforms more solid like this, you'll have to revisit your level designs to make sure they're still doable. There's at least one that can't be solved with solid platforms due to needing to jump from a smaller platform that's directly below a larger one. No way to clear the jump.
  5. You'll need a bit more than that it seems. I had to add the below to get a more solid block, although it's not perfect still. Formatting looks bad due to me using a different tab size (looks good on my notepad honest. :p) But yeah, essentially you would have to do directional checks wherever you're actually about to try to move the player. main restorescreen frame=frame+1 if (frame&7)=0 then walkframe=(walkframe+1)&1 if (frame&1) then goto joydone ; Mord Edit ; ; rem ** convert sprite coordinates to character coordinates... mytemp1=(herox+4)/8 ; rem 8 is 160A character width, but x2 for doublewide if joy0left then mytemp1=(herox-4)/8 ; rem 8 is 160A character width, but x2 for doublewide if joy0right then mytemp1=(herox+12)/8 ; rem 8 is 160A character width, but x2 for doublewide mytemp2=heroy+8 mytemp2=mytemp2/16 mytemp2=mytemp2 ; rem the block under our feet herochar2 = peekchar(screendata,mytemp1,mytemp2,20,12) ; skip horizontal movement due to obstruction. if herochar2=4 then goto joydone if joy0left && !joy0fire0 then herodir=0:herox=herox-1:goto joydone if joy0right && !joy0fire0 then herodir=2:herox=herox+1:goto joydone if joy0left && !joy0fire0 && gravity=0 then herodir=0:herox=herox-1:goto joydone if joy0right && !joy0fire0 && gravity=0 then herodir=2:herox=herox+1:goto joydone rem make the character run if joy0left && joy0fire0 then herodir=0:herox=herox-2:goto joydone if joy0right && joy0fire0 then herodir=2:herox=herox+2:goto joydone if joy0left && joy0fire0 && gravity=0 then herodir=0:herox=herox-2:goto joydone if joy0right && joy0fire0 && gravity=0 then herodir=2:herox=herox+2:goto joydone walkframe=0 : rem make our hero stand tall when he's not walking
  6. No, that won't represent where the player is. You'll need to define a couple more variables and store each location separately, sorta like below, and only use whichever ones you need at any given time based on the player's situation (is he moving left or right, or falling, etc). Also changed the rem comment to be accurate. In the X direction you aren't dealing with height. mytemp1=(herox-4)/8 ; rem 8 is our tile width. herocharLeft=peekchar(screendata,mytemp1,mytemp2,20,12) mytemp1=(herox+12)/8 ; rem 8 is our tile width. herocharRight=peekchar(screendata,mytemp1,mytemp2,20,12)
  7. rem ** convert sprite coordinates to character coordinates... mytemp1=(herox+4)/8 ; rem 16 is our zoneheight mytemp2=heroy/16 ; rem 8 is 160A character width, but x2 for doublewide These are the lines in your code that are specifying where your current test point is, for under the sprite. From the looks of it, it's checking the middle of your sprite (herox+4). To see the left side of your sprite, you'd have to use something like (herox-4) instead - this will place the test position just to the left of your sprite. To get to the right of your sprite, you'd want (herox+12) - just enough to get exactly 1 tile to the right of your sprite, again testing in the middle of that tile. In these cases, where you're only testing to the direct left or right of your sprite, you won't need to do that extra line after that, which would place the test point down one. mytemp2=mytemp2+1 ; rem the block under our feet
  8. It's a bit hard to explain in code when I don't entirely follow how the code is working - and just giving a generic example might be more difficult if it doesn't work with your existing code. However for #2 I was able to make the platforms more solid from below with a couple edits. rem ** ... then make sure we don't try to read/write rem ** off-screen memory... if mytemp1>19 || mytemp2>11 then goto falling rem ** ...then read the character! herochar=peekchar(screendata,mytemp1,mytemp2,20,12) ; MORD EDIT ; ; for the location ABOVE the player. mytemp2 = mytemp2-1 herochar2 = peekchar(screendata,mytemp1,mytemp2,20,12) mytemp2 = mytemp2+1 and if _Jump_Gravity_Counter<=7 then antigravity=5 if _Jump_Gravity_Counter>7 && _Jump_Gravity_Counter<=10 then antigravity=3 if _Jump_Gravity_Counter>10 then antigravity=1 ; MORD EDIT ; ; The quick test for for bumping into a platform from below. if herochar2=2 || herochar2=4 then _Jump_Gravity_Counter=0 : _Fall_in_Progress=1 : goto __Skip_Jump heroy=heroy-antigravity __Skip_Jump These two edits were done on a previous version than the absolutely latest code you posted. I included snippets of your code around my edits to give an idea of where they would go. I defined "herochar2" variable so I could do the extra test without reusing existing variables. Trying to add in the Y coordinate zeroing in #3 is more problematic since I'm probably missing how you're doing the jumps and platform detections entirely. When I try to do the zeroing it ended up having the side effect of causing the player to jump between half to the full height of the screen. Wasn't expecting a gravity boots jump from Symphony of the Night to be so easily coded! Either way to make the platforms more solid it'll all be about deciding where you want to test for your peekchar. For instance to make the sides of the platform feel more solid you'll want to test a couple of points on the sides of your character instead of in the middle of the sprite. You would only need to test those side points when you're actively moving in those directions however.
  9. From playing the rom a bit here's some observations and advice: 1. Even at maximum jump the player will barely make it to another platform. You might want to consider adding a little more height to the jump so it's easier to get to a platform. 2. The collision detection only seems to matter when falling since you're only checking for a position under the player. If you want the platforms entirely solid (no jumping up through them) then when the player is rising up in a jump you should be testing a second location instead that's directly above the player. If a collision is detected you immediately change to falling and start testing for the initial lower position again. 3. When the player detects landing on a platform, to avoid stopping in the middle of a platform you can also do a quick fix on the Y coordinate to zero out the bottom 3 or 4 bits (depending on if you're using 16-line zones (4) or 8 line zones (3). This should ensure the player is auto-fixed to the top of the tile. I'd probably only recommend doing this when falling. It might cause you to pop up through a platform if you do this zeroing during the rising detection recommendation in #2.
  10. With regarding the collisions, it often helps to have additional test points added for different parts of the sprite. Testing every part of course is not possible, but having a few key points near particular parts of the sprite are very useful. For instance having a point nearer the top of the sprite, or even right above the sprite, would make the platforms more solid and prevent you from jumping up through them. Having them near the sides do similarly for horizontal collisions.
  11. Not seeing an answer about the compiling issue, so going to assume it wasn't debugged yet? The problem is being caused in the complex if/then statements you have in I believe 7 places in the code that are mixing && and || conditions. As per the 7800 guide, you can have multiple &&'s or a single || in an if/then statement, but you can't mix them together. I made the below changes to each of the lines and it would at least compile. (Not sure if it's doing the right thing mind you - you may need to add goto after the first if so it'll skip over the second one in cases where both would trigger to effectively simulate an ||. To find all the places quickly, just do a search/find on "||" so you can check all the places you're using an or statement. ; if sc1>=75 && sc2>=00 && sc3>=00 || Menu_Option=$04 && Menu_Option=$03 then goto ___skip_speed_increase if sc1>=75 && sc2>=00 && sc3>=00 then goto ___skip_speed_increase if Menu_Option=$04 && Menu_Option=$03 then goto ___skip_speed_increase
  12. I've had the steamdeck+dock for about a year now. Works mostly fine for me, although probably only 1/5th of my library is Verified. Then again I usually use it docked to play Minecraft since my home comp isn't strong enough to run it anymore. I haven't noticed battery issues yet, but as I said I use it docked most of the time. Biggest irritation for me is that occasionally while docked the Steamdeck suddenly forgets it has a keyboard/mouse plugged in. Not helpful when you're surrounded by a field of sculk sensors, shriekers, and wardens... I can usually fix that by unplugging the deck from the dock for about 5-8 seconds then plugging it back in. It's a bit flaky in how often that happens. I can game all day long sometimes without issue, then it'll happen 2-3 times in a row on another day. Overall still satisfied with the deck. There are certainly things that it could do better, but honestly it's outperformed my expectations going in. I'll probably end up skipping the oled upgrade but I'll keep an eye open for the next gen.
  13. Except they were going to try for retroactively applying it. Remember, if someone reinstalled a game they already bought, they fee would have been applied to the dev. Every time. ie: Retroactively applied. And nobody seemed to consider what that would have meant for game devs that were still around (or maybe not.) but no longer selling particular/any games. They would have started getting bills. But regardless of that, what would you have expected devs to do? Destroy their means of income by pulling all their games and then praying nobody would install it going forward? They may be trying to act like the good guys here with their half step walk back but keep in mind what it really means -everyone will eventually be using the newer version of Unity that gets the install fee added (or flat rate revenue share.) 1. Unity will just stop supporting the older versions. Once they do, any bugs/exploits/etc still in the code will never get patched - would you as a developer want to take a risk releasing a game on that version knowing it could come back to haunt you? 2. Software companies have gotten very aggressive, to the point of deceptive at times, to force you to upgrade. And they generally prevent rollbacks. Click the wrong button placed in a different location one day on your daily nag screen and you've suddenly agreed to upgrade to the new version. And they'll never accept putting you back to the older versions with a "Sorry we can't do that." (Consider how bullheaded and tricky Microsoft was with trying to get people to upgrade to Windows 10 for years, switching around windows, removing decline buttons, etc. I've been seeing other software products doing those kinds of things as well these days.) He may be gone, but the board members that approved his plan are still there. At this point he's just the fall guy. Personally I'm still never going to consider using Unity in the future - we now know what they're capable of so why take the risk.
  14. So they'd be golden to just turn around and say "All developers now owe us 1 million dollars per year per game they've released. Retroactively." There are things that you can do. There are things you should never do. Unity did the initial pitch of the insane charges for 2 reasons. 1. Hope that nobody complains - at which point those extreme, abusable terms would be kept. 2. Soften the blow when they "Change their mind based on feedback" to something that they were hoping for, allowing them to be looked at like a saint that cares. For a lot of devs though, the trust is lost. I'd expect to see far less Unity games released going forward. You won't see this right away, as there are games part way through development that can't be restarted at this point. But as those dry up, expect people to be using other engines going forward. I've toyed with the idea of learning Unity here and there but never really had time to look into it. Now however, I won't look into it even if Unity gave me a personal waver of all fees ever. They've already proved they're willing to change TOS retroactively after all, so why would I trust them on anything? And if Unity -doesn't- fall into obscurity over this BS expect every other game maker engine to start charging the exact same pricing model.
  15. Mord

    Never mind...

    It's never too late to ignore a thread. I brought the chips and dip. We can all kick back and ignore this thing all day.
×
×
  • Create New...