code logs -> 2019 -> Fri, 30 Aug 2019< code.20190829.log - code.20190831.log >
--- 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
code logs -> 2019 -> Fri, 30 Aug 2019< code.20190829.log - code.20190831.log >

[ Latest log file ]