On 2/6/2012 2:29, nemesis wrote:
> It seemed to begin to load as you were close to
> get to the entry for the next section, which usually coincided with some narrow
> corridor.

That's how batman did it. Crawling thru airways, or waiting for the security 
doors to scan you.  I noticed because I went back through the wrong door in 
the jail at one point and the door took about 3 times as long to scan me, 
and I realied that's because it predicted me going thru the door that 
progressed the game. And that's on an xbox.


-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> One thing I don't understand is why games that target consoles don't do 
> infrastructure-type improvements on PCs.

  Laziness.

-- 
                                                          - Warp

Post a reply to this message

On 2/8/2012 8:12 AM, Warp wrote:
> Darren New<dne### [at] sanrrcom>  wrote:
>> One thing I don't understand is why games that target consoles don't do
>> infrastructure-type improvements on PCs.
>
>    Laziness.

Laziness???  Given how hard the games industry is known on working its 
employees, and that I figure you're aware of this too, I'm not even sure 
what you actually mean when you say "laziness" in this context.  I'd 
think that something like "other things have higher priority" would be 
far more accurate.

Post a reply to this message

On 08/02/2012 04:41 PM, Kevin Wampler wrote:

> Laziness??? Given how hard the games industry is known on working its
> employees, and that I figure you're aware of this too, I'm not even sure
> what you actually mean when you say "laziness" in this context. I'd
> think that something like "other things have higher priority" would be
> far more accurate.

The games industry is home to some visionary designers and very 
hard-working, productive programmers, who produce cutting-edge content.

It is /also/ home to developers who put out some decidedly lazy 
offerings. Short games with gratuitous padding to make them longer. 
Games which are blatantly identical to existing successful products. 
Hastily produced sequels with large sections of identical or minimally 
modified content. Oh, I'm sure some of these companies still whip their 
developers pretty hard. But the end product is still "lazy", IMHO.

I suppose it's just like any other industry, really. How many great 
films have had sequels hastily thrown together which turned out to be 
awful? Whilst I'm sure even a hasty sequel is quite a lot of work to 
produce, the result can still rightly be called "lazy".

Post a reply to this message

> I'd think that something like "other things have higher priority" 
would be far more accurate.

To put this another way: I'm sure that through the development of Portal 
2, the programmers had a lot of things to work on. It's very likely that 
they were aware of the loading screens, and were forced to answer the 
question, "Should we spend programmer time eliminating loading screens, 
or should we spend that time, say, implementing light bridges?" If you 
would prefer the game without loading screens, you should suggest what 
feature you would have liked to trade that for.

The other option is to push back the release date. However, even if they 
had done that, I guarantee you they would have said, "Should we use this 
extra time to eliminate loading screens, or should we implement <cool 
gameplay feature the designers thought of but was cut for lack of time>?"

You can see how the only way that loading screens are going to go away 
is if they push back the release so much that there's really nothing 
better to work on. The list of things that have a higher payoff than 
eliminating loading screens is long, especially when you're suggesting 
it will only work on one of the target platforms.

Laziness doesn't really factor into it. It's a matter of priorities.

  - Slime

Post a reply to this message

> Would it really be so hard to have a low-priority thread loading the 
next level into a second block of RAM during the current level, or even 
during the elevator ride?

In a word, yes. It's only (relatively) easy under the assumption that a 
level can be "loaded into a block of RAM," which is probably not the 
case. There are probably many different things in a level that are 
loaded into many different places that interact with many different 
systems, all of which would need to be updated to make that possible. 
This comes with new bugs that take time to track down and fix. 
Obviously, some games do manage to do this, but that doesn't mean it's 
an easy feature to add to an engine that doesn't support it.

  - Slime

Post a reply to this message

On 2/11/2012 19:43, Slime wrote:
> In a word, yes. It's only (relatively) easy under the assumption that a
> level can be "loaded into a block of RAM," which is probably not the case.

Actually, since most of the time seems to be spent pulling the level off the 
HD or DVD, I would think you could pre-buffer the files at least. *That* 
should be pretty trivial to implement, even if unpacking the levels into 
individual objects and such can't be done easily. I'd imagine that would 
reduce loading times a bunch.

 > If you would prefer the game without loading screens, you should suggest 
what feature you would have liked to trade that for.

That's a good question. Portal2 is pretty tight. On the other hand, if the 
loading screens took 5 minutes each, I'd bet people would balance the 
priorities differently, or even hire an extra developer to work on it, so 
it's not like I'm asking for something absurd. :-)  Plus, of course, it's 
the Source engine, so it's not like the work wouldn't be amortized over 
numerous games.

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Actually, since most of the time seems to be spent pulling the level off the 
> HD or DVD, I would think you could pre-buffer the files at least. *That* 
> should be pretty trivial to implement, even if unpacking the levels into 
> individual objects and such can't be done easily. I'd imagine that would 
> reduce loading times a bunch.

  I'm not so intimately acquainted with the PC architecture to know for
sure, but how much can disk-to-RAM data transfer be made in parallel
with everything else a game can do, in terms of memory bus usage (iow.
does disk I/O have to share, and hence compete for, the same memory
bus as the CPU and, more significantly, the GPU, when transferring data
from the main RAM to it)?

  I know that the DMA chip allows transferring data between RAM and the
different devices without the need for the CPU to do anything (other
than launching the transfer), so things like pre-loading data from disk
to memory takes zero CPU time. However, I'm thinking how much congestion
it causes on the memory bus, and if it could have a negative impact on
data transfer performance in other critical areas (such as transferring
data from the main RAM to the GPU, which happens all the time).

  Of course there are many games, especially the open sandbox type ones,
which are specifically *designed* to load data on the fly, avoiding any
loading pauses completely. However, can speeding up level data loading by
pre-loading data on the background using available free memory be done
without the game engine having been specifically designed to do so?

-- 
                                                          - Warp

Post a reply to this message

On 2/13/2012 9:02, Warp wrote:
> does disk I/O have to share, and hence compete for, the same memory
> bus as the CPU

On modern desktop type machines, I think the disk probably steals memory 
cycles from the CPU. That's a good point. On the other hand, what's the 
transfer rate of even a fast disk? 120MBps?

> and, more significantly, the GPU, when transferring data
> from the main RAM to it)?

I wouldn't think the disk's DMA would affect CPU->GPU at all, since AGP bus 
and later, but I'm not sure. Of course, the CPU has to read from the RAM as 
well, so it's hard to say.

> data transfer performance in other critical areas (such as transferring
> data from the main RAM to the GPU, which happens all the time).

An excellent point I hadn't considered. Honestly, I haven't really thought 
about this stuff since the generations of machines where RAM is faster than 
CPUs. :-)

That said, given that a level in Portal (say) can take a couple minutes to 
go through, and a level takes maybe 15 seconds to load, keeping the transfer 
rate down to 1M/s or something might even speed things up there. Especially 
when you're talking about loading it off a DVD instead of a HD, where the 
seek times will still dominate.

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.

Post a reply to this message

>> data transfer performance in other critical areas (such as transferring
>> data from the main RAM to the GPU, which happens all the time).
>
> An excellent point I hadn't considered. Honestly, I haven't really
> thought about this stuff since the generations of machines where RAM is
> faster than CPUs. :-)

My graphics card has just under 1GB of on-board RAM. I would expect that 
once all the textures and meshes and so forth have been uploaded over 
the AGP bus (or PCI-X or whatever you're using today), the GPU probably 
requires minimal bandwidth from main memory. Certainly not enough that 
the piffling transfer rate of the disk drive would affect it in the 
slightest.

Post a reply to this message