| *** tpb has joined #freeorion | 00:00 | |
| *** mithro has joined #freeorion | 01:04 | |
| *** bernardh has quit IRC | 03:10 | |
| *** mithro has quit IRC | 03:47 | |
| *** STalKer-X has joined #freeorion | 04:23 | |
| *** STalKer-Y has quit IRC | 04:39 | |
| *** GeofftheMedio has joined #freeorion | 04:50 | |
| *** GeofftheMedio_ has quit IRC | 05:08 | |
| *** dunno has joined #freeorion | 05:57 | |
| dunno | hi | 06:11 |
|---|---|---|
| dunno | any activity? | 06:11 |
| dunno | GeofftheMedio? | 06:11 |
| GeofftheMedio | yes? | 06:11 |
| dunno | cool, you're here | 06:11 |
| GeofftheMedio | mmhmm | 06:11 |
| GeofftheMedio | typing my name makes it flash | 06:12 |
| dunno | looks like the lead programmer hasn't commited anything for a while o_O | 06:12 |
| GeofftheMedio | nope, tzlaine's been busy | 06:12 |
| dunno | well, I was hoping to contribute code | 06:12 |
| dunno | so I thought I'd stop by and talk to you first | 06:13 |
| GeofftheMedio | probably a good idea | 06:13 |
| dunno | so uh, yeah...expertise-wise...uh, C/C++, Perl, some ASM | 06:13 |
| dunno | thereabouts | 06:13 |
| dunno | but I don't think you guys use Perl | 06:13 |
| dunno | so nm that | 06:14 |
| GeofftheMedio | C++ and Python | 06:14 |
| dunno | basically, I'm pretty open to do anything...probably more so engine work, though | 06:14 |
| dunno | since well, that's kinda what I do at work lol | 06:14 |
| GeofftheMedio | if you know ogre3d, you could probably pick up some of the combat system work that tzlane's been neglecting | 06:15 |
| dunno | hrm...don't know ogre3d, but shouldn't be too bad | 06:16 |
| dunno | at the end of the day, they're all pretty similar | 06:16 |
| GeofftheMedio | you might also look at this page: http://freeorion.org/index.php/Programming_Work | 06:16 |
| tpb | Title: Programming Work - FreeOrionWiki (at freeorion.org) | 06:16 |
| dunno | yup, took a look earlier | 06:17 |
| dunno | but I wasn't sure what needed to be worked on first | 06:17 |
| dunno | anyway, I'll look into the code, and thanks for the pointer =) | 06:18 |
| GeofftheMedio | there's not really anything that needs to be done first... | 06:18 |
| GeofftheMedio | I'd rather you find something you're interested in and will be motivated to work on, at least at first | 06:19 |
| dunno | how many contributors are there? | 06:19 |
| dunno | or how many active ones? | 06:19 |
| dunno | k | 06:19 |
| GeofftheMedio | depends on definition of active... | 06:19 |
| dunno | well, I don't think it'd be constructive for me to find something I'm interested in...I'd end up writing GPGPU work or some inner loop optimization =( | 06:19 |
| dunno | I saw that code-wise, you've been the only one active for the past 2 months =P | 06:20 |
| GeofftheMedio | some of my commits were on behalf of others | 06:20 |
| GeofftheMedio | but I've done most of the code commits recently, yes | 06:20 |
| dunno | ah | 06:20 |
| dunno | I hope I don't get confused by the templates o_O | 06:25 |
| GeofftheMedio | it's not the templates that are the problem really... it's the error messages they can produce | 06:26 |
| dunno | I just find templates to be a problem in general | 06:27 |
| dunno | we're banned from using templates at work - gets in the way of build times and runtime performance...so I don't have too much experience with it | 06:27 |
| GeofftheMedio | build times, sure, but runtime performance? how do you figure? | 06:28 |
| dunno | a lot of the code in our games are low-level optimized | 06:28 |
| dunno | using templates tend to mess up memory alignment and what now | 06:29 |
| dunno | not* | 06:29 |
| dunno | and it usually ends up being a crutch for a lot of people...and people start wandering into STL territory, which just becomes a crapfest | 06:29 |
| GeofftheMedio | sounds like you just don't like C++ and would rather work in C and ASM ? | 06:30 |
| GeofftheMedio | or at least your company | 06:30 |
| dunno | well, just engine | 06:30 |
| dunno | gameplay do their own thing | 06:30 |
| dunno | I think most people in the engine group just use C++ for the friendlier syntax | 06:31 |
| dunno | like, no need to typedef structs lol | 06:31 |
| dunno | inheritance is somewhat of a no-no for the most part...mostly because of the tendency to use virtual functions | 06:31 |
| dunno | which is an extra lookup and potential cache miss | 06:32 |
| dunno | and a pipeline stall | 06:32 |
| GeofftheMedio | what are you writing...? The next cryengine? | 06:32 |
| dunno | haha, it's been this way since the PS2 days (I wasn't there) | 06:33 |
| dunno | supposedly at the end of the PS2 life cycle, the entire engine was in ASM | 06:34 |
| GeofftheMedio | I'm skeptical that avoding all of modern c++ features is really that necessary... | 06:34 |
| GeofftheMedio | sure, optimize your inner loops, but avoiding the STL entirely? | 06:34 |
| dunno | STL can kinda work | 06:34 |
| GeofftheMedio | most implementations are pretty well written, I hear... | 06:34 |
| dunno | like the EASTL | 06:34 |
| dunno | well, they're well written for the general case | 06:35 |
| dunno | but that's kinda the problem...when something is done for the general case, it's slow across the board | 06:35 |
| GeofftheMedio | have you checked that with profiling recently? | 06:36 |
| dunno | I mean, I'm personally not that picky...but maybe because I'm not as "advanced" as most of them | 06:36 |
| dunno | I think most people just stopped profiling...they kinda know it by heart already o_O | 06:36 |
| dunno | I think the canonical example for bad STL is using vector naively | 06:37 |
| dunno | every time that thing has to expand, that's thousands of cycles lost | 06:37 |
| GeofftheMedio | so, just reserve whatever space you'll need beforehand? | 06:37 |
| dunno | new? delete? yeah, they get called...once during initialization, and once during shutdown =P | 06:37 |
| dunno | right, exactly | 06:37 |
| dunno | but then what's the point of using the vector? | 06:38 |
| dunno | why not just use an array? | 06:38 |
| GeofftheMedio | a vector can do a lot more than just automatically resizing itself | 06:38 |
| dunno | right, push, pop, etc etc | 06:39 |
| dunno | but the preallocation is exactly what EASTL try to solve | 06:39 |
| GeofftheMedio | what do you need a custom implementation for? there's a reserve() function in the standard | 06:39 |
| dunno | custom implementation? | 06:42 |
| dunno | oh, EASTL | 06:42 |
| GeofftheMedio | I suppose they probably have their reasons. or had them, and then stick with what they're using since that's what everyone else in EA uses... | 06:42 |
| dunno | well, EASTL is just what I heard | 06:43 |
| dunno | that's basically the attempt at getting it to work in consoles | 06:43 |
| GeofftheMedio | hmm. that would make more sense than the optmizations thing. | 06:44 |
| dunno | I guess, for example, if I were to do vector.at(5) or vector[5] (doesn't matter which), what does it compile to? | 06:45 |
| dunno | does it compile to some inline function? | 06:45 |
| GeofftheMedio | well, vector::at and vector::operator[] aren't the same thing, since one can throw an exception if out of range | 06:46 |
| dunno | ah, k | 06:46 |
| dunno | then the more optimized one | 06:46 |
| dunno | which I'm guessing is the [] | 06:46 |
| GeofftheMedio | I imagine [] would be inlined most of the time | 06:46 |
| dunno | so, [] sets up the stack, do the address computation, fetch, stuffs the result in the register, and return from stack | 06:47 |
| GeofftheMedio | not if it's inlined... | 06:47 |
| dunno | I think inline still involves a couple of instruction overhead? | 06:48 |
| dunno | and also, there's the extra indirect from the vector itself to access the array pointer | 06:49 |
| dunno | unless that's stored at offset 0 | 06:49 |
| dunno | actually, probably not | 06:49 |
| dunno | offset 0 is probably the size | 06:49 |
| GeofftheMedio | from the MS STL: vector::operator[]: return (*(_Myfirst + _Pos)); | 06:50 |
| GeofftheMedio | +Myfirst is a pointer to the array | 06:50 |
| GeofftheMedio | if inlined, it'd just be a single pointer arithmatic, which you'd also need for an array, and then a dereference | 06:50 |
| dunno | right, so that'd be this+offset | 06:50 |
| dunno | this+_Myfirst_offset+_Pos | 06:51 |
| dunno | as opposed to array_addr+_Pos | 06:51 |
| dunno | (obviously, _Pos decomposes into size * n...but that's equal in both cases) | 06:51 |
| dunno | but I mean, you're right, it's not too much overhead | 06:52 |
| dunno | but then I see code like: | 06:52 |
| dunno | v.push_back(N); // append int N to the end of the array | 06:54 |
| dunno | and this is just filling in the vector for a basic Sieve algorithm | 06:54 |
| dunno | Sieve of Erototholes (however it's spelled) | 06:54 |
| dunno | that's lots of =((( | 06:55 |
| dunno | I mean, I definitely sound picky | 06:55 |
| dunno | but I'm really just trying to see all sides of the story...and at work, it's pretty one-sided :O | 06:55 |
| GeofftheMedio | sure, that could be a bottleneck. | 06:56 |
| GeofftheMedio | if you've ever used matlab, and you do something like | 06:56 |
| GeofftheMedio | for n = 1:10 | 06:56 |
| GeofftheMedio | x(n) = n; | 06:56 |
| GeofftheMedio | end | 06:56 |
| GeofftheMedio | then it will actually pop up and say, hey! you're making the array bigger each time, and it migh be faster to preallocate | 06:56 |
| dunno | hahaha | 06:57 |
| dunno | oh man, matlab...so long ago :X | 06:57 |
| GeofftheMedio | same thing applies to C++, and you can use reserve to avoid the occasional reallocation that would result | 06:57 |
| dunno | it says from your profile that you're a grad student? | 06:57 |
| GeofftheMedio | yes | 06:57 |
| dunno | from where, may I ask? | 06:57 |
| dunno | and what field? | 06:57 |
| GeofftheMedio | also, if you were filling a seive, you'd probably know how big the array was to start, and wouldn't push_back the numbers, but would instead iterate through it with a vector::iterator or using an index and operator[] | 06:58 |
| GeofftheMedio | UBC, medical physics | 06:58 |
| dunno | right, I know...but I think the point that everyone makes is that it's so blackboxed that it's too simple to make the mistake | 06:59 |
| dunno | ooh, medical physics | 06:59 |
| GeofftheMedio | calculating primes being a somewhat optimization-centric activity, you'd actually worry about that sort of thing, but if it was something simpler and less time-critical, you'd worry | 06:59 |
| GeofftheMedio | and really, why worry at all unless the profiler says it's a bottleneck? | 06:59 |
| GeofftheMedio | er, you'd not worry | 06:59 |
| dunno | well, I mean, if a piece of code is equally crappy, then I'd say the profiler would end up saying everything's the same...which some people would think "oh, that's just how long it takes to run this" | 07:00 |
| dunno | but maybe that's slightly contrived | 07:00 |
| dunno | so what does medical physics do? I mean, I can understand biochem...but I'm not sure how physics factor into medicine? | 07:01 |
| dunno | (just not familiar with the discipline) | 07:01 |
| dunno | sorry, ignore that question...I'm just going to do the google | 07:03 |
| GeofftheMedio | the profiler would tell you what functions you're spending the most time in during execution. those are the ones you worry about optimizing. if you run an initization routine that takes 300 ms, and could optimize it to 100, and then run 100000 iteratorion of something that takes 2 ms but could be optimized to 1 ms, which is more important? the 1 ms gain, or the 200 ms gain? | 07:03 |
| GeofftheMedio | medical physics deals with medical imaging (MRI, CT, ultrasound, PET, SPECT, etc.) and radiation therapy of various types | 07:04 |
| dunno | the 100000ms gain =P | 07:04 |
| GeofftheMedio | exactly... which the profiler would tell you, since your code is spending so much more time in that code than the initialzation code | 07:05 |
| GeofftheMedio | but spending any time at all on the initization optimization isn't worth the effort until you reduce the real time sink first | 07:05 |
| dunno | I definitely agree | 07:06 |
| dunno | but I think most of my coworkers operate at the level that everything is already optimized | 07:06 |
| dunno | at least, algorithmicly | 07:07 |
| GeofftheMedio | then they're probably writing hard-to read code | 07:07 |
| GeofftheMedio | and if they're not profiling, they may be surprising about what actually takes up the most time | 07:07 |
| GeofftheMedio | but if they're as hard core as you're making them sound, they probably are profiling as well | 07:07 |
| GeofftheMedio | and just avoid unnecessary cycle wasting out of habit | 07:07 |
| dunno | I think in general, most things have been taken into consideration | 07:09 |
| dunno | cache lines/alignment, L1/L2, prefetching, odd/even pipeline rebalancing, stalls/bubbles, load-hit-store, etc... | 07:10 |
| dunno | I think most things (other than odd/even pipeline rebalancing/instruction scheduling and ASM programming) can be determined from C/C++ end | 07:10 |
| dunno | so the general practice is to avoid or hide the latency | 07:11 |
| GeofftheMedio | depends on your compiler, I suppose. maybe it's all very controllable on consoles... | 07:11 |
| dunno | so it mostly boils down to compilers | 07:11 |
| dunno | it's controllable in some ways | 07:12 |
| dunno | but in other ways, it sucks | 07:12 |
| dunno | like the GCC compiler on consoles suck total nads | 07:12 |
| dunno | well, GCC kinda sucks in general | 07:12 |
| dunno | but sometimes, it's the only thing available | 07:12 |
| GeofftheMedio | hmm | 07:14 |
| dunno | so I mean, when things are fairly optimized, then what gets inspected next are what the fundamental types are doing | 07:14 |
| dunno | so if a vector is taking one more instruction, then it'll probably get gutted | 07:14 |
| dunno | furthermore, how does a vector allocate its memory? | 07:15 |
| dunno | does it do "new" internally? | 07:15 |
| dunno | ah, you can pass it an allocator | 07:16 |
| *** mithro has joined #freeorion | 07:16 | |
| GeofftheMedio | probably depends what it's storing... | 07:16 |
| GeofftheMedio | if it's POD or a complicated object with its own constructor defined | 07:16 |
| dunno | well, I don't think that'd be the fault of the vector then | 07:17 |
| dunno | unless the vector invokes the new on the object stored in its internal array | 07:17 |
| dunno | if anything does "new/malloc" or "delete/free" behind our backs, it's something that gets gutted right away | 07:18 |
| GeofftheMedio | generally we don't store a lot of complicated objects in vectors... it's more likely there'd be an array of pointers, or map of pointers | 07:18 |
| dunno | oh no, I'm not criticizing FO | 07:19 |
| dunno | I'm just speaking academically | 07:19 |
| dunno | I'll just work with whatever FO has | 07:19 |
| GeofftheMedio | I didn't meant o imply you were | 07:19 |
| dunno | haha | 07:19 |
| dunno | I just really really liked MOO2 | 07:19 |
| dunno | and THERE WAS NO MOO3 | 07:20 |
| dunno | IT NEVER EXISTED | 07:20 |
| GeofftheMedio | so I haven't heard | 07:20 |
| dunno | haha | 07:20 |
| dunno | you probably get that a lot | 07:20 |
| dunno | for me, I just want to play the game | 07:20 |
| dunno | which is why I'm trying to see what I can do to help out | 07:21 |
| GeofftheMedio | mmhmm. | 07:24 |
| GeofftheMedio | well, if you don't know ogre well, jumping into the graphical combat system probably isn't practical right away | 07:24 |
| dunno | that's fine | 07:27 |
| dunno | just think of me as a body | 07:27 |
| dunno | whereever works | 07:27 |
| dunno | not like I'm godly or anything | 07:27 |
| GeofftheMedio | There are a lot of UI tasks listed, some of which might be approachable to start with | 07:28 |
| GeofftheMedio | if you could write something to replace the graphviz stuff that's used to do the tech tree layout, that would be nice | 07:29 |
| GeofftheMedio | but you could also just make the tech tree look nicer, with tech panels that resemble fleet data panels in the fleets window | 07:29 |
| dunno | I'll look in that general area then =) | 07:43 |
| dunno | are there shortcuts to load directly into certain parts of the game? | 08:02 |
| dunno | such as combat or what not | 08:02 |
| dunno | wow, I think I just experienced first hand how long it takes to compile template-heavy code.... | 08:05 |
| GeofftheMedio | typically takes about 30 minutes for me for FreeOrion itself, though I've got a laptop running at 1.8 MHz | 08:06 |
| GeofftheMedio | the initial stages of the 3D combat view can be started by running freeorion --tech-demo | 08:06 |
| GeofftheMedio | otherwise you can run freeorion -q to quickstart immediately using the settings from your last game, or default settings | 08:06 |
| dunno | nice | 08:07 |
| GeofftheMedio | from there, you can get to any "part" of the game by clicking one of the buttons to open a screen like research or design... | 08:07 |
| GeofftheMedio | there are no scenarios or provided test save games, though | 08:07 |
| dunno | that's fine | 08:09 |
| dunno | so uh, is: | 08:10 |
| dunno | void RenderTechPanel(TechType tech_type, const GG::Rect& main_panel, const GG::Rect& progress_panel, | 08:10 |
| dunno | GG::Clr interior_color, GG::Clr border_color, bool show_progress, double progress) | 08:10 |
| dunno | that what you're referring to as the graphvis stuff? | 08:10 |
| GeofftheMedio | no... that just renders a tech panel | 08:13 |
| dunno | right, just looked further | 08:14 |
| GeofftheMedio | TechTreeWnd::LayoutPanel::Layout has all the graphviz calls | 08:14 |
| GeofftheMedio | it's kind of a mess... | 08:17 |
| GeofftheMedio | but it's not that imporant since the suggestion is to replace it all with your own tech layout code | 08:17 |
| dunno | huh...then I'll need to read what the criteria are for the tech tree | 08:18 |
| GeofftheMedio | there's not much... | 08:19 |
| GeofftheMedio | just position all the techs, and figure out how to draw the dependency arcs between them | 08:19 |
| GeofftheMedio | by which I mean decide where all the nodes in the curves are | 08:20 |
| dunno | right | 08:20 |
| dunno | but then there must be some sort of ordering for the techs | 08:20 |
| dunno | e.g. level 1 tech, level 2 tech | 08:20 |
| GeofftheMedio | techs have prerequisites | 08:20 |
| dunno | and those would logically be aligned | 08:20 |
| GeofftheMedio | that's it | 08:20 |
| dunno | ah ok | 08:20 |
| dunno | but techs have cost | 08:20 |
| GeofftheMedio | it might be nice to be able to specify a rank for techs | 08:20 |
| dunno | or some other attribute | 08:20 |
| dunno | right, exactly | 08:21 |
| GeofftheMedio | cost doesn't necessary equate to rank | 08:21 |
| dunno | of course | 08:21 |
| dunno | but there should be some sort of ordering | 08:21 |
| GeofftheMedio | and if you let the tech definitons specify a rank, you'll end up having to deal with inconsistent ranks and dependencies | 08:21 |
| GeofftheMedio | like a leve 3 tech depending on a level 5 tech | 08:21 |
| dunno | right | 08:21 |
| dunno | so ranks shouldn't be defined as such | 08:22 |
| dunno | and should be defined as, say, the number of prerequisites | 08:22 |
| dunno | (+1) | 08:22 |
| dunno | or this could all be sortable | 08:22 |
| dunno | by cost, by "rank", etc etc | 08:22 |
| GeofftheMedio | also, "cost" is tricky, since there are both minimum time to research, and maximum research applied to the tech per turn | 08:22 |
| GeofftheMedio | the product of which is the total cost | 08:22 |
| dunno | then we can just break that down | 08:23 |
| dunno | and the sorting isn't sorted by the total | 08:23 |
| GeofftheMedio | there is also a tech list, which needs to be made into a separate window, and made sortable, etc. | 08:23 |
| GeofftheMedio | but that's a separate issue... | 08:23 |
| dunno | sorting is, afterall, a one dimensional thing...there's no reasonable way to collapse a truly two dimensional problem down | 08:23 |
| dunno | hehe | 08:23 |
| GeofftheMedio | for the tech tree, you could position techs horizontally by total cost, although doing that naively would leave some big gaps that would look bad | 08:24 |
| dunno | I think it's best to just let the user select | 08:24 |
| GeofftheMedio | I suppose you could do a histogram normalization to decide how to spread the techs out... | 08:24 |
| dunno | since this is an information visualization problem | 08:24 |
| GeofftheMedio | user meaning player, or content designer? | 08:24 |
| dunno | player | 08:24 |
| GeofftheMedio | for the list of techs, sure, the player should be able to sort however they want | 08:25 |
| dunno | right | 08:25 |
| GeofftheMedio | but for the tree, it needs to respect the tech dependencies | 08:25 |
| dunno | right | 08:25 |
| dunno | I'm thinking along the lines of civ tech | 08:25 |
| dunno | civ's tech tree, that is | 08:26 |
| dunno | and that the display of the tree should be based on the < operator | 08:27 |
| dunno | in a left-right tree view | 08:27 |
| dunno | A is on the left if A < B | 08:28 |
| GeofftheMedio | have looked at the current freeorion tech tree? | 08:28 |
| dunno | haha | 08:28 |
| dunno | I was caught | 08:28 |
| dunno | I was going to say that "maybe I should look at this before I say anything else", but I got carried away | 08:28 |
| GeofftheMedio | mmhmm | 08:28 |
| CIA-72 | FreeOrion: geoffthemedio * r3324 /trunk/FreeOrion/server/ (ServerApp.cpp ServerApp.h): | 08:30 |
| CIA-72 | FreeOrion: -Moved server combat processing into a separate ProcessCombats function from ProcessTurns | 08:30 |
| CIA-72 | FreeOrion: -Grooming in ServerApp.h | 08:30 |
| *** mithro has quit IRC | 08:57 | |
| *** mithro has joined #freeorion | 08:58 | |
| *** mithro has quit IRC | 10:33 | |
| *** enigmatic has joined #freeorion | 12:01 | |
| *** enigmatic has quit IRC | 12:51 | |
| *** enigmatic has joined #freeorion | 12:54 | |
| *** Phazorx has joined #freeorion | 14:22 | |
| Phazorx | . | 14:24 |
| *** enigmatic has quit IRC | 15:43 | |
| *** enigmatic has joined #freeorion | 15:43 | |
| *** _Magic has joined #freeorion | 16:21 | |
| *** _Magic has quit IRC | 16:45 | |
| *** dunno has quit IRC | 16:46 | |
| GeofftheMedio | Phazorx: ~ | 17:18 |
| *** dunno has joined #freeorion | 17:52 | |
| dunno | . | 18:56 |
| GeofftheMedio | ~ | 19:00 |
| *** bernardh has joined #freeorion | 19:43 | |
| *** mithro has joined #freeorion | 20:44 | |
| *** bernardh_ has joined #freeorion | 20:48 | |
| *** bernardh has quit IRC | 20:50 | |
| *** bernardh_ is now known as bernardh | 21:36 | |
| dunno | OH GOD | 22:20 |
| dunno | why is it so slow?! | 22:20 |
| GeofftheMedio | ? | 22:20 |
| GeofftheMedio | what is it? | 22:20 |
| dunno | hrm | 22:20 |
| dunno | weird | 22:20 |
| dunno | I tabbed out, and it's fine now, whee | 22:21 |
| GeofftheMedio | ... not helping clarification... | 22:21 |
| dunno | oh | 22:21 |
| dunno | looking at tech tree | 22:21 |
| GeofftheMedio | oh | 22:21 |
| dunno | just got it working | 22:21 |
| GeofftheMedio | yeah, it's pretty unoptimized | 22:21 |
| GeofftheMedio | not sure why exactly | 22:21 |
| dunno | you mean, other than all the immediate mode calls, and calculating all the curves on the fly? | 22:22 |
| GeofftheMedio | I think the layout gets redone for each zoom level | 22:22 |
| dunno | yup | 22:22 |
| dunno | that certain seems like it | 22:22 |
| GeofftheMedio | I haven't looked into the curve rendering, but those should probably not need to be redone each frame | 22:23 |
| GeofftheMedio | probably offscreen techs shouldn't be rendered | 22:24 |
| GeofftheMedio | when zoomed out, simplified panels should be swapped in as details won't be visible anyway | 22:24 |
| GeofftheMedio | optimized rendering would be nice, though immediate calls would be nice to retain as a backup in case people don't have sufficient opengl support | 22:25 |
| dunno | uh...isn't the base OGL2.0? | 22:25 |
| GeofftheMedio | yeah, but a lot of people don't actually have support for it | 22:26 |
| GeofftheMedio | with most of the rendering options turned off, FO will run under gl 1.5 | 22:26 |
| dunno | I don't see much point in supporting 1.5 | 22:26 |
| dunno | but whatever =P | 22:27 |
| GeofftheMedio | ideally we wouldn't need to, but lots of video cards still don't support 2.0... particularly on netbooks, it seems | 22:27 |
| dunno | *sigh* | 22:28 |
| dunno | I really want to rant | 22:28 |
| dunno | but I don't think it's appropriate | 22:28 |
| GeofftheMedio | I'm not easily offended... but whatever | 22:29 |
| *** mithro has quit IRC | 22:39 | |
| *** welterde has joined #freeorion | 23:05 | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!