> Half-Life 2 sure won't play quake maps nor will it play hl1 maps.
Not without modifications but Half-Life: Source is essentially a tech demo to show that they can be ported easily (if you are OK with dropping some pesky features like randomized wall textures).
AFAIK hl1 maps needs to be open in hammer, tweaked a bit and then recompiled to function in hl2. You also better have those originals .rmfs rather than a .map or a even worse, a .bsp :)
edit: there is also the fact that map compilers for gold source games have advanced far beyond what they could do back in 1999. The lightmaps and light sources alone can be far more intricate nowadays than what you would get from the official valve ones in 1999.
The other thing though is that Original Quake Back In The Day ran on a Pentium 75 (needed the maths co-processor) with a dumb framebuffer. All the rasterising of polygons was pure software, as was all the geometry processing. Running GLQuake was a huge improvement but it required an expensive add-in card that piggybacked onto your VGA card, and a whole different binary.
Now you can just kind of pile it into a block of RAM, aim a chunky ASIC at it, and pull the trigger every frame.
In the late 90s a mate of mine did a phenomenal video of a Quake demo (you could record all player movements and camera positions as a "dem file") that he'd rendered out, raytraced in POVRay. I printed it to VHS for him as part of a showreel, and never thought to keep a copy myself.
While lighting is important, not using halflife.wad and going above the
original budget of 500 polys per "scene" is what makes modern works look much
better.
Most of the original textures are under 128×96 px and some suffer from awful
palletisation artefacts with purple and orange halos.
We still cannot use more than 8 bpp but we can use 512×512 textures and do a
better job at reducing to 256 colours. I use pngquant for that.
In GoldSrc lightmaps cannot get more intricate though, they're tied to the
texture scale so you cannot get a finer lightmap unless you also make larger
textures and scale them down, and these two combined will wreck your
"AllocBlock" budget in which all your textures and lightmaps must fit.
ericw-tools and its dirtmapping are still welcome improvements over the
"traditional" *HLT compilers.
> In GoldSrc lightmaps cannot get more intricate though, they're tied to the texture scale so you cannot get a finer lightmap unless you also make larger textures and scale them down, and these two combined will wreck your "AllocBlock" budget in which all your textures and lightmaps must fit.
AFAIK some of the improvements include much better light bouncing techniques, transmission of surface colors like source does, more accurate lights, spotlights that emulate what source spotlights does and faster compilation (computers also got faster and MT support helps a lot). That alone allows level designers to be more ambitious by taking advantage of faster iteration and place even more lights.
I do agree that there are likely dozens if not hundreds of reasons why maps can and usually do look way better today than what could be done in the past. Hell, even level designer proficiency with the tools as time goes is also surely a reason.
I used to do a bit of mapping back then (nothing that survived to this day, thankfully); as I recall, practically nobody used official map compilers. As it often happens, the community wrote replacements that were much faster for debug "-O0" builds, and generated lightmaps of a significantly higher quality for the release "-O2" builds.
It was either ZHLT or VLHT, or something like that; looks like more alternatives have been written since then.
The lighting is one of the main area's that really improved a lot.
For standard Q1 mapping ericw tools [0] is great (the page has some nice previews).
This project seems to use Nuclide for building which by default uses vmap compiler [1][2]. Which is really Q3 but I think FTE handles that well internally as the newer format has some more modern features.
> Powerful BSP compiler. Use VMAP to bake levels like you're used to from similar engine technology, with high quality lightmaps, cubemap-based environment mapping and adjustable vertex colors on spline-based meshes.
There was a similar path with Unreal3. The early games (2006) lighting looks quite harsh by modern standards, one of the highlights of Mirror's Edge (2008) was DICE using third party Illuminate's "beast" lighting, then Epic moved to "lightmass" around 2009 with the public UDK toolset.
A shame to only now learn of Victor Antonov's passing. His work on HL2 and Dishonored remain some of my favorite examples of video game world building of all time. These places felt real and lived in, in a way few other video games have matched for me.
GNOME devs operates more like benevolent dictators. It sure is oppressive and you better be glad for what you are getting, but what they put out with so few resources is leagues above what microsoft can do nowadays.
Maybe the general population will be willing to have a more constructive discussions about this tech once the trillion dollar companies stop pillaging everything they see in front of them and cease acting like sociopaths whose only objectives seem to be concentrating power, generating dissidence and harvesting wealth.
But the Squirrel is only playing chess because someone stuffed the pieces with food and it has learned that the only way to release it is by moving them around in some weird patterns.
If you want maximum commodity and as many things to "just work" as possible out of the box, go for good old plain Ubuntu.
If you care a little more about your privacy and is willing to sacrifice some commodity, go for Fedora. It's community run and fairly robust. You may have issues with media codecs, nvidia drivers and few other wrinkles though. The "workstation" flavor is the most mature, but you may want to give the KDE version a try.
If you want an adventure, try everything else people are recommending here :)
You can also configure it to keep open window buttons separate from the launcher icons, but with the lack of double stacking I rather have it "take over" the launcher.
The way I've set it up it will also only show the open windows for the virtual desktop or screen the bar being shown at, which helps alleviate the crowding issue of only having one row.
> I'll also create a feature request for resizing/stacking of rows.
That's the spirit! Please do file feature requests with the docks that you think might be close to what you want. A lot of foss projects are pretty receptive to feature requests.
Keep in mind that in the foss world you're not a customer - the people doing the work will be donating their free time to build a feature you're asking for, so please be nice and polite to them - the worst thing you can do on a feature request is have an entitled tone, or insinuate that their software is crap because it doesn't quite do what you want :)
Someone else suggested that adding 2 xfce panels might accomplish something pretty close to what you're after. I had a bit of a play around and agree with that. I didn't replicate your request exactly (because my panel is very different and I didn't want to break my setup too much) but depending on where your priorities lie I think you could probably get something pretty close.
Options that are similar:
a) If you really want the 'start menu' button to span both rows, use a single panel and set "row size" to e.g 48px and "number of rows" to 2. The con of this method is that the task list (list of programs) will span both rows, which is not what you have.
b) If you want to replicate your preferred setup more closely, you might not be able to have the 'start menu' button span both rows. To accomplish this I would add 2 panels of e.g 24px and put them both at the bottom of the screen. In one you'll have the task list and in another you'll have icons.
The media player controls might be an issue in xfce. I'm not sure if anything like that exists. However you definitely can have a systray icon for your media player which pops up media controls when you click on it.
There are other docks with more customisable widgets that will give you media controls like those, but I can't really make a solid recommendation for you unfortunately. The one I used to use was called cairo-dock, but I think that might be dead. Before that I used one called avant-window-navigator. There's also a couple of others that I'm aware of, e.g tint2 and wbar.
I'd be a little bit surprised if there are zero docks out there that can do what you want. The thing is you might have to try screwing around with the config for 20 different ones if you insist on replicating that layout exactly :/
reply