I'm not sure if I'm asking this in the correct place, but I got here from the fceux.com site.
I've been searching everywhere looking for a way to get an AVI video with FCEUX. It seems pretty simple, but I don't have the necessary menu items for this task. I only have File, Options, Emulation and Movie. I'm missing NES, Config, Tools and Debug. I tried to build it from source with no success.
I'd appreciate any pointers. Thanks a lot.
While both the SDL and win32 version of fceux utilize a common emu core, the applications themselves are separate. The debugger and other features were written specifically for windows and would not work with the SDL version. A debugger for the SDL port would be awesome but someone would need to write it from scratch.
Dont worry, unpleasantness can never be avoided where I am involved.
Clearly not true; you've been a great help to me in the years that I've been working on fceux and I honestly appreciate that. I'm just saying that I think there was a lack of communication on my part that may have escalated things and for that I do apologize.
I figure I should probably chime in here. I originally offered ProcyonSJJ a feature branch on the fceux subversion server so I could look over the code and try to help out where I can. I also mentioned that if the voxel engine code was specific to the SDL port (drivers/sdl/*) and if the code was clean I would consider a merge.
I honestly have not had a time to look over the code yet (or even keep up with this topic until just now) so I can't comment on the code itself but I would not at all be opposed to hosting the sdl voxel engine on a feature branch (although to be fair I do not speak on behalf of the entire team).
If anyone wants to check out the SDL fceux-voxel feature, feel free to check it out from the feature branch. I fixed the scons scripts so that you can build it the same way you normally build fceux (just run "scons"). You can check it out with this:
svn checkout svn://svn.code.sf.net/p/fceultra/code/fceu/branches/voxel fceux-voxel
I apologize if a lack of communication on my part escalated any unpleasantness that could have been avoided.
r, can't really make it look 3D until I can make the edges reflect differently.
3) I'm only able to read the mouse with Zapper games, and only when I press click (hence the Duck Hunt shot). I need to poll the mouse continuously even in non-Zapper games.
4) Performance. Depending on how many voxels get drawn, I'm going anywhere from 10 FPS to 53. Plus, the image quality isn't even all that great... lots of jaggies.
Again I think if I consulted with someone who was stronger with OpenGL, I'd be able to resolve that. Any takers?
3) What mouse coordinates are you looking for? Absolute mouse coordinates or mouse coordinates in relation to the SDL surface? I remember mouse input being a mess in FCEUX but I doubt its something that cannot be resolved. I'll have to look into the code and get back to you
Are you hosting the code to this publicly somewhere? If so let me know - I'd be interested in perusing the changes and try to give input where I can
I hit another stumbling block tonight. I am trying to tie the camera movement to the mouse. I see where the line
t = SDL_GetMouseState (&x, &y);
is called in sdl/input.cpp, and I tried tapping into it, but I could only ever get x and y updated as soon as the application started, and never again, no matter how much I moved the mouse around. Yet when I tried out Duck Hunt, it's clearly registering the position of the mouse cuz I can shoot the ducks. All I tried doing was passing the value of x and y to another method after SDL_GetMouseState is called and use those values, but they never change. Is there something that I'm missing? Thanks.
I realized my own problem. I'm running in a window, so I'm forced to rely on the GTK results, not the SDL results. I was going nuts...
Yup, unfortunately this is one of the headaches of dealing with two toolkits simultaneously (SDL and GTK)
Hello. I'm in the process of working on something experimental, and I wanted to share some of it while asking for assistance. Essentially, I am writing a voxel engine to be incorporated into the OpenGL renderer of FCEUX. It's an expansion of an idea that I had a while back when I considered doing something similar in MAME (see this thread in MAMEWorld). I found trying to demystify MAME's renderer a little too daunting, but I recently resurrected the idea and have made a fair bit of progress with FCEUX. It also only really works well with games that have a single solid color for a background (e.g. black for older arcade games, the blue sky in Super Mario Bros.) The renderer takes the color in the upper left corner and treats that as the clear color while at the same time ignoring any pixel in the image buffer composed of that color (no voxel).
I have a couple of questions:
1) I'm developing within the SDL version (linux), but I'm not very familiar with scons. I see the whole bit about checking for OPENGL support and adding -DOPENGL to the CCFLAGS. Is there anyway to enforce the addition of -lGLU to the LIBS? Cuz right now I made my own script to link the resulting .o files against -lGLU, but there's got to be a way to have it work with scons.
2) Is anyone here fairly familiar with OpenGL? My lighting isn't working the way I had hoped (I think it has to do with my failure to switch matrix modes from MODELVIEW to PROJECTION, but I don't have enough experience with that. Also, my FPS is pretty poor, even though I'm using a Display List to render the voxels.
3) Would anyone on the official development team have any interest in supporting this concept and/or accepting the final result into the official source code?
4) Does the FCEUX using community at large have any interest in this project?
Thanks very much for your time and assistance.
Procyon
P.S. I'll get some screenshots up as soon as I have some decent looking to share. Right now it just looks like blobs of blocks, and it's not very impressive. I want to attach the mouse to the movement of the camera so you can see more impressive angles.
Hi there,
Sounds like an interesting project you are working on.
1) Yes. You could add something like "env.Append(LINKFLAGS = ["-lGLU"])" to the SConstruct and that flag will be passed on to the linker.
2) My experience with OpenGL is very limited so I won't be able to provide much help with that.
3) I'm the SDL maintainer of fceux and I would welcome a patch for this feature.
If you have some questions about the SDL codebase, feel free to drop by the fceu IRC channel on freenode (irc.freenode.net - channel #fceu). You may not get an immediate response (I idle in there) but I will see your question and respond when I get a chance.
Sounds pretty cool and I wish you the best of luck with this! If I can help out at all (some of the source code is rather.. erm... mystical? heh) let me know
If you want to use the TASeditor, fceux 2.2 runs fairly well in WINE (http://winehq.org).
Thanks, that’s how I use gens. I am not very much interested about NES tasing, but if there was a way to run an emulator natively on Linux/BSD, I would try it. Only because of this tool (TAS editor), to see it in action.
Why didn’t you use GTK to make TAS editor? Out of curiousity.
I didn't write it. Not only is TASeditor written directly for the Win32 API, the entire GUI for windows is written directly for the Win32 api. By the time that the Linux/SDL port was gaining popularity, it was far too late to rewrite the Win32 codebase to share a common GUI. Currently, (although they look similar) the GUI for Win32 and GTK are separate codebases but share the same core.
The Linux version is not as feature-rich as Windows one, so no TAS Editor or Debugger there. But traditional TASing is still possible.
amen…
TASEditor and the debugger were written in win32 specific code; mostly coded directly for the win32 API. In order to implement these tools for the SDL (Linux/BSD/Mac) port, they would need to be completely rewritten from scratch. As the sole SDL developer, I honestly don't have the time to port all of these features. I would really like to implement a debugger for the SDL port at some point in time, but I have no idea when that will be (if ever). These features are not being overlooked, but rather postponed indefinitely for the SDL port due to the amount of effort that would need to be duplicated and the lack of developer bandwidth for the SDL port.
If you want to use the TASeditor, fceux 2.2 runs fairly well in WINE (http://winehq.org).
That being said -- anyone is free to contact me with any feature requests they have for the SDL port and I will gladly take them into consideration. Better yet, patches always welcome.
What OS are you running?
While you can config your gamepad to use the joystick in SDL (Linux/BSD), I generally recommend QJoyPad so you can configure the rest of the hotkeys on your joystick if you want to
started = 0;
while (true) do
health = memory.readbyte(0x006A);
gui.text(2, 10, "Hardcore mode");
if health == 28 then
started = 1;
end;
if started == 1 and health < 28 then
FCEU.softreset();
started = 0;
end;
FCEU.frameadvance();
end;
Would you be able to provide an strace of this issue? You should be able to simply run "strace fceux" and provide the output after the crash.
Could you provide which version of Debian you are running? There have also been numerous changes to the FceuX GUI in svn, so the issue may be resolved in the latest SVN source. If you could compile the latest svn and test that it would be greatly appreciated; as I am not able to reproduce this issue. You can grab the source here:
http://sourceforge.net/p/fceultra/code/2748/tree/
AFAIK this issue has been resolved in the latest SVN and should be fixed for when 2.1.6 is released. Let me know if you are still having issues with the lastest code in SVN.
Have you tried compiling it with homebrew?
You should be able to do "brew install fceux"
http://mxcl.github.com/homebrew/
I did a little write up about FCEUX on OSX a while back here:
http://blog.xannode.com/?p=124
Let me know if I can help out; I've got FCEUX running on my MBP with the latest osx (forget which cat it is)
What version of fceux are you using? If you are using 2.1.5 could you try compiling the latest svn (which will be 2.1.6)?
http://sourceforge.net/p/fceultra/code/2748/tree/
Have you tried adjusting the XScale and YScale values to match your resolution?
I can look into the SDL.Hotkeys.Quit issue, that may be something that I've overlooked -- thanks for bringing this to my attention.
Not sure what the OpenGL issue is without looking at the logs -- if you can provide the output of the command line to this thread I can try to help
When trying to install the package with Debi, it says "Status: Error: Wrong architecture 'amd64'".
EDIT: Oh yeah, 64-bit. So I can't test it myself.
Mhh isn't it possible to manipulate .deb packages?
punkrockguy318 wrote:
Hey tasvids,
I've been working hard on the GTK GUI. Almost everything in fceux.cfg is configurable via the GUI. Here's a list of some stuff I added:
* inputcfg - no hotkeys yet, but there's a GUI for gamepad config
* video dialog
* sound dialog - all options and mixers for each sound channel
* palette dialog - also includes color/tint/hue
Your work on GTK GUI sounds interesting, any possibility to share your GUI's source code so I could compile it? In this community including visitors and me might have different distributions to play with ;)
I have a simple question:
How to disable the pressing left+right up+down simultaneously on Linux (GTK)?
The CHM file shipped with the emulator mentions that option, but I don't find it anywhere.
(Zelda 2: Adventure of Link glitches badly when left and right are both pressed.)
This feature was added to the Linux (SDL/GTK) version after the most recent release, so you will need to either wait for the next release or compile the latest subversion code. With the latest release, you can adjust the "SDL.Input.EnableOppositeDirectionals" value within "~/.fceux/fceux.cfg" to 0 to disable this behavior. If I recall correctly, an option was also added to the input configuration dialog (Gamepad Config) as a checkbox to toggle.
Sorry, I should have mentioned that I tried compiling the SVN version but I got the following error:
/usr/bin/ld: src/lua/src/loadlib.o: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'
/usr/bin/ld: note: 'dlclose@@GLIBC_2.2.5' is defined in DSO /usr/lib/x86_64-linux-gnu/libdl.so so try adding it to the linker command line
/usr/lib/x86_64-linux-gnu/libdl.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
But thanks very much for responding to my post :)
What distribution and distribution version are you attempting to compile this on?
Thanks in advance!
Hi, lead fceux SDL developer here
this issue has been resolved in the latest subversion source. you can get the latest source from here: http://sourceforge.net/p/fceultra/code/2612/tree/
If you still have issues with the latest source, feel free to PM me
Has anyone managed to get the iup lua libraries to work in linux?
LUA works fine in linux but the iups are hell to install/configure.
I can't even get them to work. And i'm the fceuX-SDL dev xfd
Hey tasvids,
I've been working hard on the GTK GUI. Almost everything in fceux.cfg is configurable via the GUI. Here's a list of some stuff I added:
* inputcfg - no hotkeys yet, but there's a GUI for gamepad config
* video dialog
* sound dialog - all options and mixers for each sound channel
* palette dialog - also includes color/tint/hue
movie loading, lua script loading, rom loading, and some other command are also available via menus
there's more to come and it will be polished more in the near future, but any feedback would be great!
here's a deb package for 64bit. it was built on ubuntu 9.10 with SDL 1.2.14. as with all linux binaries, YMMV, but if all else fails just compile the source in subversion.
http://megaupload.com/=dFCMDASUI
edit - new link; other one was bad
edit2: megaupload is down :( and these binaries are so old that you shouldn't be using them
It is both, IIRC. I remember commenting this out by hand when I found this undesirable; if you look at FCEU_DispMessage (video.cpp) there's an exception made during AVI recording specifically for the "playback stopped" message.
seems like an option to disable on-screen messages would be reasonable