• Most people probably don't realise this, but this forum has had two editors for a number of years. One is the xenForo default editor, and the other is a custom editor I made years back I called BBCEd.

    All the settings for which editor you use was lost during the upgrade. You can find the setting under Account Settings > Preferences > Editor.


Profile posts Postings Media Albums About

  • [COLOR=DarkGreen]Alright, so you mentioned how Assembly gets you all excited, so I was wondering if I could get your help on something...
    Though, it's SMW-specific stuff, so as to not confuse it with Cave Story.
    [Quote=Code]LDA #$10
    STA $AA,x
    STA $157C,x
    CMP #$00
    LDA $B6
    CMP #$E0
    STA $B6,x
    LDA $B6
    CMP #$1F
    STA $B6,x
    The first 5 lines simply call a function elsewhere that check Luigi's direction, and then stores the direction in the sprite, so it's always facing him.
    Since the direction is still in A, CMP compares which direction the sprite's facing and then either jumps to the code that handles the right direction or simply continues for the left. {Jumping later over the Right's code}
    The direction code should simply INC or DEC the sprite's current speed, depending on the direction it's facing. If the sprite reaches max speed, it'll just jump to the end of the code and not mess with it for that frame.
    With the way INC and DEC work in SMW {If it doesn't work the same elsewhere}, DECing a value of 00 leads it to FF, and INCing a FF makes it into a 00. A speed between 01-7F[/COLOR][COLOR=DarkGreen] moves them right, a speed between FF-80[/COLOR][COLOR=DarkGreen] moves them left. So I [I]think [/I]this INC and DEC system should work.
    The sprite [I]should [/I]speed up towards Luigi, and if it passes him, it will turn around, slow down it's current directional speed, and then speed up back towards Luigi.
    The problem is, the sprite doesn't want to move, period.
    It just sits there, leering at me, turning to keep me in it's sights.
    The code assembled correctly, but I guess I screwed up somewhere. I'm still not use to thinking in Assembly...

    Anyways, I was wondering if you could see what's wrong with this...
    This little part basically makes up 90% of the sprite, as I'll use something very similar to control it's Y speed, so it's [I]really important[/I] that I get this part working...
    And the max speed values probably aren't final. I'm not sure if E0 will be the same as 1F or have it zipping across the screen...
    Though, I'm sure I probably confused you with my comments....

    {Oh, and can you guess what this sprite should be? :D;}
    oh my gawd, those are beautiful.
    I don't need a transition frame per se, but if you think it would make my mod more splendiferous, go ahead.
    Thanks so much noxid, you da man.
    Most important thing first, you can keep playing Metroid (it's a girl!) until whenever.
    it's just a purple thing that stands there. Awesome, I know. You can make the image as large as u want to fit the spikes, basically it just stands their until you shoot it, then it goes all prickly and defensive. your choice what kind of spikes to use.

    And as a weird side note, could you give the behemoth ram horns?
    And as for the gig, I need to find a file uploader that can upload a midgetbyte first. :(
    1&2) Sweetzies[color=red]*[/color]
    1+2) - If you can balance a gigabyte of cave story related stuff on your head, kudos to you. I don't think I could. :(
    22?) - It's not tutu hard, I just stink at dresses.

    [color=red]*[/color]basically, [URL="http://img229.imageshack.us/img229/4207/80534969.png"]here's[/URL] what I wish for you to draw, but angrywithspikes.

    thanks a mayan, I can giveth you that gig of stuff if you want, but you need some serious sorting powers if you ever want to find anything.
    - lacy
    2 Qs;
    first, you're awesome at pixel art, right?
    second, could you do an ikkle bit of dat for me?
    nonsensical third question: if I sent you a gig and a bit of asm notes, mods, plots, etcetera, would you do something interesting with it?

    also, your mod HARD.
    I beat the first part that is all green, and then their was a second part I got halvzies thru and died. :(
    I never really got why that cavern was their tho...

    A rain of blood.

    "Each day, we will spill their blood till it rains down from the skies."

    I Think I might have killed the world.
    But anyway, I'm better off alone.

    A rain of blood.

    I Think I might have killed the world.
    But anyway, I'm better off alone

    I'm better off alone...

    "Each day, we will spill their blood till it rains down from the skies."
    [QUOTE=Noxid]The C7 is the MOV command[/QUOTE]
    [COLOR=DarkGreen]Oh, duh, now I feel silly.
    I don't know why I decided to ignore the commands in hex. {I blame lack of sleep}
    [/COLOR][quote=Noxid]and the next BYTE seems to be the type of MOV command we're dealing with, then either the next BYTE or DWORD is for how far off the register to go, and the last DWORD is the actual value being MOV'ed[/quote]
    [COLOR=DarkGreen] This is so much more confusing using something like Translhextion....
    But I see what you mean with Olly.
    [COLOR=DarkGreen]Not really sure about that...
    Assuming 40F9D5 simply becomes x0F9D5 for Translhextion, the numbers that came up look [I]nothing [/I]like that.
    Not sure if that's how the offsets change between the two, though. Just a guess, but the numbers seem to be in a pattern, like they should be for frame rects.
    Each offset {[/COLOR][COLOR=DarkGreen]Well, I tried almost a dozen}[/COLOR][COLOR=DarkGreen] always started me at a C7 , too, so it doesn't seem like I'm randomly jumping around.
    [QUOTE="Noxid"]Rects are somewhat difficult to visualise, but think of them as defining four infinitely extending lines; the line display_L draws a vertical line (for the left side) and everything to the left of that line is disregarded. display_U draws a horizontal line, and everything above is disregarded. Continue this logic with the other two and what you're left with is a rectangular area.[/QUOTE]
    [COLOR=DarkGreen]That's just about [I]exactly [/I]how I imagined them...[/COLOR]
    [QUOTE="Noxid"]As for what you've mentioned, after a bit of searching I found it in one of rune's old tutorials. The proper order is, in fact, LURD, and I'm not sure why he put them in LRUD order (possibly to group them by x/y, I dunno). Everywhere else in the compendium where it lists the actual offsets of these rects they're properly ordered as far as I can see.[/QUOTE]
    [COLOR=DarkGreen]Just my luck to see [I]only [/I]that set, eh.
    {Really, I was being lazy/rushing and just used Find until I came across it}
    [/COLOR][QUOTE="Noxid"]Finally, when you're dealing with rects and such in the .exe, remember that all the numbers are hex; hence, 16 = 10, 32 = 20 and so forth.[/QUOTE]
    [COLOR=DarkGreen]Oh, I know. I just listed them in that way because it's how Rune had all of the title screen rects listed.

    Anyways, thanks for clearing that up for me.
    [COLOR=DarkGreen]OK, this probably isn't a biggy, but it had me pulling hairs for awhile...
    I was trying to figure out how Frame Rects work, and I saw something listed in your Assembly Compendium.
    Specifically, it says the four numbers should be in this format:
    [quote][COLOR=Black]Display_L: left side of the display rect
    Display_R: right side of the display rect (NOT width)
    Display_U: top side of the display rect
    Display_D: bottom side of the display rect (NOT height)[/COLOR][/quote]Well, I spent an hour or two trying to figure out why the game would keep displaying nothing, when I noticed that the other frame rects in the code didn't follow that rule. So I tried something else.
    To display the left standing animation of Quote, it should be 000 016 000 016, right? {Left Right Top Bottom}
    That got me blank, so I tried 000 000 016 016. {Left Top Right Bottom} It displayed perfectly.
    I even tried 0000 0064 0016 0080 to display an animation that I added to an enlarged version of the MyChar.PBM, and it worked. {According to the Compendium, it should've been 0000 0016 0064 0080}

    I'm thinking the list wasn't suppose to be taken in that order, but I didn't see anything else in the little article that told how the EXE accepted them.
    Unless, do the Rects go in an order akin to the game's directions? {I just now literally noticed that}
    I mean, in the TSC.txt the directions are listed as:
    0000 Left
    0001 Up
    0002 Right
    0003 Down

    I'm rather confused at the moment....
  • Loading…
  • Loading…
  • Loading…
  • Loading…