as noted in incarnate's suggestion, those of us who have gobble amount of ram might find it less laggy to pre-cache all textures into memory to minimize sector load lags.

or perhaps a multi-level cache like:

pre-cached textures: [ default | large textures | all ]

where "default" would do whatever vo currently does, "large textures" would pre-cache those larger (hac, cappies etc) textures and leaver smaller ones spooled on disk as they load relatively fast and "all" would just fill the ram with goodies.

fine. gobble.

Totally missed the Timmy reference, huh?

oh. hrm. yeah.

wait. so you are NOT leaving vo then UC?

I'd love to precache everything. I could keep in mem ten copies of the entire media.rlb file, and still have room to spare for the rest of the processes (and kernel).

I find sad to have the aforementioned gobbles, and such a fine game can't take advantage of them.

C'mon, malloc() me to death.

Me likes

Hrm... how much RAM would be required onboard-system to be able to do this?

4 Gig? 8 Gig?

And what kind of card would you need to do this with? aWould any-old card work, or would it be better with a 256 MB or 512 MB (or HIGHER) card?

doak, i'm a paid member until fev the 3rd. until then, i still have a voice.

and i will not be drawn into another flame fest as to why i'm leaving. i think it's been made obvious in the past and the devs certainly dont need another whiner.

in time, i'll probably re-register. until then, my officious reason is "i need the 10$/month for lap dances".

so, back on topic, i have tons of ram and i dont tend to compile in the background, nor do any rna folding so if i can have vo use it all and make game play smoother, then that's one notch up for vo in the scale.

In general, it would work fine on a gig of ram, depending on how much ram was actually *free*. For instance, OS X is notoriously ram intensive, and OpenGL is sometimes kind of silly about memory management, so that platform might not work as well as others (especially RISC G4/G5s, where code takes up more memory as well). Last time we looked, I think Vendetta peaks around 400MB, total memory utilization, although in theory this should be reduced if everything was preloaded with texture compression enabled (DXT on all textures in memory should drop texture memory use by about 4:1, but models and things take up memory too). Video ram is irrelevant, this is purely a discussion of loading from disk into system memory.. loadtimes from there into VRAM should be very fast (AGP 8x and PCI-E x16 are both very speedy), or at least fast enough to not be really noticeable. In any case, that's generally handled by the driver and not something we can control. If the actual bus load times proved to be bad for anyone, they should definitely enable texture compression, which will substantially reduce the required bus bandwidth (at a cost of making textures not look quite as nice).

Downside to a preload option: it'll take a lot longer to start the game, since it would have to load everything at startup.

Oddly, there was actually a period (prior to release, I think? maybe Beta) when we did preload everything. The logic was that the OS's VM would be good enough to determine what to swap out and what not to, and if people spend enough time in the game they pretty much load everything anyway. We removed it due to complaints of startup memory usage and slow loadtimes, heh.

Note: in this vein, if you DID preload everything and your OS decided to swap something unused out to disk (like, say, a giant HAC capship texture), it'll be just as slow to reload when the ship jumps into view and the VM suddenly has to swap the pages back into memory. If you have enough ram though, this shouldn't happen, most OS's are not very aggressive about swapping out to disk.

Anyway, I'll talk to Ray about it, and see what's involved with making an option.

"officious"! :D

Ya it's an interesting thought. I do recall the complaints about preloading, though I didn't have any issues with it myself.

Oh, and NOW this is worthy of the "READ FIRST" Suggestions thread. Whoooo!

What about the -c option?

I still got those jumps with it when stuff jumped in but possibly less so. Wasn't worth the increased memory usage though so I didn'T bother with it after a while...

Spuck is right, there's already a commandline parameter (I completely forgot about that), although that doesn't work with the updater of course, so we should still do something to add it to the Options menu.

On my Athlon64 in XP, just starting up to the login, I get:

normal Vendetta - 166MB resident
-c Vendetta - 550MB resident

FYI.

well, for all i care, anyone running osx w/ less than a gig of ram is accustomed to sluggish app switches.

i have 2 gigs of ram atm and i would have used it all (well, say 1.5gig) for vo. i dont care too much about launch time. i launch it once, but i do load sectors a hell of a lot of times.

what if the cache was accumulative? eg, once it loaded something, it didn't let go of it? that might be a nice middle ground. so that would add a 4th option to that preload thing:

pre-cached textures: [ default | large textures | all | cumulative ]

What about a RAM-disk, is there some way to install vendetta to a RAM-disk. This would allow you to load things typically stored on the HDD lightning fast. in windows the game only requires 200mb of hdd space i think in mac its almost 400 but what the hell, youve got 2gb.

You might want to check this out it allows you to make a RAM-disk up to 4gb.

EDIT :Just noticed thats only for windows. I'm sure theirs a way to do it in osx.

The "cache" is cumulative. As Vendetta loads textures into memory, they aren't removed. That was the justification for originally preloading everything.. that you may well end up with it all eventually anyway (if you play for a long time). But in practice it isn't really true, since memory is taken up by the 130?-odd space station models, and so on.. and most people don't visit *every* single station during a single play session.

A ramdisk would technically help, but it would be better to simply use the ram for preloading all the textures. Part of the "lag" time is spent in disk I/O, but part of it is also spent decompressing JPEGs into raw images for loading onto the videocard.. which would not be improved by storing the data on a ramdisk. Some game developers store pre-compressed DXT/S3TC (hardware-decompressable textures) on disk for this purpose, but we don't due to the negative impact on texture fidelity (it basically truncates images to 16 bits, and color-bleeds in a lot of high frequency textures.. which we have), and also because doing so would increase our client download size (JPEG > DXT). More modern and improved hardware texture compression (3Dc, U8V8) is proprietary and not standard, so we can't very well use it.

People who want the absolute best in-game loading performance might consider enabling texture compression, and then also using total-precaching. This will take even longer to start up, as the client has to runtime decompress each JPEG -> RAW, and then recompress RAW -> DXT, and then load the DXT into memory. However, on my machine with the -c flag, I get about 260MB resident on startup, as opposed to ~550MB with uncompressed textures. Like I said previously, for a modern system with PCI-E x16 or some such, this *shouldn't* make a big difference.. but your mileage may vary. It's really up to the driver how optimally things are managed, but the more data you can keep locally on the videocard, the faster (and less frequent) loads will be. OpenGL on OS X is kind of bad at memory management, in our experience, although less-bad in recent years (10.3, 10.4).

In the beta versions of the now current UI, I had a problem with precaching. I was also running below minimum specs :P

At any rate, I think it's a good option for the whizs out there and those with higher end computers.

Just an FYI that the suggestion for this Option has been added as a ticket (#55), slated for sometime before the 1.9 release. The tickets will all be exposed as soon as the new Trac setup is ready for prime-time, but I thought I'd pass on the news that this is now slated for integration.

vo++.

great!