Re: fps modding
- From: "cr88192" <cr88192@xxxxxxxxxxxxxxxxxx>
- Date: Wed, 3 Aug 2005 10:34:02 +1000
"garry" <spam@xxxxxxxx> wrote in message
news:sradnXklJuv8WXLfRVnyhg@xxxxxxxxxxxx
>> I personally find it annoying.
>>
>> it tends to take up memory and processor time, it connects and updates
>> when I try to play hl2 (rather than just allowing the game to run
>> standalone). it could have pluses, but, personally, I find it rather
>> annoying.
>
> Yeah the memory usage used to be really high for no reason - but they've
> got a lot better about that nowadays. For me the plusses really outweigh
> the minuses..
>
dunno, I haven't checked recently, but when I was messing with things I had
just remember steam sitting around and using up a lot of memory. it is ok I
guess, I do have 1GB of ram, but it almost makes me think I should have
more.
similar goes for the memory requirements of hammer.
> + automatic patching
> + all clients using the same version
this is true, possibly, but the update downloads are annoying (partly
because internet where I am has terrible latency when accessing any us or
european servers).
> + easy game purcashing
I guess this has the same problem as wanting to pay for milkshape...
I don't really use this part.
> + open to indie developers to publish their games via
> + free additional content
sorry, I don't get how this is that much better than websites...
actually, I personally would have probably preferred websites (though maybe
a centralized service still would make sense, eg, for doing the kinds of
things steam does).
> + no 0-day piracy
>
ok.
> - steam sdk tied too closely to steam
> - ropey offline mode
>
yes.
me having to wait about 15 or so minutes for steam to connect up and
download updates is not pleasant. it involves a lot of 2 way communication,
over a rather high-latency net connection (yes, the internet here "can" be
fast, if the servers are located in taiwan or china, and to a lesser extent
japan or korea).
actually, probably steam would be a lot less annoying if I could mess with
hl2 without it bothering to log in and such.
>
>> additional minor complaint (more about hl2 itself): load times are
>> annoyingly long. I guess anymore, one can't expect new games to load as
>> fast as quake 1/2 or half-life did, but it would be nice if they could
>> load "faster". me, feeling annoyed if it takes more than a few seconds to
>> rebuild and load a map.
>
> Yeah, well kinda. The maps tend to take a long time to load the first time
> you run them (It creates a 'soundcache' while loading which speeds up
> future loads). When I was making my mod I was really concious of the load
> times - although they seemed to take a long time it, on average, took
> about 30 seconds (after the cache). Each additional search path added
> around 5 seconds to it.
>
well, yes, at least hl2 loads faster than doom3 in my experience.
just me, I am kind of fussy, I like load times (if possible) in the ms range
(quake does this). failing that, around a few seconds is "ok", but 30 is
overly long imo.
it also annoys me how long the engine takes to start up.
I don't know, new games just seem to take longer to load on new computers
than old ones did one old computers.
from memories, back on a 486dx quake took about 5s to load and about 1s or
so per map. doom was similar.
this continued, until (as far as I remember), around the time of quake 3 and
serious sam, where load times started getting a lot worse.
as for hl2: I wonder if part of their problem may be heavy use of texture
compression. or, at least, I don't know what algo they are using. at one
point, I had designed a dct+arithmatic coding based format (like jpeg) for
my engine, but then noticed that I just couldn't get dct acceptably fast. it
took long enough per-image, that with a lot of images it could be slow. it
allready takes long enough to try to pass the images to gl to use as
textures...
most of what compression I do is with bytewise lz77, partly, as bytewise can
get "almost" as good as huffman-coded lz77 (deflate: used in zip, gzip,
....). however, skipping huffman coding, with a fast decoder, can rather
exceed the decompression speeds of gzip (about 100MB/s or so afaict), the
upper limit I have pulled off is around 400MB/s (more may be possible, in
particular using an approach faster than movsb for copying memory, but the
problem is that most faster approaches are problematic when the sources and
destinations overlap).
the fastest I have gotten for c based decompressors (my typical ones) is
around 200MB/s (with, typical algo details effecting the speed, so around
150MB/s is a good "middle of the road").
hmm, maybe bytewise lz77 could be applied to images (sort of like cruddier
png) it could be smaller than tga but still get good load times. actually, I
sort of do similar for lightmaps (though the lightmaps use an older and
poorer version of the algo).
eg:
subtractive decorelation (Y=G, U=B-Y, V=R-Y);
possible difference filtering (I had used a 2 pass subtractive filter
before, maybe effective would be a midpoint-difference, but this could be
more expensive to compute), this may be ommited as it is possible that this
would hurt bytewise lz77 by possible destroying repetivive patterns, but
many of them would become long runs of 0s anyways;
bytewise lz77 (actually, given the high skew resulting from difference
filtering, huffman coding would work quite well, but huffman coding costs
time).
likely, the lz77 compressor would need to be specialized for the data
comming out of the difference filter. values near 0 (signed) are likely to
be most common, so 64..192 (128 values) or 96..160 (64 values) would likely
be the best place for escape codes (since speed is a high priority, I can't
really use variable escape codes, and a plus is that the data will likely
have very predictable statistics anyways).
actually, in my messing with lightmaps, difference filtering had been
effective, so presumably it would work well for normal images as well.
but, then again, this would be an oddball format, and there is already tga.
I am not sure if the size would be sufficiently better than tga (ok,
probably not that hard), or if it would be sufficiently fast.
I could beat it together and check though...
for now, a lot of my files are either tga or jpeg. this will be much worse
than jpeg, but hopefully a lot better than tga and hopefully not too much
slower.
>>
>> I would also like it if half-life 2 could just be left running, and, eg,
>> hammer would rebuild the map and tell the game to reload. this can be
>> done manually, but it is annoying.
>
> This works for me, kind of. Well depending on what you're talking about.
> In my mod I added a "hammer exporter".
> http://www.garry.tv/garrysmod/wiki/index.php/Export_To_Hammer.
>
> When using this you HAVE to have both Hammer and HL2 open at the same
> time. It's usually best to play windowed if you're going to do this (which
> ideally you'd be doing anyway if you're developing). The only complaint
> (if you can even call it that) I would have would be that when you compile
> the map again it can't save unless you type disconnect in HL2 to unload
> the map.
>
oh, ok, is this for more automating what I was doing manually?...
yes, I do use windowed mode, windowed mode is generally so convinient for
lots of things (switching to other apps, ...).
oh, you are the person who made that mod (with all the playing with and
positioning of stuff)?...
very cool mod at least.
I have not done much of anything interesting with hl2 myself.
actually, as noted previously it has been years since I really done much
modding, in particular going back to around 1998-2000, where I was primarily
messing quake 1.
quake 1 was much less modable than probably most newer games were (I did do
a few things though, eg, raising lots of zombies from corpses that would
battle everything on map, ...).
one was limited though, the language wasn't c, and thus couldn't do that
much that could be called "impressive" by newer standards.
after that, I did some engine modding (once I found the engine source).
eg: the upper limit was with an engine mod that had a bunch of modified
quakeworld servers that would start up and interconnect, forming a
semi-continuous world (transitioning was sort of like half-life, namely that
of fixed areas with a 'trigger_changelevel' set up. one, however, couldn't
see to the other side of a server boundary.
one thing though was that typically the client was used for storing
information related to their state when moving across servers. otherwise
though, I would have needed some better way to manage the concept of
"identity".
.
- References:
- fps modding
- From: personguy89
- Re: fps modding
- From: cr88192
- Re: fps modding
- From: GaRRy
- Re: fps modding
- From: cr88192
- Re: fps modding
- From: garry
- fps modding
- Prev by Date: Re: Why not Half Life 3 on Java ?
- Next by Date: Re: Why not Half Life 3 on Java ?
- Previous by thread: Re: fps modding
- Next by thread: Re: fps modding
- Index(es):
Relevant Pages
|
|
