Joined: 4/21/2004
Posts: 3517
Location: Stockholm, Sweden
Enabling a hotkey for "Background input" would ease time-wise my 9-tas run tremendously.
Nitrogenesis wrote:
Guys I come from the DidyKnogRacist communite, and you are all wrong, tihs is the run of the mileniun and everyone who says otherwise dosnt know any bater! I found this run vary ease to masturbate too!!!! Don't fuck with me, I know this game so that mean I'm always right!StupedfackincommunityTASVideoz!!!!!!
Arc wrote:
I enjoyed this movie in which hands firmly gripping a shaft lead to balls deep in multiple holes.
natt wrote:
I don't want to get involved in this discussion, but as a point of fact C# is literally the first goddamn thing on that fucking page you linked did you even fucking read it
Cooljay wrote:
Mayor Haggar and Cody are such nice people for the community. Metro City's hospitals reached an all time new record of incoming patients due to their great efforts :P
while true do
gui.box(0, 8,255,231,0x00FF0001,0x00FF0001)
emu.frameadvance()
end
Should paint an (almost) invisible green box on the entire screen. You shouldn't notice any difference in color.
What's likely a bug is the fact I see everything is shifted up 8 pixels.
For more fun, here's a small box you can drag around:
Language: lua
local lastkeys, keys= input.get(), input.get()
--*****************************************************************************
local function UpdateKeys() lastkeys= keys; keys= input.get() end
--*****************************************************************************
local function Limits(V,l,h) return math.max(math.min(V,h),l) end
--*****************************************************************************
local x,y= 50, 50
local function Fn()
UpdateKeys()
if keys.leftclick then
x= Limits(x+keys.xmouse-lastkeys.xmouse , 0 , 235)
y= Limits(y+keys.ymouse-lastkeys.ymouse , 8 , 211)
end
gui.box(x,y,x+20,y+20,0x00FF0001,0x00FF0040)
end
gui.register(Fn)
What's likely a bug is the fact I see everything is shifted up 8 pixels.
Actually, I think that was a bugfix: text at position (0, 0), for example, actually is both visible and starting in the exact top left corner of the screen now. :p
I'm talking about the display of the NES graphics.
That is to say, where the gui.box is placed, it's showing the NES graphics 8 pixels down from that spot. And I'm not even sure what it's trying to display on the 8 bottommost pixels.
EDIT: Notably, in my first tiny script, seeing the giant screen-filling box isn't intended -- The alpha is 1, meaning it's almost invisible. Seeing any difference here shouldn't happen whether the script is running or not. Setting an alpha of 0, on the other hand, will not shift the NES graphics at all.
EDIT2: Here's what I believe is happening...
With the recent changes in the lua gui display, it now paints the pixel at a location depending on whatever offset is in Config -> Video... -> Drawing Area. The destination for the pixel is affected, but not the source pixel when mixing colors with alpha blending. Hence, the 8 pixel offset I'm seeing.
Using svn2085.
EDIT3: Because I'm impatient and constantly worry about whether my responses mean anything, just do this.
- Run my 4-line lua script in my previous post.
- Play out at least one frame.
One of two things should result:
- You notice no difference.
The bug I describe does not exist. At least, under whatever version you're running.
The four line script basically puts up a box that covers the entire screen. But with an alpha of 1 (almost completely transparent), and with FCEUX's color limitation, there really should be no visible difference to speak of.
- The game graphics are shifted upwards by 8 pixels
This is exactly the bug I am describing.
A translucent box shouldn't be moving game graphics, to my knowledge. It should simply blend with the graphics as needed and not end up shifting things around. I'm aware the lua gui may be shifted, but I don't think that should include shifting the game graphics wherever the lua script paints things.
FCEUX 2.1.4a is fine here.
FCEUX 2.1.5 appears to have broken here.
This is as complete as I know how to describe my problem. Apologies for my frequent edits.
I have a feature request:
The .FM2 extension shall be associated with FCEUX at startup, if it is not already registered. When a filename with a .FM2 extension is passed on the command line, the emulator reads it in and searches for the game's checksum in a configuration file containing a list of filenames, modification times and checksums. If not found, it scans the designated Roms directory and computes the checksum of every file with a .NES or .FDS extension that is not listed or has a different modification time, until a matching checksum is found, then it adds the filename, modification time and checksum to the list. If a file was found, the matching ROM is loaded and the movie file is started. If no file is found, the Open ROM dialog is displayed, and if the user presses OK, the selected ROM is loaded and the movie file is started. This would make it easy to download and watch movies in one click.
Just wanted to mention there's a minor bug in the noise channel after switching between NTSC and PAL mode.
Start a game in PAL mode, or change to PAL mode and reset. Switch to NTSC mode. Noise becomes higher pitched than it would otherwise be. Most noticeable for looped noise mode. Example: Quick Man's stage in Mega Man 2. Resetting again fixes the problem.
Also, there's a spam entry on the SF bug tracker that hasn't been deleted.
Does it mean it's acceptable to submit a TAS with TaoTao's version instead of the new FCEUX 2.1.5?
I only ask this because my first TAS I'm working on (Indiana Jones and the Temple of Doom Thread #11250: Indiana Jones and the Temple of Doom) is also suffers from this (enemy position, hidden exit and an unnamed glitch depends on CPU clock, that's why my WIP shows different result on 2.1.5 and TaoTao's patch) and I would like to take benefit of higher accuracy instead of "reworking" the same for a "possibly not accurate" version of FCEUX.
I dunno, that is a sucky situation and would like to not worry about it.
Considering that it is an accuracy fix I would like to eventually see this in FCEUX. The change would break some runs for sure. NES runs are being console verified. On NES I would rather side with the real hardware and hold on to my TAS for FCEUX to implement this.
As the bug FatRatKnight described seems to be fixed, no graphics is shifted inside his boxes, we have totally rewrote the AVI-HeadsUpDisplay script. Though some secret guy is going to allow us recording HUD onto AVI as an option of FCEUX, it won't be movable and won't contain regular timer as this script allows.
http://pastebin.com/fJq0zGjc
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Enabling a hotkey for "Background input" would ease time-wise my 9-tas run tremendously.
Let's imagine, you have it. If it is checked for all emulators, all you can do is unchecking it after you recorded them all. But how you gonna check it back for all emulators? They don't accept background input once you unchecked it. It's not some global system hotkey, that can be read regardless of being disabled.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I came across a little graphical lua bug.
When I draw a transparent box, using gui.drawbox and gui.opacity, stuff rendered from the game is displaced.
Also, it doesn't seem to be able to read words and dwords.
FCEUX can't readword. Your script works fine in 2.1.6 interim, but not in 2.1.5.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I currently use fceux 2.1.6 and the Ram Watch seems to not work properly. All of the addresses and names that I gave them are saved and remain but the specific details of them are not saved. What I mean by that is that the values are placed to be hex values (I believe) instead of the signed or unsigned options that I have them saved as.
Is this a known bug, is there something wrong with the revision I am using, or is this someone a completely unique error?
I didn't want to create a new thread. Sorry if this was not the place for this.
Edit
OK and now when I open the watch file that wouldn't cooperate it crashes fceux. What the hell?
This isn't known bug, because most people use Memory Watch instead of RAM Watch.
I fixed these 2 loading bugs in r2498. Now try finding a .wch that can crash FCEUX!
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.)
Hi ans, there seems to be something weird going on with the lua colors:
The boxes that have a white outline over enemies are actually set to have a yellow outline and yellow fill ("#FFFF0040","#FFFF00FF") but they show up more white than anything.
Here's the same script running in bizhawk using the same color codes and how it should look:
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 8/14/2009
Posts: 4083
Location: The Netherlands
I can also see the images just fine.
http://www.youtube.com/Noxxa
<dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects.
<Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits
<adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Pasky13, that's because FCEUX Lua draws images using NES palette, while Bizhawk Lua uses RGB (platform-independent). So it's not a bug, only a limitation.
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.
FCEUX doesn't seem to read any input when I load an FDS game. I tried mapping to my gamepad and keyboard, and running it in GNU/Linux and Windows. No matter what, it never sees any of my button presses (but it works fine with cartridge ROMs). What's the deal with that?
Also, it doesn't seem to be able to read words and dwords.
The boxes that have a white outline over enemies are actually set to have a yellow outline and yellow fill ("#FFFF0040","#FFFF00FF") but they show up more white than anything.
Here's the same script running in bizhawk using the same color codes and how it should look:
