| 00:45.18 | Solsis | I have a curious question. Anyone available? |
| 00:54.58 | Noshei | maybe |
| 00:55.07 | Noshei | depends on the question |
| 01:00.18 | Noshei | so Solsis, what id the question? |
| 01:05.13 | Solsis | sorry was getting some food |
| 01:06.51 | Solsis | after doing a variable = unit.detail(sometable) for i, v in pairs(variable) do, Does using the values from v.XXX get expensive? or are they pretty small at that point. |
| 01:08.03 | Solsis | I was thinking they would be pretty miniscule since the variablees in a for loop are local correct? |
| 01:08.46 | Solsis | or variables of a for loop* (however you want to word it... THE i & v)! |
| 01:11.03 | *** join/#riftuidev Solsis_mobile (~androirc@108-226-48-242.lightspeed.fyvlar.sbcglobal.net) |
| 01:16.06 | seebs | Yeah, those are locals, and table lookups themselves are pretty fast. |
| 01:16.27 | Noshei | yeah I believe the variables are local to the loop only, and unless your storing a ton of data in them it shouldn't be bad at all |
| 01:17.35 | Solsis | ok.. wow.. that means I've been doing a lot of extra stupid work |
| 01:17.37 | Solsis | <PROTECTED> |
| 01:19.00 | Noshei | just try to avoid usint inspect.unit.detail in 2 many locations |
| 01:19.10 | Solsis | are absolutely |
| 01:19.21 | Solsis | oh* |
| 01:19.26 | Solsis | lol |
| 01:20.38 | Solsis | You should still try to avoid them as much as possible... but doing this helps reduce the cost: |
| 01:20.40 | Solsis | local _G = getfenv(0) |
| 01:20.40 | Solsis | local unitDetail = Inspect.Unit.Detail |
| 01:21.20 | Solsis | ie.. local details = unitDetail(cbh.QueryTable) |
| 04:06.13 | Solsis | Awful quiet in here tonight |
| 04:10.50 | Noshei | yeah |
| 04:27.44 | Torhal | Solsis: You're missing something there. You're declaring an upvalue for _G, yet never using it. |
| 04:28.31 | Torhal | Lua will perform two lookups for globals - one for the global environment, and another for the value from that environment…unless you do _G.whatever after making an upvalue for _G |
| 04:28.43 | Torhal | Then it already knows where your local _G is and simply has to do the lookup on it. |
| 04:30.01 | Torhal | So "local unitDetail = Inspect.Unit.Detail" isn't grabbing it from your upvalued _G |
| 04:32.33 | ZorbaGama | solsis, honestly, the speed gain of caching Inspect.Unit.Detail locally is pretty much irrelevant compared to the cost of calling Inspect.Unit.Detail |
| 04:41.50 | Noshei | so ZorbaGama I heard that we might soon be able to eliminate the need for the grey box to tell users they can't click somewhere because we have a frame there |
| 04:42.55 | ZorbaGama | I know it's an issue, it's difficult to fix. No promises. |
| 04:43.58 | Noshei | another thing, would it be possible to have a way to make irregularly shaped frames? |
| 04:45.13 | Noshei | what I'm thinking here is a way to do the CD display without needing 100 textures to do it |
| 04:45.32 | ZorbaGama | you'd be much more likely to see the ability to draw arbitrary polygons within a rectangular frame than actually have irregularly shaped frames |
| 04:45.56 | Noshei | that would work as well |
| 04:46.09 | ZorbaGama | that said, with the texture loading fixes, 100 textures shouldn't be all that impractical. Ugly, but not impractical. |
| 04:46.47 | Noshei | so not as costly? |
| 04:47.41 | ZorbaGama | right - you'd want to preload all the textures into hidden Texture frames first. Once you've done that, setting a frame's texture to an already-loaded texture should be quite cheap. |
| 04:48.51 | Noshei | wouldn't you need to load in all 100 textures into separate frames then? |
| 04:49.26 | arton | should work with the same one I'd think. just reuse it to load the file. |
| 04:50.14 | arton | s/file/next file/ |
| 04:50.26 | ZorbaGama | yes, you would, but frames are cheap and frames that aren't being rendered are really, really cheap |
| 04:50.38 | ZorbaGama | if you load it into a single frame then they'll be deallocated automatically when no longer used :) |
| 04:50.52 | arton | :\ |
| 04:51.10 | Noshei | yeah I can see how that will be ugly |
| 04:51.30 | ZorbaGama | it wouldn't entirely surprise me if someone whipped up a cheap LibPreload or whatever |
| 04:51.39 | ZorbaGama | I suspect it would be maaaaaybe 50 lines of code |
| 04:51.44 | Solsis | haha... I was doing some testing... NOWWWW you guys come online.. =p |
| 04:52.38 | Noshei | I think I'd rather be able to draw the polygons inside a frame |
| 04:53.15 | Noshei | though I'm guessing that isn't something easy to implement on your end |
| 04:53.21 | ZorbaGama | definitely not easy to implement |
| 04:53.30 | ZorbaGama | and probably waiting on some significant refactoring in the UI system |
| 04:53.36 | arton | Can you pivot textures yet? |
| 04:53.38 | Solsis | Ok.. So 2 things on my subject... |
| 04:53.40 | Solsis | local _G = getfenv(0) |
| 04:53.40 | Solsis | local unitDetail = Inspect.Unit.Detail |
| 04:53.55 | Solsis | Your saying it should have _G.Inspect.. blah blah balh |
| 04:53.59 | ZorbaGama | arton, most likely I'll just end up wrapping texture pivoting/distortion/arbitrary polygons into some kind of advanced rendering frame |
| 04:54.09 | arton | Ah yes. |
| 04:56.08 | Solsis | and that doing all of that putting those in locals isn't really helping me any? |
| 04:57.02 | ZorbaGama | solsis, yeah, I doubt the speed you'll get from that will be significant. But that said, all you'd really need would be "local unitDetail = Inspect.Unit.Detail" |
| 04:57.08 | arton | ZorbaGama: Is it possible currently to add Questing info on my unit tooltip addon? I mean where it'll say a unit belongs to a quest, or drops something a quest needs, how many have been killed, etcc... |
| 04:57.21 | Solsis | I had this long drawn out conversation with Imhothar about local unitDetail = _G.Inspect.Unit.Detail not needing the _G. since I had local _G = getfenv(0) |
| 04:57.39 | ZorbaGama | arton, I don't believe so, that isn't being exposed yet. Not quite sure where to put it honestly. |
| 04:57.46 | arton | k |
| 04:58.17 | Solsis | Torhal was just saying that I did need it though? |
| 04:58.48 | Noshei | Inspect.Quest.Detail().objective |
| 04:59.30 | arton | Noshei: I can match that up with my mouseover target? |
| 05:00.03 | Noshei | sec and ill find out |
| 05:01.45 | ZorbaGama | I don't think you can - I wouldn't have embedded that into Inspect.Quest, I don't want to give out lists of entity IDs |
| 05:01.55 | arton | nods. |
| 05:02.21 | arton | That's the big kicker with StarTip and why it can't replace the default tooltip for me. |
| 05:02.41 | arton | But I haven't been in-game much either. :) |
| 05:02.42 | arton | lol |
| 05:02.57 | arton | I stopped leveling at lvl 32 I think. |
| 05:03.13 | arton | just coded from then on |
| 05:03.25 | arton | My computer can't handle events. |
| 05:03.49 | arton | breaches or whatever they're called |
| 05:04.09 | arton | rift |
| 05:04.10 | arton | lol |
| 05:04.17 | arton | It's the name of the game in fact. |
| 05:05.16 | Noshei | I think it could be possible to, but it would be a huge pain in the ass |
| 05:05.27 | arton | would require a database? |
| 05:05.45 | Noshei | because you would have to figure out what needed to be done from the description |
| 05:05.52 | arton | oh |
| 05:05.52 | Noshei | most likely |
| 05:05.58 | arton | oh well :) |
| 05:06.03 | arton | thanks for looking into it |
| 05:06.26 | Noshei | np |
| 05:06.53 | Noshei | hey zorba, you mentioned the chat api earlier, is any of that up on the pts? |
| 05:07.11 | ZorbaGama | noshei, won't be in 1.9, that's 1.10 at absolute earliest and that's not a guarantee |
| 05:07.12 | arton | a database design would suck because you can't discover anything freshly new. |
| 05:07.21 | arton | you have to have that information already |
| 05:07.24 | arton | so no go |
| 05:08.03 | Noshei | bummer, was hoping to play around with it a bit |
| 05:09.17 | Torhal | Solsis: You're shadowing _G by declaring the upvalue |
| 05:09.31 | Torhal | However, by not USING the upvalue, it's defaulting to the global version. |
| 05:10.02 | Torhal | But in that upvaluing of Unit.Inspect.Detail, it's not necessary at all because it's happening exactly once. |
| 05:10.29 | Torhal | Simply making a local version of _G doesn't necessitate the requirement of explicitly using it is what I'm saying. |
| 05:10.37 | Torhal | Er, does |
| 05:10.58 | Torhal | You're shadowing The original _G, not replacing it |
| 05:11.35 | Torhal | If in doubt, fire up luac and test both methods. |
| 05:11.46 | Torhal | The bytecode execution will definitely be different. |
| 05:12.43 | Noshei | zorba are we going to be able to edit settings for the console? |
| 05:13.26 | ZorbaGama | noshei, probably, but unless someone comes up with a really awesome idea that they can't do yet, it'll probably be low priority. |
| 05:14.11 | Noshei | I'd like to have more than one combat tab, so I can easily see different types of combat events |
| 05:14.58 | ZorbaGama | you probably won't be able to override the combat tab lockouts, at least unless we implement that on our side |
| 05:15.06 | ZorbaGama | though to be honest I have no idea why we allow only one combat tab |
| 05:16.00 | Noshei | yeah it would be nice to add more |
| 05:18.33 | Noshei | would it be able to add a stat for threat modifier (from buffs and talents)? obviously we would need it on abilities as well. Though I think I remember you saying it would be a huge pain |
| 05:19.33 | Solsis | Torhal, I think I understand that having _G but not having _G.Inspect... is making those statements worthless. |
| 05:19.55 | Torhal | The speed-boost, yes. |
| 05:20.02 | ZorbaGama | there's a few problems, honestly - one of them is that design may not want to expose that data. another problem is that the data may be difficult to retrieve or difficult to calculate. |
| 05:20.12 | Torhal | Really, though, since you're upvaluing Inspect anyway... |
| 05:20.33 | Solsis | what do you mean upvaluing? |
| 05:21.00 | Torhal | I use a local _G if I don't upvalue something. Like, type() for example. If I'm using it once or twice, I don't need to make an upvalue for it, so I'll do _G.type(whatever) |
| 05:21.17 | Torhal | When you make a local reference, it's an upvalue. |
| 05:21.29 | ZorbaGama | torhal, I'm honestly not sure upvaluing _G is a speed benefit |
| 05:21.36 | Torhal | http://www.lua.org/pil/27.3.3.html |
| 05:21.55 | Torhal | ZorbaGama: Very minor one. Lua has to do a lookup to find _G, then perform the table lookup within it. |
| 05:22.18 | ZorbaGama | but it doesn't do a lookup for _G - it's a virtual stack index, just like upvalues are |
| 05:22.37 | Torhal | Solsis: http://www.lua.org/pil/27.3.3.html |
| 05:22.59 | Noshei | I dont think it would be horrible difficult to calculate, we already know a decent amount about threat as well. The only thing we don't know is how much abilities that "generate significant threat" add to the threat modifier |
| 05:23.27 | ZorbaGama | that said I really wish luajit supported lua 5.2's setfenv replacement, it's super-elegant |
| 05:24.17 | Torhal | ZorbaGama: I never actually did experiments with luac to confirm, but Mikk has this in his FindGlobals project: "Put a "local _G=_G" at the top of the file, and then access them through _G.SomeFunc, etc. This is actually somewhat faster than accessing them directly, believe it or not. (Direct global access involves looking up the global variable table first!)" |
| 05:24.38 | Torhal | But he has, so I believe him. |
| 05:25.05 | ZorbaGama | Huh. well, I'll admit I'm skeptical, but if he tested it, then he's put more work into it than I have :) |
| 05:25.18 | ZorbaGama | Although note that luajit's performance patterns may be different than vanilla jit's |
| 05:25.56 | Solsis | So just to be clear you are saying that local unitDetail = _G.Inspect.Unit.Detail is correct? Yes? |
| 05:26.54 | Torhal | Oh, I don't doubt that. |
| 05:27.05 | Torhal | Solsis: Yes. |
| 05:27.15 | Solsis | Ok.. |
| 05:27.21 | Torhal | Though not neessary since you're doing it one time. |
| 05:27.22 | Solsis | That's how I originally had it. |
| 05:27.28 | Torhal | necessary* |
| 05:27.43 | Torhal | If you were doing the assignment several times in a loop, it would be helpful |
| 05:27.49 | Torhal | Since you're not, it's just fluff. |
| 05:28.09 | ZorbaGama | although I am going to point out again that this is probably a microoptimization that is just not worth worrying about :) |
| 05:28.12 | Noshei | I'll bug zinbik, see if that additional threat from attacks and items is something he could let us in on. Outside of that data, everything else is fairly simple to a certain extent, since we can guess a lot about a persons spec from the abilities thay have |
| 05:28.20 | Solsis | Well.. I call unitDetail a various amount of times through my addon. |
| 05:28.37 | ZorbaGama | Yeah, if you can get that data in the FTP data, I don't even bother asking Design if I can add it to the addon system, I just assume it's fine |
| 05:29.04 | Solsis | Zorba: Though that may be true... it's already there and I've coding around so.. changing it now would be messy. :P |
| 05:29.10 | Torhal | ZorbaGama: It is |
| 05:29.20 | Noshei | also, how about being able to inspect other players abilities? |
| 05:29.22 | Torhal | I just use it to be clear that I'm using a global var |
| 05:30.00 | ZorbaGama | solsis, lemme see if I can explain why I think this is unnecessary :) Let's say you take frequent trips across the country via plane. Every few days, you troop back across the country, six-hour plane trip and all. |
| 05:30.20 | ZorbaGama | These optimizations are like moving your bed two feet closer to your door to make it a shorter trip. |
| 05:30.26 | Torhal | <PROTECTED> |
| 05:30.45 | Torhal | If you want to test yourself, use the Lua interpreter and do both versions in a 10k loop |
| 05:30.56 | Torhal | You'll see that one _is_ faster, but not enough to care about. |
| 05:31.04 | ZorbaGama | Inspect.Unit.Detail() is really expensive. Like, really really expensive. It does a *lot* of work. Table lookups are effectively free compared to it. Note that Inspect.Unit.Detail is two table lookups, and reading .name and .hp out of the resulting table is *also* two table lookups |
| 05:31.37 | ZorbaGama | I'm not saying "don't do this", but I am saying that if you have a choice between this optimization and adding new features to your addon, you'd probably be best served by adding the features. |
| 05:33.00 | Solsis | Right.. Which makes sense Zorba. Like I said.. I've already got it all in place. Wherever Inspect.Unit.Detail would be located is where I put the unitDetail variable |
| 05:33.04 | Torhal | Optimization should always come after everything is done AND you're noticing things are slow. |
| 05:33.29 | Solsis | I completely agree. |
| 05:33.39 | Torhal | Though upvaluing to get rid of 2-3 table lookups is nice, and makes the code shorter |
| 05:36.20 | Torhal | ZorbaGama: I'm a bit curious as to what Legend of Grimrock's Lua API is like. Can't wait until they release their level editor. |
| 05:36.47 | Solsis | The whole _G thing came about out of a random conversation that I asked about earlier today |
| 05:37.59 | Solsis | My addon is already coded around those variables so I'm not doing anything new... and I'm not sitting here recoding everything for a little bit of performance. Thanks for the info though. |
| 05:38.12 | Torhal | I use it as a "because I can" pre-optimization because of my tendency to do things like _G.type(whatever) when I don't use type() eveough to upvalue it and I like being explicit that this isn't MY function. |
| 05:38.42 | Torhal | a/eveough/enough/ |
| 05:38.54 | *** join/#riftuidev arton (~arton@tx-184-6-177-47.dhcp.embarqhsd.net) |
| 06:16.16 | ZorbaGama | solsis, looking forward to seeing the result of all the work you're doing on this addon, btw, it sounds like you're putting a lot of good code in :) |
| 06:23.09 | Solsis | I'm trying |
| 06:23.22 | Solsis | Gadgets is going to be hard to beat |
| 06:23.42 | Solsis | Not really competing per say.. but still. |
| 06:31.56 | arton | Solsis: What's the addon about? |
| 06:36.35 | Solsis | Mine is a raid frame addon like grid/healbot |
| 06:53.25 | arton | Oh cool |
| 07:03.35 | arton | trolls Rift chat lines. |
| 08:30.46 | *** join/#riftuidev Imhothar (Miranda@ppp-188-174-125-207.dynamic.mnet-online.de) |
| 09:01.47 | Solsis | You still there Zorba? |
| 09:04.41 | ZorbaGama | yup, what's up? |
| 09:06.18 | *** join/#riftuidev Wildtide (~Wildtide@host86-135-35-151.range86-135.btcentralplus.com) |
| 09:07.43 | Solsis | So the Command.Context issue on offline units, would that also affect like units that are in your party that you haven't "seen" yet or haven't been in your zone yet? |
| 09:08.03 | Solsis | Cause I can't right click on them either. |
| 09:08.27 | Solsis | Example.. you're in a dungeon and someone ports out.. you can't click them anymore. |
| 09:08.35 | ZorbaGama | yeah, it would. I think that's fixed on the PTS now |
| 09:09.14 | Solsis | No offense to Rift's default UI... but once that is fixed... I can hide EVERYTHING. =) |
| 09:09.36 | Solsis | Woot |
| 09:09.41 | Solsis | Is there a date on 1.9 yet? |
| 09:10.05 | ZorbaGama | not officially announced :) |
| 09:12.05 | Solsis | k |
| 09:12.11 | Solsis | secrets... ugh |
| 09:12.16 | Solsis | I see that smile |
| 09:12.26 | Solsis | Is it soon? |
| 09:12.53 | ZorbaGama | c'mon, you know full well I'm not gonna answer that question either |
| 09:13.19 | Solsis | lol |
| 09:13.21 | Imhothar | he's new |
| 09:13.30 | Solsis | but I'm not stupid |
| 09:13.34 | Imhothar | many things to learn he has |
| 09:13.49 | Solsis | I work in a business where integrity is important as well |
| 09:14.03 | Solsis | Doesn't mean I can't give him hell though... He loves us. :P |
| 09:14.28 | Imhothar | ZorbaGama, I heard you were working on the texture loading issue |
| 09:15.05 | ZorbaGama | imhothar, I believe it's fixed, I'm not 100% sure that the fix is included on the PTS but it'll be part of 1.9 (barring some disastrous bug I'm not aware of, of course) |
| 09:15.27 | Imhothar | so was reloading the texture from disk everytime actually a bug? |
| 09:15.42 | ZorbaGama | yeah, that wasn't intended. Side effect of how the loading was happening. |
| 09:16.16 | ZorbaGama | Now it'll load a texture once and once only, although it will throw away the texture data again once no frames are using that texture. |
| 09:16.21 | Solsis | So now once a texture is loaded now it will be cached for every other time you load it? |
| 09:16.33 | Solsis | ok |
| 09:16.36 | Imhothar | awesome |
| 09:16.48 | Solsis | so changing textures still costs. |
| 09:17.04 | ZorbaGama | changing textures only costs if you're changing it to a texture that isn't yet loaded |
| 09:17.19 | ZorbaGama | you can do a bunch of trickery with "pre-loading" textures by creating an invisible Texture frame and setting it to whatever you want to remain in memory |
| 09:17.33 | Solsis | Yea.. I saw you guys talking about that earlier |
| 09:18.39 | ZorbaGama | I think this actually taps into the same texture cache the game itself uses, so you could theoretically write an addon that made the soul tree load faster by preloading all of your calling's icons |
| 09:18.52 | ZorbaGama | (at memory cost, of course - that's why we don't do it by default) |
| 09:20.29 | Wildtide | is a happy lil' Wild, didn't know that was coming :) |
| 09:20.31 | Solsis | The short lag of opening the soul trees isn't that big of a deal. Doesn't bother me... some people whine about it but it's like... why? What is it hurting? Nothing! |
| 09:22.21 | Wildtide | hey Zorba, I was playing KØЯ. last night. man that's a frustrating game! ;) |
| 09:22.23 | Solsis | oh.. and I was totally rude earlier Zorba... Thanks for the compliment on my addon. It's functional now and out there.. not sure you can ever really consider something like that "finished" but it's mostly done. |
| 09:22.35 | ZorbaGama | wildtide, yeah, it's kinda tough :D enjoying it? |
| 09:22.37 | Wildtide | yep :) |
| 09:22.44 | ZorbaGama | you get a different ending if you get through it below a certain number of deaths, although there's nothing really telling you so |
| 09:22.58 | Wildtide | it says i need to get through with less than 4 deaths |
| 09:23.06 | ZorbaGama | oh, it does? I guess I fixed that then |
| 09:23.14 | ZorbaGama | okay, yeah, less than 4 deaths! it's tough but I promise it's possible |
| 09:23.26 | Wildtide | but i keep getting mobbed by 3 biggies at once, need to get quicker with the grapple |
| 09:23.48 | ZorbaGama | solsis, no worries :) it just concerns me when I see people possibly burning a lot of time on things that aren't great uses of that time. In my old addon days I always saw people trying to shave off tiny fragments of memory usage |
| 09:24.06 | ZorbaGama | like, dude, your addon uses less than 200k of RAM, *nobody cares anymore, stop that* |
| 09:24.16 | Solsis | lol |
| 09:24.17 | Solsis | yea |
| 09:24.49 | ZorbaGama | this is one of the reasons rift doesn't report on per-addon memory usage :V (the other reason being that it's really hard and I don't think it's actually doable without major changes to luajit) |
| 09:24.53 | Solsis | Yea.. Like I said though.. Mines already using those methods and is coded around them so wasn't nothing to change but 4 lines |
| 09:25.06 | ZorbaGama | but yeah, it looks like you're overall on the right track, so, rock on! |
| 09:25.22 | ZorbaGama | wildtide, one of the important things in the game is that there's almost never a case when you need to grapple-damage something ASAP |
| 09:25.53 | ZorbaGama | if your choice is between maybe doing grapple damage while possibly dying, and not doing any damage but definitely living, the latter choice is almost the right one |
| 09:26.21 | ZorbaGama | (unless you're trying to do something gimmicky like defeating that miniboss that shows up and leaves within a second or two - it is possible, but it's really really tight) |
| 09:26.46 | Wildtide | it's the 3 at once, when they start spamming cubes of doom, it gets a bit hectic |
| 09:26.56 | Wildtide | really cool though |
| 09:27.07 | ZorbaGama | I clearly need to play that game again, I don't even remember that |
| 09:27.59 | Solsis | Well.. some of it was stuff I saw in other addons or learned from talking to people like Imhothar. So some it is there just because it works. Not because I understand it. Which is what I'm trying to do now. As far as optimization and performance, I'm not sure what something like a unit frame addon would use as "typical" CPU usage so right now I don't even really have a target.. I just want to keep it as low as possible. Seems |
| 09:29.34 | Wildtide | been reading your blog as well, it's really interesting stuff. your take on personal involvement vs. being a bit player in an epic storyline is spot on, i think |
| 09:31.14 | Solsis | me? or Zorba? |
| 09:31.40 | ZorbaGama | hah, I forgot how neat some of the special effects in kor were. I did a good job on that game |
| 09:31.53 | Wildtide | you did :) |
| 09:31.53 | ZorbaGama | a lot of subtlety, too - if you haven't noticed what happens to the background, pay attention to it :) |
| 09:32.06 | Wildtide | i haven't... *scoots off to have a look* |
| 09:32.19 | ZorbaGama | it's a very gradual change, it's most obvious if you compare the beginning to the end |
| 09:32.35 | ZorbaGama | solsis, www.mandible.net - I do a lot of blogging about gamedev |
| 09:40.25 | Wildtide | 9 deaths, it said less than 6 this time (must've remembered wrong) |
| 09:40.38 | ZorbaGama | there's a few endings |
| 09:40.40 | Wildtide | i see what you mean about the background. that is really cool |
| 09:40.59 | ZorbaGama | one of them is between 4 and 6 :) |
| 09:41.05 | Wildtide | lol |
| 09:41.23 | ZorbaGama | I think if you do really badly it doesn't even let you fight the last boss |
| 09:41.39 | Wildtide | yep, it doesn't |
| 09:42.03 | Wildtide | or so someone told me... obviously i've never failed that badly myself... *cough* |
| 09:42.05 | ZorbaGama | I got better at score eventually - Shopping Adventure is the best score system I've developed, by far |
| 09:42.20 | ZorbaGama | but player motivation is an absolute nightmare of a subject |
| 09:42.31 | Wildtide | haven't seen that one, i've only seen the 3 recommended games on the site? |
| 09:42.48 | ZorbaGama | http://www.mandible.net/category/monthly-game/ |
| 09:42.54 | Solsis | Does anyone remember colonization? |
| 09:43.02 | ZorbaGama | though note there's a really big reason some of these weren't recommended. ;) |
| 09:43.13 | Wildtide | hehe :) |
| 09:43.18 | ZorbaGama | solsis, I know it was a 4x-ish game made by Sid Meier, I don't know much more than that |
| 09:45.41 | Wildtide | are these all written using your own RAD game engine? |
| 09:46.08 | Wildtide | you're somewhat prolific, have only managed to read about 0.1% of your site ;) |
| 09:47.28 | ZorbaGama | yeah, although that game engine has been modified so much that the end result bears only dubious relationship to the beginning |
| 09:48.02 | ZorbaGama | though, interesting fact here, that game engine is where the first bunch of attempts on the Frames API came from :V |
| 09:52.09 | Solsis | How bad are doing things like Frame:GetAlpha()? or GetText() etc |
| 09:52.32 | ZorbaGama | Get is quite efficient. I wouldn't include it as part of a super-high-performance loop, but if you just need it occasionally, go for it |
| 09:53.58 | Wildtide | if you managed to build a game engine and evolve it, you're doing better than me. i've got about 20 half finished ones. i'm terrible for "starting again better", which means i never finish anything |
| 09:55.03 | ZorbaGama | finish a game, yo. Most important part of game development. |
| 09:55.12 | ZorbaGama | do some game jams or monthly game competitions :) |
| 09:56.22 | Wildtide | i do quite like the idea of a 48 hour game. might give that a go (though not in one sleepless session) |
| 09:56.31 | ZorbaGama | yeah you absolutely want to sleep |
| 09:56.34 | ZorbaGama | can't do gamedev on no sleep |
| 09:58.16 | Wildtide | anyway... my son is hovering, making random noise on my guitar and talking nonsense, which always means he wants to play Minecraft. better let him on :) |
| 09:58.34 | ZorbaGama | sounds like a plan, cya :) |
| 09:58.39 | Wildtide|afk | *waves* |
| 09:59.13 | Solsis | So.. I already knew this... but Rift is an amazingly beautiful game. |
| 09:59.21 | ZorbaGama | We've got some great artists. |
| 09:59.27 | Solsis | Just for kicks my friend and I were playing with the settings. |
| 09:59.49 | Solsis | I bumped it not only to ultra.. but went ahead and dragged all the sliders to full. |
| 10:00.44 | Solsis | hovering around 20-25 fps. Went exploring some different zones with said settings... Did that for almost an hour maybe a little more... it is just freaking crazy. I wish everyone could see the game like this. |
| 10:01.14 | ZorbaGama | I wish we could get the game running faster at those graphics settings |
| 10:01.24 | ZorbaGama | but rendering is hard :/ |
| 10:01.35 | Solsis | Did a warfront.. farmed some Oricalcum in EI just to see what it would do under pressure.. still wasn't too bad. |
| 10:02.13 | Solsis | I would imagine part of it is due to stuff in the graphics engine you use? same reasons for the loading issues in Meridian and such. |
| 10:02.45 | Solsis | Really overall it's great. But things can always be better. |
| 10:03.32 | Solsis | I'm not one to really dig into that stuff so I dont' want to speak over my head but really it looks pretty nice. |
| 10:04.07 | Solsis | I'm going to try leaving my settings like this for a little while.. see how bad "real work" actually kills it. |
| 10:05.02 | ZorbaGama | eh, part of it is just that MMOs are a bear to render. Other games can have reasonable predictions about what's going to be displayed, but MMOs are just chaos |
| 10:05.05 | Solsis | I've got a nice card. I just but it seemed like the default settings were actually producing the same or lower fps than when I jacked it all up. |
| 10:05.28 | ZorbaGama | people expect to see a hundred units walking around the screen, and people expect to see Crysis-level quality with only one unit on the screen, simultaneously. These things don't happen simultaneously. :) |
| 10:05.35 | Solsis | Which makes sense.. I'm not knocking it or anything. It really is a beautiful game. |
| 10:05.51 | Solsis | Oh definately not. |
| 10:06.22 | Solsis | Just think of what Crysis did to PCs with just that 1 unit. Lol... Now multiply that by 50 people standing in Meridian. |
| 10:06.32 | ZorbaGama | Yeah, not really practical :D |
| 10:06.36 | Solsis | = very dead PC |
| 10:07.01 | Solsis | if you could have negative framerates.. that would probably do it.. lol |
| 10:07.15 | ZorbaGama | that's the point where you measure it in seconds per frame instead |
| 10:11.04 | Solsis | lol |
| 10:16.24 | Baanano | hi |
| 10:20.51 | Solsis | Heya Baanano |
| 10:21.48 | Baanano | hi solsis, how are you doing? |
| 10:23.05 | Solsis | What about changing the width and stuff for textures (currently). You set a texture to something, in my case a health frame and of course it's width is changing and stuff all the time. |
| 10:23.27 | Solsis | Does it bother the cpu much now? and will it less after 1.9? |
| 10:23.46 | Solsis | I'm doing pretty good Baanano. Yourself? |
| 10:23.57 | Imhothar | You need to get less paranoid about CPU consumption |
| 10:24.17 | Solsis | Curious |
| 10:24.23 | Solsis | Not paranoid. |
| 10:25.06 | Solsis | Since we were having a conversation about the texture changes and all. |
| 10:28.54 | Imhothar | technically that's I/O-bound |
| 10:29.24 | ZorbaGama | keep in mind it doesn't really change the texture, just how the texture is rendered |
| 10:34.47 | Solsis | K |
| 11:02.21 | *** join/#riftuidev Baanano (~chatzilla@202.pool85-59-204.dynamic.orange.es) |
| 12:00.53 | *** join/#riftuidev Sunspots (~Sunspots@c213-89-208-104.bredband.comhem.se) |
| 12:48.40 | Solsis | alright.. i'm calling a break.. i'll be back later... Happy Father's day those that it applies to! |
| 13:06.56 | Baanano | coroutine sync is a pain >_< are any of you good with them so i can ask you some questions? |
| 13:23.21 | Wildtide|afk | i read the docs, that's about as far as i went :) |
| 13:34.44 | *** join/#riftuidev Sunspots_ (~Sunspots@c213-89-208-104.bredband.comhem.se) |
| 14:15.58 | *** join/#riftuidev Solsis|mobile (~androirc@108-226-48-242.lightspeed.fyvlar.sbcglobal.net) |
| 15:26.26 | *** join/#riftuidev Sunspots (~Sunspots@c213-89-208-104.bredband.comhem.se) |
| 17:14.31 | *** join/#riftuidev ChanServ (ChanServ@services.) |
| 17:14.31 | *** mode/#riftuidev [+o ChanServ] by kornbluth.freenode.net |
| 17:43.11 | seebs | Baanano: I'm not sure I'm "good with" coroutines, but I have used them successfully a few times. |
| 17:45.56 | *** join/#riftuidev Noshei (~quassel@c-67-161-146-244.hsd1.co.comcast.net) |
| 18:07.11 | Baanano | so seebs, how would you nest coroutines? |
| 18:08.50 | seebs | I am not sure what you mean by "nest". The thing about coroutines is that they don't really have a fixed location in the call stack; you can call them from wherever. |
| 18:10.24 | Baanano | i think the problem aren't the coroutines themselves, just how i'm using them, let me explain |
| 18:10.29 | seebs | So I'm not quite sure what you're trying to do. In theory, coroutines could probably call each other, although if they went back and forth much I'd expect you to run out of stack. |
| 18:11.28 | Baanano | i'm using a queue manager to split execution across frames, and it does that by using coroutines |
| 18:12.59 | Baanano | you send a task to the queue manager like this QueueTask(priority, task, callback), where task is the function with the coroutine.yield calls inside, and callback is the function you want to be executed when the task is finished |
| 18:13.25 | *** join/#riftuidev Noshei_mobile (~Noshei@c-67-161-146-244.hsd1.co.comcast.net) |
| 18:13.37 | Baanano | (ignore the priority right now) |
| 18:14.22 | seebs | Okay, makes sense. So it'll be doing coroutine.resume(task, args) until that yields nil or something? |
| 18:14.46 | Baanano | until it returns (coroutine.status = dead) |
| 18:15.03 | seebs | Ahh, okay. |
| 18:15.54 | Baanano | this needs to be a queue, to avoid a second task to execute while the first one might have the variables in an incoherent state |
| 18:16.17 | seebs | Makes sense. |
| 18:18.18 | Baanano | so i have a GetAuctions(callback, criteria) function, that uses this thing to search the auctions that match the criteria, across several frames if needed, and then calls the callback with the results |
| 18:18.36 | seebs | k |
| 18:19.23 | Baanano | now i want to write a GetAveragePrice(item) one |
| 18:20.02 | Baanano | as it can trigger the watchdog, it needs to be async too, so it would be GetAveragePrice(callback, item) |
| 18:20.40 | Baanano | problem here is that GetAveragePrice needs to use the GetAuctions one |
| 18:22.09 | Baanano | and i can't use the queue manager as it is right now, as it won't execute GetAuctions until GetAveragePrice has ended |
| 18:25.31 | Baanano | i guess i could add a InsertTask(priority, task, callback) to the queue manager to insert in the head of the queue |
| 18:25.31 | seebs | hmm |
| 18:26.23 | seebs | I see your point. I think what I'd do is have GetAveragePrice(item) look like GetAuctions(...); ComputeAveragePrice(...) |
| 18:26.37 | seebs | Or, wait. |
| 18:26.48 | seebs | GetAuctions(ComputeAveragePrice, item) |
| 18:27.02 | seebs | Where ComputeAveragePrice is a callback which can then, itself, do whatever's needed. |
| 18:27.36 | seebs | And if its computations can hit watchdog, then you go one step further, and GetAuctions(function (...) ComputeAveragePrice(callback, ...) end, item) |
| 18:28.19 | Baanano | that could work |
| 18:29.09 | Baanano | i'm going to try |
| 18:29.41 | Baanano | but i think this code is going to be ugly, i hope i never have to modify it again :P |
| 18:29.45 | Baanano | thanks seebs |
| 18:40.55 | Baanano | can i ask you the "more difficult still" part, seebs? |
| 18:47.00 | seebs | Go right ahead. |
| 18:48.24 | Baanano | now imagine that part has been solved and i have GetAveragePrice, GetMedianPrice, GetAnotherPrice, ... functions that work that way |
| 18:48.58 | *** join/#riftuidev Noshei_mobile2 (~Noshei@184.232.197.25) |
| 18:49.35 | Baanano | i need a GetAllPrices(callback, item) now that calls those in a for loop and builds a table like { average = 70, median = 17, ... } |
| 18:51.26 | Baanano | the list of GetXXXPrice functions isn't known until GetAllPrices is called, as you can add or delete pricing functions |
| 18:52.41 | seebs | Okay. You clearly *must* have a table of the GetFooPrice functions; you can't do this without that table. |
| 18:53.07 | seebs | Hmm. You already have a queue, so life is easy. |
| 18:53.18 | seebs | Imagine a table, p, containing all the GetFooPrice functions. |
| 18:53.34 | seebs | Make a copy of that table, and then: |
| 18:53.40 | seebs | last = table.remove(p, #p) |
| 18:53.48 | seebs | stash = {} |
| 18:54.01 | seebs | for _, func in ipairs(p) do |
| 18:54.06 | seebs | stash[func] = {} |
| 18:54.34 | seebs | func(function(...) stash_in_table(stash[func], ...) end, item) |
| 18:54.36 | seebs | end |
| 18:54.52 | seebs | last(function(...) process_last_callback(stash, ...) end, item) |
| 18:55.07 | seebs | All the Get* are going into the queue (if that means I spelled the calls wrong, fix that up). |
| 18:55.29 | seebs | Each of them is queued, and the stash_in_table callbacks stash their results in stash[func]. |
| 18:55.47 | seebs | Then process_last_callback gets the table of stashed values, plus the final value, and can do all the statistics. |
| 18:56.21 | Baanano | i really like it, i wouldn't have imagined such as solution |
| 18:56.57 | Baanano | thanks again, seebs :) |
| 18:57.38 | seebs | The basic gimmick is to just ignore the "I call this and then that" logic because the queue already hides it for you. :) |
| 18:59.16 | Baanano | my problem was detecting when the last one has been processed, and you've solved it in cool way |
| 18:59.44 | Baanano | at first i was clueless why were you removing a function from the table :P |
| 19:10.12 | seebs | Actually, there's a simpler way. |
| 19:10.23 | seebs | for idx, func in ipairs(p) do ... if idx == #p then ... |
| 19:12.26 | Baanano | i'm doing it this way, i think it should work too: |
| 19:14.22 | Baanano | function PublicInterface.GetPricings(callback, item) |
| 19:14.23 | Baanano | local prices = {} |
| 19:14.25 | Baanano | for pricingModelID, pricingFunction in pairs(pricingModels) do |
| 19:14.26 | Baanano | QueueTask(Priorities.HIGH, function() return pricingFunction(item) end, function(price) prices[pricingModelID] = price end) |
| 19:14.28 | Baanano | end |
| 19:14.29 | Baanano | QueueTask(Priorities.HIGH, function() callback(prices) end) |
| 19:14.31 | Baanano | end |
| 19:29.25 | seebs | Oh, that's nice too. |
| 19:29.27 | seebs | Good insight. |
| 19:35.39 | Baanano | no, it doesn't work, your is better |
| 19:51.26 | *** join/#riftuidev Noshei_mobile2 (~Noshei@173.134.252.86) |
| 20:12.18 | *** join/#riftuidev Noshei_mobile (~Noshei@c-75-71-99-42.hsd1.co.comcast.net) |
| 20:24.50 | *** join/#riftuidev Noshei_mobile2 (~Noshei@c-75-71-99-42.hsd1.co.comcast.net) |
| 20:42.48 | *** join/#riftuidev Noshei_mobile2 (~Noshei@184.229.208.69) |
| 21:25.03 | *** join/#riftuidev Noshei_mobile2 (~Noshei@184.229.39.230) |
| 22:55.03 | Baanano | see you tomorrow |