I've noticed that there's been no new versions since 2004. Is it that the current version is perfect and doesn't need updating? (don't think so, I've seen a couple of semiserious flags with GameGenie emulation) Or is the project no longer being developed, and so, dead as ESounD is?
I fail to see how you can perceive Generator as "dead". It's not commercial software, so there's no point in releasing Generator 2k, Generator XP, Generator hasta la vista. It's certainly not perfect - nothing is. Also it's not useful to compare different kinds of software. ESounD for example is useless if not supported by any software. Generator is not a library so it doesn't need support by anyone. Last but not least, ESounD has far more issues than Generator ever had.
However, it's been working fine for years now. The question is just whether the existing bugs or missing features are sufficiently important to anyone to work on them. I can only speak for myself but to me Generator (respectively my patched version) isn't important enough to spend any more time on it. I'll try to keep it usable by fixing trivial issues
that arise due to changes to compilers or operating systems but that's all. Generator is not dead, it just works.
Fibonacci, your post was in poor taste. Do you just want to see updates for the sake of updates? It would be better to mention the specific problems you are having with Generator. As for using /dev/dsp, you can configure with --with-sdl-audio to use SDL output instead.
To paraphrase someone else, not being able to program is a problem, although a fixable one.
I apologise if it sounded like that. I just wanted to show why Christian's arguments were flawed.
>Do you just want to see updates for the sake of updates?
Oh Heavens, no! I want to see updates for the sake of (first and foremost) bug fixing and (if there's time for that) feature adding.
>It would be better to mention the specific problems you are having with Generator.
Not possible to read Game Genie codes in XXXX-XXXX format.
After applying a Game Genie code, it's not possible to de-apply it.
No way of having emulation start by default when a ROM file is loaded.
Haven't yet discovered fullscreen mode, and I'm starting to suspect it doesn't exist.
>As for using /dev/dsp, you can configure with --with-sdl-audio to use SDL output instead.
I have problems with SDL - namely, that it blocks all my other audio sources. Only ALSA and ESD work fine (most of the time), ALSA more so than ESD. I'd love to have ALSA support.
>To paraphrase someone else, not being able to program is a problem, although a fixable one.
I had no problems with not being able to program until I moved to Linux and wanted to play the Genesis ROMs I still have on my HD.
I'd love to see more open-source Genesis development as well, but it looks like it's just not happening. It would've been incorporated into Mednafen, except for non-commercial licenses (MAME sound/cpu cores) conflicting with GPL.
> Not possible to read Game Genie codes in XXXX-XXXX format.
> After applying a Game Genie code, it's not possible to de-apply it.
> No way of having emulation start by default when a ROM file is loaded.
> Haven't yet discovered fullscreen mode, and I'm starting to suspect it doesn't exist.
An auto start feature would be nice. Fullscreen works fine for me - alt+enter
> I have problems with SDL - namely, that it blocks all my other audio sources. Only ALSA
> and ESD work fine (most of the time), ALSA more so than ESD. I'd love to have ALSA support.
I would try to fix your sound setup, because SDL can output to ALSA, ESD, whatever you like. See: http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fenvvars
Anyway, Generator isn't dead, it's just dormant. I assume you can't use Gens because you're non-x86?
>It would've been incorporated into Mednafen, except for non-commercial licenses (MAME sound/cpu cores) conflicting with GPL.
You mean, MAME cannot be incorporated into Mednafen? Since Mednafen is GPL, there would be no problem with incorporating Generator, or Gens, or DGen into it.
>Fullscreen works fine for me - alt+enter
That's why I said I hadn't discovered it. Thank you. But the other issues still remain.
>I would try to fix your sound setup, because SDL can output to ALSA, ESD, whatever you like. See: http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fenvvars
Erm, that page is not clear enough. Do I have to write a program to set those variables?
>Anyway, Generator isn't dead, it's just dormant.
Oh.
>I assume you can't use Gens because you're non-x86?
I don't want to use Gens because:
1- They don't offer precompiled binaries for GNU/Linux, unlike Generator.
2- Compiling it from source is a pain in the rectum - at least with the last GCC version.
3- Even when I manage to get it compiled, the sound is SOOO crappy.
4- Even if I managed to ignore that the audio quality is poor, the sound output lags about one second behind the video.
Yes, I have complained about that in the Gens forums. There's only ONE GNU/Linux user there (Tomman, using FC4), and he says everything works fine for him, so no luck. After many failed attempts at solving my problem (use CVS, change the audio driver, and so on), one guy told me to use Kega. With WINE.
No way. I'd rather use Generator than Gens, but I would like it to work.
Right, MAME's is a non-commercial license, whereas GPL allows commercial use, so by that alone they are incompatible. There is MAME code (or Starscream) in every single Genesis emulator, either Z80 or sound cores. Except maybe for Kega Fusion, which is closed-source. Generator, Gens, and DGen are GPL in name only - they all include non-commercial licensed code.
Try export SDL_AUDIODRIVER=esd from the command line, before you run Generator, if you like ESD. Remember you must've compiled with the sdl audio option.
Gens works fine for me, as does Kega Fusion under Wine.
Somehow I believe, you're not aware of my slightly advanced version Generator:
http://ghostwhitecrab.de/generator/
"Not possible to read Game Genie codes in XXXX-XXXX format."
I've never used a real Game Genie cartridge but I believe this format issue is fixed in my version. The original didn't parse them properly so that this feature didn't work at all. I tested some cheats and they worked.
"After applying a Game Genie code, it's not possible to de-apply it."
That's not fixed. You'd have to remove the code and restart the emulation.
"No way of having emulation start by default when a ROM file is loaded."
Nobody ever asked for it. My version has a command-line switch "-a" which stands for "arcade mode". It goes to fullscreen mode and starts the ROM which you specified on the command-line immediately. If you're mostly playing a few games you could add
"generator-gtk -a /path/to/game" as menu item to your window manager. Auto-start on loading a ROM would be trivial if that's what you want.
"I have problems with SDL - namely, that it blocks all my other audio sources. Only ALSA and ESD work fine (most of the time), ALSA more so than ESD. I'd love to have ALSA support."
Simple. Put this line into your ~/.profile or ~/.bash_profile or ~/.bashrc whatever shell and file you have:
SDL_AUDIODRIVER=alsa; export SDL_AUDIODRIVER
As budgie wrote, you have to compile my patched Generator with --with-sdl-audio. Otherwise, it might pick-up some other audio method.
"Haven't yet discovered fullscreen mode, and I'm starting to suspect it doesn't exist."
Use Control+F or Emulation->View->Fullscreen to toggle fullscreen mode.
"I don't want to use Gens because:
1- They don't offer precompiled binaries for GNU/Linux, unlike Generator."
This is simply a PITA especially for a single person or small teams because there are so many platforms and options to compile a program. Also binary packages are constantly broken if not shipped by whatever package management or distribution you use. For performance-sensitive apps like Generator which benefit a lot from compiler switches like --march it's also not very cool to either provide 20 different binaries or otherwise some half-optimized that works sub-optimal.
Several distros provide binaries for Generator as well as my version. That's the proper source to look for binaries. Even if people would contribute binaries I wouldn't like to distribute them on my website because it's impossible to check whether they added trojan horse for example. A non-evil issue is a badly compiled binary like ignoring serious compile warnings or half-assed attempts to fix some compile etc.
The source tarballs I provide are signed, so as long as you check the signature you only have to trust me and the previous developers. But as said, it's available in distros so why would anyone take this risk and if they don't care they can probably find a binary with Google...
"2- Compiling it from source is a pain in the rectum - at least with the last GCC version."
Well, for Generator it should be trivial. You have to know a few basics of course. Basically just "./configure && make && make install". Otherwise, look whether your distro ships it and if not ask them to add it. Or just ask the developers or in their forums. It's just said that many Linux distros make it much more difficult to compile things yourself than it actually is.
I tried your patch to Generator, which I compiled with SDL support, and now I have the exact same sound lag as I had with Gens, which was the reason for me to stay with Generator. Now, not even Generator sounds right!
Sound lag doesn't change. In fact, I was given the same suggestion on the Gens forums - which didn't help either.
> Or compile again using --without-sdl-audio for configure.
That would make it OSS-only, which is one of the problems with Generator which I wanted to solve in the first place.
> If
> none of that helps, edit ~/.genrc or change the audio settings
> in the GUI:
>
> sound_minfields = 4
> sound_maxfield = 10
There's no ~/.genrc file. I haven't installed it yet (and will not unless I'm sure it sounds at least as good as the Generator I already have), I'm just running the binary from the source directory.
I'm a bit confused. If you use --without-sdl-audio, there should be no difference with respect to audio between Generator and the patched Generator. If alsa does not work, try dsp or dma or any other audio options which are available for you.
If Gens has the same problem - and I don't think they share any code - I wonder whether there isn't something wrong with your audio driver or SDL.
The ~/.genrc file has nothing to do with installing. It's created as soon as you save the options in the GUI.
> I'm a bit confused. If you use --without-sdl-audio, there should be no difference with respect to audio between Generator and the patched Generator.
Of course. It also hogs the sound output, which I thought your version didn't.
> If alsa does not work, try dsp or dma or any other audio options which are available for you.
Why, then, should I use the patched version instead of the original Generator?
> If Gens has the same problem - and I don't think they share any code - I wonder whether there isn't something wrong with your audio driver or SDL.
Don't think so. All other apps using ALSA, ESD or any other audio server work fine. MPlayer using SDL works fine too, and the sound doesn't lag like in Gens or Generator.
> The ~/.genrc file has nothing to do with installing. It's created as soon as you save the options in the GUI.
One difference is that my version allows mute playing, so if you had no soundcard or it's in use ("hogged") you can still play. The original Generator does crash in this case. Nothing you probably care about but I once did.
If you want that Generator doesn't hog your soundcard, either you drivers have to support this natively or you need to use SDL along with ESD or whatever sound driver supports sharing of the sound device.
The section "Additional features" lists advantages over the original Generator. If you don't care about any of those, there's probably no reason to use it.
All other applications may work fine but none of those seems to be interactive and lag is most annoying for interactive applications. For others it might not even be noticable. However I obviously cannot remotely diagnose this. How much CPU time does Generator use? How bad is the lag? Seconds? Less than a second?
I already understood that you have no ~/.genrc file. As said, this file will be created by the original as well as the patched Generator if and only if you save the options in the GUI. Otherwise it won't. What I'm talking is Emulation->Options->Sound under "Bounds". The
settings "Try to buffer this many fields of sound" and "Make sound buffer this many fields of sound" control the sound lag. If you set them to high, there will be lag, if they are too low the sound will skip or have audible blips. You could try to set them to 1 and 2 for those. If I knew the perfect setting I'd make them default. Some people have trouble with lower, others with higher values. It depends on drivers, systems speed and what not.
> If you want that Generator doesn't hog your soundcard, either you drivers have to support this natively or you need to use SDL along with ESD or whatever sound driver supports sharing of the sound device.
Okay, I think I didn't make myself clear enough:
I want Generator not hogging the soundcard, AND I want Generator's sound not lagging. I did try SDL_AUDIODRIVER=esd too, and it didn't change things a bit.
>The section "Additional features" lists advantages over the original Generator. If you don't care about any of those, there's probably no reason to use it.
Only one of those features I do care about:
"SDL audio support (in favour of OSS Audio) which means you can use ESound and others for sharing the sound device among other applications."
As for this one:
"Working support for Game Genie codes. "
I thought Generator supported that already. Only not in XXXX-XXXX format, but hexadecimal instead.
> All other applications may work fine but none of those seems to be interactive and lag is most annoying for interactive applications.
I thought MPlayer, XMMS, Xine, Second Life, SuperTux and Pingus were considered interactive?
> For others it might not even be noticable.
Even a minimum sound lag in MPlayer would most certainly be noticeable for most video files.
> However I obviously cannot remotely diagnose this. How much CPU time does Generator use?
It varies, but the number reported by htop is around 2%, and it never exceeds 5%
> How bad is the lag? Seconds? Less than a second?
One second.
> I already understood that you have no ~/.genrc file. As said, this file will be created by the original as well as the patched Generator if and only if you save the options in the GUI. Otherwise it won't. What I'm talking is Emulation->Options->Sound under "Bounds". The
> settings "Try to buffer this many fields of sound" and "Make sound buffer this many fields of sound" control the sound lag. If you set them to high, there will be lag, if they are too low the sound will skip or have audible blips. You could try to set them to 1 and 2 for those. If I knew the perfect setting I'd make them default. Some people have trouble with lower, others with higher values. It depends on drivers, systems speed and what not.
Setting those to 1 and 2 respectively did help reduce the lag, but did NOT eliminate it.
Even if it's not what you want, could you please try dsp and dma too? I just want to know whether it eliminates the lag. If that does help, it's definitely an issue with the other sound driver (models). If that does NOT help, try --without-sdl-audio please. If that eliminates the lag, it's definitely an issue with SDL or at least the way it's used in Generator. If that does NOT help either, there must be some general timing flaw in Generator. If it uses about 10% CPU or even less, then it's clearly not a performance issue.
A lag of about a second sounds really bad though. There's one thing you could still try then. In main/ui-gtk.c comment out nanosleep that is change
nanosleep(&ts, NULL);
to
/* nanosleep(&ts, NULL); */
or remove the line temporarily and recompile, just run make again. It's possible that the CPU time saving causes some heavy delay for you.
> Even if it's not what you want, could you please try dsp and dma too? I just want to know whether it eliminates the lag. If that does help, it's definitely an issue with the other sound driver (models). If that does NOT help, try --without-sdl-audio please. If that eliminates the lag, it's definitely an issue with SDL or at least the way it's used in Generator. If that does NOT help either, there must be some general timing flaw in Generator.
Isn't trying dsp the same as compiling --without-sdl-audio? And what is dma, and how do I use it?
> If it uses about 10% CPU or even less, then it's clearly not a performance issue.
Thought so, the games run smoothly. Even the sound runs smoothly, one second behind the video of course.
> A lag of about a second sounds really bad though.
It is.
> There's one thing you could still try then. In main/ui-gtk.c comment out nanosleep that is change
>
> nanosleep(&ts, NULL);
>
> to
>
> /* nanosleep(&ts, NULL); */
>
> or remove the line temporarily and recompile, just run make again. It's possible that the CPU time saving causes some heavy delay for you.
Yes, dsp and dma both refer to OSS audio. dma is only supported by some drivers, not all, as far as I know. If SDL_AUDIODRIVER=dma main/generator-gtk doesn't work, yours might not support it. Anyway, SDL doesn't handle sound the same. As far as I can see, it uses an audio thread. I suspect that this might be the cause of the lag. This thread might have insufficient low priority or whatever, thus causing delayed audio. So just because SDL with dsp and --without-sdl-audio will be using the same audio interface, the behaviour is different. Therefore I want to know whether using --without-sdl-audio makes the lag disappear. My only other suspicion was the nanosleep(). If it's neither SDL audio nor nanosleep(), I'm out of ideas.
Just tried ZSNES (which, as far as I know, uses SDL too) and the sound is perfectly synchronised with the video. Doesn't this prove that the problem isn't with my SDL installation?