Occasional lurker, decided to join.

Discussion in 'Introductions' started by Natorite, Mar 31, 2017.

  1. Natorite
    OP

    Natorite Newbie

    Newcomer
    4
    1
    Mar 31, 2017
    United States
    USA
    Hey guys, I've been occasionally visiting this forum for a few years but never decided to join until now.

    I'm a CS student with a weird passion about developing retro emulators. I'm currently working on a set of Gameboy (DMG only) tools including an emulator (w/ debugger of course), disassembler, and possible an assembler/compiler for my "Capstone" project at my university. I graduate in about a year and a half.

    Note on the Capstone: My school has its students do "Capstone" projects before we're allowed to take our Enterprise Projects courses, in which we get together in teams and do projects for companies to get real-world experience for nearly an entire year before graduating. (New project/company every few months). The point of the Capstone project is to show that we are able to go through with a project and that we are competent with our skills and ready to take on a real-world project.

    I work as a Software Engineer Intern with a company in the same city as my university, as well as an Academic Coach for the Freshmen and Sophomores at my university.

    My main interests in console hacking and emulation design/development has brought me to join here. It's been a while since I've joined a forum and was active, so I'm excited. Looks like a great community here.
     
    WeedZ likes this.
  2. WeedZ

    WeedZ Possibly an enlightened being

    Member
    GBAtemp Patron
    WeedZ is a Patron of GBAtemp and is helping us stay independent!

    Our Patreon
    2,715
    5,220
    Jan 13, 2015
    United States
    Welcome to the community
     
    Natorite likes this.
  3. Meteor7

    Meteor7 Guess where this thumb goes.

    Member
    859
    815
    Jun 9, 2014
    United States
    New Jersey
    Well, it's a pleasure to have you! Retro emulators today, I find, are very lacking in terms of their input lag, so it'll be great to have someone with a passion in that area joining the community. Cool to have you, and I hope you like it here. :)
     
    Natorite likes this.
  4. Natorite
    OP

    Natorite Newbie

    Newcomer
    4
    1
    Mar 31, 2017
    United States
    USA
    Thanks!

    Can you explain what you mean by their input lag a little better? It might be something I should look into.

    At the moment, I'm still working on getting the processor emulation and the VM running smoothly.
    Something interesting that I'm trying to do is step away from the "Fetch->Decode->Execute" cycle where the CPU opcodes are interpreted, over to essentially a Just-In-Time dynamic recompilation. It should look something like this (I'm aiming for O(1) times across the board):
    1. Start execution at usual entry point, $100.
    2. For each instruction up until the next branch/jump, store it in a HashSet of Action delegates and execute the instruction.
    3. Once reaching a branch/jump, store the HashSet and original jump address that brought you there into a Dictionary<Address, HashSet<Instruction>>, if the dictionary does not already contain an entry for the jump address.
    4. If the Dictionary contains an entry for the address the jump you've reached wants to jump to, then retrieve that HashSet of instructions and execute through it.
    5. Else, goto 2.
    EDIT: Sorry for the swe jargon. The Dictionary and HashSet data structures all have O(1) lookup/access times, so regardless of how big the data gets, I will have no difference in performance. Retrieving a value from a set of 500000 entries will yield the same performance as only have 1 entry.
     
    Last edited by Natorite, Mar 31, 2017
  5. Meteor7

    Meteor7 Guess where this thumb goes.

    Member
    859
    815
    Jun 9, 2014
    United States
    New Jersey
    Input lag is the amount of time that passes between pressing a button and seeing the action on screen. It's the only thing that makes them not worth using for me. Regarding the PSX Retroarch emulator on a raspberry pi, for instance, I haven't been able to get input lags below 8 frames, which makes action games (at least for me) completely unplayable. This post has the full record of my measurements across a few emulators.

    https://www.reddit.com/r/RetroPie/comments/5g3561/help_with_input_delays/

    But this fellow has done a much more in depth and accurate testing of emulator input lag among different pieces of hardware, and he even speculates on from where exactly the lag is coming.

    https://retropie.org.uk/forum/topic/2019/an-input-lag-investigation/2

    Maybe his hypotheses can spark an idea for you?
     
    Last edited by Meteor7, Mar 31, 2017
  6. WeedZ

    WeedZ Possibly an enlightened being

    Member
    GBAtemp Patron
    WeedZ is a Patron of GBAtemp and is helping us stay independent!

    Our Patreon
    2,715
    5,220
    Jan 13, 2015
    United States
    Input lag would be dependent on the hardware. Running them on a pc would be fine, running them on a calculator would cause issues. You just need to optimize your hardware and lower any unnecessary rendering settings that would take up resources.
     
  7. Natorite
    OP

    Natorite Newbie

    Newcomer
    4
    1
    Mar 31, 2017
    United States
    USA
    That's interesting. Perhaps it's an issue of having most things on the same thread? I usually plan for my final design versions to have essentially have the emulation, display, and input handling in their own respective little worlds.
    I've seen most emulators on Github and other sources do something like "Fetch -> Decode -> Execute -> GetNewInput -> UpdateInput -> ClearDisplay -> DrawDisplay"
    Here's a diagram of how I would like to make my Gameboy emulator designed.
    With this design, the program flow will have three different asynchronous processes and will look something like this instead of that long process above, effectively keeping the input lag to <= 1ms, and display to 16ms (60fps). The input actually doing anything is dependent of whether or not the code is actually checking the inputs, which just relies on writing optimized code.

    NOTE: There may be an issue with this design that I have not encountered yet, but it's the way that I would aim for to design it. I'm also bad at making diagrams, so sorry.
    • Execution:
    • If executing cached code, invoke the delegates until the next jump.
    • If running JIT algorithm, fetch the next opcode from the VM, translate/execute/repeat until next jump.
    • Input:
    • Compile byte (array?) of the input states and send them off to the VM to get written to memory.
    • Display:
    • Grab the data needed (sprites, vram, etc) and draw the next frame.

    [​IMG]
     
  8. Meteor7

    Meteor7 Guess where this thumb goes.

    Member
    859
    815
    Jun 9, 2014
    United States
    New Jersey
    The other guy I linked to was testing on a Windows 10 gaming PC. Additionally, I optimized the settings in RetroPie when doing my tests.
     
    WeedZ likes this.
  9. Master Dimentio

    Master Dimentio The Pleaser Of Crowds

    Member
    585
    304
    Feb 17, 2016
    United States
    Making my perfect world.
    Welcome to GBAtemp! I'm Master Dimentio and I hope we see more of you now around here. :P
     
    Natorite likes this.
  10. Natorite
    OP

    Natorite Newbie

    Newcomer
    4
    1
    Mar 31, 2017
    United States
    USA
    Thanks for the warm welcome! I'm currently out-of-state right now visiting with my parents since I'm on break. They don't have cable/internet at the moment, so I'm having to tether my phone over USB which doesn't really provide a reliable enough connection for my to be decently active. I'm flying back in a few days and should be back in my apartment soon, though!