I'm not familiar with it but yes, I was told this included the 16 byte header (eg: rom.readbyte(1) returns the first byte of the header). Imo it's not a bad thing, although it may be a little misleading. Maybe the function can be renamed and the user can do the +16 for himself?
Unless these headers can be of variable length? In which case some mapping function could be added or something.
Headers are always 16 bytes, and ... what?
rom.readbyte(1) should return the second byte of the ROM. Not the first. But I digress...
There should be a rom.header function if they want to include that. Hell, allow reading what kind of data it is putting out as well if they're going to be like that. Mirroring, mapper type, size etc.
Also, there should be a rom.writebyte too ;) That could coincide with the Hex Editor's real-time editing feature(s).
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Xkeeper wrote:
rom.readbyte(1) should return the second byte of the ROM. Not the first. But I digress...
Um, yes.
Xkeeper wrote:
There should be a rom.header function if they want to include that. Hell, allow reading what kind of data it is putting out as well if they're going to be like that. Mirroring, mapper type, size etc.
I'll read that as "Yes, rename the function to prevent confusion, we can do the +16 operation ourselves", then. One could also interpret the "rom" table name as the rom-file, instead of the read-only-memory. In such case things are fine. Maybe rename "rom" to "romfile"?
Xkeeper wrote:
Also, there should be a rom.writebyte too ;) That could coincide with the Hex Editor's real-time editing feature(s).
rom.readbyte(1) should return the second byte of the ROM. Not the first. But I digress...
Um, yes.
I hope that means you understood what I said.
Xkeeper wrote:
There should be a rom.header function if they want to include that. Hell, allow reading what kind of data it is putting out as well if they're going to be like that. Mirroring, mapper type, size etc.
I'll read that as "Yes, rename the function to prevent confusion, we can do the +16 operation ourselves", then.
No, it was saying that if they want to read the header, then there should just be a function that returns useful pieces of the ROM's header, such as mapper, mirroring, ROM sizes, etc.
One could also interpret the "rom" table name as the rom-file, instead of the read-only-memory. In such case things are fine. Maybe rename "rom" to "romfile"?
Or just keep it ROM and read the actual ROM and not the header.
Xkeeper wrote:
Also, there should be a rom.writebyte too ;) That could coincide with the Hex Editor's real-time editing feature(s).
I was told this isn't as easy but idk.
They already have the feature. It's in the Hex Editor -- I'm not sure at all how simply calling whatever does that editing within Lua could be that difficult.
Then again, we still don't have a way to read the emulation registers (mirroring, sound, scroll) or anything else, so...
By the way, every user of the SDL build may feel free to test "scons CREATE_AVI=1" and report on success/failture. I know it works for me (and probably Bisqwit), but I haven't seen anyone else using it yet.
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
When recording a movie, FCEUX 2.0.3 doesn't display frame counter when the emulator is paused or when frame advancing, but the frame counter does show when recording in 100% speed. And I do have the "Display frame counter" option checked. This bug wasn't present in version 2.0.2.
Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
franpa wrote:
FCEUX 2.0.3 Windows XP (not SDL)
Scale 3x Windowed - Drag the right side of the screen to the right to increase the height of the emulator, drag to the left to cause constant flicker between 2 window sizes.
force integral scaling factors - on
force aspect ratio correction - on
Is this something that you didn't experience on the the .2 release? Also, I tried those settings and could not recreate your bug.
Randil wrote:
When recording a movie, FCEUX 2.0.3 doesn't display frame counter when the emulator is paused or when frame advancing, but the frame counter does show when recording in 100% speed. And I do have the "Display frame counter" option checked. This bug wasn't present in version 2.0.2.
Yes, this is a major problem. I have tracked down where this bug was introduced and hopefully can get a fix for this right away.
I am having trouble viewing the help file. Also, my computer is complaining of "unknown publisher" whenever I attempt to run the .exe or open the help file. I can run the .exe anyway, but the help file can't be viewed.
I did not have this problem with FCEUX 2.0.2, and I never got any warning about "unknown publisher" in that version. I specifically remember the warning never popping up for 2.0.2, and I still can see the help file in that version. For 2.0.3, I get a warning and can't even view the help file, either directly or through the executable.
When I attempt to access the help, I see a lovely Internet Explorer was unable to link to the Web page you requested. The page might be temporarily unavailable. In the help viewer.
I am using Windows XP Professional, if it matters.
Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Wow, I have no idea about that. I didn't do anything different to the help file. Perhaps just copy over the helpfile from .2. Nothing is different (come to think of it, I even forgot to add the .3 changelog to it)
I opened up Command Prompt and told FC to compare the two files. Apparently, there are a few differences between the files, but the question is, if you largely did nothing, then how did these differences arise? A binary comparison picked up 62 bytes that do not match (In three distinct areas), although the two files are exactly the same size.
If they were exactly the same, I would have to question my operating system's sanity. Why accept one without question, but flatly refuse to run the other? In this case, I'm still questioning things, but at least I can detect some difference between the files.
I don't understand enough to figure out why 62 bytes is enough to call up a warning and prevent me from reading the contents of the file. If no one else is coming up with any problems, then the problem might be on my end. If that is the case, then for some reason, my computer is especially picky about something.
Well, thanks for letting me know the (lack of) changes made to the help file. I'll try a few more things before giving up on the file.
Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Oh I forgot to post this. This fixes the frame counter bug. It turns out it was introduced when porting over some of Bisqwit's patch.
http://fceux.com
So this is the .4 interim.
What I did is change frame advance from "backslash" to ctrl (right), and checked other hotkey to see if other were using ctrl (I don't think there was)
Then if I try to use ctrl, it pause emu, then unpause itself after 1 second. Or sometime cause emu to lock up. Once I had emu opening up all emu windows (debugger, cheat menu, input config window, etc etc...)
Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
In general it is not a good idea to use ctrl, alt, or shift as hotkeys. In this case weird things are happening because FCEUX has accel keys built into it. Ctrl+O opens a rom, for instance.
I used ctrl as frame advance all the time for fceu 98.##
I mean, I use right hand on arrows and thumb on ctrl. Left hand on gamepad pro 4 buttons since that keyboard doesn't accept 3 keys or more.
If I try to make mario moves right and jump in frame advance, I use my left hand on a button then right hand for arrow right, then tap frame advance with thumb on ctrl, there's no other suitable key for a thumb while being on arrows keys.
Number 0 on keypad would have been next suitable key for the pinky finger, but again keyboard doesn't accept 3 keys at a time (if I press left + right + 0, keyboard would ignore 0) ctrl, alt, del doesn't limit keys.
I guess it might be the end of fceu tas for me.
Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Is this a laptop or possibly USB keyboard?
I can't recreate your problem on my PC, so I am not sure what the problem is.
Still, in general, on emulators I would avoid using ctrl, alt, or shift as hotkeys.
EDIT:
http://fceux.com
interim build updated. I removed the accel keys table from the main window. Since they were only used on open/close ROM I just made a remappable hotkey entry for both.
See if this fixes your problem.
On a PC, win xp pro SP3. USB keyboard.
I just tried new 2.0.4 interim. It behaves differently from 2.0.3 but still not working right.
The different from previous was:
Sometime if I push CTRL, it does pause (but other time it won't).
While it's being paused, if I push CTRL again, it goes 1 frame, then it decides to unpause after 1 second later.
No lockup so far.
Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
So yeah, it is the USB keyboard. It is probably that particular one is causing some keyboard codes that FCEUX isn't recognizing. There is already a similar bug report where the special buttons such as volume up/down cause weird behavior.
We have attempted to fix that but so far no success. In the meantime try using a regular keyboard if you have one laying around.
Is this something that you didn't experience on the the .2 release? Also, I tried those settings and could not recreate your bug.
http://download21.mediafire.com/iz3nsiilw0mg/uy1nzqgykzg/fceux.cfg
try that config file and just drag the right side of the window to the left, occurs under XP Home and Vista Home Premium 32bits. I do not remember if it occurs on the .2 release, but I believe it did yet I never bothered to mention it at the time because it doesn't really 'harm' a users work flow.
Joined: 10/11/2008
Posts: 64
Location: Kajaani, Finland
Could you fix the bug that when I am recording movies and it can randomly crash? I can still append the movie and it works fine, but it's annoying when I record movie and it crashes. Any fixes to this?
I'm sorry, but that's like saying "My car just made a strange noise, fix it over the internet for me, please". Could you elaborate how this happened exactly and/or how to reproduce this?
I actually get random crashes all the time, but I have no idea what causes them. (It seems to happen more frequently when I'm dealing with Lua, but happens even without.)
Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
It is also particularly hard to fix vague crash bugs when I can't reproduce them. FCEUX hasn't crashed one time for me since it was released. And the past 4-5 non crashing bug reports are also things I have never experienced.
FCEUX seems to behave quite differently from one computer to the next :/
