The best would be when the game speed was displayed a certain, short, period of time, independent of the frames, so that it is readable, but doesn't get displayed too long.
It is a period of time, independent of how many frames go by. But, apparently only if you pause it.
Angerfist seems to be right that at low speeds when not using pause or frame advance there is an extra 1-frame delay of input relative to the display update, I'll try to fix that...
Hmm, does the frame count disappear after a few seconds too? I think it would be good to leave it up in case you start to forget what it was, but let you turn it off without having to advance a frame in case you want to see the screen under it.
put yourself in my rocketpack if that poochie is one outrageous dude
I'm trying to compile on NetBSD 2.0 (and an ubuntu 5.10 box, too), and I ran into the same problem that dugan had above. Taking care of that, I now get this collection of messages:
gmake[1]: Entering directory `/home/evan/tmp/fceu-nitsuja-src/src'
gcc -Wall -fomit-frame-pointer -g -O2 -I/usr/pkg/include/SDL -D_REENTRANT -o fceu x6502.o fceustr.o cart.o cheat.o crc32.o debug.o endian.o fceu.o fds.o file.o filter.o general.o ines.o input.o md5.o memory.o netplay.o nsf.o palette.o ppu.o sound.o state.o unif.o video.o vsuni.o wave.o movie.o unzip.o boards/mmc5.o boards/mmc3.o boards/mmc1.o boards/tengen.o boards/bonza.o boards/deirom.o boards/dream.o boards/konami-qtai.o boards/n106.o boards/karaoke.o boards/90.o boards/112.o boards/164.o boards/183.o boards/186.o boards/8237.o boards/8157.o boards/addrlatch.o boards/datalatch.o boards/h2288.o boards/malee.o boards/novel.o boards/sachen.o boards/subor.o boards/super24.o boards/supervision.o input/cursor.o input/zapper.o input/powerpad.o input/arkanoid.o input/shadow.o input/fkb.o input/hypershot.o input/mahjong.o input/oekakids.o input/ftrainer.o input/quiz.o input/toprider.o input/bworld.o input/suborkb.o mappers/6.o mappers/8.o mappers/15.o mappers/16.o mappers/17.o mappers/18.o mappers/21.o mappers/22.o mappers/23.o mappers/24and26.o mappers/25.o mappers/27.o mappers/32.o mappers/33.o mappers/40.o mappers/41.o mappers/42.o mappers/43.o mappers/46.o mappers/50.o mappers/51.o mappers/57.o mappers/58.o mappers/59.o mappers/60.o mappers/61.o mappers/62.o mappers/65.o mappers/67.o mappers/68.o mappers/69.o mappers/71.o mappers/72.o mappers/73.o mappers/75.o mappers/76.o mappers/77.o mappers/79.o mappers/80.o mappers/82.o mappers/83.o mappers/85.o mappers/86.o mappers/88.o mappers/89.o mappers/91.o mappers/92.o mappers/95.o mappers/97.o mappers/99.o mappers/113.o mappers/117.o mappers/151.o mappers/180.o mappers/183.o mappers/184.o mappers/187.o mappers/189.o mappers/193.o mappers/200.o mappers/201.o mappers/202.o mappers/203.o mappers/204.o mappers/208.o mappers/211.o mappers/212.o mappers/213.o mappers/214.o mappers/215.o mappers/217.o mappers/225.o mappers/226.o mappers/227.o mappers/228.o mappers/229.o mappers/230.o mappers/231.o mappers/232.o mappers/234.o mappers/235.o mappers/240.o mappers/241.o mappers/242.o mappers/244.o mappers/246.o mappers/255.o mappers/emu2413.o mappers/mmc2and4.o mappers/simple.o drivers/common/args.o drivers/common/cheat.o drivers/common/config.o drivers/common/vidblit.o drivers/common/hq2x.o drivers/common/hq3x.o drivers/common/scale2x.o drivers/common/scale3x.o drivers/common/scalebit.o drivers/sexyal/sexyal.o drivers/sexyal/md5.o drivers/sexyal/smallc.o drivers/sexyal/convert.o drivers/sexyal/drivers/oss.o drivers/pc/input.o drivers/pc/main.o drivers/pc/sdl.o drivers/pc/sdl-joystick.o drivers/pc/sdl-sound.o drivers/pc/sdl-throttle.o drivers/pc/sdl-video.o drivers/pc/unix-netplay.o -lz -lz -L/usr/pkg/lib -Wl,-rpath,/usr/pkg/lib -lSDL -lossaudio -lpthread -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -L/usr/X11R6/lib -Wl,-R/usr/X11R6/lib -lm -L/usr/X11R6/lib -lX11 -lXext -L/usr/pkg/lib -laa-x11 -lm -L/usr/X11R6/lib -lX11 -lusbhid
input.o(.text+0x879): In function `CommandEmulationSpeed':
/home/evan/tmp/fceu-nitsuja-src/src/input.c:626: undefined reference to `FCEUD_SetEmulationSpeed'
input.o(.text+0xa51): In function `CommandSoundAdjust':
/home/evan/tmp/fceu-nitsuja-src/src/input.c:711: undefined reference to `FCEUD_SoundVolumeAdjust'
input.o(.data+0x140): In function `B4016':
/home/evan/tmp/fceu-nitsuja-src/src/input.c:143: undefined reference to `FCEUD_HideMenuToggle'
input.o(.data+0x1d0): In function `FCEU_DrawInput':
/home/evan/tmp/fceu-nitsuja-src/src/input.c:177: undefined reference to `FCEUD_TurboOn'
input.o(.data+0x1d4):/home/evan/tmp/fceu-nitsuja-src/src/input.c:177: undefined reference to `FCEUD_TurboOff'
input.o(.data+0x320): In function `FCEU_UpdateInput':
/home/evan/tmp/fceu-nitsuja-src/src/input.c:202: undefined reference to `FCEUD_SaveStateAs'
input.o(.data+0x440): In function `CheckSLHook':
/home/evan/tmp/fceu-nitsuja-src/src/input.c:268: undefined reference to `FCEUD_LoadStateFrom'
input.o(.data+0x680): In function `FCEUI_SetInput':
/home/evan/tmp/fceu-nitsuja-src/src/input.c:358: undefined reference to `FCEUD_MovieRecordTo'
input.o(.data+0x7a0): In function `FCEUI_HandleEmuCommands':
/home/evan/tmp/fceu-nitsuja-src/src/input.c:601: undefined reference to `FCEUD_MovieReplayFrom'
input.o(.data+0x8a8): In function `CommandSelectSaveSlot':
/home/evan/tmp/fceu-nitsuja-src/src/input.c:638: undefined reference to `FCEUD_MovieStop'
input.o(.data+0x908): In function `CommandStateSave':
/home/evan/tmp/fceu-nitsuja-src/src/input.c:650: undefined reference to `FCEUD_ToggleStatusIcon'
input.o(.data+0x920): In function `CommandStateLoad':
/home/evan/tmp/fceu-nitsuja-src/src/input.c:655: undefined reference to `FCEUD_SoundToggle'
input.o(.data+0x980): In function `CommandMovieSelectSlot':
/home/evan/tmp/fceu-nitsuja-src/src/input.c:674: undefined reference to `FCEUD_AviRecordTo'
input.o(.data+0x998):/home/evan/tmp/fceu-nitsuja-src/src/input.c:670: undefined reference to `FCEUD_AviStop'
ppu.o(.text+0x2a49): In function `FCEUPPU_Loop':
/home/evan/tmp/fceu-nitsuja-src/src/ppu.c:1361: undefined reference to `PPUViewer'
ppu.o(.text+0x2a59):/home/evan/tmp/fceu-nitsuja-src/src/ppu.c:1361: undefined reference to `PPUViewScanline'
ppu.o(.text+0x2ae5):/home/evan/tmp/fceu-nitsuja-src/src/ppu.c:1376: undefined reference to `UpdatePPUView'
video.o(.text+0x528): In function `FCEU_DrawRecordingStatus':
/home/evan/tmp/fceu-nitsuja-src/src/video.c:112: undefined reference to `FCEUD_ShowStatusIcon'
video.o(.text+0x5a5): In function `FCEU_PutImage':
/home/evan/tmp/fceu-nitsuja-src/src/video.c:143: undefined reference to `FCEUI_AviIsRecording'
video.o(.text+0x6b6):/home/evan/tmp/fceu-nitsuja-src/src/video.c:166: undefined reference to `FCEUI_AviVideoUpdate'
gmake[1]: *** [fceu] Error 1
gmake[1]: Leaving directory `/home/evan/tmp/fceu-nitsuja-src/src'
gmake: *** [all-recursive] Error 1
It looked to me like all of these undefined references point to functions from code in the drivers/win/ directory. Again, this is happening for me in both Ubuntu and NetBSD.
Also, I learned that NetBSD's zlib.h does not define OF(), so the compile fails at unzip.c, too. There is an easy fix for this, just add these lines to unzip.h:
#ifndef OF
#define OF(a) a
#endif
One more thing, the link to this patched fceu version was outdated on the wiki emulator page. Somebody might want to point it to the more recent version that was in this thread.
Apparently that means this is the first time anybody has ever tried compiling FCEU with SDL since before Blip's first 0.98.12 version was released, or at least the first time they've complained about it here...
Most of these need to be either duplicated from the windows source into the SDL source (such as SetEmulationSpeed) or added as a dummy function to the SDL source (such as HideMenuToggle).
Andy Olivera wrote:
There's still some desync in the AVIs, though much less severe than before. I think it's caused by the values in FCEUI_GetDesiredFPS().
Actually, the AVI code didn't use FCEUI_GetDesiredFPS(), it used exactly 50 or 60 FPS. As it turns out, this is what was causing the audio/video desync all along - I tried changing it to use FCEUI_GetDesiredFPS() instead of 50 or 60 and now it's perfectly in sync.
Hmm, does the frame count disappear after a few seconds too? I think it would be good to leave it up in case you start to forget what it was, but let you turn it off without having to advance a frame in case you want to see the screen under it.
I missed this post, but no, the frame count / input display doesn't disappear after a few seconds (it used to, but it was annoying so I changed that in an earlier version).
That was quick on the new version! I had to fix it up a little more to get it to compile:
Added another dummy function and changed some types in that dummy section of sdl.c:
This one was a problem that I had before and forgot to mention:
drivers/pc/input.c: In function `KeyboardCommands':
drivers/pc/input.c:269: error: too few arguments to function `FCEUI_SelectMovie'
drivers/pc/input.c:269: error: too few arguments to function `FCEUI_SelectState'
drivers/pc/input.c:270: error: too few arguments to function `FCEUI_SelectMovie'
drivers/pc/input.c:270: error: too few arguments to function `FCEUI_SelectState'
drivers/pc/input.c:271: error: too few arguments to function `FCEUI_SelectMovie'
drivers/pc/input.c:271: error: too few arguments to function `FCEUI_SelectState'
...etc...
I changed the relevant lines in input.c to SelectMovie(x,1) and SelectState(x,1) so it would compile, but I didn't really look at what the int was for.
And that's that. Compiles and runs, but no sound at all. I wasn't expecting that, but everything else is only broken where I figured it would be.
It doesn't run at all? What the hell? OK, well there's an easy way to work around it: Copy your fceu98.cfg file from your previous version of FCEU into the directory of v6, and then it should run fine. You'd probably want to do that anyway so you don't have to reconfigure all your settings.
Copying the config file also doesn't seem to help.
It keeps getting this windows error message:
(don't know what it exactly says in English, since the message isn't in English)
"An error has occured at fceu.exe and has to be closed. Sorry for this inconvienience.
Blah blah blah
You want to tell microsoft about this problem:
Send report, don't send"
Just wanted to let you know that the newest version compiles for me without any problems.
I solved my sound problem, too, in case anyone in the future is looking for a solution. For NetBSD, all instances of "/dev/dsp" in drivers/sexyal/drivers/oss.c needed to be replaced by "/dev/audio" (or whatever else is appropriate).
Well, after converting the 73 minute Final Fantasy run I think it's safe to say the AVI sync issue has finally been fixed! Bravo Nitsuja!!!
In other news, the AVI splitting routine wasn't working, so I came up with some code to fix it. On the downside, there's no easy way to compute a file's length in C. On the upside, AVIStreamWrite() will send the number of bytes written to a variable, so we can just add as we go.
Add the bold stuff. The rest is for reference.
Add two globals at the top of aviout.c:long Bytebuffer;
long tBytes;Add to avi_open():
avi_file->video_frames = 0;
avi_file->sound_samples = 0;
tBytes = 0;
Bytebuffer = 0;Change FCEUI_AviSoundUpdate():
Replace:
if(FAILED(AVIStreamWrite(avi_file->compressed_streams[AUDIO_STREAM], avi_file->sound_samples, soundLen, soundData, nBytes, 0, NULL, NULL)))
With:
if(FAILED(AVIStreamWrite(avi_file->compressed_streams[AUDIO_STREAM], avi_file->sound_samples, soundLen, soundData, nBytes, 0, NULL, &Bytebuffer)))Add to FCEUI_AviSoundUpdate():
avi_file->sound_samples += soundLen;
tBytes += Bytebuffer;Change FCEUI_AviVideoUpdate():
Replace:
if(FAILED(AVIStreamWrite(avi_file->compressed_streams[VIDEO_STREAM], avi_file->video_frames, 1, avi_file->convert_buffer, avi_file->bitmap_format.biSizeImage, AVIIF_KEYFRAME, NULL, NULL)))
With:
if(FAILED(AVIStreamWrite(avi_file->compressed_streams[VIDEO_STREAM], avi_file->video_frames, 1, avi_file->convert_buffer, avi_file->bitmap_format.biSizeImage, AVIIF_KEYFRAME, NULL, &Bytebuffer)))Add FCEUI_AviVideoUpdate():
avi_file->video_frames++;
tBytes += Bytebuffer;Change FCEUI_AviVideoUpdate():
Replace:
// segment / split AVI when it's almost 2 GB
if(!(avi_file->video_frames%60))
{
char* findGlob=saved_cur_avi_fnameandext;
WIN32_FIND_DATA wfd;
HANDLE hFind;
int i=0;
memset(&wfd, 0, sizeof(wfd));
hFind = FindFirstFile(findGlob, &wfd);
if(hFind != INVALID_HANDLE_VALUE)
{
int size=wfd.nFileSizeLow;
if(size>(2048-100)*1024*1024) // 2 GB - 100 MB
{
FCEUI_AviNextSegment();
}
FindClose(hFind);
}
free(findGlob);
}
With:
// segment / split AVI when it's almost 2 GB (2000MB, to be precise)
if(!(avi_file->video_frames % 60) && tBytes > 2097152000)
FCEUI_AviNextSegment();
In other news, the AVI splitting routine wasn't working
What isn't working about it? You're saying that FCEUI_AviNextSegment works, but the filesize check doesn't work at all? wfd.nFileSizeLow should definitely contain the size of the file (unless it's over 4GB, which it can't be), so I'm not sure what part you're saying was wrong.
Andy Olivera wrote:
On the downside, there's no easy way to compute a file's length in C.
No, actually this is quite easy with fseek and ftell. The real problem is that there's no easy way to compute the length of a file that the OS is denying both read and write access to. The Windows API has a way around that, which is to match the file with a findfile call and ask the size of the file, which works even when opening the file with read access would fail.
The size check wasn't working. Your code looked fine, though, so I tried a different approach. FCEUI_AviNextSegment() works exactly like it's supposed to...
OK, well I was asking what part of the size check wasn't working, but I guess you're not sure of that... The first thing that comes to mind is that maybe you have the AVI being saved to some weird pathname that findfile for some reason isn't able to find, or that something is wrong with the code that stores the filename. It works fine for me when I try it...
But, anyway, I wasn't aware that plBytesWritten of AVIStreamWrite gives the actual number of bytes written taking compression into account (as opposed to the number of source bytes you told it to write). Everyone I asked said it doesn't, and MSDN doesn't say a thing about it. That's a much preferable method if it works.
OK, well I was asking what part of the size check wasn't working, but I guess you're not sure of that...
Nope. I didn't do any debugging beyond staring at the code and not having anything jump out at me.:-)
The first thing that comes to mind is that maybe you have the AVI being saved to some weird pathname that findfile for some reason isn't able to find
Just f:\fceu. I thought it might've had something to do with the usage of spaces in the filename, but it occurres without, as well. Weird...
I wasn't aware that plBytesWritten of AVIStreamWrite gives the actual number of bytes written taking compression into account (as opposed to the number of source bytes you told it to write).
I wasn't sure either. In fact, before I remembered that variable I'd changed it to a simple frames*framesize calculation(it worked, but split the file too often when using compression, of course). After testing plBytesWritten with uncompressed and two different compression codecs I can confirm it is writing the final number of bytes, not just the size of the buffer it's fed.
When updating version, is it possible that old custom configuration compatible? It's pretty sad always reconfigurating things.
Well, it's just a suggestion. It's not absolutely required but nice to have.
I don't think v6 will be the last version but the differences between blip's version and this one is so big that there won't probably have not so much another new versions but still. With the new FCM format that will make movies easily hex-editable and subtitles/chapters feature, except new mappers and boards, there won't be not so much new additions after.
I don't know if this post belongs in this topic but it's about improvments so here it is:
I think that if FCEU could show the pixels of the game it would be big help to players.
I don't know if it's possible though.
But I have idea how it could be done: With vertical and horizontal lines showing how wide and high one pixel is.
It could be big help for example in Rockman videos.
You could know exactly how far you can slide from a platform etc.
Ignore this post if you think the idea is stupid or someone has already posted it.
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
Guybrush wrote:
I don't know if this post belongs in this topic but it's about improvments so here it is:
I think that if FCEU could show the pixels of the game it would be big help to players.
I don't know if it's possible though.
But I have idea how it could be done: With vertical and horizontal lines showing how wide and high one pixel is.
It could be big help for example in Rockman videos.
You could know exactly how far you can slide from a platform etc.
Ignore this post if you think the idea is stupid or someone has already posted it.
I don't know if this post belongs in this topic but it's about improvments so here it is:
I think that if FCEU could show the pixels of the game it would be big help to players.
I don't know if it's possible though.
But I have idea how it could be done: With vertical and horizontal lines showing how wide and high one pixel is.
It could be big help for example in Rockman videos.
You could know exactly how far you can slide from a platform etc.
Ignore this post if you think the idea is stupid or someone has already posted it.
i think you mean a grid?
Yeah, that's the word I was looking for!
I couldn't find that word in my head so I just explained it.
So, is it possible or has it already been asked or done?
