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 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 Alastor the Stylish

---

If you even consider an ice theme, there's obviously something wrong with you


SMW's physics are slippery enough without ice making everything worse.

---

Originally posted by Stifu

---

4. Demand credits for your incredibly hard work.

---