Ah. I built from the version on sourceforge ... which btw was updated on June 19. Upthorn, have you checked the main branch of gens to see if there 's anything new in there you could incorporate into your version? (Assuming you're not one of the official project maintainers ... which you may just be :P).
As for grrl, it looks like there's a glade ui included, but it's not part of the makefile, so it never gets built. The version of gens I compiled this morning (2.15.2) has a gtkui directory under src/gens which we could probably port to Upthorn's version without (hopefully) too much difficulty.
If you're compiling the source under linux, it builds with a gtk interface. Just make sure you install it (make install just copies a bunch of stuff to wherever prefix is defined). Then run gens.
Upthorn, if your computer's descent (2 gb of ram or so), you could just install a linux distro in a virtual machine and use that for testing. If you don't have access to VMWare, VirtualBox is free from Sun and is a pretty good alternative (and open source to boot :P)
Using a cross-platform toolkit for ui would probably be a good move as it makes it easier to maintain in the long run, though the initial investment of time is high. I'm sure someone could cobble something together in gtk or qt to handle the basic functionality ... assuming the current core emulator code is nicely decoupled from the ui code :)
first rm config.sub config.guess depcomp, then run automake --add-missing to recreate those files.
You will not be able to build successfully though as the changes in 9826 were windows-based and as such, we didn't update the source for linux compilation.
I'm looking into this now though ;)
EDIT: too slow i guess. nitsujrehtona beat me to it ;)
The makefile is still setup for the environment that the last author had configured. Chances are your msys path to fceu isn't the same. Download and install msysdtk first so you'll have the autotools at your disposal. Then, from the root of the fceu build you're trying to make, do the following:
aclocal
autoconf
automake
./configure --with-nativewin32
windres -o src/res.o src/drivers/win/res.res
make
Video review takes as long as it takes ... There's really no set time on when accepted movies are published (or submitted movies are accepted for that matter).
Open source is probably the preferred way, not the only way. Open source projects allow for a larger pool of "possible" developers, but there's usually only a handful that will really commit to the project. I agree that an open source solution is a better approach, simply because it allows us to implement and test new features more quickly.
In the meantime though, DeHackEd was working on adding re-recording functionality to PCSX ... does anyone see anything wrong with continuing with this emulator for the moment?
Cool, thanks for that info, Maximus. :D
I compiled a test version with that change here:
http://popibot.googlepages.com/fceu-cheat-search-test.zip
Someone better than me should try and see if it still can find any address now. I couldn't find any, but I normally suck at this.
EDIT: Actually, I'm stupid. It does work fine. :D
Well, there's that build with that change if anyone needs it now and can't wait for the next version. Thanks again, Maximus.
Happy to help :D I've been having a tough time with the new mappers though :( I can get the new content in and patch the necessary files to make it work (the one i did with the 98.15 mappers shows that it's possible), but for some reason, the new stuff doesn't work :( Everything compiles correctly, but Startropics 2 and Powerblade 2 still show the same as in 98.16 ... ah well ... I'll keep on truckin'
It would be really nice if the ram search (Add Cheat) window could stay open while working with it. Right now, to do a search, you have to open the window, search, close it, frame advance, open, search, close, advance.
advance -> search -> advance -> search would be nicer.
It looks like the add cheat window is actually a DialogBox (as opposed to a modeless dialog, which would allow FCEU to regain focus without needing to close the cheat window).
If you modify src/drivers/win/cheat.c's ConfigAddCheat function to create a new dialog (CreateDialog(), then ShowWindow()), as opposed to simply calling DialogBox, it should address that issue.
This all assumes that the information the cheat window uses isn't a copied when the window is created .. cause if that's the case, though FCEU is still running, the memory values wouldn't change .... but I don't think that's the case ;)
Good work mz, nice list of fixes :)
I did some more work last night and have got the latest boards and mappers in (from the fceumm subversion repository, so they're even newer than the 2006 release stuff), but once again, I'm having problems with them actually working.
This could take a while as I try to pinpoint what's causing the weirdness, but once it's good to go, I'll merge my changes with your latest source tree.
Keep up the good work.
mz: This was a proof of concept release only. I still plan to keep merging the mappers, but now I know I have something that compiles successfully, and fixes some of the known issues that were introduced with 98.16 :D
As for FCEUXD, I already asked nitsuja and he said that there are too much windowsisms and such. And we don't want that.
Fair enough. On the bright side though .....
I tried a different approach, and have REVERTED the mappers and boards to the state they were in with 98.15. This may be detrimental to some games, but Startropics, Startropics 2 and PowerBlade 2 work now. I tagged this release as a beta (in the fceu main window) so that it's easy to differentiate, but if everything works, I'm going to try to start adding the new mappers and boards from fceu-mm.
There weren't all that many changes from 98.15 to 98.16, so i'm not sure what messed up those games, but i'll see what I can find as I update them. This build is based on the mappers/boards of 98.15 and some modification to the unif.c and ines.c files, but the rest is from 98.21, so all mz's fixes are in place.
Please let me know if something that was working fine is now broken (namely games not loading).
You can download the updated fceu here.
You can try to merge the fceu-mm mappers with the source of 0.98.15 in order to see what is the root of the problem.
I guess that would be the best course of action, but that would involve first merging the mappers with 98.15, then merging luke's changes for basicbot/shared-memory, then adding mz's changes.
I'll take a look later though (wife's working tonight so I've got some time :P). One thing I did find interesting though is how many files were virtually identical between fceumm and fceu9817 (there are only 43 files in the source tree that have some luke or tas-specific changes after doing a merge of the original files).
What I ideally want to accomplish though is the following:
* merge mappers/boards and make sure they work
* merge luke's and mz's changes into the working copy
* incorporate the enhanced features of fceuxd into 98.*
The last is a "nice idea, but unlikely", but I figure if I say it out loud, I'm more likely to actually work on it ;)
Ok, after farting around for a few hours, I've managed to merge the fceu-mm mappers with the source of 0.98.20 (not 21, but I didn't check the forums until this morning :P).
My test rom was PowerBlade 2, which works for the compiled version of fceumm, but for some reason it doesn't work with mine :( I was wondering if I can get a list of games that are known not to work with the current version of FCEU that I can run some tests on.
I did a minor improvement to Memory Watch in v0.98.18, but you'll only notice it if you're working with frame advance only. I'd love to see it not being such resource hog too, but sadly my knowledge in C and maths is really poor. Actually, I don't know C at all; this was the first time I saw some code. :P
Anyway, someone better than me should try to see if he can improve the UpdateMemWatch() function in memwatch.c; it's a really short function, but it's the one that takes all of the CPU power. I can't understand anything in it.
And I tried to fix other bugs too, but as I said, my C skills are really poor. I'll try to read some books about C now it got me interested in it, so maybe someday I will make a proper new version, with updated mappers and boards from fceu-mm too (I'd really like to have Startropics 1/2 and Power Blade 1/2 fixed someday).
It's good to see work being done on FCEU. I've got some time tonight so I'm going to see if i can merge some new mappers and boards into the source mz's working on. I haven't really done any work with C since college, but I'm assuming I still remember how :P I said I'd do this before, maybe this time I'll actually accomplish something :D
I use this frontend when I want to play something in my GoodMerged sets: QuickPlay. Here's a screenshot with my setup, but you can configure it in almost any way you want:
That looks like exactly what i'm looking for. The only thing is that it's windows-only (I was hoping for something cross-platform), but I guess that's what Wine is for ;)
Thanks mz.
Just out of curiosity, does anyone know if there is a good utility out there for working with GoodMerged sets? I've recently upgraded my collections to these sets, but was hoping to avoid having to extract everything (GoodMerged sets tend to house a whole bunch of hacks and crap you'll likely never play that just eats up disk space).
I haven't seen anything useful out there and was thinking of writing my own, but before I do, figured I'd do some research first. What ROM management tools do you guys use, if any? Would anyone find something like this helpful? I was thinking of something that could work for compressed sets, compressed single files and uncompressed ROMs for all supported platforms.
[URL=http://www.mediafire.com/?5udzwuozj2n]Here's SNES9x 1.43 improvement 11 beta 20[/URL] for linux.
Did some quick tests, but if anyone has any problems, let me know.
I fail at making proper packages, so I've removed the debs. The tgz's should work fine, though, and I updated the FCEU one to include DeHackEd's stream-dumping .16 version (for encoding purposes).
I'll try to get VBA, Dega and Mupen up as soon as possible along with some documentation, perhaps.
I can make debs if you like, but it looks like it's usually just a binary into /usr/local/bin, so it's probably not necessary :D
[*]Nesmock - Is there a binary to download on this page? I couldn't find one in the first 4 or 5 download links, and the version I somehow got long ago is pretty outdated.
[URL=http://www.mediafire.com/?eweelmmsd3b]Here ya go[/URL]
Just built a copy for linux and windows. Had to do some minor tweaking for the Windows build, so let me know if it doesn't work for whatever reason.
Since the source/linux column isn't supposed to line up with any content in the other column, it might look nicer if you top-aligned the content (td valign=top)
Thanks Maximus. I have one more question though; which files do I need? The GZip, the .deb, or both?)
I would actually only host the gzip files, as it looks like a couple of the debs aren't made properly (someone else may want to test to confirm, but only the snes9x one actually opened with GDebi for me).
FYI, the deb is like an MSI/Installed EXE while the tar.gz is like a ZIP of the same thing that you extract and run from where ever.
[*]Ubuntu packages put together by mushroom - really I just need these explained to me. Are they binaries? Source? both?.
The ubuntu packages are basically just precompiled packages with dependecy checks, so you can quickly install an application without having to to worry about missing dependencies.
They (generally) won't contain source.
PS. Uniform table widths would look a lot nicer in the "all re-recording emulator's" page.