Go to the actual source directory that has files like cart.c, cheat.c, etc. Type "make". Configure no longer works, in fact if you run it, it might corrupt the makefile. If you want to change the compiling options you can edit the makefile manually.
If you have automake, you could try that. That should update the configure file.
The reason for this is, I added the memory mapper files, but you need automake (which I don't have) to add new files to the configure script.
You should make it clean. Btw, you don't give the root directory with files like config and makefile.
The makefile you give doesn't compile FCEU.
$ make
Makefile:1083: .deps/x6502.Po: No such file or directory
Makefile:1084: .deps/fceustr.Po: No such file or directory
Makefile:1085: .deps/cart.Po: No such file or directory
Makefile:1086: .deps/cheat.Po: No such file or directory
Makefile:1087: .deps/crc32.Po: No such file or directory
Makefile:1088: .deps/debug.Po: No such file or directory
Makefile:1089: .deps/endian.Po: No such file or directory
Makefile:1090: .deps/fceu.Po: No such file or directory
Makefile:1091: .deps/fds.Po: No such file or directory
Makefile:1092: .deps/file.Po: No such file or directory
Makefile:1093: .deps/filter.Po: No such file or directory
etc.....
make: *** No rule to make target `drivers/win/.deps/aviout.Po'. Stop.
Oh I see. Hmm this is why make is dumb. You will need to create these files. Probably the easiest way is to put a # before the include lines that are causing the errors. Run make once, and then you will have these files.
Automake can be used under MInGW and there's one version on their site. I recommend you to make it clean so it can be easily configurable and makeable.
it is not taking background input from my gamepad, only keyboard. not that i need it, but is it supposed to be like this?
I have problems with this too. I need a gamepad, I just can't use the keyboard.
Try downloading it now. I'd don't have a joystick so I didn't even think of this :) I can't test this, but it's a simple fix so I hope this will work now.
Sorry, but it still doesn't work. :(
EDIT: No wait it works! Yay! :)
BUG: when doing either of the following, the palette is completely screwed:- Going from windowed to fullscreen, or vice versa.
- Changing any settings under Config -> Video. Actually, just opening that dialog and then hitting the Close button is enough. o_OGoing to Config -> Palette and reloading the desired palette seems to fix the problem though, as does checking and/or unchecking the NTSC Color Emulation box.
Seems to me like the memory location from which the palette is grabbed is being added to or subtracted from unknowingly, because when the bug is done repeatedly, the garbage palettes are usually the same and usually show up in the same order...
Hmm, I guess 50webs cancelled my site. lol. Apparently emulators fall under their "copyright vio" policy, even though FCEU violates no copyrights. Maybe bandwidth usage got their attention... Screw them.
Anyway here is the 98.16 FCEU and the html files
http://media2.uploadjar.com/file.php?file=uploads/fceu.zip
And here is all the source (this includes the .Po files so it should compile without all the extra work)
http://media2.uploadjar.com/file.php?file=uploads/src_1.rar
I'll check out the palette bug, it shouldn't be hard to fix. I have a couple other tweaks I should add to FCEU too.
I will probably do automake/autoconf in the future. Although I am a little afraid that running these will mess everything up, since FCEU uses a custom config file. I don't have any experience with these...
What are you doing when it crashes? Recording a movie, playing a movie, opening a ROM, etc.? Any particular ROMs? Are more than one FCEU open? Most importantly, can you tell me how to recreate a crash?--then I could easily debug it.
Anyone else seen any crashes?
I would like to at least know what code to look at.
I haven't seen FCEU crash yet. I know it's possible, there are some problems in the code (some memory leaks have always existed, but I think they are harmless unless you are REALLY trying to crash it). I am curious if anything I changed has unintended problems, because I would at least like to fix my bugs.
The problem, I don't know what has caused this since it happens 2 times now.
One time is when playing a movie of CV3 jap, I pause the emu then minimize and switch to mIRC window and it crashes.
The second time is when browsing for movie file on desktop.
It never happens before. I think it's probably newest changes. I didn't tested with your older version since I don't have it now but it never crashed when I do have it. Maybe it's related with cpu or other C compiler optimization that you have decided to use?
I also recommend to fix known bugs and don't use those optimizations and see if it happens again.
From now on, Luke's FCEU had crashed 3 times.
2 times is when browsing movie file on desktop.
Can you explain in your doc how Auto-fire pattern, auto-fire offset works?
That's really uncommon.
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
I love what you have done so far, luke, good job. Just fixing those bugs would make it excellent.
But have you seen this thread? i made an image for an ideal TAS making tool idea, maybe you could consider making it? i see it needs a lot of work, but user friendlyness is the key to make tasing easier, which leads to more people making movies and better quality movies too.
http://tasvideos.org/forum/viewtopic.php?t=2607&postdays=0&postorder=asc&start=0
Now, I am 100% sure it occurs when browsing through desktop when trying to load a movie or ROM. Sometimes it doesn't crash. I will try to find the real way to make it crash. Since it seems to happen only on desktop, I think you should try finding the solution.
edit: I don't know if it is useful but using windebugger gives me this:
(284.21cc): Access violation - code c0000005
eax=02032038 ebx=00000000 ecx=0672f1da edx=0672f1d2 esi=0672f3e0 edi=0029bf28
eip=7ca614ae esp=0672f134 ebp=0672f37c iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
SHELL32!SHCreateQueryCancelAutoPlayMoniker+0xf7f8:
7ca614ae 8b08 mov ecx,[eax] ds:0023:02032038=????????
Edit: The easiest way to make the bug happen is by opening the ROM then play the game normally, sometimes use frame advance, pause, save and load state and do this for 2 minutes then browse for the ROM on desktop but don't open it immediately. Press the letter of any known files, ex. Arkanoid, you should press A, and also some other file that share the same first letter. Hold it then "left click" with your mouse on any file and FCEU should crash.
If it fails, redo those steps.
Another bug happens when trying to open a zip file that doesn't contain a valid ROM. You will get an error message. Now retry loading that zip file again or another one. OOPS, it crashed.
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
Phil wrote:
Another bug happens when trying to open a zip file that doesn't contain a valid ROM. You will get an error message. Now retry loading that zip file again or another one. OOPS, it crashed.
the same thing happens in any fceu version i tested
Literally speaking, true. But everything in your posts indicated you were specifically blaming Luke's FCEU, even if you didn't say that explicitly...
You should be more careful in thinking what kind of impressions people get when they read your posts. Try to eliminate the wrong impressions and strengthen the right impressions. As you may have realized, there's a very high chance that people get the wrong impressions, understand wrong meaning. You can affect that if you concentrate on it. Word differently, explain more. In this case, using an extra sentence like "I did not test whether this occurs with the standard FCEU as well" would have avoided the misinterpretation.
The question is not "Is it Luke's fault" but "Is this bug in his version". Yes it is. I don't care, and no one should, who is responsible but I want bugs to be removed.
This thread title is FCEU development. With that perspective in mind, I can't be blamed.
In fact, someone taking his free time to track bug(s) should be encouraged.
Here, we are supposed to report bugs for the latest FCEU version. And the latest version is Luke's one.
Oh, when I will try your Linux version someday, prepare to fix bugs or/and implementing missing features that I will request. :P
My first request is that you should start making a nice GUI.
It just sounded like you were complaining at luke like when you say "you should make your version clean". It's not very nice, he's doing a good job.
I should complain at who?
Luke is the last one that made changes in source. It is indeed not clean. Is "random crash" clean? Is "source that doesn't compile using standard method" clean? Is adding new features that aren't well documented clean?
If I wouldn't have reported many bugs since blip had released its version, how could they have fixed bugs when they even don't know their existence?
Yes, but from a coder's perspective, it seems as if you are placing the blame on him and his code. Which he may or may not find insulting. Additionally, he assumes that the problem is a result of something he changed. So that's where he starts looking, and it wastes his time and yours.
And you could try asking, not complaining.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Luke: Ok the bug that makes FCEU crash when browsing files is also in nitsuja's version. Vatchern had also encountered this problem and told me it started occuring in nitsuja's version.
When people doesn't report bug(s) like I do, we are sticked with bugs. If Vatchern would have reported the bug when he did noticed that and nitsuja was working on it, all those troubles wouldn't have happened. I also noticed many people complaining about some things they don't like without reporting.
Ex. Some users whining for many monthes about supposedly "windowsisms" in FCEU which wasn't true.
As for the "Pause the emu then minimize and switch to mIRC window and it crashes.", it never happens again but it's true that I only tested the "browse for file" problem.
OmnipotentEntity wrote:
Yes, but from a coder's perspective, it seems as if you are placing the blame on him and his code. Which he may or may not find insulting. Additionally, he assumes that the problem is a result of something he changed. So that's where he starts looking, and it wastes his time and yours.
And you could try asking, not complaining.
I didn't complain, I have just told him how to make those bugs happen. I didn't lose my time. What makes me lose my time is posts made by you guys. You are making assumptions that aren't justfied.
Also, it is certainly not user's fault if there is bug in the code.
