don't click here

Cycle accurate emulation: Exodus 2.0 + Open Source Release

Discussion in 'General Sega Discussion' started by Nemesis, Apr 27, 2015.

  1. Nemesis

    Nemesis

    Tech Member
    Thanks for reporting the issue, I've fixed it in the mainline, and a few other bugs I noticed with the panel while I was checking it out. The next release will fix the problem.

    I'm using a pretty cheap and nasty averaging calculation to get that value. I'm pretty sure it's not all that accurate.

    That would be nice, I simply haven't bothered spending time on these kind of issues yet. This file:
    https://bitbucket.org/exodusemulator/exodus/src/e7339975eba43964fb0f895f3fd7b1ab6893f440/Extensions/MDExtensions/MegaDriveROMLoader.cpp?at=default
    This is where all the platform-specific nastiness of loading raw Mega Drive ROM files belongs. This class takes a random Mega Drive binary, inspects it, and generates a corresponding module file so that it can be loaded in Exodus. This is where SMD support needs to be handled. SMD format is problematic though, because it's insanely system specific. I'll be adding native support for interleaved files to the platform itself, but SMD is another level entirely. To do this in a generic way, you really need to convert the ROM. The loader can do this for you, but it'll still require a copy of the binary. I'm not going to add native SMD support to the platform itself, it simply doesn't belong there.

    Could you give me some specific steps to reproduce this issue? I've tried every way I can think of, and couldn't find any problems here.

    Not doing anything like that actually. In 32x32 cell mode on the Mega Drive, pixels aren't square, and on top of that, I support mid-screen changes between 32x32 and 40x32 cell modes. To avoid any loss of precision at the actual rendering step, each line is rendered as a strip of pixels, with an associated cell mode. The Image window itself then renders strips of textured quads with each line mapped to an individual polygon. All that said, nearest neighbour filtering is there. Check under "Settings -> Mega Drive -> VDP -> System Settings", and turn off "Enable Line Smoothing". That'll give you what you're after

    No experience with that particular USB device, but there's certainly no custom support for any particular controllers. I'm just using standard Win32 API calls to the Winmm library to handle the input. If the device doesn't work correctly through that API, it won't work correctly in Exodus, or most other Windows software for that matter. If you couldn't get keyboard input to work though, that'd almost certainly be a window focus issue. Try clicking in the image window itself first. Input keys aren't hooked globally, each window handles them, so the image window needs focus in order to process the input. It'd be a problem if you're trying to interact with debug windows, but all "A" key events are being sent to the game input for example.

    Agreed, I know the interface has issues with usability. It's actually a hard problem to solve in some cases though, because remember that Exodus is a generic platform. Almost all menu items come through plugins. Try renaming your "Plugins" folder and open Exodus, then check out the menu and you'll see what I mean. The bigger issue however, is that almost all settings are system-specific. Did you know that in Exodus, you can emulate more than one Mega Drive concurrently? Try it, go to "File -> Load System/Module", and select "MegaDriveTestSystem.xml". Now load in a ROM. You'll see you get to choose which cartridge port to map it to. Now load in another ROM for the other system. Now hit run. Both systems will run in parallel, keeping perfect timing. You could now build a device to emulate the "Zero Tolerance Link Cable" for example, and connect both systems together, and they'll talk to each other just like the real system, keeping perfect timing accuracy. Or, someone could build a system module to emulate Pong. They could even load Pong, two linked Mega Drives, a Master System, and a Game Gear all at once. What then is the input mapping window supposed to look like with these cases in mind? Obviously before you can ask about how to map input, you need to ask what you're mapping input for. Kega Fusion doesn't have to worry about this.

    The menu is also problematic for similar reasons. The menu system has a structure, which is designed to allow multiple concurrently loaded systems, and multiple independent plugins, to all define settings and expose menu items, without collisions or ambiguity occurring. That system seems a bit cumbersome from a user's perspective though, when they're used to a hard-coded dedicated emulator, which has a known fixed list of settings and one dialog where everything is defined. I'm hoping to come up with ways to simplify menu navigation, but I've got no ideas on that right now that don't break the generic nature of the platform. Personally, I think a better option is to largely abandon the menu entirely for system-specific options, and instead visualize them in a form that's easier to navigate. I'm thinking of a settings window for example, with a tree view on the left showing the tree of all loaded systems and components within the system that define settings, and a main panel area on the right, where the component that's selected shows a docked settings window in the main panel area, or you can doubleclick or something to open a standalone window. A similar tree view approach could work for debug windows. This would allow you to quickly see everything at once, and open anything with a doubleclick, and the main menu can then be stripped of this stuff, and greatly simplified.

    Anyway, this is an area that does need improvement. This platform has quite a different set of problems to deal with than other emulators though, because of the generic nature of the system, and that means the solutions are likely to be different too.

    Usability issues are important, and they need to be addressed. I've been working on this emulator for over 8 years now though, and if I waited for all these issues to be ironed out before releasing it, it would never see the light of day. I've got ideas, but limited time. I'm hoping other people might be willing to contribute some of their own time and talents to improve the areas that are most important to them.
     
  2. winterhell

    winterhell

    Member
    1,165
    7
    18
    Cool.

    http://imgur.com/bEsQahp,2DBpsAF,YjKw6Dr#0

    The first image is the default window. The second is when I double click on the window title/maximize, and the third is fullscreen. All 3 should be 'touch window from inside', or at least the last one.

    Yes apparently the input maybe was something to do with the focus, now it seems to work.
    Some programs do recognize the controller's 6 buttons properly, some don't.

    The Winmm wrapper I use behaves differently than this, but still no full functionality.

    Is there a way to change the default Mega Drive Rom path? When I close the emulator it resets. Saving the workspace didnt change things. What does the "Sega Mega Drive ROM Loader" do?

    Thanks.
     
  3. Meat Miracle

    Meat Miracle

    Researcher
    1,664
    5
    18
    Can you also add support for byte switched files, such as direct rom dumps (or is it already there)?
     
  4. Sappharad

    Sappharad

    Oldbie
    1,413
    70
    28
    I figured it out. This is either a problem with your server config, or your web host, if the server isn't yours. It happens when you connect over a network that supports IPv6. If I manually disable IPv6 on my machine, such that the browsers can only connect over IPv4, the site works fine. My home network has been set up with full IPv6 support for the last 6 years or so, but unfortunately the majority of ISP's don't even support it so it's hard for people to test against it.

    Best of luck trying to get that fixed. :-)
     
  5. Nemesis

    Nemesis

    Tech Member
    Hmmm, no matter what I do, I can't seem to re-create this problem. Can you let me know the exact version of Windows you're running? I'll have to give it a go on the same OS. It might be a quirk in the way window sizes are being reported on that version, there have been a few changes to this stuff in each version after XP.

    There's no way to save the default ROM path right now. I know it's annoying, and something that needs to be fixed.

    The "Sega Mega Drive ROM Loader" makes it possible to actually load a random Mega Drive ROM directly in the system. A ROM file is just a data dump out of context, you can't actually do anything with it without making some kind of assumption about what it's for. Exodus is a generic platform, so it can't make those kind of assumptions, and as such, exodus can't load raw ROM files, it can only load modules, which describe what is being loaded, and how to link it to the rest of the system. The Mega Drive ROM loader is an extension that becomes active when a "Mega Drive" system is loaded, and takes care of the platform-specific knowledge required to take a random binary ROM file, and present it as a module to the system so that it can be loaded in Exodus. This is also where game-specific loading "hacks" are applied, like knowing that SSFII is a 40-Mbit game with bankswitching hardware, or that Virtua Racing has an SVP processor attached (Exodus doesn't actually support these yet, but this is where that support would be added). You can bypass the loader completely, and write your own module file to define whatever you want to (like your own custom cart with special hardware), the ROM loader just makes it more convenient to do what 99% of people will want to do, which is just load an existing ROM file dump the way they do currently in other emulators.

    Yep, the support will be quite comprehensive in this area. At a minimum, it'll need to be able to do everything natively that would be be required to load any of the interleaved or byteswapped ROM dumps that exist for arcade roms currently. I'll make the support as flexible and comprehensive as possible.

    Thanks for letting me know! I've been told by my webhost that IPv6 should now work. I can't test this myself, but let me know if it seems to be working for you now.
     
  6. winterhell

    winterhell

    Member
    1,165
    7
    18
    Windows 7 64-bit, Aero interface.
    Gonna try it later on an old laptop with with the same settings.
     
  7. Sappharad

    Sappharad

    Oldbie
    1,413
    70
    28
    Still getting the "Lithium hosting Account is operational" page, even if I run in incognito mode to avoid cache & cookies.

    According to google, this only affects 6.17% of people right now. Given those odds, it's likely your host can't test their own problem. :-)
     
  8. Nemesis

    Nemesis

    Tech Member
    Could you test This magic address and tell me if it works? If it doesn't, try http://[2604:4500:0000:0021:0000:0000:0001:0000].
     
  9. Sappharad

    Sappharad

    Oldbie
    1,413
    70
    28
  10. Nemesis

    Nemesis

    Tech Member
    I've made some DNS changes that should propagate over the next couple of days. They'll either fix IPv6 access to the main site, or totally break everything and make the site unusable for anyone. Time will tell. I'd be lying if I said I understood even half of what I'm doing with DNS config.

    Based on my tests with http://ipv6proxy.net, the domain is now working over IPv4 and IPv6.
     
  11. Sappharad

    Sappharad

    Oldbie
    1,413
    70
    28
    Your links on the previous page now work for me from the correct URL's. Thanks once again for fixing them.
    (DNS propagation hasn't had the 24 hour delay in a long time, it should be switched for most people at this point)
     
  12. The plane viewer is cool as hell! It's even better than what I had in mind back when I requested this feature! Awesome work! :thumbsup:
     
  13. Thousand Pancake

    Thousand Pancake

    Being a food you put milk on and then eat in the m Member
    360
    0
    0
    Are there any plans for porting to not-Windows? I've had a really hard time finding a good Genesis emulator on Lubuntu.
     
  14. Nemesis

    Nemesis

    Tech Member
    I've got no plans to do a port myself, but I've written the code to be quite easy to port. It'd be quite a bit of work to re-implement the user interface, but getting emulation itself and running should be quite easy. The project is open source now, so anyone can have a go at this if they want to. I won't personally be working on ports to any other operating systems anytime soon though.