--- Log opened Fri Aug 30 00:00:07 2019 |
00:16 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Connection closed] |
00:47 | | Kindamoody is now known as Kindamoody[zZz] |
01:21 | <@celmin|away> | XD @ the Perl thing |
01:22 | <@celmin|away> | The C function calling Perl. to be precise. |
01:22 | | celmin|away is now known as celticminstrel |
04:10 | < Pink> | I love hoe unity's 2d and 3d have diverged so much that they both have completely different capabilities at this point |
04:11 | < Pink> | 2d just comes with physics effectors, inverse kinematics, skinning editors, etc. But completely lacks any equivalent to the character controller |
04:19 | | celticminstrel [celticminst@Nightstar-6an2qt.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
05:00 | <@Reiv> | ... wait what |
05:00 | <@Reiv> | that seems a bit, uh |
05:18 | < Pink> | (The character controller being an alternative to rigidbody that isn't strictly realistic but very convenient for player-controlled characters, due to it interacting with the physics system but also easily handling stairs, moving platforms, etc) |
05:20 | | Derakon is now known as Derakon[AFK] |
05:23 | < Pink> | Basically a capsule collider that 'knows' it is an abstration for feet and a torso. |
05:32 | <@Reiv> | oh I see |
05:33 | <@Reiv> | That would seem useful for a 2d game |
06:46 | | celticminstrel [celticminst@Nightstar-6an2qt.dsl.bell.ca] has joined #code |
06:46 | | mode/#code [+o celticminstrel] by ChanServ |
06:51 | | celticminstrel is now known as sleepyminstrel |
06:59 | < Pink> | My guess is that it is a combination of it being harder to define 'standard' behavior for 2d platforming and them having two teams using two physics frameworks(physX for 3d, box2d for 2d) |
07:36 | | sleepyminstrel [celticminst@Nightstar-6an2qt.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
07:36 | | Vorntastic [uid293981@Nightstar-6br85t.irccloud.com] has joined #code |
07:36 | | mode/#code [+qo Vorntastic Vorntastic] by ChanServ |
08:08 | | VirusJTG [VirusJTG@Nightstar-42s.jso.104.208.IP] has quit [Connection closed] |
08:08 | | VirusJTG [VirusJTG@Nightstar-42s.jso.104.208.IP] has joined #code |
08:08 | | mode/#code [+ao VirusJTG VirusJTG] by ChanServ |
08:37 | | Degi [Degi@Nightstar-t1u5qf.dyn.telefonica.de] has joined #code |
08:55 | <&McMartin> | It is indeed the case that platformer behavior has, like, 20 knobs that matter and any given character needs them all set properly (and differently) to match their personalities |
09:11 | | Kindamoody[zZz] [Kindamoody@Nightstar-eubaqc.tbcn.telia.com] has quit [Client exited] |
09:16 | <@sshine> | hmm |
09:18 | <@sshine> | I'm trying to generate the sequence [ a^2 + b^2 | a <- [0..], b <- [0..] ] in increasing order. |
09:19 | <@sshine> | naively I thought that I could just do [ (1,1), (2,1), (2,2), (3,1), (3,2), (3,3), (4,1), ... ] |
09:19 | <@sshine> | but I realize that 3^2 + 3^2 = 18 while 4^2 + 1^2 = 17 |
09:21 | <~Vorntastic> | Priority queue |
09:22 | <@sshine> | so... generate them one at a time and insert them in sorted order. |
09:25 | <@sshine> | I figure that if I do generate them in the order I just wrote, I want the last element that I generate to be (a,1) where a^2 + 1^2 = N <=> a^2 = N - 1 <=> a = sqrt(N - 1) |
09:30 | <@sshine> | simply because I can't find a good way to decide if e.g. a^2 + b^2 <= c^2 + d^2 when (a,b) is e.g. (3,3) and (c,d) is e.g. (4,1), I'm forced to check all the way up to (c,1) when c = sqrt(N - 1^2) |
09:32 | <@sshine> | Vorntastic, are you saying there's no trivial way to generate the pairs in the right order? after this problem I've got triples that result in a^2 + b^2 + c^2, which, if there's a pattern in their order, it is well beyond me. I thought I'd found it for pairs, but (3,3) > (4,1) was a counter-proof to that. |
09:33 | <~Vorntastic> | Generate one at a time, insert potential successors into a pq... Itinerary = [(0, (0,0))]; oldval = None; while true: newval, (a,b) = heappop(itinerary); if oldval == newval: continue; yield newval; oldval = newval; heappush(itinerary, ((a+1)**2+b**2, (a+1,b))); if a > b: heappush(itinerary, (a**2+(b+1)**2, (a,b+1))) |
09:34 | <@sshine> | but I'd need some kind of knowledge of how far to look ahead before I can safely emit the frontest element. |
09:34 | <@sshine> | s/frontest/frontmost/ |
09:35 | <~Vorntastic> | That's what heap is doing here |
09:36 | <~Vorntastic> | this is monotonic: if x appears earlier in the list than y, then the thing that adds x ti the list is also earlier than y. |
09:36 | <@sshine> | ah, it keeps all the larger elements on the heap until a smaller one occurs, or the sequence is finished, at which point I can pop the remaining. |
09:38 | <~Vorntastic> | http://oeis.org/A001481 here's the full sequence |
09:40 | <@sshine> | thanks. |
09:43 | <~Vorntastic> | http://oeis.org/A000378 here's the one for three. |
09:44 | <~Vorntastic> | And, uh, http://oeis.org/A001477 the one for four. |
09:56 | <~Vorntastic> | Oh, fish |
09:56 | <~Vorntastic> | Code above is wrong, don't continue, instead just skip yield |
09:57 | <~Vorntastic> | (otherwise you will miss one of (6,0) or (4,4), both of which give unique entries) |
09:59 | <~Vorntastic> | But then you should actually check to see if your new itinerary entries are in the list first. |
09:59 | < Degi> | Huh, with the sum of four squares you can cover all integers? |
10:00 | <~Vorntastic> | Yes! Someone noticed! |
10:00 | < Degi> | Well I mean you linked the list of integers heh |
10:01 | <~Vorntastic> | https://en.wikipedia.org/wiki/Lagrange%27s_four-square_theorem |
10:01 | <~Vorntastic> | I did |
10:09 | <~Vorntastic> | Improvement: use (a+1,b+1) and you don't have to check the condition. |
10:20 | <~Vorntastic> | (but since we're adding more entries unconditionally on outgoing we need to filter in incoming; otherwise we end up with exponential growth of duplicates on the heap) |
11:50 | | Degi [Degi@Nightstar-t1u5qf.dyn.telefonica.de] has quit [Ping timeout: 121 seconds] |
12:02 | | Degi [Degi@Nightstar-t1u5qf.dyn.telefonica.de] has joined #code |
12:10 | | Degi [Degi@Nightstar-t1u5qf.dyn.telefonica.de] has quit [Ping timeout: 121 seconds] |
13:23 | | celticminstrel [celticminst@Nightstar-6an2qt.dsl.bell.ca] has joined #code |
13:23 | | mode/#code [+o celticminstrel] by ChanServ |
13:40 | | Pinkhair [user1@Nightstar-g7hdo5.dyn.optonline.net] has joined #code |
13:43 | | Pink [user1@Nightstar-g7hdo5.dyn.optonline.net] has quit [Ping timeout: 121 seconds] |
13:56 | | celticminstrel is now known as celmin|away |
16:18 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
16:18 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
16:58 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has joined #code |
17:46 | | Vorntastic [uid293981@Nightstar-6br85t.irccloud.com] has quit [[NS] Quit: Connection closed for inactivity] |
20:00 | | Kimo|autojoin [Kindamoody@Nightstar-eubaqc.tbcn.telia.com] has joined #code |
20:00 | | mode/#code [+o Kimo|autojoin] by ChanServ |
20:01 | | KiMo|autorejoin [Kindamoody@Nightstar-eubaqc.tbcn.telia.com] has joined #code |
20:01 | | mode/#code [+o KiMo|autorejoin] by ChanServ |
20:01 | | KiMo|autorejoin is now known as Kindamoody |
20:33 | | VirusJTG [VirusJTG@Nightstar-42s.jso.104.208.IP] has quit [Connection reset by peer] |
20:33 | | VirusJTG [VirusJTG@Nightstar-42s.jso.104.208.IP] has joined #code |
20:33 | | mode/#code [+ao VirusJTG VirusJTG] by ChanServ |
21:07 | | Derakon[AFK] is now known as Derakon |
21:38 | <&jerith> | Implementing macros is trickier than it seems. |
21:39 | < Yossarian> | https://ipfs.io/ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco/wiki/Nintendo_S-SMP.html |
21:40 | < Yossarian> | "The Sony SPC700 [3] is the S-SMP's integrated 8-bit processing core manufactured by Sony with an instruction set similar to that of the MOS Technology 6502 (as used in the Commodore 1541 diskette drive and the Vic 20, Apple II, BBC Micro and in modified form in the original NES). |
21:40 | < Yossarian> | It is located on the left side of the sound module. It shares 64 KB of PSRAM with the S-DSP (which actually generates the sound) and runs at 2.048 MHz, divided by 12 off of the 24.576 MHz crystal. It has six internal registers, and can execute 256 opcodes. |
21:40 | < Yossarian> | " |
21:41 | < Yossarian> | "he SPC700 instruction set is quite similar to that of the 6502 microprocessor family, but includes additional instructions, including XCN (eXChange Nibble), which swaps the upper and lower 4-bit portions of the 8-bit accumulator, and an 8-by-8-to-16-bit multiply instruction." |
21:42 | <&McMartin> | It's odd that one would use make that list and not point out that the SNES's own 65816 is the 16-bit successor to the 6502. |
21:45 | < Yossarian> | Oh right, Ricoh 2A03 is based on MOS 6502 |
21:46 | <~Vornicus> | I'm still impressed at how quickly I picked up 6502 assembler |
21:46 | <~Vornicus> | having never worked in an assembly language before |
21:47 | < Yossarian> | wait does the SNES use FM synthesis? |
21:49 | < Yossarian> | SNES: Ricoh 5A22, which is a modification of the WDC 65C816. It is a derivative of the 16-bit 65C816. | sound: S-SMP, is a dedicated single chip consisting of an 8-bit CPU, along with a 16-bit DSP, and 64 KB of SRAM. It is designed and produced by Sony[64] and is completely independent from the rest of the system. It is clocked at a nominal 24.576 MHz in both NTSC and PAL systems. It is capable |
21:49 | < Yossarian> | of producing stereo sound, composed from 8 voices generated using 16 bit audio samples and various effects such as reverberation. |
21:49 | <~Vornicus> | the last metroid is in captivity. the galaxy is at peace. |
21:50 | < Yossarian> | http://www.vgmpf.com/Wiki/index.php?title=S-SMP |
21:51 | < Yossarian> | the S-SMP uses fully digital audio samples like a module. Some sound engines used instrument samples given to them by Sony themselves. One of these instruments was the infamous slap bass patch from the Korg M1. More times than not though, composers, sound designers and programmers just used instruments from keyboards they had at the time. |
21:51 | <&McMartin> | It's closer to Amiga |
21:51 | <&McMartin> | It was used as a sort of MOD player. |
21:51 | <&McMartin> | Which was not the intent of the Amiga hardware but I think might have been for the SNES~ |
21:52 | <&McMartin> | The *Genesis* had FM synthesis as its primary. |
21:52 | <&McMartin> | Yamaha OPN-2, IIRC, a bit more sophisticated than the AdLib |
21:52 | <&McMartin> | And then a very weak and finicky DAC intended for standalone sound effects that developers got Very, Very Good At |
21:53 | <&McMartin> | (And then the 3-bit square wave squonker from the master system that it shared with the PCjr~) |
21:53 | <&McMartin> | I have yet to Face The Terror that is SNESdev. |
21:55 | <&McMartin> | yeah, this. https://en.wikipedia.org/wiki/Yamaha_YM2612 |
21:56 | <&McMartin> | Oh also instead of an integrated CPU, the Genesis had a Z80 just kind of hanging out as a coprocessor to wrangle them |
21:56 | | Kimo|autojoin [Kindamoody@Nightstar-eubaqc.tbcn.telia.com] has quit [Client exited] |
21:56 | <&McMartin> | https://bumbershootsoft.wordpress.com/category/retrocoding/sega/ covers my adventures with the Genesis. |
21:57 | <&McMartin> | This is that Master System squonker. https://raw.githubusercontent.com/michaelcmartin/bumbershoot/master/genesis/psg_nyan.ogg |
21:58 | <&McMartin> | FM synth chips are really hard to use well and the program I wrote for *that* flatly isn't very good |
22:00 | < Yossarian> | Indeed the SNES S-SMP chip has samples. But no type of synthesis for production? |
22:01 | < Yossarian> | are all the songs on the cartridge sampled to? |
22:03 | < Yossarian> | Chrono Trigger's SPC library is 5.8 MiB |
22:03 | <&McMartin> | I suspect it works like MODs. You take one sample per insturment and then run it at different speeds to get different notes. |
22:04 | <&McMartin> | (Genesis's digital audio was just a register you wrote 8-bit sound data to, and the timing was on you and your ability to cycle-count the Z80 and avoid memory bus conflicts that would throw off your timing.) |
22:05 | <&McMartin> | (Despite that, Toy Story managed to put a proper MOD player in there, becuase Traveller's Tales was full of Specifically British Sorcerers) |
22:07 | < Yossarian> | but not a module bigger than 64kb |
22:08 | <&McMartin> | Right, but, hm |
22:08 | <&McMartin> | So, there's a trick you can do with that which is how you eventually get modern audio |
22:09 | <&McMartin> | This worked on the *Sound Blaster* at least |
22:09 | <&McMartin> | You defined two or three fairly large sound buffers and then just alternated between them, filling the other with new data while the one is being played by the sound DMA system. |
22:09 | < Yossarian> | but some songs are in one 64kb SPC file |
22:10 | <&McMartin> | I mean, OK, and? Is the idea that the sampled instruments would have to be really lo-fi? |
22:10 | <&McMartin> | Because, I mean, well, yeah... |
22:11 | < Yossarian> | Or wait... the PCM samples and the instructions on how they're played in a particular SPC file? How to access the individual samples, in that case? |
22:12 | <&McMartin> | I'm pulling this out of my butt here, to be clear |
22:12 | < Yossarian> | or, dumb question, just what format and length are the data, then if that is true you can yank out the samples |
22:12 | <&McMartin> | But my guess would be "the sample information are stored as, basically, arrays within the SPC's 64kB program" |
22:12 | <&McMartin> | It knows what its length and format &c are and it's telling it what to do and how. |
22:13 | <&McMartin> | And if *is* MOD it's probably playing Silly Buggers with the alleged format. |
22:13 | <&McMartin> | MOD-like, anyway |
22:13 | <&McMartin> | Obviously not Literally A .MOD file. |
22:16 | < Yossarian> | Apparently some people made an interesting player/editor: http://vspcplay.raphnet.net/screenshot.png |
22:18 | < Yossarian> | Any recommendations for attacking files as raw? xxd? maybe find a way to use vim and xxd? |
22:18 | <&McMartin> | You mean, just to look at the output? |
22:18 | <&McMartin> | I use hexdump -C |
22:19 | < Yossarian> | infer patterns |
22:19 | <&McMartin> | vim probably *has* a hexedit mode but I just use Ghex. |
22:19 | <&McMartin> | Also, re: player/editor: that's how all those soundchips had to work, basically. You wrote a reasonably generic music driver and then you wrote songs for that music driver. |
22:19 | <&McMartin> | Also hahaha, sinusoidal scroll text in the SDL_gfx embedded bitmap font |
22:20 | <&McMartin> | Legit |
22:20 | <&[R]> | <McMartin> I use hexdump -C <-- xxd is my prefered hex viewer. hexdump's defaults are braindead. |
22:20 | <&McMartin> | That's why you pass in -C. |
22:20 | <&[R]> | That's why one should use xxd |
22:20 | < Yossarian> | I'm looking via xxd | less now |
22:21 | <&[R]> | Defaults should be sensible |
22:21 | <&McMartin> | I'm looking at an xxd output right now |
22:21 | <&McMartin> | These defaults are also unacceptable |
22:23 | <&[R]> | In what way, looks like every other hex view of something I've ever seen |
22:23 | <&McMartin> | The default view is each line presented as 8 16-bit big-endian integers |
22:24 | <&[R]> | 16 bytes, address increases by 0x00000010 each line |
22:24 | <&McMartin> | Yeah, and |
22:25 | <&McMartin> | That's also the hexdump default |
22:25 | <&McMartin> | Which you say is nonsense |
22:25 | <&McMartin> | So that's clearly not the metric |
22:25 | <&McMartin> | But yes |
22:25 | <&[R]> | hexdump swaps bytes by default |
22:25 | <&McMartin> | What I want is 16 *actual* bytes, and ideally extra separators at 8-byte columns. |
22:25 | <&McMartin> | hexdump's default is 16 8-bit values. |
22:25 | <&[R]> | Which is braindamaged |
22:26 | <&McMartin> | No. |
22:26 | <&McMartin> | It's for a specific problem that neither you nor I have. |
22:26 | <&McMartin> | Which is why defaulting to 16-bit is dumb. |
22:26 | <&McMartin> | When I *do* have that problem, though, I use ghex. |
22:26 | <&McMartin> | "Little-endian N-bit integer at X", but X is almost never aligned, so hexdump and xxd are both the wrong tool. |
22:27 | <&McMartin> | to get xxd to do what I would want, and it still doesn't actually quite manage it, is xxd -g1. |
22:28 | <&[R]> | -g1 is kind of hard to read, the doubling up makes counting the columns easier |
22:28 | <&McMartin> | Right, that's why hexdump -C is better because it introduces extra space at the 8th column as a reference point. |
22:29 | <&McMartin> | And has a clearer delineation between the bytes part and the chardump part. |
22:29 | <&[R]> | Fair enough |
22:29 | <&McMartin> | Which is sort of the nub, really. What's actually happening there is "hexdump -C is the closest 7-bit ASCII approximation to the DOS semigraphical hex editors of my childhood" |
22:30 | <&[R]> | Still, I don't want to remember options for tools I rarely use, so xxd works best for me |
22:30 | <&[R]> | Because the results are correct by default |
22:30 | <&McMartin> | Yeah, while I'd need them for both, so I pick the one that has the smaller config result |
22:30 | <&McMartin> | hexdump appears to no longer group by default, so no byte swapping occurs unless you also turn on groups |
22:30 | <&McMartin> | At which point you're no longer "default" |
22:31 | <&McMartin> | And I'm not going to argue that little-endian integers by default is braindamaged when of all the systems we've been discussing here, only half of the Geneisis isn't =P |
22:34 | <&McMartin> | Oh, that also said |
22:34 | <&McMartin> | xxd is still the cheapest tool for applying *raw binary* patches. hd is read-only. |
22:35 | <&[R]> | Yeah |
22:41 | < Yossarian> | I see the text tags but I'm not sure, if there is a document for these opcodes maybe? |
22:44 | <&McMartin> | I mean, there has to be *somewhere* |
22:44 | <&McMartin> | My personal searches for docs on this would start on nesdev's snesdev links, and on romhacking.net |
22:46 | < Yossarian> | Besides getting manual for the thing... |
22:47 | < Yossarian> | You know, a software that can read this type of file, the source code of. |
22:47 | < Yossarian> | Tags at the beginning and end of file, 64kb in size, if samples are in there maybe they're 8 bit? depends on the PCM specs I guess |
22:49 | <&McMartin> | The PCM samples are almost certainly 8-bit. |
22:52 | <&McMartin> | Heh. The SPC file format specs I'm finding are 404s. ++. |
22:53 | <&McMartin> | It also appears that SPC works rather differently from the other console systems for this stuff, in terms of not being ripped from the ROM itself. |
22:53 | <&McMartin> | It's a "CPU snapshot", not a code dump. |
22:53 | <&McMartin> | SNSF is the code dump version and is used only when necessary |
22:54 | <&McMartin> | I'm pretty sure there are open-source SPC players if you'd rather have code than documents. |
22:55 | | * McMartin digs around some more |
22:55 | <&McMartin> | Oh, here's vspcplay again. |
22:55 | < Yossarian> | Yeah I'm fucking with it |
22:56 | < Yossarian> | how to add a Windows Explorer or run dialog from virtual wine desktop? |
22:56 | < Yossarian> | GUI version wants me to drag and drop files |
22:56 | <&McMartin> | What is your actual top-level goal here? |
22:57 | <&McMartin> | ... and why aren't you just building it on your Linux system |
22:57 | < Yossarian> | See the graphic on vspcplay |
22:57 | <&McMartin> | That... doesn't answer my question. |
22:58 | <&McMartin> | And I dunno about run dialogs, but you can pass executables to Wine to have them run in their bottles. |
22:58 | <&McMartin> | Along with arguments |
23:01 | <&McMartin> | Here's the opcodes. https://wiki.superfamicom.org/spc700-reference#toc-5 |
23:02 | < Yossarian> | I found an explorer for wine but dragging and dropping the files into vspclay but it didn't work and then wine threw a fit and exploded |
23:07 | <&McMartin> | Welp |
23:08 | <&McMartin> | But anyway, the vspcplay stuff I see on Github is a butt-standard "all you need is build-essentials and libsdl1-dev" setup |
23:08 | | Kindamoody is now known as Kindamoody[zZz] |
23:21 | < Yossarian> | vspclay messes up in wine :/ |
23:22 | <&McMartin> | What's your host OS? Linux or Mac? |
23:23 | <&McMartin> | Because it's Linux you should be able to Just Type Make |
23:25 | < Yossarian> | Oh, I was trying the v1.1 binary for windows |
23:25 | < Yossarian> | if there is source I could make |
23:26 | < Yossarian> | cool |
23:26 | <&McMartin> | Oh yeah, uh, when I said "I found vspcplay" I found its github |
23:26 | <&McMartin> | https://github.com/raphnet/vspcplay |
23:27 | <&McMartin> | I suspect this won't run on Mac anymore because of my Recent Unfortunate Experiences with SDL1.x on macOS 10.14 |
23:33 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Connection closed] |
23:39 | < Yossarian> | I got it to work, but I'm not sure how to add multiple files to the player. |
23:40 | < Yossarian> | The code is interesting as hell, especially https://github.com/raphnet/vspcplay/blob/master/spc_structs.h |
23:40 | < Yossarian> | I like the drawing of the memory map even though it is done kinda slopily |
23:41 | <&McMartin> | Heh. This is the zsnes lineage through snes9x for the cores here, which is pretty great |
23:41 | <&McMartin> | That means it started as 16-bit x86 asm |
23:48 | < Yossarian> | I'm looking at the output of vspcplay, I think the bottom 8 spires that go are something for voice 0-7 |
23:48 | <&McMartin> | That would make sense |
23:48 | | * McMartin also grumbles at these other alleged documents |
23:48 | <&McMartin> | You can't just say "ADPCM", that's an entire class of bitstreams and compression strategies! |
23:50 | < Yossarian> | something weird happens at address 002D |
23:50 | < Yossarian> | erm 2C |
23:51 | < Yossarian> | but given the visualization it seems like a cartesian map from left to right of addresses, top to bottom |
--- Log closed Sat Aug 31 00:00:09 2019 |