Originally posted by Glyph Phoenix

---

Emulators should be able to do whatever the hell they want; extra graphical effects, fancy quality sound, what-have-you as long as the ROMs pretty much stay the same. It's when the ROMs start changing to support the emulators when things get really messy.

---

Originally posted by Glyph Phoenix

---

The first group seems to encompass extra hardware features. My beef isn't just with roms becoming unusable on their original system, but with other emulators. Compatiblity over platforms and emulators = win. But since emulation entails emulating features made by fans as well, I guess this might count. Though building new features for an ancient system is impractical to the highest degree, it'd still be cool.

---

---

The second feature group, debugging, is largely unrelated to the issue. The problem is adding things to ROMs that cause incompatiblities and can't be run on the original system. Debugging tools aren't ROM features, they're emulator features. Emulators should be able to do whatever the hell they want; extra graphical effects, fancy quality sound, what-have-you as long as the ROMs pretty much stay the same. It's when the ROMs start changing to support the emulators when things get really messy.

---

---

Your third group, system-specific interface tools and such, doesn't make much sense. It would be a lot harder to make a rom that the system uses as a plugin or interface than to actually write an interface or plugin system and build it directly into the emulator.

---

Originally posted by HyperHacker

---

I mean like adding features that the ROM can use, but only using them for debugging. Extra RAM or a second display screen would be a good example of this.

---

Originally posted by HyperHacker

---

Eh, I think it'd be fairly easy and kinda cool to do. Making an interface in Windows can be a huge pain. If you have a ROM doing it, not only is it easier (I'd assume if you can write an emulator for a given console, you can write ROMs for it too), but you get the added bonus that you can work the interface using a joypad.

---

Originally posted by Glyph Phoenix

---

That would be more work.

---

---

Your points about joysticks and such don't hold any weight-- the emulator already has joystick access if it's emulating with one, obviously.

---

---

It has better joystick access, in fact, because it can know things like whether extra buttons are pressed and the exact joystick position instead of left, right, up, down, A, B, X, Y, et cetera.

---

---

Even if you wanted to create a SNES style interface, it would be a bad idea to store it in a ROM because you'd be limited in what you can do and what you can do in the future without scrapping the old system.

---

---

It would also be a security risk. Every time I download a hard-to-find rom from some shitty site I am thankful there's no chance a corrupted rom can possibly do more than cause a crash. If my emulator is good enough, it shouldn't even be able to crash. Not so if it were possible to corrupt my interface via a ROM.

---

Originally posted by Glyph Phoenix

---

If you have written an emulator with joystick and screen support, the emulator will have joystick and screen support. Are you still with me?

---

---

You seem to think that it is wrong to simply take those features and write functions in whatever language the emulator is written in to create an interface. Instead, you seem to believe it is better to create an entirely new ROM and coding complex systems to communicate from ROM to emulator. That is where you seem to have gotten lost.

---

---

You would think I needn't mention that a built-in interface could directly access the mouse, keyboard, and other features without coding an in-between.

---

---

Also, not once did I mention the Windows interface.

---

---

In fact, I specifically mentioned that even for system-style interfaces there are significant advantages to building it into the emulator or using a plugin or skin rather than a ROM.

---

Originally posted by HyperHacker

---

Acting like an ass hardly helps your case.

---

Originally posted by HyperHacker

---

I only said it would be easier and you'd be able to navigate the interface with a joystick.

---

Originally posted by HyperHacker

---

You act like it's difficult to write:
if(ROMFlags & RF_INTERFACE) IO[2] = (GetKeyState(IO[1]) & 0x8000) ? 1 : 0;
It actually takes more work to have a built-in interface respond to the joystick than a ROM-based one, since you'd have to poll it a second time outside of the emulation loop.

---

---

When you talk about making an interface for a Windows program, it's generally assumed you'd use a Windows interface.

---

Originally posted by HyperHacker

---

Which I responded to in the previous post.

---

Originally posted by HyperHacker

---

Are we done, or did you want to continue arguing that things I haven't said are wrong?

---

Originally posted by Glyph Phoenix

---

Originally posted by HyperHacker

---

I only said it would be easier and you'd be able to navigate the interface with a joystick.

---

Which doesn't make any sense. I said it wouldn't be easier and you can navigate the interface with a joystick easily without using a ROM.

---

---

Originally posted by HyperHacker

---

You act like it's difficult to write:
if(ROMFlags & RF_INTERFACE) IO[2] = (GetKeyState(IO[1]) & 0x8000) ? 1 : 0;
It actually takes more work to have a built-in interface respond to the joystick than a ROM-based one, since you'd have to poll it a second time outside of the emulation loop.

---

Is it so difficult to set a simple variable within the poll if the interface is active?

---

---

Also, if you wanted to use the ROM interface while a game is running, you'd have to add support for loading two ROMs at once.

---

---

---

When you talk about making an interface for a Windows program, it's generally assumed you'd use a Windows interface.

---

Good job. Now find the post where I mentioned making an interface for a Windows program.

---

---

Originally posted by HyperHacker

---

Which I responded to in the previous post.

---

Ah, yes, "Not if you do it right". How thoughtful and informative that sentence was! Care to elaborate?

---

Originally posted by HyperHacker

---

Well I just plain disagree there. Making a Windows interface is a HUGE pain and I feel I could make a Game Boy ROM to do the job far easier. Navigating a Windows interface with a joystick is quite difficult to implement. As far as making your own non-standard interface, this might be easier than a Windows interface but I still feel it'd be more difficult than a ROM-based one.

---

---

The emulation loop would have to be running for this to work. It can't very well be running if you're still in the interface choosing which ROM to load.

---

---

Ideally you'd do this for a simple emulator that doesn't need to display an interface while the game is running. Either way it wouldn't be particuarly difficult to run multiple ROMs at once if you design it with this capability to begin with; nearly every Game Boy emulator already has to do this for link support.

---

---

You didn't; I figured since there are far more emulators for and users of Windows than any other platform, and since AFAIK neither of us code for any other platform, it'd be implied. The fact that you didn't bring up the idea of a non-Windows emulator until now further backs up this implication.

---

---

You'd have to design the entire system quite poorly for it to impose any severe limitations.

---

---

This entire thread is about adding features to emulators that exceed the capabilities and limitations of the system they're emulating. To use these limitations in your argument just doesn't make sense.

---

---

Honestly, don't you have anything better to do than to analyze every post you see looking for even the smallest, most insignificant flaw?

---

Originally posted by Glyph Phoenix

---

Originally posted by HyperHacker

---

Well I just plain disagree there. Making a Windows interface is a HUGE pain and I feel I could make a Game Boy ROM to do the job far easier. Navigating a Windows interface with a joystick is quite difficult to implement. As far as making your own non-standard interface, this might be easier than a Windows interface but I still feel it'd be more difficult than a ROM-based one.

---

How would making your own interface using limited tools and limited graphic formats in a ROM--which you would specifically have to build support for--be easier than simply putting an interface directly into the emulator?

---

---

---

The emulation loop would have to be running for this to work. It can't very well be running if you're still in the interface choosing which ROM to load.

---

You wouldn't have to put joystick support in an emulation-only loop. A system organized like so doesn't seem like a good idea at all, really. I'd consider a separate code section for input that tosses values to code that tells the game what buttons are pressed to be a more elegant solution.

---

---

---

You didn't; I figured since there are far more emulators for and users of Windows than any other platform, and since AFAIK neither of us code for any other platform, it'd be implied. The fact that you didn't bring up the idea of a non-Windows emulator until now further backs up this implication.

---

Just stop assuming Windows altogether. Whatever you're programming in, anyway, it should be easier to put in a couple of code pieces in already existant screendrawing functions to make an interface than to write an entirely new ROM and supporting functions for it.

---

---

---

You'd have to design the entire system quite poorly for it to impose any severe limitations.

---

That's not true. It's a matter of the ROM not being designed for interfaces

---

---

and requiring heavy modifications to the emulator in order to interpret it as such.

---

---

If you ever wanted improved resolution, additional colors (or colors at all), any integration with any sort of application, or basically any features common to operating systems today but not to ROMs

---

---

---

This entire thread is about adding features to emulators that exceed the capabilities and limitations of the system they're emulating. To use these limitations in your argument just doesn't make sense.

---

The more ROM systems that are overwritten, the more work involved and the more bugs to catch. It's just not rational to override regular emulation so a single limited, emulated ROM image can serve as an interface when much better options are present.

---

Originally posted by HyperHacker

---

I don't see your point here. Limited tools? A tile editor, a text editor and an assembler are all the tools I need to make a Game Boy ROM. Limited graphic formats? Sure if you wanted super-high-resolution graphics, but the idea of a ROM-based interface is to use the same resolution, colours etc that games use, to make it feel like it's built right into the game.

---

---

What, like a separate loop? That would just consume more CPU power and make it harder to keep everything synchronized. Especially if, for example, you want to support the console's real controllers plugged into a parallel port (even moreso on systems like N64 where you have accessories connected to the controller), synchronization is important for accurate emulation.

---

---

If you want to use the existing screen-drawing functions, then you'd again need to have the emulation loop running. You then have the choice of drawing on a separate buffer not used by the ROM at all, which uses up more memory, or writing your graphics directly into emulated VRAM in which case it's already halfway to being ROM-based.

---

---

...Wha? The ROM that's designed solely to act as an interface, not being designed for an interface? I'm afraid I can't find any meaning to this sentence.

---

---

Originally posted by Glyph Phoenix

---

and requiring heavy modifications to the emulator in order to interpret it as such.

---

Adding this functionality would be trivial, as I've already mentioned a few times.

---

---

Then you shouldn't be using a ROM-based interface to begin with.

---

---

Again, the point is to use the same resolution and colours as the original system.

---

---

If I can write one line of code to allow a ROM to do something, and 10-15 to allow a standard or built-in interface to do the same, it's pretty clear which is the better option. Compare:
if(ROMFlags & RF_INTERFACE) IO[2] = (GetKeyState(IO[1]) & 0x8000) ? 1 : 0;
versus
case WM_KEYDOWN:
if(ProgramMode == PM_INTERFACE)
{
if(wParam == VK_UP) InterfaceMenuPos[InterfaceMenu]--;
else if(wParam == VK_DOWN) InterfaceMenuPos[InterfaceMenu]++;
else if(wParam == VK_SPACE)
{
InterfaceMenu = InterfaceMenuTarget[InterfaceMenu][InterfaceMenuPos];
InterfaceMenuPos = 0;
}
if(InterfaceMenuPos >= InterfaceMenuMax) InterfaceMenuPos = 0;
else if(InterfaceMenuPos < 0) InterfaceMenuPos = InterfaceMenuMax - 1;
}
else
//Normal emulation-related keystroke handling here
break;
Not including the additional code you'd need for mouse movements, joystick input, actually drawing the menu, the menu definitions themselves, and special cases for the menu options that don't just lead to another menu.

---

Originally posted by Glyph Phoenix

---

Originally posted by HyperHacker

---

I don't see your point here. Limited tools? A tile editor, a text editor and an assembler are all the tools I need to make a Game Boy ROM. Limited graphic formats? Sure if you wanted super-high-resolution graphics, but the idea of a ROM-based interface is to use the same resolution, colours etc that games use, to make it feel like it's built right into the game.

---

It's not built into the game, though. It'd be for an emulator, which has a wide array of advantages--the higher resolution being only one of them--that would be tossed away in favor of an interface stuck to a ROM.

---

---

---

What, like a separate loop? That would just consume more CPU power and make it harder to keep everything synchronized. Especially if, for example, you want to support the console's real controllers plugged into a parallel port (even moreso on systems like N64 where you have accessories connected to the controller), synchronization is important for accurate emulation.

---

Separating the input read through the OS or whatever you use to gather input from the rest of the emulation loop is not only valid; it's smart when you might want to choose a different way to gather input down the line or code the emulator to run on different platforms.

---

---

---

If you want to use the existing screen-drawing functions, then you'd again need to have the emulation loop running. You then have the choice of drawing on a separate buffer not used by the ROM at all, which uses up more memory, or writing your graphics directly into emulated VRAM in which case it's already halfway to being ROM-based.

---

Again, separating the input and screen drawing functions from the direct emulation loop is going to help out in the long run anyway. Do you really think running and interpreting a second ROM will take up LESS memory than a simple buffer?

---

---

---

...Wha? The ROM that's designed solely to act as an interface, not being designed for an interface? I'm afraid I can't find any meaning to this sentence.

---

Most ROM formats weren't designed with interfaces in mind. The SNES, GBA, NES, and a great deal of other ROM formats were never designed to be used as interfaces. And while there are some ROMs designed to be used as BIOS (Neo Geo has a BIOS, I think), those were designed back when we didn't have speedup or manipulatable display or the things we have now and just aren't as valid today as they were then.

---

---

Speaking of speedup keys, can you imagine writing a ROM interface that accesses more keyboard input than a regular ROM? That'd be uncomfortable. And you'd have to do it in order to put a button mapping system in the ROM interface.

---

---

---

Originally posted by Glyph Phoenix

---

and requiring heavy modifications to the emulator in order to interpret it as such.

---

Adding this functionality would be trivial, as I've already mentioned a few times.

---

It wouldn't be, though. Manipulating a loop designed for emulation to add setting-changing support would involve sticking lots of code where it doesn't belong and just misusing the ROM in general.

---

---

---

Again, the point is to use the same resolution and colours as the original system.

---

More resolution can mean you can fit in more menus. Menus can get cramped in a GB even when you have much more space available. As for colors, I'd sure like to be able to see more of them if ever this ROM interface were to support changing the palette.

---

---

---

If I can write one line of code to allow a ROM to do something, and 10-15 to allow a standard or built-in interface to do the same, it's pretty clear which is the better option. Compare:
if(ROMFlags & RF_INTERFACE) IO[2] = (GetKeyState(IO[1]) & 0x8000) ? 1 : 0;
versus
case WM_KEYDOWN:
if(ProgramMode == PM_INTERFACE)
{
if(wParam == VK_UP) InterfaceMenuPos[InterfaceMenu]--;
else if(wParam == VK_DOWN) InterfaceMenuPos[InterfaceMenu]++;
else if(wParam == VK_SPACE)
{
InterfaceMenu = InterfaceMenuTarget[InterfaceMenu][InterfaceMenuPos];
InterfaceMenuPos = 0;
}
if(InterfaceMenuPos >= InterfaceMenuMax) InterfaceMenuPos = 0;
else if(InterfaceMenuPos < 0) InterfaceMenuPos = InterfaceMenuMax - 1;
}
else
//Normal emulation-related keystroke handling here
break;
Not including the additional code you'd need for mouse movements, joystick input, actually drawing the menu, the menu definitions themselves, and special cases for the menu options that don't just lead to another menu.

---

This is complete bunk. Key handling code already exists if you've written a decent emulator, and the other features are just a common courtesy that, if desired, would have to be coded whether making a ROM-type interface or not.

---

---

Let me simplify this:

A built-in interface can have access to whatever you code for the emulator, and coding access to features for it should be as simple as passing a few variables to it and tossing a few to the screen functions.

On the other hand, a ROM has only access to what regular ROMs do and whatever expansion features are coded in. In this case, expansion features would be incompatible emulator features introduced for a single rom.

---

• Modify the screen-drawing functions to draw in a higher resolution and with more colours, and from an alternate source
  
• Enlarge the emulation window, and change screen resolutions in full-screen mode
  
• Add a second input handler
  
• Rewrite large portions of the emulation loop so that you can exit the loop and re-enter it again later without changing any of the emulated system states
  
• Add functions to draw the interface, detect clicks, respond to keypresses depending what control has focus, etc etc

• Modify one or two parts (depending how complex you want it) of the emulation loop to read from an unused I/O port, use the value as an index in a switch statement, and write things into other unused I/O ports, if a certain flag is set.
  
• Modify the ROM loading code to set that flag if the ROM being loaded has a certain filename or is being loaded from a resource within the EXE.

Originally posted by HyperMackerel

---

Originally posted by MathOnNapkins

---

You know the SNES has an I/O port... hop to it.

---

That's just the port I was thinking of when I wrote that. No idea how to use it though.

---