AVWW Beta 0.921 "World Of Darkness" Released!

[Penumbra]

Reading the (relatively) small amount of serialized data from disc into RAM can't be what is taking so "long" (My computer may just be very fast, but I have almost read the text that appears when I go to a new chunk )

I think you said it already, but correct me if I'm wrong.  It is the chunk generation that is eating up those CPU cycles. What about generating the adjacent chunks in a separate thread while the player is exploring one. Worst case the player gets to a chunk that hasn't been processed yet and has to wait as normal. At a lower priority I don't see it taking away too much from the active game thread. I know you guys love your multi-threading

I don't presume to understand exactly how you have the game structured (well, I'm going to do exactly that now, but don't hold it against me). Wouldn't it  be streaming the new chunks right to disc, so that they are just "there" when the player moves to the next one. That way, it wouldn't even be hitting shared memory.

[x4000]

Reading the (relatively) small amount of serialized data from disc into RAM can't be what is taking so "long" (My computer may just be very fast, but I have almost read the text that appears when I go to a new chunk )

It's not reading data, it's writing about 3 files perhaps.  How long are we talking about, anyhow?

I think you said it already, but correct me if I'm wrong.  It is the chunk generation that is eating up those CPU cycles. What about generating the adjacent chunks in a separate thread while the player is exploring one. Worst case the player gets to a chunk that hasn't been processed yet and has to wait as normal. At a lower priority I don't see it taking away too much from the active game thread. I know you guys love your multi-threading

It's not thread-safe and would increase disk I/O quite a bit.  Not to mention we take a strict lazy-generation approach for good reason, so that things are generated at the last possible moment and thus are as up to date as possible as versions increase, etc.  Plus then world folders don't get vastly larger for no good reason just because of chunks you walked near, versus actually into.

I don't presume to understand exactly how you have the game structured (well, I'm going to do exactly that now, but don't hold it against me). Wouldn't it  be streaming the new chunks right to disc, so that they are just "there" when the player moves to the next one. That way, it wouldn't even be hitting shared memory.

Definitely not up for consideration prior to 1.0, and probably not anytime in the next year or two either.  That's a pretty enormous change, and the lag between rooms in most cases seems to be about 300ms for me.  For a large outdoor chunk, a second or two.  Seriously, what's being suggested would be an enormous investment of dev-time, as well as a huge potential for bugs on an ongoing basis, to shave off a very small amount of performance gain.  Holy cow no no no.

[Penumbra]

How long are we talking about, anyhow?

Not quite sure, but less time that it takes me to blink. Certainly not complaining, just curious.

[x4000]

How long are we talking about, anyhow?

Not quite sure, but less time that it takes me to blink. Certainly not complaining, just curious.

Right -- I'm definitely not putting weeks of man hours into developing a fix for that plus dealing with endless stream of bugs it would cause.  Plus then dealing with the extra slowness this would cause when backing up worlds because of all the excess files it was generating.  Plus all the extra CPU load for anyone who has only one processor (although we could make it turn on this feature only for those with multiple cores, then we'd have two code paths and thus even more bugs; and with low core counts there's not even a guarantee that the OS will properly allocate the worker threads to other cores).

[Penumbra]

There, now if anyone ever mentions it again, you can just reference this post instead! See, I'm saving you time 

[x4000]

Cheers.

[orzelek]

Just out of curiosity when we are talking memory and such:

1. Are you able to use all of GPU's texture memory before you start throwing textures out of it?
2. Would you be able to preload the textures in AIW in manner proposed here (it does quite many loading there when you zoom in closely or change to icons on right bar)? (since in AVWW it's not really possible due to size)

[x4000]

To the two questions:

1. No, we load a texture, draw it across some vertices for a bit, and then drop the texture.  In terms of the innards of what is really happening, a lot of that is obscured by unity, and then either directx or opengl under that.

2. We could do that for AIW (we do for Tidalis like we do here, except Tidalis has low enough counts of graphics that it never unloads anything), however I feel that AIW's current method is actually better for AIW.  It does give you pop-in and a slight bit of stutter there, but we're not talking about something that is frequent and it saves you a lot of loading time overall.  In your whole galaxy there are lots of ships that you would not see unless you go to that specific planet; And even then, not unless you zoom in.  So why load all that stuff and make you wait a long time (30+ seconds, probably) when you first load each galaxy?  Why not just load it as needed, and have a slight stutter when it's doing so?  It's loading those on 8 background worker threads, so they aren't blocking to the application itself.

[KDR_11k]

Is there any point in having 32 bit binaries these days? I don't think there are any CPUs being sold without 64 bit functionality anymore.

[eRe4s3r]

Actually there aren't any sold for many years now - the problem is as long as Windows does not offer a unified x64 OS there will always be people who buy a x86 OS when they have a x64 cpu

And again for Windows 8 the stupidity of Microsoft continues

[tigersfan]

Is there any point in having 32 bit binaries these days? I don't think there are any CPUs being sold without 64 bit functionality anymore.

What eRe4s3r said, but also, there are still a TON of older computers running x86 running out there.

[KDR_11k]

I wonder when those 32 bit systems are so old that we can just tell them that their hardware is no longer supported and make everything 64 bit only.

And again for Windows 8 the stupidity of Microsoft continues

Is it even possible to build a 32-bit-only PC that can run Win8?

[eRe4s3r]

I wonder when those 32 bit systems are so old that we can just tell them that their hardware is no longer supported and make everything 64 bit only.

And again for Windows 8 the stupidity of Microsoft continues

Is it even possible to build a 32-bit-only PC that can run Win8?

We already reached that time, we just need to educate developers (no offense x4000 ^^ )

You can still build a system that runs Vista with an Athlon XP or P4 but it'd be PAINFUL slow. These cpu's are at their limit with Windows XP.

These are the only CPU's you could possible still consider "able to run" anything above Windows XP in 32bit mode

Pentium 4
Athlon XP

Sadly, we can't tell from Steam Hardware Survey whether a CPU supports x64 or not. So we don't know what the actual numbers are, but I would guess the conversion to x64 is about 80% to 90% now. Only people holding out on extremely outdated hardware are left. (And those, who run Windows XP with a modern CPU (which is downright crazy!) and those who buy 32bit OS even though they have a x64 cpu)

Why Windows doesn't convert to native 64bit is probably for marketing reasons only. Customers usually don't enjoy being told by an OS that their hardware is outdated.