Posts for Xkeeper


Banned User
Joined: 12/23/2004
Posts: 1850
I guess it's alright. Any longer and it probably would've been boring, but as it is it's pretty decent. Sure, why not.
Perma-banned
Banned User
Joined: 12/23/2004
Posts: 1850
AnS wrote:
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).
Perma-banned
Banned User
Joined: 12/23/2004
Posts: 1850
Banned User
Joined: 12/23/2004
Posts: 1850
Reading this thread makes me smile.
Perma-banned
Banned User
Joined: 12/23/2004
Posts: 1850
Limne wrote:
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.
;horizontal adder is at first byte + high byte of spinstate,
;vertical adder is same + 8 bytes, two's compliment
;if greater than $08 for proper oscillation
FirebarPosLookupTbl:
      .byte $00, $01, $03, $04, $05, $06, $07, $07, $08
      .byte $00, $03, $06, $09, $0b, $0d, $0e, $0f, $10
      .byte $00, $04, $09, $0d, $10, $13, $16, $17, $18
      .byte $00, $06, $0c, $12, $16, $1a, $1d, $1f, $20
      .byte $00, $07, $0f, $16, $1c, $21, $25, $27, $28
      .byte $00, $09, $12, $1b, $21, $27, $2c, $2f, $30
      .byte $00, $0b, $15, $1f, $27, $2e, $33, $37, $38
      .byte $00, $0c, $18, $24, $2d, $35, $3b, $3e, $40
      .byte $00, $0e, $1b, $28, $32, $3b, $42, $46, $48
      .byte $00, $0f, $1f, $2d, $38, $42, $4a, $4e, $50
      .byte $00, $11, $22, $31, $3e, $49, $51, $56, $58
I doubt SMB3 would be much different.
Perma-banned
Banned User
Joined: 12/23/2004
Posts: 1850
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).
Perma-banned
Post subject: Where did gui.drawing go so wrong
Banned User
Joined: 12/23/2004
Posts: 1850
FCEUX 2.1.1 | FCEUX 2.1.4
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.)
Perma-banned
Banned User
Joined: 12/23/2004
Posts: 1850
FatRatKnight wrote:
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.
Perma-banned
Banned User
Joined: 12/23/2004
Posts: 1850
Perma-banned
Banned User
Joined: 12/23/2004
Posts: 1850
Mothrayas wrote:
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.)
Perma-banned
Banned User
Joined: 12/23/2004
Posts: 1850
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
Perma-banned
Banned User
Joined: 12/23/2004
Posts: 1850
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.
Perma-banned
Post subject: I know you have this bizarre facination with breaking things
Banned User
Joined: 12/23/2004
Posts: 1850
But come on, seriously. You can at least think of the impact of removing all descriptive text for a change.
Perma-banned
Banned User
Joined: 12/23/2004
Posts: 1850
henke37 wrote:
Anyone remember when we had to do with maybe 32 sprites at a time? Not me either.
The NES could actually do 64 at any given time (of course, a game could have more active, just not drawn to screen).
Perma-banned
Banned User
Joined: 12/23/2004
Posts: 1850
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.
Perma-banned
Banned User
Joined: 12/23/2004
Posts: 1850
(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. )
Perma-banned
Banned User
Joined: 12/23/2004
Posts: 1850
TAS FASTER
Perma-banned
Banned User
Joined: 12/23/2004
Posts: 1850
Reposting on last page so you don't have to dig for it. Hope you're hurrying.
Perma-banned
Banned User
Joined: 12/23/2004
Posts: 1850
isamu wrote:
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.
Perma-banned
Post subject: Re: Another fabulous FCEUX Lua bug
Banned User
Joined: 12/23/2004
Posts: 1850
FractalFusion wrote:
Xkeeper wrote:
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).
Perma-banned
Banned User
Joined: 12/23/2004
Posts: 1850
FatRatKnight wrote:
blah blah words
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.
Perma-banned
Banned User
Joined: 12/23/2004
Posts: 1850
moozooh wrote:
Let's do this.
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;
Lots to do, still.
Perma-banned
Post subject: Lua netplay, round two
Banned User
Joined: 12/23/2004
Posts: 1850
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.
Perma-banned
Banned User
Joined: 12/23/2004
Posts: 1850
Aglar wrote:
Don't worry, we've already found out how it works (long ago actually), and it will be used in the run - eventually.
Cool, care to explain?
Perma-banned
Banned User
Joined: 12/23/2004
Posts: 1850
Xkeeper wrote:
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));
Sigh.
Perma-banned