On Thu, Jun 13, 2013 at 1:10 AM, Andrej Mitrovic <andrej.mitrovich@gmail.com
> wrote:

>
> I'd rather programmers spend their time building cool games than fast games. Not everything has to be ultra-realistic-shiny-3D-lens-flair-ultra-optimized-60fps crap.


Do you assume that non-realistic games don't need to have fast code?
It's not a correct assumption. It depends on the game and ultra-realistic
games are not the only
ones who are better with fast code or 60fps.

Basically, nothing can be generalized with games. Which is why more
opportunities to optimize are always welcome.
I suspect it's true for all kind of software in the end (even web services,
in particular massive web services).

Joel Lamotte

On 2013-06-12 06:40:05 +0000, Manu said:
> Personally, I think it's disappointing. x86's key advantage is being able to run crappy desktop code fast.
> Games are not usually 'crappy desktop code', they're carefully tuned, purpose-specific code.
> x86 uses MASSIVE amounts of its CPU realestate to tolerate crappy code. I'd rather use that CPU realestate on more raw power, and put the responsibility on the engines engineering merits to make the most of it.
> 
> This move sets a low upper limit, and the bar will start high. I don't anticipate you'll see much tier-ing between 1st gen -> 3rd/4th gen games this time round.
> 
> ARM might be better/more interesting than x86, but I actually still think PPC is a good architecture for the purpose. VMX/SPU is still the best SIMD unit.

I thought that the main motivation behind move to x86 was to utilize existing toolchains, alowing usage of great compilers and tools and not some arcane or old toolchain.

On Thu, 13 Jun 2013 01:10:34 +0200
Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 6/12/13, Manu <turkeyman@gmail.com> wrote:
> > Games are not usually 'crappy desktop code', they're carefully tuned, purpose-specific code.
> 
> I'd rather programmers spend their time building cool games than fast games. Not everything has to be ultra-realistic-shiny-3D-lens-flair-ultra-optimized-60fps crap.

Actually, I quite like 60Hz games ;) But that's been perfectly feasible for a long long time: Really the only reason they haven't all been running at 60Hz for the past 15 years is because graphical fidelity is often considered more important than bumping up from 30Hz to 60Hz.

Not that I'm complaining about that. I can entirely understand the tradeoff of settling for 30Hz for the sake of a higher quality image. It's just not my preferred tradeoff - I'd normally prefer framerate.

(Of course getting a *consistent* framerate can be difficult, but getting a higher one is fairly straightforward: Decrease the polygon/texture budget.)

Although, there are a rare few games that manage top botch up the tradeoff horrifically. Ex: The PS3 versions of Sonic Unleashed and Splinter Cell frequently have absolutely *atrocious* framerates despite the fact that the versions for *less* powerful systems (Wii and the first XBox 1) run at consistently *good* framerates (Because for those versions, they didn't try to cram too much into each frame and overload the hardware).

Actually, that always bugged the hell out of me: That the at-the-time "next-gen" PS3 versions actually ran vastly *worse* (barely even playable, in fact) than the versions on notably *less* powerful hardware. I know the PS3 is much more of a pain than the 360, but even still: Something was clearly managed wrong. Especially with the Sonic one which is heavily speed-oriented, therefore making framerate much more important (Not that Sonic Unleashed didn't have other big problems, though).

In any case, yea I do agree with you: I'll have a fun, low-graphics
game like Sound Shapes, Echochrome or last-gen Disgaea, over a
graphics-heavy-but-ultra-dull game like Assassin's Creed or
Heavy Rain any day.

Related to that: My absolute favorite game developer quote (because I so strongly feel the same way) is from Johnathan Blow, creator of the absolutely fantastic Braid (which incidentally is also *not* a super-high-tech-graphics game):

"I like games that are interesting, that give me something to think
about or to be well-engaged in, that give me the benefit of the doubt
as being an intelligent person. Fewer games like that are being made
these days -- an awful lot of games are just about ushering the player
through a fake experience, letting him win, making him feel like he is
clever and strong without actually requiring him to be anything but a
couch potato. I'm not interested in playing those games, and as a
result of that (and other long-term design trends) these days there
aren't many games that I enjoy."
- From:
http://www.joystiq.com/2008/09/25/joystiq-interview-blow-unravels-braid-in-post-mortem/

On Thursday, 13 June 2013 at 06:43:21 UTC, Nick Sabalausky wrote:
> Actually, I quite like 60Hz games ;) But that's been perfectly feasible
> for a long long time: Really the only reason they haven't all been
> running at 60Hz for the past 15 years is because graphical fidelity is
> often considered more important than bumping up from 30Hz to 60Hz.
>
> Not that I'm complaining about that. I can entirely understand the
> tradeoff of settling for 30Hz for the sake of a higher quality image.
> It's just not my preferred tradeoff - I'd normally prefer framerate.
>
> (Of course getting a *consistent* framerate can be difficult, but
> getting a higher one is fairly straightforward: Decrease the
> polygon/texture budget.)
>

I love rage for that. If the engine don't have everything it needs, it render something with a lower quality in order to keep the framerate high. The game is really enjoyable and have very few lags.

You would get more power out of using another architecture, but I think being able to write the games in D is even more powerful. Plus, PS4 seems to smile on self-publishing. That's a big opportunity to shine as a rogue D games console developer.

On Thu, 13 Jun 2013 08:57:03 +0200
"deadalnix" <deadalnix@gmail.com> wrote:
> 
> I love rage for that. If the engine don't have everything it needs, it render something with a lower quality in order to keep the framerate high. The game is really enjoyable and have very few lags.

Really? That's pretty cool, I didn't know about that aspect of the engine.

What's the game itself like? There's no demo so I haven't been able
to try it (after Quake3 and Doom3 I'm hesitant to buy an id game without
tying it first). But being a huge fan of everything id's ever done up
through Quake 2, I can't help being extremely curious: What direction
does it take the gameplay? Back to say, Quake 2, or does it expand on
the gameplay of Doom 3, or something completely different?

On Thursday, 13 June 2013 at 08:01:38 UTC, Nick Sabalausky wrote:
> On Thu, 13 Jun 2013 08:57:03 +0200
> "deadalnix" <deadalnix@gmail.com> wrote:
>> 
>> I love rage for that. If the engine don't have everything it needs, it render something with a lower quality in order to keep the framerate high. The game is really enjoyable and have very few lags.
>
> Really? That's pretty cool, I didn't know about that aspect of the
> engine.
>

You can that here :

https://www.youtube.com/watch?v=-I91AG2BhcI

Obviously, this is an extreme example and you won't see that all the time during the game :D

> What's the game itself like? There's no demo so I haven't been able
> to try it (after Quake3 and Doom3 I'm hesitant to buy an id game without
> tying it first). But being a huge fan of everything id's ever done up
> through Quake 2, I can't help being extremely curious: What direction
> does it take the gameplay? Back to say, Quake 2, or does it expand on
> the gameplay of Doom 3, or something completely different?

It is an fps. You find some moment where you can travel around with bugguy, do races and stuff, but the core of the game is really strong FPS like id knows how to do.

The game is very reactive, due to high framerate and also very beautiful. I really enjoyed it to the point I'd say that the main drawback is that the game is too short.

On Thursday, 13 June 2013 at 07:23:11 UTC, w0rp wrote:
> You would get more power out of using another architecture, but I think being able to write the games in D is even more powerful. Plus, PS4 seems to smile on self-publishing. That's a big opportunity to shine as a rogue D games console developer.

Do you have some news about that ? I'd really like to play with the PS4, it seems like an interesting machine to program on. Especially the unified memory model.

On Thursday, 13 June 2013 at 09:18:17 UTC, deadalnix wrote:
> On Thursday, 13 June 2013 at 07:23:11 UTC, w0rp wrote:
>> You would get more power out of using another architecture, but I think being able to write the games in D is even more powerful. Plus, PS4 seems to smile on self-publishing. That's a big opportunity to shine as a rogue D games console developer.
>
> Do you have some news about that ? I'd really like to play with the PS4, it seems like an interesting machine to program on. Especially the unified memory model.

http://kotaku.com/indie-developers-won-t-be-able-to-self-publish-on-xbox-509271999

"This news comes in stark contrast to Sony’s promises that indies will be able to self-publish content on the PS4."

I don't think there's much other details about it.

On Thursday, 13 June 2013 at 09:18:17 UTC, deadalnix wrote:
> On Thursday, 13 June 2013 at 07:23:11 UTC, w0rp wrote:
>> You would get more power out of using another architecture, but I think being able to write the games in D is even more powerful. Plus, PS4 seems to smile on self-publishing. That's a big opportunity to shine as a rogue D games console developer.
>
> Do you have some news about that ? I'd really like to play with the PS4, it seems like an interesting machine to program on. Especially the unified memory model.

It isn't simply unified like old consoles(xbox first?!) either, the GPU and CPU use the same virtual address space, and in fact the GPU supports full x86 addressing, and the gpu is connected to the CPU's cache coherency protocol.

Literally, HSA allows you to pass a pointer to your opencl or HSAIL compiled c/c++(hopefully D via llvm or gcc) code without copying to GPU memory and without having to remap memory to the GPU. The gpu sees the same physical memory through the hMMU giving it the same virtual address space as the rest of your application.

HSAIL bytecode is complex enough to allow c++ virtual functions to be properly accessed in GPU code.