I was referring to dynamic lights specifically. On 17 June 2010 15:24, Adam Buckland <adamjbuckl...@gmail.com> wrote: > You say that, I'm not sure it's that the lighting 'sucks', but more > that it's a pain in the arse for modders because they don't have > server farms to compile lightmaps unlike Valve. > > On 17 June 2010 15:20, Harry Jeffery <harry101jeff...@googlemail.com> wrote: >> I noticed that too, lighting is one of the major things the source >> engine sucks at. Hopefully Source 2011 will make the life of modders >> 10x easier. >> >> On 17 June 2010 15:11, Adam Buckland <adamjbuckl...@gmail.com> wrote: >>> Also, after looking at the Portal 2 gameplay footage from IGN: >>> http://www.youtube.com/watch?v=5THiN8szSKM (there's 3 parts) am I the >>> only one that thinks that the lighting system has had to have a large >>> overhaul to support how the levels change dynamically? (particularly >>> obvious in the part 1) >>> >>> On 17 June 2010 14:58, Alexander Hirsch <1ze...@googlemail.com> wrote: >>>> Mesa3D? >>>> >>>> On Tue, Jun 15, 2010 at 5:20 AM, Katrina Payne >>>> <fullmetalhar...@nimhlabs.com >>>>> wrote: >>>> >>>>> This also adds a rather odd burden here, that allows Linux to get a better >>>>> standing for gaming. >>>>> >>>>> It is not that unknown that without mixing, Linux generally does not >>>>> require >>>>> anywhere near as much over head to run as windows. >>>>> >>>>> The minimum requirements to run a GUI on Linux is about 256MiB of RAM. >>>>> This >>>>> even includes GUIs like KDE and Gnome. Though XFCE and LXCE would be >>>>> better >>>>> if >>>>> you really did only have 256MiB of RAM (well if you were using a DE... and >>>>> not >>>>> a slimmed down WM with only a few programs loaded into it) >>>>> >>>>> You can do just fine win 1GiB of RAM. >>>>> >>>>> Linux also, as an OS can run on some old Intel boards--that running an OS >>>>> on >>>>> would other wise be insane today. a Pentium 1 can still get (some) use >>>>> with >>>>> Linux. >>>>> >>>>> Not enough to really be noteworthy as a desktop PC... but, this is a lot >>>>> less >>>>> than the least you will get Windows 7 onto. >>>>> >>>>> So we have a nice toss up here: >>>>> >>>>> 1: Linux requires Software Rendering in place. IE: how rendering was done, >>>>> before we got silly things like TNT and Voodoo on the market. >>>>> >>>>> 2: Linux requires significantly less overhead to run, as far as OS goes. >>>>> >>>>> If we can get it so that we can show Steam running on Linux, using mostly >>>>> Software Rendering, and getting it to run as fast as the same game on >>>>> Windows, >>>>> on comparable hardware... >>>>> >>>>> This will definitely sell Linux as an OS... >>>>> >>>>> Which in turn will get various Graphics Card makers on board to add their >>>>> support. >>>>> >>>>> You know--I kind of want to see somebody work on that goal then. I am >>>>> almost >>>>> ready to dig up some old books that go over the theory of 3d programming, >>>>> just >>>>> to pull make a software rendering engine for this idea. >>>>> >>>>> On Monday, June 14, 2010 07:59:45 pm Darren VanBuren wrote: >>>>> > Yes, 3D drivers are definitely quite lacking on the GNU/Linux front, >>>>> > but if Valve shows support for the development of these drivers, this >>>>> > may prompt certain GPU manufacturers to step up their GNU/Linux driver >>>>> > development. >>>>> > >>>>> > Darren L. VanBuren >>>>> > ===================== >>>>> > http://theoks.net/ >>>>> > On Mon, Jun 14, 2010 at 18:35, Bob Somers <magicbob...@gmail.com> wrote: >>>>> > > Something to consider, though, is that the 3D driver support is years >>>>> > > behind from *ahem* a particular GPU manufacturer. I won't embarrass >>>>> > > them by saying their name, so I'll just say their initials: ATI. >>>>> > > >>>>> > > Their driver support for Linux is, frankly, pathetic at best. The >>>>> > > Fedora team is trying to solve this with their new free drivers in >>>>> > > Fedora 13 (which, I'll admit, are quite good), but it's still not up >>>>> > > to par with what you need to run a game. For example, the new free >>>>> > > drivers have very little (read: practically none) support for basic >>>>> > > vertex and fragment shaders. It will be at least another year before >>>>> > > the free drivers are up to what ATI's crappy proprietary drivers are >>>>> > > now. Even worse, right now you can get the proprietary drivers running >>>>> > > on Fedora 11 alright, sort-of on Fedora 12 with some ugly hackery, and >>>>> > > not at all on Fedora 13. Literally, ATI's Linux drivers are at least >>>>> > > 12 months behind, and the free ones are 12 months behind that. >>>>> > > >>>>> > > Unless somebody gives ATI a swift kick in the nuts the situation does >>>>> > > not look good. >>>>> > > >>>>> > > --Bob >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > On Mon, Jun 14, 2010 at 5:01 PM, Darren VanBuren <onekop...@gmail.com> >>>>> wrote: >>>>> > >> Spoiler Alert. It's like the ratman drawing that says "She's watching >>>>> > >> you." Canonical is she in that case. >>>>> > >> >>>>> > >> I'm personally a fan of Fedora, but if Steam on GNU/Linux is >>>>> > >> distributed as a tarball, that'd be best in the interests of Valve. >>>>> > >> Even if some people (mainly Ubuntu users) would be a bit stuck on the >>>>> > >> concept of a tarball, it'd be minimal work for Valve, and maximum >>>>> > >> cross-distribution compatibility. >>>>> > >> >>>>> > >> Darren L. VanBuren >>>>> > >> ===================== >>>>> > >> http://theoks.net/ >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> On Mon, Jun 14, 2010 at 16:49, Harry Jeffery >>>>> > >> <harry101jeff...@googlemail.com> wrote: >>>>> > >>> It's all down to personal opinion, as long as it does what you need >>>>> > >>> quickly and effectively then it's fine. I've yet to see the dark >>>>> > >>> side >>>>> > >>> in cannonical so I honestly can't say much about their ethics. >>>>> > >>> >>>>> > >>> Either way, I <3 Linux and so should Valve. >>>>> > >>> >>>>> > >>> On 15 June 2010 00:19, Katrina Payne <fullmetalhar...@nimhlabs.com> >>>>> wrote: >>>>> > >>>> Well a few points: >>>>> > >>>> >>>>> > >>>> The commands in the Linux Commandline... and well those on any UNIX >>>>> or >>>>> UNIX >>>>> > >>>> Workalike have not really changed since the 1970s. You could pick >>>>> > >>>> up >>>>> a >>>>> book on >>>>> > >>>> BASH or TCSH from the 1970s, and still have most of what you should >>>>> do. >>>>> > >>>> >>>>> > >>>> This kind of has allowed for tools to be put around these base >>>>> functions, such >>>>> > >>>> as autocomplete, history and well--quite a few other really handy >>>>> tools, to be >>>>> > >>>> added into the Linux CLI, to make its functionality go above and >>>>> beyond >>>>> > >>>> anything cmd.exe is capable of. >>>>> > >>>> >>>>> > >>>> I still have yet to look into Microsoft's PowerShell though. >>>>> > >>>> >>>>> > >>>> This is why most Linux users use the CLI. It has developed into an >>>>> experience >>>>> > >>>> that is completely unlike the root canal that is cmd.exe. You can >>>>> actually go >>>>> > >>>> in, and get some functionality from it. A lot of functionality too. >>>>> It >>>>> also >>>>> > >>>> gives the feeling that the user has more direct control--without >>>>> that >>>>> Pesky >>>>> > >>>> GUI in the way (though, technically, this just has a bunch of other >>>>> items >>>>> > >>>> typically in the way, such as init.d, bash, various bash >>>>> extensions-- >>>>> maybe >>>>> > >>>> screen... you are just trading one thing in the way, that is, a >>>>> > >>>> GUI, >>>>> for >>>>> > >>>> another thing, that is a CLI). >>>>> > >>>> >>>>> > >>>> Now, that said--there are plenty of Desktop Environments ('DE') >>>>> > >>>> that >>>>> Linux can >>>>> > >>>> make use of, that pretty much make requirement of CLI use >>>>> unnecessary. >>>>> That >>>>> > >>>> is, between KDE4, LXDE, XFCE, E17 and GNOME2/GTK, the average Linux >>>>> user >>>>> > >>>> nearly never has to do anything on the CLI. Unless something has >>>>> gone >>>>> horribly >>>>> > >>>> wrong. In which case, he should be able to get the local Linux >>>>> > >>>> Admin >>>>> to >>>>> fix it. >>>>> > >>>> >>>>> > >>>> As that technically is what he'd do if something went horribly >>>>> > >>>> wrong >>>>> on >>>>> > >>>> Windows. He'd get his local Windows Expert to fix it. >>>>> > >>>> >>>>> > >>>> The "required" use of the CLI rather than GUI to properly use >>>>> > >>>> Linux, >>>>> is >>>>> much >>>>> > >>>> like how using Vi is "required" rather than EMACS for the proper >>>>> > >>>> use >>>>> of >>>>> Linux. >>>>> > >>>> >>>>> > >>>> Also, I use Fedora, and typically find it a LOT easier to work with >>>>> than >>>>> > >>>> Ubuntu. This maybe, because Fedora tries not to be a bunch of >>>>> asshats >>>>> to the >>>>> > >>>> people upstream. The same cannot be said about Canonical, the >>>>> > >>>> owners >>>>> of >>>>> > >>>> Ubuntu. Where, from what I have seen on their policies by past >>>>> actions... >>>>> > >>>> their MAIN desire is to be asshats to the upstream. >>>>> > >>>> >>>>> > >>>> I have a long winded rant on why I do not like Ubuntu... I mostly >>>>> just >>>>> state >>>>> > >>>> that nobody uses Ubuntu Linux. Typically most people go over to >>>>> another >>>>> Linux >>>>> > >>>> Distro afterwards, generally agreeing that no matter what Linux >>>>> Distro >>>>> they go >>>>> > >>>> to, be it Fedora, Puppy (well, prior to being based on Ubuntu), >>>>> Arch, >>>>> Slack, >>>>> > >>>> Gentoo, Knoppix, CentOS, LFS, etc., is better than Ubuntu... either >>>>> that, or >>>>> > >>>> they return to Windows--only using Ubuntu as a rescue disk setup. >>>>> > >>>> >>>>> > >>>> Right, now then. Back to your regular discussion >>>>> > >>>> >>>>> > >>>> ~Katrina >>>>> > >>>> >>>>> > >>>> On Sunday, June 13, 2010 07:20:08 am Harry Jeffery wrote: >>>>> > >>>>> People like the command line because it's very fast to do what you >>>>> > >>>>> want if you know what you are doing. So far ubuntu seems to be the >>>>> > >>>>> most user friendly linux distro and what a majority of linux >>>>> > >>>>> gamers >>>>> > >>>>> might use. >>>>> > >>>>> >>>>> > >>>>> Personally I'd just use arch-linux and optimize my system...a lot. >>>>> As >>>>> > >>>>> long as nVidia release decent linux drivers it's all good. >>>>> > >>>>> >>>>> > >>>>> On 13 June 2010 14:01, Adam Buckland <adamjbuckl...@gmail.com> >>>>> wrote: >>>>> > >>>>> > A couple of things: >>>>> > >>>>> > >>>>> > >>>>> > Elan Ruskin gave a good talk on porting to consoles at GDC08. >>>>> > >>>>> > The >>>>> > >>>>> > slides are on Valve's website. There's something in there that >>>>> may >>>>> > >>>>> > help you here: >>>>> > >>>>> > >>>>> > >>>>> > #ifdef __GNUC__ >>>>> > >>>>> > #define MAXSI_THREADED_VARIABLE __thread >>>>> > >>>>> > #else >>>>> > >>>>> > #define MAXSI_THREADED_VARIABLE __declspec( thread ) >>>>> > >>>>> > #endif >>>>> > >>>>> > >>>>> > >>>>> > You may wish to use another define for windows rather than an >>>>> else >>>>> > >>>>> > statement in case you wish to port it somewhere else in the >>>>> future. >>>>> > >>>>> > >>>>> > >>>>> > Also I agree, the Mac and Linux ports are incredibly similar. In >>>>> fact, >>>>> > >>>>> > on the Mac port a shell script is executed first to determine >>>>> whether >>>>> > >>>>> > it's running on OS X or Linux. >>>>> > >>>>> > >>>>> > >>>>> > Finally Linux could be a great consumer platform. Before it can >>>>> become >>>>> > >>>>> > this, it needs to learn that not everyone is a power user, and >>>>> make >>>>> > >>>>> > things simple. Learn from the Mac app bundles, and remove >>>>> reliance >>>>> on >>>>> > >>>>> > the command line (for example the output is shown on the update >>>>> > >>>>> > software). It scares normal users. That, and a lot of power >>>>> > >>>>> > users >>>>> > >>>>> > (like myself), don't want to have to rely on the command line >>>>> > >>>>> > for >>>>> > >>>>> > everything. >>>>> > >>>>> > >>>>> > >>>>> > On 13 June 2010 13:28, Jonas 'Sortie' Termansen < >>>>> hlcod...@maxsi.dk> >>>>> wrote: >>>>> > >>>>> >> I'd like to share a few experiences about porting code and >>>>> writing >>>>> > >>>>> >> portable code. Scroll down, if you just want my thoughts on how >>>>> portable >>>>> > >>>>> >> the Source Engine is. >>>>> > >>>>> >> >>>>> > >>>>> >> Recently I've been porting my in-development digital >>>>> distribution >>>>> > >>>>> >> platform to GNU/Linux for the fun of it. Naturally, most of my >>>>> code >>>>> > >>>>> >> didn't work right out of the box. But it is worth that several >>>>> > >>>>> >> subsystems actually worked at the first attempt, or with an >>>>> > >>>>> >> edit >>>>> or >>>>> two. >>>>> > >>>>> >> For instance, my string system and parser classes/functions >>>>> compiled >>>>> > >>>>> >> right away. >>>>> > >>>>> >> >>>>> > >>>>> >> However, stuff like accessing the filesystem, multithreading, >>>>> user >>>>> > >>>>> >> interfaces, networking, and so on didn't work because it relied >>>>> on >>>>> the >>>>> > >>>>> >> Windows API. The interesting part here is that POSIX does >>>>> > >>>>> >> things >>>>> > >>>>> >> differently; but almost in the same manner as Windows. That >>>>> means >>>>> for >>>>> > >>>>> >> each Windows API call you use, there is often one or more POSIX >>>>> calls >>>>> > >>>>> >> that does the same thing (if you add a little abstraction, that >>>>> is). >>>>> > >>>>> >> >>>>> > >>>>> >> Now, some of you heavily suggested the use of #ifdefs all >>>>> > >>>>> >> around >>>>> the >>>>> > >>>>> >> code. You should not use #ifdefs each time you rely on platform >>>>> specific >>>>> > >>>>> >> behavior, but only in shared function calls or in headers. For >>>>> instance, >>>>> > >>>>> >> if you have to open a file. On Windows you can call the >>>>> CreateFile >>>>> > >>>>> >> function, while POSIX supports the open function. That means >>>>> > >>>>> >> for >>>>> each >>>>> > >>>>> >> file opening, you need to write something like. >>>>> > >>>>> >> >>>>> > >>>>> >> #ifdef linux >>>>> > >>>>> >> int FileHandle = open(Path, Flags); >>>>> > >>>>> >> #elif defined(WIN32) >>>>> > >>>>> >> HANDLE FileName = CreateFile(...) >>>>> > >>>>> >> #endif >>>>> > >>>>> >> >>>>> > >>>>> >> Naturally, this isn't very pretty. And if this was used all >>>>> > >>>>> >> over >>>>> the >>>>> > >>>>> >> Source Engine you would spend a lot of time writing #ifdefs and >>>>> checking >>>>> > >>>>> >> platform specific documentation. However, I am not saying >>>>> #ifdefs >>>>> are a >>>>> > >>>>> >> bad idea. But instead of using them all over your code, you >>>>> should >>>>> move >>>>> > >>>>> >> them to a shared class or function that simply implements all >>>>> this >>>>> once. >>>>> > >>>>> >> In my code, I declared an abstract baseclass called >>>>> MaxsiFileSystem >>>>> that >>>>> > >>>>> >> implements all the common functions to access the local >>>>> filesystem. >>>>> So >>>>> > >>>>> >> now when I wish to open a file for reading, I would call: >>>>> > >>>>> >> >>>>> > >>>>> >> MaxsiHandle FileHandle = FileSystem()->OpenFile(Path, >>>>> MAXSI_FILE_READ | >>>>> > >>>>> >> MAXSI_FILE_SEQUENTIAL); >>>>> > >>>>> >> >>>>> > >>>>> >> This additional layer of abstraction makes it very easy to add >>>>> support >>>>> > >>>>> >> for new platforms as you just have to define a new child of the >>>>> abstract >>>>> > >>>>> >> baseclass. I have also added such a layer for my Window System. >>>>> This >>>>> > >>>>> >> means I call my own APIs in my actual code, and then it >>>>> redirects >>>>> it to >>>>> > >>>>> >> the Windows API or GTK+ depending on your platform. >>>>> > >>>>> >> >>>>> > >>>>> >> You might also have noticed I implemented a FileSystem() >>>>> function, >>>>> in >>>>> > >>>>> >> the same manner I have implemented a WindowSystem() function >>>>> that >>>>> > >>>>> >> returns the window system in use by the current function/class. >>>>> This >>>>> > >>>>> >> makes it easy to simply swap the window system on the fly. For >>>>> instance, >>>>> > >>>>> >> my source mod links against my distribution platform (LGPL) and >>>>> my >>>>> mod >>>>> > >>>>> >> then implements some of these interfaces. It could implement >>>>> > >>>>> >> the >>>>> > >>>>> >> MaxsiWindowSystem class using VGUI and then my programs could >>>>> > >>>>> >> be >>>>> > >>>>> >> natively drawn ingame with mininal work. >>>>> > >>>>> >> >>>>> > >>>>> >> Other porting issues includes how the VS compiler breaks a lot >>>>> of >>>>> the >>>>> > >>>>> >> C99 standard. To counter this, I have simply declared a lot of >>>>> macros in >>>>> > >>>>> >> my header files that replaces platform specific behavior. >>>>> #defines are >>>>> > >>>>> >> very powerful for this. For example, to declare a >>>>> thread-specific >>>>> > >>>>> >> variable, I would use this header define: >>>>> > >>>>> >> >>>>> > >>>>> >> #ifdef __GNUC__ >>>>> > >>>>> >> #define MAXSI_THREADED_VARIABLE __thread >>>>> > >>>>> >> #else >>>>> > >>>>> >> #define MAXSI_THREADED_VARIABLE __declspec( thread ) >>>>> > >>>>> >> #endif >>>>> > >>>>> >> >>>>> > >>>>> >> And then use the MAXSI_THREADED_VARIABLE macro to declare each >>>>> threaded >>>>> > >>>>> >> variable. My experience is also that the GNU Compilers throw >>>>> much >>>>> more >>>>> > >>>>> >> errors and warnings than the Visual Studio compiler - and it is >>>>> often >>>>> > >>>>> >> right to do so. Visual Studio teaches you to write bad >>>>> > >>>>> >> standards-breaking code, even if you just compile using MinGW >>>>> you >>>>> will >>>>> > >>>>> >> get to fix a lot of issues that makes your code rather >>>>> non-portable. >>>>> > >>>>> >> (Like avoiding Microsoft-specific extensions to the C Library, >>>>> in >>>>> some >>>>> > >>>>> >> cases.) But Microsoft did break the standard enough that you >>>>> might >>>>> need >>>>> > >>>>> >> to use some of the above methods for porting, just to get your >>>>> code >>>>> > >>>>> >> compiling using MinGW. >>>>> > >>>>> >> >>>>> > >>>>> >> >>>>> > >>>>> >> Now to return to the Source Engine. In my experience a lot of >>>>> stuff >>>>> in >>>>> > >>>>> >> the SDK code is already defined using interfaces, classes, and >>>>> such. >>>>> > >>>>> >> That means the actual porting issues have been outsourced to >>>>> > >>>>> >> the >>>>> Engine. >>>>> > >>>>> >> This, in turn, means that the SDK code will be rather easy to >>>>> port >>>>> > >>>>> >> compared to the Engine. Fortunately, as the Source Engine >>>>> already >>>>> is >>>>> > >>>>> >> highly modular using interfaces, it is easy to just swap a DX >>>>> renderer >>>>> > >>>>> >> with OpenGL. As such, they already have the framework to make >>>>> their >>>>> code >>>>> > >>>>> >> work on new platforms - all they have to do is implement their >>>>> > >>>>> >> interfaces using the local system calls. If you start to do >>>>> > >>>>> >> this >>>>> on >>>>> the >>>>> > >>>>> >> low-level interfaces and move upward, then soon your program >>>>> starts >>>>> > >>>>> >> working in all its glory. >>>>> > >>>>> >> >>>>> > >>>>> >> As for a Steam Client for GNU/Linux. It exists. I lost the >>>>> > >>>>> >> link, >>>>> but it >>>>> > >>>>> >> seems that Valve uploads nightly builds of their Steam Client, >>>>> and >>>>> each >>>>> > >>>>> >> day it works just a bit better. Last I heard, the Steam Client >>>>> actually >>>>> > >>>>> >> logged on and the actual UI was partially drawn. I am not sure >>>>> why >>>>> Valve >>>>> > >>>>> >> is so silent about this - perhaps it's just experimental, or >>>>> they >>>>> they >>>>> > >>>>> >> to make a big deal about it, like they did with the Mac. >>>>> Seriously, >>>>> when >>>>> > >>>>> >> are they gonna shut up about it? Last I saw was that they made >>>>> > >>>>> >> a >>>>> funny >>>>> > >>>>> >> TF2 comic about it. >>>>> > >>>>> >> >>>>> > >>>>> >> >>>>> > >>>>> >> Porting programs to Linux hasn't been very hard for me, though >>>>> it >>>>> is a >>>>> > >>>>> >> lot of work, if you want to do it properly. It seems that the >>>>> Source >>>>> > >>>>> >> Engine is already highly portable and GNU/Linux build doesn't >>>>> seem >>>>> too >>>>> > >>>>> >> difficult, as it seems from the nightly builds. There is no >>>>> doubt >>>>> about >>>>> > >>>>> >> whether we need a client for GNU/Linux, it is just a matter of >>>>> time >>>>> > >>>>> >> before they announce and release it. >>>>> > >>>> >>>>> > >>>>> > Bucky >>>>> >>>>> _______________________________________________ >>>>> To unsubscribe, edit your list preferences, or view the list archives, >>>>> please visit: >>>>> http://list.valvesoftware.com/mailman/listinfo/hlcoders >>>>> >>>>> >>>> _______________________________________________ >>>> To unsubscribe, edit your list preferences, or view the list archives, >>>> please visit: >>>> http://list.valvesoftware.com/mailman/listinfo/hlcoders >>>> >>>> >>> >>> >>> >>> -- >>> >>> Bucky >>> >>> _______________________________________________ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>> http://list.valvesoftware.com/mailman/listinfo/hlcoders >>> >>> >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> > > > > -- > > Bucky > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > >
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
