Originally posted by asdf

---

Originally posted by Alastor the Stylish

---

That's not going to help, either, since the stupid people are just as capable of hitting us as we are of hitting them.

---

Which is what I've always been trying to explain to people who say that. Not to mention you could randomly hit people over the internet and disconnect your modem so they can't retaliate. Or worse, hit random people over the internet, and hold up a board with a lot of nails in it to your computer. When they attempt to retaliate...they'll be in a world of pain.

---

Originally posted by Karadur

---

Interestingly enough, while in newreply.php (and possibly elsewhere), the Color Chart link at the top of the page points to "http://board.acmlm.org/newreply.php?id=reply number here" That could very well be a bug, but it's still strange, seeing as the error messages posted earlier in this thread both involved colors.php, as did the code that sent the old board to it's doom (look here if you don't know what I'm talking about). The only thing out of the ordinary with it from here is a missing close bracket (I can't remember the proper name right now), in this line: <.td class='tbl tdbg1 font center'.

---

cript on click, and it's not related to colors.php.
Side note: The javascript: protocol exists for a reason.

---

(edited by HyperMackerel on 05-08-06 10:38 PM)

• A motion-sensitive controller
  
• LEDs on the controller to show which player you are (look at the top)
  
• A built-in hard drive
  
• A full system and a cheaper "core" system

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.