Note that these games only use "45 degrees" ramps. Those 45-degrees slopes don't even need to have lookup tables because y(x+1) = y(x) + 1. It's easy to code such collisions with only addition/subtraction operations.
The same goes for further bisections, which are just y = x >> level, where "level" how many times the angle has been halved (45 = 1, 22.5=2, etc).
Derakon: I mean cyclical motion of the kind used by the Rotodiscs in Mario 3 (The glowing balls with the grid pattern that orbit around certain blocks).
I figure that if I can get that straightened out there ought to be a fairly straight-forward way to derive more complex patterns like ellipses, hypotrochoids, hypocycloids, etc. Or, then, I suppose that if I had a decent approximation of sinsoidal motion I could derive a circle from that.
The fire bars in SMB1 just used a pre-built lookup table for the offsets to place the fireballs at.
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Please note that we have added --
Use the magic of editing. Or at least ent_fire aperture_ai kill (or whatever it was).
Basically whoever updated the Lua drawing code fucked it up and now it draws 8 lines too low on every drawing call and cuts off 8 lines too early (combined, this means it draws 16 less lines than it should).
Easiest way to demonstrate this:
while true do
i = input.get();
gui.line(i.xmouse - 5, i.ymouse, i.xmouse + 5, i.ymouse, "red");
gui.line(i.xmouse, i.ymouse - 5, i.xmouse , i.ymouse + 5, "red");
emu.frameadvance();
(The line thickness is different but that is due to a whole other algorithm that works better anyway)
This breaks all drawing functions, from gui.text to gui.line and box and so on.
Code used for above demo:
while true do
gui.drawline(0, 0, 255, 255, "red");
gui.text( 190, 8, "I'm drawn at\n x 190 y 8");
FCEU.frameadvance()
end
(uses somewhat older methodologies to allow it to run in 2.1.1.)
Here's why I spoke about my anger in the IRC channel a while ago: Someone asked why, the reason amounted to nothing more than a whim, there are numerous posts speaking against this change, evidenced in this very thread, and apparently they're not good enough against said whim.
I made the mistake of thinking this was actually some idea that had some thought put into it.
My disappointment only grows. Ugh.
They're not going to fix it because it's an "intentional feature", and not a bug.
I think you missed the point of my post, which was that there are two pairs of two buttons for downloading and neither marks what the hell it actually is.
(Sorry, I guess I was unintentionally making fun of the lack of descriptions in publications too. Which is a fucking retarded idea, by the way. As usual.)
(And no, I'm not really fond of this mismanagement.)
Has there been any progress? I recently redownloaded the latest interm build ("updated nightly", which was apparently last September or so) and judging from the fairly ancient date and lack of FCEUX mailing list nags I'm guessing not.
orz
The "record microphone" thing is just a binary flag to indicate if the microphone is receiving sound -- FCEUX has no built-in support, at all.
As for the others, yes, give yourself a buffer. "Three, two, one, now", and as soon as you finish saying "now" start recording your input movie (Pause emulator > Record new movie, do countdown, unpause emulator). Then syncing is a breeze, since you know exactly where you started emulation. The only delay you would experience is +/- 0.25sec if you do it right (often even less)
And yes, using Fraps (or any other screen recorder) is a bad idea. Use FCEUX's AVI dump function, it works better. Use pre-recorded input files so that you can play the game without having to deal with potential slowdown or lag.
Voting no because what you did to the game is simply inhumane.
It's also inhuman but that's besides the point.
Mr.Inzult tested this by using PowerPak with a real NES. In a word, DelayStageClear in the BombManStage is possible also in real NES! (OldPPU of FCEUX is proven to be correct.)
And now I can vote no with a clear conscience! Thanks a bunch.
(Fun fact: I contributed absolutely nothing to the TAS my team put together other than Acmlm, who I found in some random drop on the first stage)
(actually, I never ran the ROM for more than about 10 seconds -- the throttle I use to keep my core temp below shutdown range doesn't even permit VBA to run at full speed. )
Xkeeper....Here is a copy and paste of *part* of a reply I posted in the ZSNES forums yesterday:
isamu wrote:
My ultimate goal though, is to one day see an snes emu, whether it be zsnes, bsnes (btw i am dumb) or snes9x, that will bring together a large online community where we can gather and watch each other play the games Live!!! Kinda like what GGPO does, but with snes games instead.
A netplay client that becomes very popular and has lots of people join in a lobby, where all we have to do is click on a "watch" button and proceed to spectate someone(or two) casually playing Super Mario Allstars. And at the top of the screen in the right hand corner it says "500 spectators". Call me an oddball, but that is a scenario I would KILL for! My gaming life would be complete!
Suffice to say Xkeeper, that after reading your description in that Youtube video, I am very excited to see what you will be able to accomplish with this project!
The biggest issue with something like that is "dynamically joining". If you join 30 minutes into someone's game session, how will it cope with that? You would have to transfer a state to the client.
Now think of several people joining... uh oh, now we have a ton of data to send (each state is quite large) and we probably don't want to count on the client sending this data every time.
One thing might be to have "regular" savestates (say, every 60 seconds or so) and keep an input buffer of that time, so that a client can get the latest, then fast forward up to the newest point.
This is all theoretical and highly depends on savestates being able to be read as binary data, as well as being portable. It's a nice pipe dream, but who knows if it is possible?
Netplay for old school emulation is simply not getting enough love in the emu community. Why anyone would frown upon the idea is beyond me. We need to get together and show the fighting game fans that it's not only about netplay to compete with each other, it's about the enjoyment that spectating brings. GGPO is gaining popularity by the day. But GGPO focuses on fighting games mainly, and things like live spectating is just a side benefit. I want to see a netplay client where the focus is "game broadcasting". And being able to watch someone play live and WITHIN the emulator...but for consoles rather than arcade.
Here's to seeing where this idea goes :)
I have a vested interest in it, because even as I'm typing this post, I'm watching someone play Final Fantasy 7 over ePSXe's (bad) netplay system, occasionally cracking jokes and talking about stuff. I do this with friends all the time; ZSNES is a favorite of mine, and we've beaten Breath of Fire 3, Tales of Destiny (a 2P game, no less) and a bunch of other stuff.
I want to see what I can do, but no guarantees. I'm, unfortunately, very very ... sporadic, and often can't really focus on one thing. Just look at the date between the cross-emulator test (the basic implementation) and this.
Hitting the bug in FCEUX -- and other emulator-specific oddities, really -- doesn't help much at all.
Patashu wrote:
How are you going to cope with latency?
The current plan is to have input buffered for all players by x frames, where x is a number appropriate for the network latency. My test used 6 and got a smooth framerate, for example. (When the buffer runs empty, the script goes into a loop waiting for more).
So, you push A on frame 1; the delay is 10, so the core saves your input in the joypad buffer for frame #11, and sends it to the client and marks it as being for that frame, as well.
This works in reverse, so the other player also has the same input delay.
It is theoretically possible to run it delay-free for one player, but at the same time the second player would experience twice the delay.
"Broadcast" games, where there is only one player repeating its input elsewhere, will be lag-free. (It wouldn't make much sense to delay it for nothing!)
As it is, the plan is to send one frame per packet, providing for a fairly steady stream of input, and no stupid input tricks like tripling your input or other crap. One keyframe every 5 frames my ass.
This is all preliminary, and still open to a lot of shaping. The test right now is just very basic and doesn't do much (if it fails to get a response the first time, it doesn't even bother retrying). Just a proof of concept.
I didn't want to build it up too much, but at the same time, the concept of an external netplay client that works in several emulators is too exciting for me to pass up.
You know, to that end, one interesting idea I had a night or two ago, making a special feature for VBA that would allow it to mess with the link cable. The problem is that the real cable doesn't have latency (much) and I'm not sure how well it would work. And that depends on several things being there in VBA, too.
We'll see.
It works as intended in VBA and possibly other emulators
VBA23 changelog wrote:
gochaism - Lua: changed joypad.set, it no longer adds input if the field value means false.
It might be unintended.
That seems to imply that it doesn't press the button.
The standard seems to be:
nil: do nothing. Leave it as is. (this is not used in the script for obvious reasons)
true: force button on.
false: force button off.
I'm not sure what that bug fixed or the end resolution, but as of my last test using the new release, it works as intended (delays buttons by a frame).
I was under the impression you were saying that it would be fixed by using emu.registerbefore() as opposed to the way it was done, so try not to take it the wrong way. (I was also using emu.registerbefore() in my test scripts -- I just moved it to the main loop to make it as simple as possible.)
And yes, I saw that post pretty soon afterwards, though it's really long and turns into a wall of text.
Regardless, I hope the issue is fixed soon.
The comments in the code are even worse. Lots of self-depreciation in it, since I made a lot of really dumb mistakes (including spending about an hour debugging a packet issue when it was really the repeater server sending strlen(strlen($buf)) of $buf (as in, a lot less than it should have).
Case in point, here's a snip:
-- netplay.start
-- sets up sockets, the connections, and other things
-- that will be relied on later for smooth sailing
-- settings table is currently just 'host'
-- but will later allow the delay, what players to use, etc.
-- Actually, this may be moved to an 'init' function,
-- with "start" setting up the game, configuring the delay, and
-- other stuff -- allowing runtime configuration of
-- controller values and other crap
function netplay.start(mode, settings)
if mode == "server" then
-- TODO: EVERYTHING. FUCK.
elseif mode == "client" then
-- todo: make the configuration configurable
-- one way or another
sockets['game'] = socket.udp();
bindname = "*" -- YOU
bindport = 7845 -- ALSO YOU
peername = settings['host'];
peerport = 7845
-- in retrospect, the 'settings' table
-- is kind of pointless, figure out something
-- better to do with it later
sockets['game']:setsockname(bindname, bindport)
sockets['game']:setpeername(peername, peerport);
sockets['game']:settimeout(0);
-- Some set up for who is what in this
-- Right now hard coding to always be player 1
-- What player I am
netplay.state['plocal'] = 1;
-- What the other player is
netplay.state['premote'] = 2;
-- Ideally setting these to 0 would
-- disable it entirely
-- but that takes EFFORT.
joypad.buffers[1] = {}; -- Player 1
joypad.buffers[2] = {}; -- Player 2
netplay.state['started'] = false;
netplay.state['delay'] = 6;
netplay.state['frame'] = 0;
-- Delay should be auto-configured based
-- on some timing
-- but that's MORE EFFORT.
-- besides, 10 should be obvious and
-- annoying as all hell
-- Should probably be moved to a dedicated wait loop somewhere
-- SO that we can keep sending it every second or so until we get a reply
netplay.send("start", nil);
end;
return true; -- why not
end;
Link to video
Full details in the description. It's not done yet (or close), but if nothing else the concept seems sound.
Also, for fuck's sake, can we get rid of the YOUR SIGNATURE HAS IMAGES nag yet? Put it in the fucking profile editing field and get rid of huge retarded signatures, don't nag me every fucking time I go to post because I have a mind-blowing 512 pixels of images in my signature.
Reminds me, I wonder if a shitty workaround would be something like this:
t = joypad.get(1); -- get intended input
joypad.set(1, {}); -- clear forced
p = joypad.get(1); -- get user input
joypad.set(1, t); -- re-enable intended input
I just tested, and this doesn't work either.
joypad.set(1, {}); -- Force input cleared.
temp = force(joypad.get(1));
FCEUX 2.1.1 | FCEUX 2.1.4
But come on, seriously. You can at least think of the impact of removing all descriptive text for a change.
)
FASTER