Forum Rules ---- Game FAQ ---- Forum Search ---- Limit Theory Website

Return to “Dev Logs”

Display posts from previous
Sort by
Post

Re: Sunday, February 12, 2017

  • Sun Feb 19, 2017 5:16 pm
    • #62 by erf
    It is very interesting to hear about your progress, benchmarking and your endeavour into various programminng languages, compilers etc. but i'm just curious if you tried everything when it comes to algorithms, data structures, parallelizing, instancing etc. Moving more stuff to the graphics API ( Vulkan ? ). Or if its not possible to scale down certain aspects of LT, before spending time on extreme performance optimizations as you seem to be doing now?

    * i have not been following the threads lately, so i'm sorry in advance if this has already been discussed
    Post

    Re: Sunday, February 12, 2017

  • Tue Feb 21, 2017 1:41 am
    • #65 by LindseyReid
    JoshParnell wrote:
    Detritus wrote:
    JoshParnell wrote:55 89 e5
    Hrrm... :think:
    JoshParnell wrote:b8 39 05 00 00 5d c3
    Hrrm... :think:
    See below..
    ruok wrote:1337 post indeed Josh :geek:
    :clap: :clap: :clap:

    Hahaha somebody got it woohoo!!! :D Great first post, welcome to the forums ruok :thumbup:

    (More responses on the way, but for now, this ^ . I just woke up. Yayy Monday :squirrel: )
    Josh seems to be taking his time, so I'll post my best guess.

    I immediately recognized it as disassembled x84 assembly, which I have little to no experience with :P I first tried using a table to lookup each instruction's assembly representations, but after translating the first one, got really impatient and just ran it through a disassembler instead, lol:

    55 89 e5
    push ebp
    mov ebp,esp

    b8 39 05 00 00 5d c3
    mov eax,0x539
    pop ebp
    ret

    Which I'm pretty sure are basic instructions at the beginning and end of every function to push memory onto the stack to make room for the function, and then de-allocate that space and return once the function is done.

    So that's just his super nerdy way of saying "begin post" and "end post".

    1337 indeed.
    Ship Inspiration Pinterest!! (send me stuff)

    "You’ve got to work on something dangerous. You have to work on something that makes you uncertain. Something that makes you doubt yourself... because it stimulates you to do things you haven’t done before. The whole thing is if you know where you’re going, you’ve gone, as the poet says. And that’s death."
    - Stephen Sondheim
    Post

    Re: Sunday, February 12, 2017

  • Tue Feb 21, 2017 6:57 am
    • #67 by charnode
    HappyGhecko wrote:Hah, it still pays off to visit this forum now and then. :ghost:

    also
    Grumblesaur wrote:Wasn't X Rebirth a truckload of awful on release anyway?
    it still is.
    The only game ever that I actively removed from my Steam games list for good. That's how much of a trainwreck it was. Colossal failure.
    You cannot not communicate.
    Paul Watzlawick - 1st Axiom
    Post

    Re: Sunday, February 12, 2017

  • Tue Feb 21, 2017 1:49 pm
    • #68 by Plofre
    AlexWasLike wrote: ....
    Josh seems to be taking his time, so I'll post my best guess.

    I immediately recognized it as disassembled x84 assembly, which I have little to no experience with :P I first tried using a table to lookup each instruction's assembly representations, but after translating the first one, got really impatient and just ran it through a disassembler instead, lol:

    55 89 e5
    push ebp
    mov ebp,esp

    b8 39 05 00 00 5d c3
    mov eax,0x539
    pop ebp
    ret

    Which I'm pretty sure are basic instructions at the beginning and end of every function to push memory onto the stack to make room for the function, and then de-allocate that space and return once the function is done.

    So that's just his super nerdy way of saying "begin post" and "end post".

    1337 indeed.
    Nice one, tried the same and gave up.
    Looking at the code it actually sets up a standard stack frame for the function's local variables, then at the end loads 0x539 into eax, which represents the return value of the function.

    Now, 0x539 is 1337 decimal.

    1337 confirmed :)

    PS: really psyched for Josh's next post on what happened last week. I really like the new techie posts, been hacking around with LEXX/BISON and YACC in the old days to implement a script language.
    Josh, if you are going for performance, that is the way to go, you can generate really fast, low-down c parser code from a nice grammar file. Leastways that's what was the way to go about 20 years ago ;) , no idea what hot and cooking today.

    Fly safe, commanders
    Post

    Re: Sunday, February 12, 2017

  • Tue Feb 21, 2017 3:32 pm
    • #69 by LindseyReid
    Plofre wrote: Nice one, tried the same and gave up.
    Looking at the code it actually sets up a standard stack frame for the function's local variables, then at the end loads 0x539 into eax, which represents the return value of the function.
    Fly safe, commanders
    Yes, that's what I said, so we are in violent agreement :)
    Ship Inspiration Pinterest!! (send me stuff)

    "You’ve got to work on something dangerous. You have to work on something that makes you uncertain. Something that makes you doubt yourself... because it stimulates you to do things you haven’t done before. The whole thing is if you know where you’re going, you’ve gone, as the poet says. And that’s death."
    - Stephen Sondheim
    Post

    Re: Sunday, February 12, 2017

  • Wed Feb 22, 2017 9:53 am
    • #71 by JoshParnell
    Grats to femnode for the correct explanation :clap:

    Code: Select all

    /* My post is the function: */
void devlog (void) { return 1337; }
    Though frankly only two lines were necessary for such a simple function (that uses no stack space):

    Code: Select all

    mov eax, 1337
ret
    I included the prototypical x86-32 prologue and epilogue anyway as hints to those who might google the hex strings. Those hex sequences are so common in 32-bit disassemblies that googling them would actually clue you in to what it all means :)

    Also
    AlexWasLike wrote:... got really impatient and just ran it through a disassembler instead ...
    It's the same online assembler/disassembler that I use to check the correctness of my emitted machine code. This site is awesome, bookmark it if you work with reversing or are just interested in asm :squirrel:

    Maybe more asm / machine code puzzles in future logs...
    “Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
    Post

    Re: Sunday, February 12, 2017

  • Wed Feb 22, 2017 10:06 pm
    • #72 by Flatfingers
    First I tested if it was ASCII. Nope.

    Then I tried EBCDIC. Also nope. (Well, you never know.)

    Then I looked up 80x86 op codes, but I couldn't find 0x55 in any of the references I had at hand. It's been too long since I wrote TSRs, obviously.

    Then I looked up 68x0x op codes, but no 0x55 there, either. (Again, you never know.)

    Then I decided that you can't fix stupid, and went and did something else less embarrassing.

    Nice that I was on the right track at one point, though -- grats to those who clevered it out proper-like!
    Post Reply

    Return to “Dev Logs”

    Online Now

    Users browsing this forum: Baidu [Spider] and 1 guest

    cron