www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Jonathan Blow's presentation

reply Rel <relmail rambler.ru> writes:
What do you guys think of the points explained here:
https://www.youtube.com/watch?v=gWv_vUgbmug

Seems like the language shares a lot of features with
D programming language. However there are several
features that caught my interest:
1) The compile times seems very fast in comparison
with other modern programming languages, I'm wondering
how he managed to do it?
2) Compile-time execution is not limited, the build
system is interestingly enough built into the language.
May 08
next sibling parent reply Ethan Watson <gooberman gmail.com> writes:
On Monday, 8 May 2017 at 13:21:07 UTC, Rel wrote:
 What do you guys think of the points explained here:
 https://www.youtube.com/watch?v=gWv_vUgbmug

 Seems like the language shares a lot of features with
 D programming language. However there are several
 features that caught my interest:
 1) The compile times seems very fast in comparison
 with other modern programming languages, I'm wondering
 how he managed to do it?
 2) Compile-time execution is not limited, the build
 system is interestingly enough built into the language.
I was at that talk, and spoke to him quite a bit there. He also attended my talk. And yes, there is quite a bit of overlap in terms of features. He's well in to design by introspection, for example. I can answer #1, I know a few things there but that's more something he should talk about as I don't know how public he's made that knowledge. I also put forward to him a case with regards to compile time execution and code generation. Say you've got a global variable that you write to, and reading from that changes the kind of code you will generate. Thus, your outputted code can be entirely different according to whenever the compiler decides to schedule that function for execution and compilation. His response was, "Just don't do that." That's essentially the philosophical difference there. Jonathan wants a language with no restrictions, and leave it up to the programmer to solve problems like the above themselves. Whether you agree with that or not, well, that's an entirely different matter.
May 08
parent reply Rel <relmail rambler.ru> writes:
On Monday, 8 May 2017 at 14:47:36 UTC, Ethan Watson wrote:
 I can answer #1, I know a few things there but that's more 
 something he should talk about as I don't know how public he's 
 made that knowledge.
Well, I know that DMD in particular made a trade off not to collect garbage during the compilation to improve the speed, so it is really interesting to look at their compiler sources to find out what they did to make it compile so quickly. On Monday, 8 May 2017 at 14:47:36 UTC, Ethan Watson wrote:
 I also put forward to him a case with regards to compile time 
 execution and code generation. Say you've got a global variable 
 that you write to, and reading from that changes the kind of 
 code you will generate. Thus, your outputted code can be 
 entirely different according to whenever the compiler decides 
 to schedule that function for execution and compilation. His 
 response was, "Just don't do that."

 That's essentially the philosophical difference there. Jonathan 
 wants a language with no restrictions, and leave it up to the 
 programmer to solve problems like the above themselves. Whether 
 you agree with that or not, well, that's an entirely different 
 matter.
At very least it is interesting to have this feature, I don't know if I ever will need it in my code. For the game development use case it may be useful, for example to package all of the game assets at compile time. I've seen similar thing being very popular in different Haxe-based game frameworks, though Haxe seems to be a bit more restrictive in this regard.
May 08
parent reply Ethan Watson <gooberman gmail.com> writes:
On Monday, 8 May 2017 at 16:10:51 UTC, Rel wrote:
 I don't know if I ever will need it in my code. For the game
 development use case it may be useful, for example to package
 all of the game assets at compile time.
It's only useful for very select cases when hardcoded assets are required. You know, unless you want to try making a 45 gigabyte executable for current Playstation/Xbox games. A talk I watched the other year made the point that as far as textures go in video games, literally all but 10 you'll ever use are read only so stop trying to program that exception as if it's a normal thing. Hardcoding a select few assets is also a case of a vast-minority exception. There's ways to do it on each platform, and it's not really worth thinking about too much until those rare times you need one. Embedding inside the executable is also already a thing you can do in D with the import keyword.
May 08
next sibling parent reply Meta <jared771 gmail.com> writes:
On Monday, 8 May 2017 at 19:11:03 UTC, Ethan Watson wrote:
You know, unless you want to try making a 45
 gigabyte executable for current Playstation/Xbox games.
Is this why most console games that get ported to PC are massive? GTA V on PC, for example, was 100GB, while Skyrim was around 8GB.
May 08
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Monday, 8 May 2017 at 19:14:16 UTC, Meta wrote:
 On Monday, 8 May 2017 at 19:11:03 UTC, Ethan Watson wrote:
You know, unless you want to try making a 45
 gigabyte executable for current Playstation/Xbox games.
Is this why most console games that get ported to PC are massive? GTA V on PC, for example, was 100GB, while Skyrim was around 8GB.
Skyrim was that size on release because the console version had to fit on a DVD for the xbox 360 version, plus they made almost no changes to the PC version of the game. GTA V however, was released several months after the console release and had larger textures and uncompressed audio.
May 08
next sibling parent reply Meta <jared771 gmail.com> writes:
On Monday, 8 May 2017 at 19:28:51 UTC, Jack Stouffer wrote:
 On Monday, 8 May 2017 at 19:14:16 UTC, Meta wrote:
 On Monday, 8 May 2017 at 19:11:03 UTC, Ethan Watson wrote:
You know, unless you want to try making a 45
 gigabyte executable for current Playstation/Xbox games.
Is this why most console games that get ported to PC are massive? GTA V on PC, for example, was 100GB, while Skyrim was around 8GB.
Skyrim was that size on release because the console version had to fit on a DVD for the xbox 360 version, plus they made almost no changes to the PC version of the game. GTA V however, was released several months after the console release and had larger textures and uncompressed audio.
Ok, fair point. Let's look at Final Fantasy XIII (linear, non-open world console RPG released in 2009 on X360 and PS3, recently ported to PC) and The Witcher 3 (huge open world PC RPG released in 2015). FFXIII's size on disk is 60(!) GB, while The Witcher 3 is 40 GB. This isn't true all the time, but a lot of console games ported to PC take a surprisingly large amount of space. It's like they just unpacked the disk image, did an x86 build, then uploaded the whole thing to Steam with uncompressed assets and called it good enough.
May 08
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 05/08/2017 09:57 PM, Meta wrote:
 Ok, fair point. Let's look at Final Fantasy XIII (linear, non-open world
 console RPG released in 2009 on X360 and PS3, recently ported to PC) and
 The Witcher 3 (huge open world PC RPG released in 2015). FFXIII's size
 on disk is 60(!) GB, while The Witcher 3 is 40 GB. This isn't true all
 the time, but a lot of console games ported to PC take a surprisingly
 large amount of space. It's like they just unpacked the disk image, did
 an x86 build, then uploaded the whole thing to Steam with uncompressed
 assets and called it good enough.
I don't know anything about Witcher, but FF13 *does* have a fair amount of pre-rendered video, FWIW. And maybe Witcher uses better compression than FF13? Also, just a side nitpik, but open-world vs non-open-world alone shouldn't have any impact on data size - the real factors in a game world's data size are overall size and detail of the game world. Whether it's open world is just a matter of how all the data in the game world is laid out, not how much data there is.
May 08
prev sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 05/08/2017 03:28 PM, Jack Stouffer wrote:
 Skyrim was that size on release because the console version had to fit
 on a DVD for the xbox 360 version, plus they made almost no changes to
 the PC version of the game. GTA V however, was released several months
 after the console release and had larger textures and uncompressed audio.
Yea. The crazy thing is though, the huge sizes don't even buy as much as the numbers suggest. Major case of diminishing returns: Look at PS3 vs PS4 GTA5: Something like 25GB on PS3 and double that on PS4, and yea you *can* tell a difference, but its *very* slight, and usually you have to really look for it. (And then there's other games like Cod Ghosts and Destiny, where I honestly couldn't tell any difference whatsoever between the systems no matter how closely I looked, aside from a few extra particles in the particle systems...although I can't say what the size difference is on those games, maybe they just used the same assets for both systems on those games.)
 uncompressed audio.
Uncompressed? Seriously? I assume that really means FLAC or something rather than truly uncompressed, but even still...sounds more like a bullet-list pandering^H^H^H^H^H^H^H^H^Hselling point to the same suckers^H^H^H^H^H^H^H"classy folk" who buy Monster-brand cables for digital signals than a legit quality enhancement. Take a top-of-the-line $$$$ audio system, set down a room full of audiophiles, and compare lossless vs 320kbps Vorbis...in a true double-blind, no WAY they'd be able to consistently spot the difference even if they try. Let alone while being detracted by all the fun of causing mass mayhem and carnage. Unless maybe you just happen to stumble upon some kind of audio savant.
May 08
next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Tuesday, 9 May 2017 at 02:13:19 UTC, Nick Sabalausky 
(Abscissa) wrote:
 On 05/08/2017 03:28 PM, Jack Stouffer wrote:

 Uncompressed? Seriously? I assume that really means FLAC or 
 something rather than truly uncompressed, but even 
 still...sounds more like a bullet-list 
 pandering^H^H^H^H^H^H^H^H^Hselling point to the same 
 suckers^H^H^H^H^H^H^H"classy folk" who buy Monster-brand cables 
 for digital signals than a legit quality enhancement. Take a 
 top-of-the-line $$$$ audio system, set down a room full of 
 audiophiles, and compare lossless vs 320kbps Vorbis...in a true 
 double-blind, no WAY they'd be able to consistently spot the 
 difference even if they try. Let alone while being detracted by 
 all the fun of causing mass mayhem and carnage. Unless maybe 
 you just happen to stumble upon some kind of audio savant.
Don't need to go that high. c't did a double blind study some years ago with the help of her sister magazine for audio equipment. So they made a very good setup. What they discovered is that mp3 with 160 kbit/s CBR was already undistinguishable from CD for 99% of people for almost all kind of music. mp3 is much better than its reputation, due to really bad encoders at the beginning (Xing was awful and was the widest used at the beginning, Fraunhofer was excellent but not free, lame took years before it was any good) people thought that the crap they heard was inherent to the mp3 format but very often it was bad grabbing, over eager lo-pass filtering and crappy psycho-acoustic models (Xing). So you make a good point that uncompressed audio for a game is completely nuts.
May 08
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 9 May 2017 at 06:10:39 UTC, Patrick Schluter wrote:
 equipment. So they made a very good setup. What they discovered 
 is that mp3 with 160 kbit/s CBR was already undistinguishable 
 from CD for 99% of people for almost all kind of music.
It isn't all that hard to distinguish if you know what to listen for. I hear a big difference in music I have mixed down/mastered on a good headset.
May 08
prev sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 05/09/2017 02:10 AM, Patrick Schluter wrote:
 On Tuesday, 9 May 2017 at 02:13:19 UTC, Nick Sabalausky (Abscissa) wrote:
 On 05/08/2017 03:28 PM, Jack Stouffer wrote:

 Uncompressed? Seriously? I assume that really means FLAC or something
 rather than truly uncompressed, but even still...sounds more like a
 bullet-list pandering^H^H^H^H^H^H^H^H^Hselling point to the same
 suckers^H^H^H^H^H^H^H"classy folk" who buy Monster-brand cables for
 digital signals than a legit quality enhancement. Take a
 top-of-the-line $$$$ audio system, set down a room full of
 audiophiles, and compare lossless vs 320kbps Vorbis...in a true
 double-blind, no WAY they'd be able to consistently spot the
 difference even if they try. Let alone while being detracted by all
 the fun of causing mass mayhem and carnage. Unless maybe you just
 happen to stumble upon some kind of audio savant.
Don't need to go that high. c't did a double blind study some years ago with the help of her sister magazine for audio equipment. So they made a very good setup. What they discovered is that mp3 with 160 kbit/s CBR was already undistinguishable from CD for 99% of people for almost all kind of music. mp3 is much better than its reputation, due to really bad
Interesting. Any links? Not familiar with what "c't" is. Although, even 1% is still a *LOT* of people. I'd be more curious to see what encoding it would take to get more like 99.99% or so.
 encoders at the beginning (Xing was awful and was the widest used at the
 beginning, Fraunhofer was excellent but not free, lame took years before
 it was any good) people thought that the crap they heard was inherent to
 the mp3 format but very often it was bad grabbing, over eager lo-pass
 filtering and crappy psycho-acoustic models (Xing). So you make a good
 point that uncompressed audio for a game is completely nuts.
Fair point. Also, I've heard that the big quality improvements that aac/vorbis/etc have over mp3 are mainly just at lower bitrates.
May 09
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Tuesday, 9 May 2017 at 08:24:40 UTC, Nick Sabalausky 
(Abscissa) wrote:
 On 05/09/2017 02:10 AM, Patrick Schluter wrote:
 On Tuesday, 9 May 2017 at 02:13:19 UTC, Nick Sabalausky 
 (Abscissa) wrote:
 On 05/08/2017 03:28 PM, Jack Stouffer wrote:

 Uncompressed? Seriously? I assume that really means FLAC or 
 something
 rather than truly uncompressed, but even still...sounds more 
 like a
 bullet-list pandering^H^H^H^H^H^H^H^H^Hselling point to the 
 same
 suckers^H^H^H^H^H^H^H"classy folk" who buy Monster-brand 
 cables for
 digital signals than a legit quality enhancement. Take a
 top-of-the-line $$$$ audio system, set down a room full of
 audiophiles, and compare lossless vs 320kbps Vorbis...in a 
 true
 double-blind, no WAY they'd be able to consistently spot the
 difference even if they try. Let alone while being detracted 
 by all
 the fun of causing mass mayhem and carnage. Unless maybe you 
 just
 happen to stumble upon some kind of audio savant.
Don't need to go that high. c't did a double blind study some years ago with the help of her sister magazine for audio equipment. So they made a very good setup. What they discovered is that mp3 with 160 kbit/s CBR was already undistinguishable from CD for 99% of people for almost all kind of music. mp3 is much better than its reputation, due to really bad
Interesting. Any links? Not familiar with what "c't" is.
https://www.heise.de/ct/artikel/Kreuzverhoertest-287592.html So, I got some details wrong in my recollection from memory. They compared 128 kbit/s, 256 kbit/s and CD. To remove bias, they burnt the mp3 after decompression on CD so that the testers couldn't distinguish between the 3 formats and played them in their high quality audio setup in their studios. The result was surprizing in that there was no difference between CD and 256K mp3, and only a slightly lower score for 128K mp3. They were also surprized that for some kind of music (classical), the mp3 128K was even favored by some testers over the other formats and they speculate that the encoding rounds out somehow some roughness of the music. They also had one tester who was 100% accurate at recognizing mp3 over CD, but the guy had had a hearing accident in his youth where he lost part of the hearing spectrum (around 8KHz) which breaks the psycho-acoustic model and allows him to hear noise that is suppressed for the not hearing impared. I don't know where I got the 160 KBit part of my message.

 Fair point. Also, I've heard that the big quality improvements 
 that aac/vorbis/etc have over mp3 are mainly just at lower 
 bitrates.
May 09
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 05/09/2017 04:44 AM, Patrick Schluter wrote:
 On Tuesday, 9 May 2017 at 08:24:40 UTC, Nick Sabalausky (Abscissa) wrote:
 On 05/09/2017 02:10 AM, Patrick Schluter wrote:

 Interesting. Any links? Not familiar with what "c't" is.
https://www.heise.de/ct/artikel/Kreuzverhoertest-287592.html So, I got some details wrong in my recollection from memory. They compared 128 kbit/s, 256 kbit/s and CD. To remove bias, they burnt the mp3 after decompression on CD so that the testers couldn't distinguish between the 3 formats and played them in their high quality audio setup in their studios. The result was surprizing in that there was no difference between CD and 256K mp3, and only a slightly lower score for 128K mp3.
Not surprised the 128k MP3 was noticeable. Even I've been able to notice that when I was listening for it (although, in retrospect, it was likely a bad encoder, now that I think about it...)
 They were also surprized that for some kind of music
 (classical), the mp3 128K was even favored by some testers over the
 other formats and they speculate that the encoding rounds out somehow
 some roughness of the music.
 They also had one tester who was 100% accurate at recognizing mp3 over
 CD, but the guy had had a hearing accident in his youth where he lost
 part of the hearing spectrum (around 8KHz) which breaks the
 psycho-acoustic model and allows him to hear noise that is suppressed
 for the not hearing impared.
Fascinating. The 128k being sometimes favored for classical kinda reminds me of how some people prefer vinyl over CD/etc. Both are cases of audio data being lost, but in a way that is liked.
 I don't know where I got the 160 KBit part of my message.
Your memory recall must've applied a low-pass filter over "128K" and "256K" ;)
May 09
prev sibling parent reply Era Scarecrow <rtcvb32 yahoo.com> writes:
On Tuesday, 9 May 2017 at 02:13:19 UTC, Nick Sabalausky 
(Abscissa) wrote:
 On 05/08/2017 03:28 PM, Jack Stouffer wrote:
 uncompressed audio.
Uncompressed? Seriously? I assume that really means FLAC or something rather than truly uncompressed, but even still...
Nope, uncompressed. Seems some games they decided the small amount of time spent decompressing audio and textures was too high, which is why some of the games are 50Gb in size, because it's more important to have larger textures than trying to push the HD textures and 4k stuff, vs actually having hardware that can handle it, since the console hardware is seriously behind PC hardware.
May 09
next sibling parent Era Scarecrow <rtcvb32 yahoo.com> writes:
On Tuesday, 9 May 2017 at 23:47:46 UTC, Era Scarecrow wrote:
 Seems some games they decided the small amount of time spent 
 decompressing audio and textures was too high <snip> since the 
 console hardware is seriously behind PC hardware.
Found an appropriate articles Regarding Titanfall (a few years ago), although that's for PC and the reason for giving a boost to 'underpowered PC's', although i could have sworn they did it for consoles more. Still ridiculous in my mind. http://news.softpedia.com/news/Titanfall-Needs-50GB-of-Space-on-PC-Due-to-Uncompressed-Audio-Files-431586.shtml http://www.pcworld.com/article/3128214/software-games/why-pc-game-downloads-are-so-damned-big.html http://www.escapistmagazine.com/news/view/132922-Titanfall-Dev-Explains-The-Games-35-GB-of-Uncompressed-Audio
May 09
prev sibling next sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 05/09/2017 07:47 PM, Era Scarecrow wrote:
 since the console hardware
 is seriously behind PC hardware.
Side nitpick: Console hardware is behind *gaming-PC* hardware. Important distinction. Heck, my most powerful PC is a little behind PS3 (in terms of game performance, anyway) and does everything I need it to do and then some (including the vast majority of indie games, which I usually prefer anyway). And ok, yea, that's just my own stuff but still, take a look at the laptop market: For anything that *doesn't* have Intel graphics, you're looking at easily around double the price. You can get a quite good latptop for $400 or less. But want one with an ATI or NVIDIA (and not their budget "comparable with Intel Graphics" lines)? Then you're looking at around $1,000. But what good does that ATI or NVIDIA chipset do (over an Intel) for anything other than 3D modeling/animation and non-indie gaming? Nada (but maybe suck the battery dry). You could say "yea, well, that's for laptops, any serious gamer's gonna want a desktop". But then again you'd simply be talking "gaming PC" again. And these days, how much point is there really in a desktop (as opposed to laptop) for non-gaming, non-3dsMax/Maya purposes? Minimal. Point being: There's a big difference between "PC" and "gaming PC". In the context of AAA gaming, it tends to get falsely assumed that all PCs are gaming-PC spec. Not so. Console hardware is only behind "high-end" PC hardware (what I mean by "high-end" in that sentence isn't so much "top of the line" but simply "costs more than the highest-end console available").
May 09
prev sibling parent Ethan Watson <gooberman gmail.com> writes:
On Tuesday, 9 May 2017 at 23:47:46 UTC, Era Scarecrow wrote:
 Nope, uncompressed. Seems some games they decided the small 
 amount of time spent decompressing audio and textures was too 
 high, which is why some of the games are 50Gb in size, because 
 it's more important to have larger textures than trying to push 
 the HD textures and 4k stuff, vs actually having hardware that 
 can handle it, since the console hardware is seriously behind 
 PC hardware.
On Tuesday, 9 May 2017 at 23:58:13 UTC, Era Scarecrow wrote:
 Found an appropriate articles Regarding Titanfall (a few years 
 ago), although that's for PC and the reason for giving a boost 
 to 'underpowered PC's', although i could have sworn they did it 
 for consoles more. Still ridiculous in my mind.
Yeah, you might want to actually read the entire thread before stating this stuff again.
May 10
prev sibling parent reply Ethan Watson <gooberman gmail.com> writes:
On Monday, 8 May 2017 at 19:14:16 UTC, Meta wrote:
 Is this why most console games that get ported to PC are 
 massive? GTA V on PC, for example, was 100GB, while Skyrim was 
 around 8GB.
Consoles have a fixed hardware level that will give you essentially deterministic performance. The quality of assets it can handle are generally 1/4 to 1/2 as detailed as what the current top-line but reasonably-priced PC hardware can handle. And PC gamers *love* getting the higher detailed assets. So we ship PC games with the option to scale the quality of the assets used at runtime, and ship with higher quality assets than is required for a console game. See as an alternative example: the Shadows of Mordor ultra HD texture pack, which requires a 6GB video card and an additional download. Another example I like using is Rage, which is essentially 20GB of unique texture data. If they wanted to re-release it on Xbox One and PS4 without being accused of just dumping a port across, they'd want to ship with 80GB of texture data. There's also grumblings about whether those HD packs are worth it, but now that 4K displays are coming in those grumblings are stopping as soon as people see the results. On Tuesday, 9 May 2017 at 02:21:19 UTC, Nick Sabalausky (Abscissa) wrote:
 I don't know anything about Witcher, but FF13 *does* have a 
 fair amount of pre-rendered video, FWIW. And maybe Witcher uses 
 better compression than FF13?
Correct about the video. The Final Fantasy games are notorious for their pre-renders and their lengthy cutscenes. All of which require massive amounts of video and audio data. Better compression though? Unlikely. Texture formats are fairly standardised these days. Mesh formats are custom, but not as much of a space hog as textures. Other assets like audio and video is more where the compression formats come in to play. But gaming hardware has a few tricks for that. For example: On Tuesday, 9 May 2017 at 02:13:19 UTC, Nick Sabalausky (Abscissa) wrote:
 Uncompressed? Seriously? I assume that really means FLAC or 
 something rather than truly uncompressed, but even 
 still...sounds more like a bullet-list 
 pandering^H^H^H^H^H^H^H^H^Hselling point to the same 
 suckers^H^H^H^H^H^H^H"classy folk" who buy Monster-brand cables 
 for digital signals than a legit quality enhancement.
Well, no. Gaming consoles - and even mobile devices - have dedicated hardware for decompressing some common audio and video formats. PC hardware does not. Decompression needs to happen on the CPU. Take Titanfall as a use case, which copped quite a bit of flack for shipping the PC version with uncompressed audio. The Xbox One version shipped on a machine that guaranteed six hardware threads (at one per core) with dedicated hardware for audio decompression. Their PC minspec though? A dual core machine (at one thread per core) with less RAM and only using general purpose hardware. The PC scene had a cry, but it was yet another case of PC gamers not actually understanding hardware fully. The PC market isn't all high-end users, the majority of players aren't running bleeding edge hardware. They made the right business decision to target hardware that low, but it meant some compromises had to be made. In this case, the cost of decompressing audio on the CPU was either unfeasible in real time or increased load times dramatically during load times. Loading uncompressed audio off the disk was legitimately an optimisation in both cases. On Tuesday, 9 May 2017 at 06:50:18 UTC, Ola Fosheim Grøstad wrote:
 It isn't all that hard to distinguish if you know what to 
 listen for. I hear a big difference in music I have mixed 
 down/mastered on a good headset.
So, as Walter would say, "It's trivially obvious to the casual observer." That's the point of the blind test. It isn't trivially obvious to the casual observer. You might think it is, but you're not a casual observer. That's essentially why LAME started up - a bunch of audiophiles decided to encode for perception of quality rather than strictly objective quality.
May 09
next sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 05/09/2017 04:12 AM, Ethan Watson wrote:
 In this case, the cost of
 decompressing audio on the CPU was either unfeasible in real time or
 increased load times dramatically during load times. Loading
 uncompressed audio off the disk was legitimately an optimisation in both
 cases.
I'm surprised it would've made that much of a difference, I'd grown accustomed to seeing audio decoding as computationally cheap on even low-end hardware. But then again, I suppose the average level of a modern AAA game may involve a bit more audio data than the average MP3 song (not to mention a lot more audio streams playing simultaneously), and is already maxing the hardware as much as it can.
May 09
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 9 May 2017 at 08:12:20 UTC, Ethan Watson wrote:
 That's the point of the blind test. It isn't trivially obvious 
 to the casual observer. You might think it is, but you're not a 
 casual observer.
Well the point of a blind test is more to establish validity for something having a different effect, but not for establishing that it isn't different. i.e. false vs unknown, so in the latter case it would be inconclusive. These 2 statements are very different: 1. we have not been able to establish that there was any perceived difference 2. we have established that there was no perceived difference How would they research this? By asking if one is better than the other? Well, that is highly subjective. Because better has to do with expectations. Anyway, cognitive analysis of difference is rather at a high level and for many something sounds the same if they interpret the signal the same way. Whereas immersion is much more subtle and depends on your state of mind also, not only what you perceive. So not easy to measure! Our perceptual machine is not a fixed machine, our expectations and mood feeds back into the system. Some things like phasing/smearing in high frequency content and imaging does affect the experience, although the effect is very subtle and you need good head sets and having heard the original many times to pinpoint where the differences are at higher bitrates. (at 300kbit/s it probably isn't all that easy).
May 09
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 9 May 2017 at 16:26:35 UTC, Ola Fosheim Grøstad wrote:
 Some things like phasing/smearing in high frequency content and 
 imaging does affect the experience, although the effect is very
I want to add that of course, modern commercial music is already ruined by too much compression and dynamic abuse so it is distorted from the beginning... just to get a loud signal. Trash in -> trash out. Same with speakers. Regular speakers are poor. Use a good headset (E.g. Sennheiser HD600 or better) and preferably use the same headset the audio engineer used... Loudspeaker in room -> not the same signal as on the CD. Anyway, it is a complicated topic. I went to a two hours lecture on it a week ago. We were told to use this book: Applied Signal Processing: A MATLAB™-Based Proof of Concept by Dutoit and Marqués. It comes with code in matlab so you can modify the mp3 algorithms and explore the effects yourself. :)
May 09
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 05/09/2017 12:58 PM, Ola Fosheim Grøstad wrote:
  Use a good headset (E.g. Sennheiser
 HD600 or better) and preferably use the same headset the audio engineer
 used... Loudspeaker in room -> not the same signal as on the CD.
You seem to know a thing or two about audio hardware (more than me anyway) - Any idea offhand where to find a good set of clip-style headphones? That's something I've been dying to find for years (I don't like "earbuds" - I find sticking thing inside my ears to be terribly uncomfortable, even compared to the occasion pinch of clip-style, and traditional are always just falling off in casual use). I used to use Koss's clip-style (and loved the one with in-line volume control) since, despite being affordable, they were the only ones I'd ever found that didn't sound horrible (all the Sony ones of remotely comparable price sounded like complete trash no matter what the box claimed about its specs...and the Sonys are downright ugly to boot. Other brands didn't fare any better.) Unfortunately, after a few years, both my Koss pairs crapped out (ie, no sound period out one or both speakers), and the non-free "warranty" replacements consistently crapped out the same way after about two months max (sounded good until then, though). At this point, I don't care about cost, would just like to find a reliable good-sounding (ie, at least comparable to Koss's sound quality) clip-style. Any leads? Is there even such a thing has high-end, or even mid-range clip headphones?
May 09
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 9 May 2017 at 17:25:37 UTC, Nick Sabalausky 
(Abscissa) wrote:
 me anyway) - Any idea offhand where to find a good set of 
 clip-style headphones?
Unfortunately not. I try to avoid headphones these days, too easy to crank up the volume without noticing, especially if you have good ones which can go up to 120db without distortion...
 That's something I've been dying to find for years (I don't 
 like "earbuds" - I find sticking thing
Yeah, don't use consumer-earbuds, can easily damage your hearing.
 At this point, I don't care about cost, would just like to find 
 a reliable good-sounding (ie, at least comparable to Koss's 
 sound quality) clip-style. Any leads? Is there even such a 
 thing has high-end, or even mid-range clip headphones?
I've kinda stopped consuming music when travelling, but I personally prefer large headsets that enclose the ear completely. Closed ones in non-silent environment so you don't crank the volume up too much. A bit clunky even if foldable of course... I used some from Ultrasone, not the best quality, but decent. I think personal taste and musical style kinda means that you have to test them in a store to make up your mind. I guess you could ask at the https://www.head-fi.org/ forums, but not sure if that site is good anymore? It was a useful resource a decade ago, but seems to be rammed down with awful ads now? Unbearable. Btw people say that one should keep new headset playing some heavy bass for 10? hours after purchasing before evaluating them, something about the coils needing to be run in. Well, they are mechanical so I guess that makes sense (tightening, friction or something). Maybe different for cans without coils...
May 09
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 05/09/2017 02:14 PM, Ola Fosheim Grøstad wrote:
 I've kinda stopped consuming music when travelling, but I personally
 prefer large headsets that enclose the ear completely. Closed ones in
 non-silent environment so you don't crank the volume up too much. A bit
 clunky even if foldable of course... I used some from Ultrasone, not the
 best quality, but decent. I think personal taste and musical style kinda
 means that you have to test them in a store to make up your mind.
Hmm, regarding large over-the-ear ones, about a year or two ago I made the mistake of shelling out for one of Sony's "PlayStation Gold" headsets. Was initially thrilled with it (except they look hideous while they're being worn - like any Sony headset really), but then as with most other people who got them, it didn't take too long before I hit the infamous problem of its cheap plastic (on a $100 pair??? That's Sony I guess) cracking and breaking. :/
 I guess you could ask at the https://www.head-fi.org/ forums, but not
 sure if that site is good anymore? It was a useful resource a decade
 ago, but seems to be rammed down with awful ads now? Unbearable.
Thanks, I'll take a look.
 Btw people say that one should keep new headset playing some heavy bass
 for 10? hours after purchasing before evaluating them, something about
 the coils needing to be run in. Well, they are mechanical so I guess
 that makes sense (tightening, friction or something). Maybe different
 for cans without coils...
Interesting, first I've heard that. Good to know.
May 09
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/9/2017 1:12 AM, Ethan Watson wrote:
 So, as Walter would say, "It's trivially obvious to the casual observer."
I was surprised to learn at DConf that "trivially obvious to the most casual observer" was an unknown expression. Googling it shows only around 10 hits, none predating 2005. I learned it at Caltech in the 1970s, where it was applied to concepts and proofs that were exceptionally difficult to follow. I suppose that from now on if you hear the phrase, you can conclude that the source is from the set of: 1. techers 2. D programmers :-)
May 09
prev sibling parent bachmeier <no spam.net> writes:
On Monday, 8 May 2017 at 19:11:03 UTC, Ethan Watson wrote:

 unless you want to try making a 45 gigabyte executable for 
 current Playstation/Xbox games
Just yesterday I was listening to my son cursing his Xbox as it downloaded 72 GB before he could play his game...
May 08
prev sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 05/08/2017 09:21 AM, Rel wrote:
 What do you guys think of the points explained here:
 https://www.youtube.com/watch?v=gWv_vUgbmug
Watched the first 15-20 min of it. Definitely want to watch the rest. Buuuuuutttt.....so far it's a good example of the *one* little thing that kinda bugs me about Johnathan Blow: I keep hearing him say the same things I've been saying for years, but because he wrote Braid, he can sometimes get people to actually listen instead of blindly dismissing everything. :/ (Granted that's not a fault of Blow's. But it still bugs me!)
 1) The compile times seems very fast in comparison
 with other modern programming languages, I'm wondering
 how he managed to do it?
By being a game (and engine) developer and knowing the basics of writing efficient code, unlike the majority of the software industry. (Seriously, if other circles of dev would pull their ***** out of their ***** long enough recognize all of what game programming obviously involves (ex: It's more than the glorified calculators that the upptity banking software is, and don't get me started on "enterprise" in general), then they could finally start learning how to write grown-up code and software today wouldn't suck so f****** badly.) Also, not using header files.
 2) Compile-time execution is not limited, the build
 system is interestingly enough built into the language.
Nemerle had that years ago (although I'm guessing/hoping that unlike Nemerle, Blow's implementation probably doesn't require manually compiling to a DLL before being able to use given code at compile-time). My inclination is that it's the right approach, and is one thing that makes D look clunky and awkward by comparison. I never bought D's argument that compiling source shouldn't be allowed to do arbitrary code execution or I/O because, come on, "build scripts" and "build systems". That "no arbitrary code execution" ship sailed ages ago: Who in hell compiles software from source without using the provided buildscript or buildsystem configuration (all of which, by necessity, allow arbitrary code execution and IO)? Nobody who isn't searcing for their own little corner of hell, that's who. The *one* thing that does give me a little pause though is the possibility that order of compilation could change the results of generated code. I think it'll be interesting to see how that plays out in practice. "Don't do that" sounds nice, but the question remains: "Is it something that will happen without the author knowing he's doing it? If so, will it be a problem?"
May 08