| 00:03.27 | Noshei | oh yay, pts update |
| 00:03.43 | Noshei | hopefully I can log in to my character in margle |
| 00:06.43 | Noshei | yay, no crash |
| 01:21.24 | ZorbaBeta | noshei, I'd love 64 bit, but it's gonna be a pretty big effort to support it. No promises. |
| 01:21.29 | ZorbaBeta | also yay no crash |
| 01:21.57 | ZorbaBeta | that said I'm starting to run out of performance boosts without heroic measures, so who knows what'll happen next |
| 01:22.40 | Noshei | ZorbaBeta: daglar and simon mentioned you were looking into the possibility of 64 bit on the stream today |
| 01:22.59 | ZorbaBeta | well, okay, if they're saying it then: yes, we're looking into it :V but it's gonna be tricky |
| 01:23.23 | Noshei | no surprised |
| 01:23.36 | Noshei | s/surprised/surprise/ |
| 01:23.37 | Ivnedar_ | s/32/64/g |
| 01:23.37 | Imhothar2 | <PROTECTED> |
| 01:23.38 | Ivnedar_ | done! |
| 01:24.19 | Imhothar2 | in my experience that's the only obstacle for 64 bit porting |
| 01:25.08 | ZorbaBeta | imhothar, well, there's two big obstacles |
| 01:25.09 | Imhothar2 | there are also architectural changes to take full advantage of 64 |
| 01:25.18 | ZorbaBeta | the first is that rift currently builds in msvc2008. msvc2008 does not support 64-bit. |
| 01:25.43 | Imhothar2 | that is really old⦠|
| 01:25.45 | ZorbaBeta | the second is that we rely on the free version of havok. there is no free 64-bit havok library. |
| 01:25.54 | ZorbaBeta | it is, though in fairness, we've never had a pressing need to update |
| 01:26.20 | Imhothar2 | hmm does MS's license allow using the express version for Rift? :p |
| 01:27.19 | ZorbaBeta | I think so, though we actually have licenses for newer compilers |
| 01:27.29 | ZorbaBeta | but porting a project of this size up to a newer compiler is not a simple project >_< |
| 01:27.41 | Imhothar2 | seriously though, just having a C++11 compiler can make stuff go faster with move semantics without changing code |
| 01:27.59 | ZorbaBeta | true, and I'm looking forward to taking advantage of that |
| 01:28.13 | Imhothar2 | and the committee is always very careful not to break existing code |
| 01:29.35 | Imhothar2 | but I think the true advantages to go 64 bit is the lower register pressure, faster syscalls and 64bits of virtual address space |
| 01:29.38 | ZorbaBeta | sadly that doesn't always work as well as you might hope |
| 01:29.49 | ZorbaBeta | I'm fully expecting at least a few glitches converting over to msvc2013 |
| 01:29.56 | Imhothar2 | more RAM is a bonus, but not *that* big a deal usually. but the virtual address space increase is a game changer |
| 01:31.13 | Imhothar2 | what some games now do is mmap their entire asset archives and only use memory access for everything, bypassing the slow file operations |
| 01:31.38 | ZorbaBeta | that doesn't really bypass anything, though, it just means you halt on memory access |
| 01:31.55 | ZorbaBeta | we already have a really good file loading system (it's actually better than UE4's) and so that, at least, is a non-issue for us |
| 01:32.03 | Imhothar2 | it does bypass small buffer reads |
| 01:32.25 | ZorbaBeta | when we read data we read it all asynchronously anyway |
| 01:32.31 | ZorbaBeta | one asset at a time :V |
| 01:32.56 | Imhothar2 | of course |
| 01:33.43 | Imhothar2 | but traditionally you first allocate memory and then fill it in with file reads. mmapping everything means you don't need to allocate anything. the memory you are using is backed by swap files (your asset archives) and can be swapped in and out on demand |
| 01:34.00 | ZorbaBeta | yeah, there's definitely advantages to that |
| 01:34.25 | ZorbaBeta | I kind of want to make that shift at some point, but I'll need to figure out if there's some good way to notify the OS to get a bunch of mmap'ed data into active memory |
| 01:34.32 | ZorbaBeta | that said, certainly not happening before 64 bit |
| 01:34.34 | Imhothar2 | and if you're smart you design your asset files around that to consider page sizes etc |
| 01:34.59 | Imhothar2 | you can, just do a memory access |
| 01:35.25 | Imhothar2 | that'll force loading the page the address is in |
| 01:35.38 | ZorbaBeta | that's the problem, I need something which says "hey, we'll need this later, tell me when we have it" |
| 01:35.49 | ZorbaBeta | doing a memory access says "I need this now, I'm going to wait until I have it" |
| 01:36.06 | Imhothar2 | do it on the asset loading thread ;) |
| 01:37.22 | ZorbaBeta | more complexity. :) |
| 01:38.02 | Imhothar2 | you probably don't want to get rid of async loading anyway. you still need to for external files (which should of course be mapped, too) |
| 01:39.28 | Imhothar2 | the beauty is that you can't run out of physical memory because all the allocated memory can be swapped out |
| 01:39.44 | Imhothar2 | so you can keep the asset "open" indefinitel |
| 01:41.36 | Imhothar2 | it's something I'm looking into on 64bit mobile phones |
| 01:41.55 | Imhothar2 | they have SSDs and low memory, so mmapping is the perfect solution there |
| 01:44.47 | Imhothar2 | it then becomes an interesting approach to have code-structures reflected in the file, i.e. mmap the content, set a pointer to the start address and treat it as an actual object |
| 01:47.39 | Imhothar2 | by the way http://msdn.microsoft.com/en-us/library/windows/desktop/Hh780543%28v=vs.85%29.aspx |
| 01:48.39 | Imhothar2 | this should do what you want ZorbaBeta |
| 01:49.20 | Imhothar2 | oh windows 8 only |
| 01:49.21 | Imhothar2 | meh |
| 01:49.29 | ZorbaBeta | yeah if it's windows 8 it's not what I want to do :V |
| 01:49.43 | ZorbaBeta | in all honesty we don't load enough data off disk for IO API throughput to be a real issue |
| 01:49.51 | ZorbaBeta | we spend a whole lot more CPU time processing that data |
| 01:50.03 | ZorbaBeta | and it's stored compressed anyway, so we have to copy it anyway |
| 01:50.42 | ZorbaBeta | I suspect the OS cache is efficient on roughly the same level as memory mapping is, for our needs, at least |
| 01:51.59 | Imhothar2 | hmm if you're doing async reading, then doing an overlapped read should trigger loading too |
| 01:52.52 | Imhothar2 | but yeah uncompressing is a thing |
| 01:58.03 | ZorbaBeta | yeah |
| 01:58.44 | ZorbaBeta | and, again, it's unclear if this is a speed hit; before 3.0, we spent about 20% of the loading time adding physics data to the physics engine, and 60% adding model data to the culling engine |
| 01:58.56 | ZorbaBeta | even if we could make loading take literally zero CPU it would not be an appreciable optimization |
| 01:59.46 | Noshei | gah, I wish I had a better understanding of the things you guys are talking about. |
| 02:00.15 | ZorbaBeta | (note: fixed the CPU use adding to the culling engine, turning around should perform better now) |
| 02:04.09 | Noshei | I do wish I had a more thorough knowledge of kernel level stuff, though professionally it would be useless |
| 02:04.14 | ZorbaBeta | noshei, a lot of it is just experience. you pick this stuff up eventually. after beating your head against a seemingly endless number of walls |
| 02:04.34 | Noshei | ZorbaBeta: I know exactly what you mean |
| 02:04.35 | Imhothar2 | and desks |
| 02:05.12 | Noshei | going on 7 years now as a server admin, plenty of wall (and desk) banging from me |
| 02:05.31 | ZorbaBeta | we actually just had a problem today where, as far as I can tell, our server is running out of entropy :V |
| 02:05.42 | Noshei | I just dont really have any reason to dig into the programming side of stuff |
| 02:06.57 | Noshei | running out of entropy? so becoming less random? |
| 02:07.08 | Ivnedar_ | connect /dev/random to the rift forums, problem solved |
| 02:07.34 | Imhothar2 | stuff a few chaos balls in the server room |
| 02:08.38 | ZorbaBeta | blocking on /dev/random, apache stops responding, is bad. |
| 02:08.46 | ZorbaBeta | that's at my nonprofit though |
| 02:08.48 | ZorbaBeta | not rift-related :V |
| 02:11.51 | Noshei | yeah you guys are at a whole different level in IT than me. I'm the guy that gives you servers to run your programs on. |
| 02:13.26 | Noshei | though I'm perfectly profecient as a windows admin, I prefer the more hardware side of things, kinda. |
| 02:13.57 | Noshei | I personnaly look at vmware as a type of hardware. |
| 02:20.15 | Ivnedar_ | <PROTECTED> |
| 02:58.36 | Noshei | so it seems that GGG either didn't think about, or didn't know, how Hideout would end up being shortened |
| 02:59.19 | Noshei | can't tell you how many times I have seen "come in my ho" since hideouts were released |
| 04:08.59 | *** join/#riftuidev Imhothar (~Adium@ppp-93-104-168-171.dynamic.mnet-online.de) |
| 04:09.21 | *** join/#riftuidev Imhothar__ (~Imhothar@ppp-93-104-168-171.dynamic.mnet-online.de) |
| 04:38.44 | Ivnedar_ | huh, is the super jump out of water normal? |
| 04:39.17 | Ivnedar_ | ahh, side effect of the underwater aura |
| 04:41.06 | Ivnedar_ | lol, current xp is -40781931/12926420 :D |
| 04:55.20 | Noshei | lol |
| 04:55.52 | Noshei | Ivnedar_: thanks for pointing out the buff, I was wondering what the super jump was from |
| 04:56.38 | Ivnedar_ | It's going to be a long long time before I hit 61 :( |
| 04:57.03 | Noshei | im not leveling at all on the pts |
| 04:57.26 | Noshei | just wanted to find my way to margle, so I know how to get there right away |
| 04:57.34 | Noshei | and check out minions |
| 04:57.40 | Ivnedar_ | I'm updating carnage book for new carnages |
| 04:58.02 | Noshei | ah |
| 04:58.31 | Noshei | ./wrist |
| 04:59.13 | Ivnedar_ | heh, one of the first quests only has plane of water attuned gear as a reward |
| 04:59.39 | Ivnedar_ | I can see that causing some aggravation |
| 06:15.39 | Ivnedar_ | poor Deeps :) |
| 12:16.00 | Ivnedar_ | well, 51 carnages found so far in first zone, plus 4 lvl 65 elite ones around Gyel Fortress that I won't be able to get details on for a while. Zone achievement is 52 quests, so that's pretty close :D |
| 12:16.35 | Ivnedar_ | I've made it up to -23197247 out of 12926420 xp til lvl 61, so it's going to be a long grind if I want to try later zones :( |
| 12:16.44 | Ivnedar_ | really hope that doesn't happen on live |
| 16:52.39 | *** join/#riftuidev purl (ibot@rikers.org) |
| 16:52.39 | *** topic/#riftuidev is http://pastebin.com for code snippets || PIL: http://www.lua.org/pil || Rift AddOn Policy: http://t.co/7xXd4LL || AddOn Wiki: wiki.riftui.com/ || this channel is logged, via purl || Happy Pi day! |
| 17:26.39 | *** join/#riftuidev Imhothar (~Imhothar@ppp-93-104-168-171.dynamic.mnet-online.de) |
| 17:32.17 | Imhothar | it's hilarious how many people post their C++ homework to the std discussion forum |
| 18:12.40 | seebs | FedEx doesn't think they've yet delivered the desk top (they have), and thinks the rest of it will be here by 12:00 AM today. |
| 18:13.09 | seebs | Note that it hasn't been scanned once since it was in California on the 1st. |
| 18:13.37 | Imhothar | someone there really hates his job |
| 18:13.40 | seebs | Oh, haha. Apparently this is an AJAX thing. |
| 18:13.55 | seebs | They have a page with fancy status tracking things... which don't update unless you manually reload. Also they claim to have delivered it. |
| 18:21.23 | Imhothar | then the web dev hates his job |
| 18:30.27 | Imhothar | point is, somewhere somebody hates his job |
| 18:31.20 | Imhothar | and an incredibly complex chain of reactions causes this confusion |
| 18:58.45 | seebs | Oh, hey, desk parts here. FWIW, the desk top does not have pre-drilled holes. |
| 18:59.05 | Imhothar | it all makes sense now |
| 20:03.13 | *** join/#riftuidev Thorarin (marcel@D57DD135.static.ziggozakelijk.nl) |
| 20:23.28 | *** join/#riftuidev jeffreyhamby (~quassel@72.47.173.141) |
| 20:32.03 | *** join/#riftuidev Noshei (~quassel@c-24-9-171-99.hsd1.co.comcast.net) |