Thread overview | ||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
May 08, 2017 Jonathan Blow's presentation | ||||
---|---|---|---|---|
| ||||
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, 2017 Re: Jonathan Blow's presentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rel | 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, 2017 Re: Jonathan Blow's presentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ethan Watson | 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, 2017 Re: Jonathan Blow's presentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rel | 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, 2017 Re: Jonathan Blow's presentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ethan Watson | 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, 2017 Re: Jonathan Blow's presentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Meta | 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, 2017 Re: Jonathan Blow's presentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ethan Watson | 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 09, 2017 Re: Jonathan Blow's presentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jack Stouffer | 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, 2017 Re: Jonathan Blow's presentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jack Stouffer | 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, 2017 Re: Jonathan Blow's presentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Meta | 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.
|
Copyright © 1999-2021 by the D Language Foundation