gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > Self contained ROM + Emulator executable

#109949 - sgeos - Thu Nov 23, 2006 1:43 pm

What would it take to bundle a GBA ROM and emulator as an inseparable package? The fact that the game is actually a GBA ROM running in an emulator should be completely hidden from the user. (Normal users at least.)

-Brendan

#109954 - tepples - Thu Nov 23, 2006 4:55 pm

Conceptually, that will be easy. Microsoft Windows executables can have something called "resources", which are similar to an appended GBFS. Windows programs normally store icons, bitmaps, and dialogs in resources. You could store the ROM in a resource

Practically, that will be hard. Most native games' options for control and graphics configuration are done with in-game styled UI, but most emulators' options for frame skip and control setup are done using plain-looking Win32 UI. Players who enter character names in a native game expect to be able to use the keyboard (not the joystick), and they also expect to have each save file created within the game mapped to a different file on the PC (not a .sav file).

Legally, that will be hard. Some emulators are released under licenses that preclude distribution on the same medium as ROMs or that preclude commercial use. VisualBoyAdvance isn't (it's copylefted free software), but recent versions of that emulator aren't exactly efficient either. If you use VBA or any other copylefted emulator, you also have to distribute the emulator source code, which would reveal the presence of an emulator.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#109993 - Ant6n - Fri Nov 24, 2006 1:33 am

you want something like an application which is actually a rom loaded by some emulator, but you want people to just click and play, without having o worry about emulators etc.
would it be possible to create some kind of .exe which has vba sdl and your rom packaged in it and then put both in some temporary folder and run sdl vba with your rom from there?

#110001 - sgeos - Fri Nov 24, 2006 4:41 am

Ant6n wrote:
you want something like an application which is actually a rom loaded by some emulator, but you want people to just click and play, without having o worry about emulators etc.

I want an alternative to standard PC development that would be easy to port if and when that becomes an option. I've looked at various libraries, and I'm not completely happy with any of them. A GBA emulator should have most of the capabilities of a GBA, and should have capabilities similar to the DS. =) Then again, "enhancing" the emulator looks like a lot of work.

Ant6n wrote:
would it be possible to create some kind of .exe which has vba sdl and your rom packaged in it and then put both in some temporary folder and run sdl vba with your rom from there?

Probably?

tepples wrote:
Practically, that will be hard. Most native games' options for control and graphics configuration are done with in-game styled UI, but most emulators' options for frame skip and control setup are done using plain-looking Win32 UI.

The emulator would have to be "enhanced" for the game to look professional. Options could be done by dropping a few virtual dip switch registers off in O/I space. Win32-style UI menus would flip the dip switch registers to communicate with the game; the UI would have to be redone for each game. (Neo-Geo arcade style option system. =) Maybe the header could store the "hard dip" options instead of the nintendo logo?

tepples wrote:
Players who enter character names in a native game expect to be able to use the keyboard (not the joystick),

A keyboard could be "emulated" using registers and/or SWIs. The game would have to echo the input. The same could be done for the mouse.

tepples wrote:
and they also expect to have each save file created within the game mapped to a different file on the PC (not a .sav file).

Yet another goofy virtual register. Or you could muck around with the save state system.

The "enhancements" would clearly render the ROM unusable on hardware. This is probably a good thing. A proper port would (in theory) be simple- simpler than a true PC to GBA port. #ifdef SHAREWARE

tepples wrote:
Legally, that will be hard. Some emulators are released under licenses that preclude distribution on the same medium as ROMs or that preclude commercial use.

Clearly these could not be used without contacting the author and getting a copy under a different license. Potentially possible. The ROM clause has to do with piracy, which this is not. The commercial use probably has to do with piracy, but it's not as clear cut. Then again, depending on the author, it might not be possible.

tepples wrote:
VisualBoyAdvance isn't (it's copylefted free software), but recent versions of that emulator aren't exactly efficient either.

The "game" only has to efficient enough. (Neat info: CPUs have more or less plateaued 3.2 GHz.)

tepples wrote:
If you use VBA or any other copylefted emulator, you also have to distribute the emulator source code,

That could be available via the "make your GBA game look like shareware" page (source + tools for developers; it probably needs to be renamed). Very few "normal" people would go there, and they'd leave quickly.

tepples wrote:
which would reveal the presence of an emulator.

The goal isn't so much to hide the emulator as to avoid bogging down "normal" people.

In short, the conclusion is that it would be a mess. =)
-Brendan

#110002 - tepples - Fri Nov 24, 2006 5:03 am

sgeos wrote:
Ant6n wrote:
would it be possible to create some kind of .exe which has vba sdl and your rom packaged in it and then put both in some temporary folder and run sdl vba with your rom from there?

Probably?

It'd probably be just as easy to make the ROM a separate file. Doom has its WAD files, and Quake has various iterations of PAK files.

sgeos wrote:
tepples wrote:
VisualBoyAdvance isn't (it's copylefted free software), but recent versions of that emulator aren't exactly efficient either.

The "game" only has to efficient enough. (Neat info: CPUs have more or less plateaued 3.2 GHz.)

But a lot of your target audience doesn't have PCs manufactured anywhere near the plateau. I'm still on a PC from 4th quarter 2000, with an 0.86 GHz CPU, and the latest versions of VBA make TOD lag.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#110038 - sgeos - Fri Nov 24, 2006 3:36 pm

tepples wrote:
sgeos wrote:
Ant6n wrote:
would it be possible to create some kind of .exe which has vba sdl and your rom packaged in it and then put both in some temporary folder and run sdl vba with your rom from there?

Probably?

It'd probably be just as easy to make the ROM a separate file. Doom has its WAD files, and Quake has various iterations of PAK files.

The cheapest way to go would be to bundle the ROM and emulator in an installer and unpack everything in install directory. The emulator probably wants to be modified to look like "my game" and autolaunch the ROM. To make things simple, configuration wants to be disabled and the emulator wants to launch in full screen mode. Key input and mouse go unused. Joystick/keyboard are used as standard input. (Stripping everything sounds like a bit of a pain.)

The SDL version could probably be modified to accept a "shareware shell" commandline option. Mac, Windows and Linux all have idiot friendly ways of passing command line options via "click me" icons, right?

tepples wrote:
sgeos wrote:
tepples wrote:
VisualBoyAdvance isn't (it's copylefted free software), but recent versions of that emulator aren't exactly efficient either.

The "game" only has to be efficient enough. (Neat info: CPUs have more or less plateaued 3.2 GHz.)

But a lot of your target audience doesn't have PCs manufactured anywhere near the plateau. I'm still on a PC from 4th quarter 2000, with an 0.86 GHz CPU, and the latest versions of VBA make TOD lag.

How fast a computer do suppose you'd need to run TOD at full speed? (IIRC, TOD was renamed... not that that matters.)

For a very long time we've been at the point where normal users don't need new computers; many people should still be using "old" hardware. Does anyone know of a PC hardware spec survey? How low spec does one reasonably want to aim? (286 is clearly silly =)

-Brendan

#110046 - tepples - Fri Nov 24, 2006 8:13 pm

sgeos wrote:
To make things simple, configuration wants to be disabled and the emulator wants to launch in full screen mode.

A lot of people still demand window mode so that they can see the game (in 480x320 pixels, 2x) and a walkthrough or their IMs or an IRC channel.

sgeos wrote:
Key input and mouse go unused. Joystick/keyboard are used as standard input.

Make sure that the keyboard and the joystick are fully configurable. A lot of USB joysticks that contain both a digital direction pad and an analog thumbstick map the direction pad to an 8-way hat switch, not the primary axes.

sgeos wrote:
The SDL version could probably be modified to accept a "shareware shell" commandline option. Mac, Windows and Linux all have idiot friendly ways of passing command line options via "click me" icons, right?

Windows has .lnk (shortcuts) and .bat (cmd.exe scripts), and Linux and BSD have bash scripts. Mac "bundles" may have something similar to BSD.

sgeos wrote:
tepples wrote:
a lot of your target audience doesn't have PCs manufactured anywhere near the plateau. I'm still on a PC from 4th quarter 2000, with an 0.86 GHz CPU, and the latest versions of VBA make TOD lag.

How fast a computer do suppose you'd need to run TOD at full speed?

In an older VBA, TOD runs fine on my machine with frameskip 0. In a newer emulator, it needs frameskip 1.

sgeos wrote:
(IIRC, TOD was renamed... not that that matters.)

For the record, TOD was renamed to TOD. (It now stands for Lockjaw: The Overdose.)

sgeos wrote:
Does anyone know of a PC hardware spec survey? How low spec does one reasonably want to aim?

A lot of PC gamers expect the effort required to set a game up to be proportional to the production values. Thus a game should either
  1. not require installation (that is, be written in Java or Flash) or
  2. be a 3D game.

_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.