MarkeyJester, on 30 April 2015 - 10:20 PM, said:
The plane viewer is much cooler than I was expecting, the green boxes than bend and reshape based on the scroll positions is a genius idea! Though it seems to crash when selecting sprites while the sprite table is being changed/altered mid-screen multiple times.
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.
Covarr, on 30 April 2015 - 10:03 PM, said:
For some reason, it seems to hover around 61-62fps when I have throttling enabled, instead of 60. Is this on purpose?
I'm using a pretty cheap and nasty averaging calculation to get that value. I'm pretty sure it's not all that accurate.
winterhell, on 01 May 2015 - 12:57 AM, said:
Things to make the emulator great :
- .smd format support(this would include autodetection which is the actual format since some .bin files are actually renamed .smd and vice versa)
That would be nice, I simply haven't bothered spending time on these kind of issues yet. This file:
https://bitbucket.or....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.
Quote
- while maximizing the emulator window changes backbuffer size, it should also change the actual viewport's size, and not it remaining in the bottom left corner with the same number of pixels.
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.
Quote
- I assume you are rendering to a 640x448 pixel buffer. If you copy that to a texture and then have the option for aspect scaling with no filtering(nearest neighbor) it would make many people happy.
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
Quote
- while it did detect I have 6-button controller, I cant seem to be able to use it for playing. I'm with the 'USB Genesis RetroPort ' . Apart from it not being configured, in the configuration it doesnt detect A,B,C and Start. This is likely due to the way the controller works and some APIs have trouble with that as well, or cloning the input for A/X, B/Y, C/Z, Start/Mode.
All this being said, I cant seem to be able to control a game with neither the keyboard or the controller(mapped one of the buttons to Start and it still doesn't work)
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.
Quote
- needs a better UI. The File menu is a good start, you would want to take couple of hints from the likes of Kega Fusion for setting the Input.
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.
Quote
Disclaimer: I understand this emulator is primarily for research and development purposes, not so much for the consumers. That being said, having all of those points would make for a several times better user experience. If they are already possible, then they are either not set as the default setting, and I'm having a hard time finding the way to set any of them. And I've been programming for 15 years now.
I can also tell those would take minor effort or time compared to the whole endeavor that is the whole emulator.
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.
00
/>
