BlackMesa3D? Sounds like a new Disney flick. -----Original Message----- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Alexander Hirsch Sent: Thursday, June 17, 2010 9:58 AM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Source Engine 2!!!
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 _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
