The only thing not mentioned so far that I suspect is GPU-CPU convergence ala Larrabee.

Larrabee was an huge fail indeed
And that proved once more that you get maximum efficency by specialization, not abstraction.

I think that the new consoles will be much more specialized than current ones: probabily they will have shared RAM-VRAM with huge caches, a very programmable (DX11-level) GPU, and a LOT of other hardware functions such as security, video decoding, wifi, etc, on a single SOC in order to reduce costs.
And yes, this means that they will be harder and more specific to program.

Average Software, nice list of things that will never happen

I'm ok with point (2), while you're a bit exaggerating the thing - the new X360 dashboard allows to play the disc with one "A" push.
Also an OS of some kind is needed if you want digital delivery and permanent residence of games into the console.

As for point 1. PLEASE NO. My N64 games are all defective and the N64 itself only boots a game once in 10 tries. While I still have to see a DVD that becomes illegible... CDs were still in their infancy with the Saturn, today's DVDs are far more durable than any NAND, as they don't deteriorate with reads.

3. Online Multiplayer and game patches. I don't see how you could do without.

IMO consoles are pretty good as they are, what I would like to see is better mediacenter-y stuff as currently it's still too limited to be really useful, maybe with a version of Windows8 on the new X.

Also a better hardware and PLEASE use some of that raw power for image quality. 30fps with no AA and a ton of depth blur/motion blur/bloom bleeding everywhere is going to look CRAP 10 years from now.

Uhm... yeah, it can be. But at least these "twice as likely" values are evenly distributed across the interval, so it shouldn't be too noticeable in a game...
Also, with small n more doubles are mapped to the same ints, so assuming an even double distribution the results should be better?

Heh, the original implementation looks interesting. I wonder why the original author did it this way.

What's wrong with this though?

Code:

return randInt() % n;

Uhm, this could be wrong because it makes twice as probable a segment of numbers...

let's say that m is the max, and n = 2/3max. This way the numbers that are "extracted" in the remaining one third are re-fitted in the first one third of the valid interval.
So, each third of max has 1/3 probability to be choosen, but the last third is actually the first, so the probability in n is 2/3 for the first half, and 1/3 for the second half.

Which I think is bad enough even in a game

Grabbed a Mersenne Twister random number generation from the internet to fit in my game (with the due credits)!

It looks like wheel-reinventing, but was actually needed because rand()with a given seed would yield different results on different compilers... and the savegame is seed+diff, so this is pretty bad.

Quiz (to which I don't know the answer):
the original implementation had this code

Code:

uint32 used = n;
used |= used >> 1;
used |= used >> 2;
used |= used >> 4;
used |= used >> 8;
used |= used >> 16;

// Draw numbers until one is found in [0,n]
uint32 i;
do
i = randInt() & used;  // toss unused bits to shorten search
while( i > n );
return i;

which I think is slow because in the worst case it can do up to (n/2)-1 iterations? I replaced it with

Code:

   return (uint32)( (double)randInt()*(1.0/4294967295.0) * n );

which just takes a double from 0 to n in O(1) and casts it to int.
and I wonder why this wasn't ok in the first place

Uhm... I'm no electronic engineer but the last posts look a bit off

-there have been non-binary computers, and they were always more costly overall (the comparison between the russian one and it's direct replacement is pointless, unless you know why it costed so much), mostly in engineering costs due to the increased costs due to complexity.
That, and the fact that most complex operations have more efficient algorithms in binary form.
Besides, it's hard to compare the current state of CPUs to that ternary thing, because

-that above applies only to analogic computers as fast transistors only can have "on" and "off" states due to the way semiconductors work.
this could change in the future, but the jump in complexity between clumping together 2 binary transistors and having a quaternary transistor is HUGE, and makes it pointless.

-I'm not at all ok with the idea that the industry is *always* wrong. The industry is sometimes a little off mark, but usually it shows excellent intuition overall, at least when talking of fundamental engineering problems.
For example, NAND Flash memory DOES actually use ternary or quaternary internally. Why?
Because in storage the drop in performance or the rise in costs is less important than the 33% (ternary) or 50% (quaternary) increases in density.

-the imprecision with float is NOT AT ALL due to "representing base-10 numbers in binary" as this sentence actually means nothing.
Numbers are numbers. They can be real, natural, rational or whatever.
Both 2 an 10 representations are this, representations. They are perfectly equivalent and are not carried around with a number.
The reason of float "imprecision" (or better, limited resolution, as they are NOT imprecise, only unevenly distributed) is just like what happens in base-10: you have to choose how many fractional digits you want to store. The more you have, the better is the resolution, but you can never be "precise" when talking about infinite precision number such as reals.
Also, if the reason was the one you stated, floats would be very precise - as they are never, ever converted to decimal except that when printed on screen!

/rant

EDIT: I started with a quite harsh rant, but after all I'm not so sure about the ternary thing
Still hundreds of very bright people choose binary, and it would be interesting to know what are and were the advantages.
For a fact, decimal works really bad.

Well, if I were you, I would make the DM be a service (as in a web service/WCF service, whatever) and the clients be applications which communicate with the service through standard protocols like SOAP. This way you could run it all on a computer, or use it over web. Of course you can do it with sockets, but I find it a little overboard for a turn based game like this.

well, SOAP is much more "overboard" than socket, as it's exchanging xml-serialized objects over a HTTP connection over a socket.
Much more overboard, indeed, while much easier to code

Either way, I hope more great devs get into this pre-purchase, crowd funded ballpark.

I wouldn't hope that this crowd-funding model becomes too... crowded.

 

Okay, seriously: how much deep is the internet's pocket?
If loads of "huge indie" studios such as Double Fine or Obsidian start dropping into the crowd-funding because it is a gold mine, how much will it last before people become cynic and feel used?
I think this could as well mean the end of the whole thing, on the long run. Remember that perfect competition means that nobody earns nothing.

I gotta say, I tried to get back into the games and stuck with Soul Silver for a while, but honestly I think it's me that's really changed.

This. I feel that the game is just "honest to good" now. I'm sure that' it's me that changed as Silver used to be my favourite... and I dropped Soul Silver because it was too boring.
Too much grinding, too little strategy in battles comparing to brute force use, the pace is really slow and the story is inane.
And those all were strong points back when I were a kid.

So uhm, they can try to have a decent battlesystem and some tactics more complicated than try to grind a pokemon for each strong type, but I don't think they will.

I love this graphic style!
I'm wondering how buildings and units are going to appear, I can't wait to see more!

Thanks  
Units and buildings will not be to scale and will probably be lowpoly-3D, but at this point I don't really know how I will make them, so I will use some placeholders for now.
Btw, the textures on that scene are placeholders too!

I'm pouring detail into the terrain generator for my very-large-scale turn based game

Here's a peninsula with a vast desert:


the dark grey lines are impassable (for vehicles and non-jetpack infantry) cliffs, I need to find a more eye-pleasing way to show them.
The slightly greenish sand at the center of the desert is an Erg, or dunes.

And I added snowlands, where water freezes and vehicles are slower:

(I still need to do the cliff prop in the zoomed view, imagine awesome rocks around the frozen lake)

The terrain has to be contrived enough to be interesting at large scale, for region based gameplay, and for turn based battle gameplay where you manage single units on a battlefield.

I think it's coming out nice. Next in line: roads, regions and buildings!

but, in my current code "super" and other table references are a bit of a problem... currently inheritance is computed post-parse: both tables are parsed and then are merged field by field, so right now I'm only not copying overriden members.
Anything else would require to parse an expression, locate and replace an external reference, solve that expression.
And since I don't like to reinvent the wheel, this has to wait until I implement some scripting language

Just added inheritance to my data format, so that this table "custom_weapons"

Code:

custom_weapons : weapons = {
    rifle = {
        range = 15
    }
}

is actually identical to weapons except that rifle.range is overriden to 15. And the cool part is that it required only 10 lines of code

It would have been even awesomer with "super" semantics such as "range = super.range + 5", but then I would be better off implementing Lua.

That's not streamlining; which is taking a relatively complex set of actions and simplifying them to common denominators

I think over-streamlining is good, as there can definitely be too much of it. Just take the "lowest denominator" and try to apply it to "everyone" and here you have a bland an on-rails game that completes itself.

This was exactly my big problem with Skyward Sword!
While I wouldn't call this "over-polish", because what damages your game can't really be polish, that's more like over-caring-for-the-casuals.

I tried ARGB ABGR BGRA and a maybe 10 or so more.

RBAG? For the disappearing green, you know
Ok seriously, really strange. Also because it would be an huge bug and I can't google it.
You should really try what happens on other devices!

Seriously. GL_UNSIGNED_BYTE was the problem. It works on iOS and PC operating systems, but it threw a fit with Android. 

Maybe, GL_RGBA format on Android is different, as byte order is not guaranteed?
It is really strange that the simplest format ever for the hardware is not supported, I'd bet something other is wrong somewhere.

But then, if the AI is sluggishly coded you don't need to downgrade it, you just need to optimize. If it's inherently heavy, I don't see how you could scrap parts of it without damaging your game's playability.
Imo you just have to set a minimum and assume it is always there, trying to scale on everything is pointless.

Maintaining low spec functionality is a huge pain. It's hardly as easy as you make it sound. And then, some people are going to blame the shitty AI/graphics/gameplay on the developer or the game and form their impression based on that. Many developers would rather people not buy or play their game than play a gimped, cut down version that won't be fun for anybody.

If you have an old computer, don't expect to be able to play every new game. Simple as that.

this.
And I really wonder anyway what kind of AI you can have that takes more than 1% of frame time even on an old pc. It has to be something massive

[new]

alloca() isn't standard.  It also causes problems in C++ because you won't get proper execution of constructors and destructors.

You would be much better off writing a custom memory pool object and overloading new and delete to use it for those scenarios.

Or even better, do nothing and use standard allocation avoiding a lot of drama
After all modern allocators are as fast as they get. I always used custom allocators previously, but they cause additional hassle (on top on what C++ already masterfully causes) and the effective performance gain is invisible if you're already allocating memory in a sane way.
So uhm, do not new() and delete() at runtime when possible!