| --- Log opened Thu Oct 21 00:00:00 2010 |
| 00:08 | | TarinakyKai [Tarinaky@Nightstar-f349ca6d.plus.com] has quit [Connection closed] |
| 00:40 | | Anno[Laptop] [annodomini@Nightstar-8580b280.adsl.tpnet.pl] has quit [[NS] Quit: leaving] |
| 00:51 | | Orthia [orthianz@Nightstar-ce5a2312.xnet.co.nz] has joined #code |
| 00:56 | | Attilla [Some.Dude@Nightstar-c010325e.threembb.co.uk] has quit [[NS] Quit: ] |
| 01:04 | | Zed [Zed@Nightstar-556ea8b5.or.comcast.net] has joined #code |
| 01:40 | | kwsn [kwsn@Nightstar-1def9d24.dyn.centurytel.net] has quit [[NS] Quit: BEEP BEEP IMMA JEEP] |
| 01:46 | | Derakon[AFK] is now known as Derakon |
| 01:49 | | Orthia [orthianz@Nightstar-ce5a2312.xnet.co.nz] has quit [Connection reset by peer] |
| 01:56 | | Orthia [orthianz@Nightstar-ce5a2312.xnet.co.nz] has joined #code |
| 02:26 | | Vornicus-Latens is now known as Vornicus |
| 02:27 | | Orthia [orthianz@Nightstar-ce5a2312.xnet.co.nz] has quit [Connection reset by peer] |
| 02:35 | | Orthia [orthianz@Nightstar-ce5a2312.xnet.co.nz] has joined #code |
| 03:05 | | gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has quit [[NS] Quit: Z?] |
| 03:44 | | celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has joined #code |
| 04:44 | | Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has joined #code |
| 05:21 | | Stalker [Z@26ECB6.A4B64C.298B52.D80DA0] has quit [Ping timeout: 121 seconds] |
| 05:37 | | Ortiha [orthianz@Nightstar-ba7819b9.xnet.co.nz] has joined #code |
| 05:39 | | Orthia [orthianz@Nightstar-ce5a2312.xnet.co.nz] has quit [Ping timeout: 121 seconds] |
| 05:44 | | celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 05:54 | | Stalker [Z@3A600C.A966FF.5BF32D.8E7ABA] has joined #code |
| 06:28 | | Derakon is now known as Derakon[AFK] |
| 07:10 | | Stalker [Z@3A600C.A966FF.5BF32D.8E7ABA] has quit [Ping timeout: 121 seconds] |
| 07:14 | | You're now known as TheWatcher |
| 07:40 | | Ortiha [orthianz@Nightstar-ba7819b9.xnet.co.nz] has quit [Ping timeout: 121 seconds] |
| 07:41 | | kwsn [kwsn@Nightstar-1def9d24.dyn.centurytel.net] has joined #code |
| 07:49 | | SmithKurosaki [Smith@Nightstar-8ff23d84.dsl.teksavvy.com] has quit [Ping timeout: 121 seconds] |
| 08:20 | | kwsn is now known as kwsn\t-2 |
| 08:21 | | Anno[Laptop] [annodomini@Nightstar-15c1c53b.adsl.tpnet.pl] has joined #code |
| 08:22 | | kwsn\t-2 is now known as kw-sleep-n |
| 08:46 | | Vornicus is now known as Vornicus-Latens |
| 09:24 | | ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has quit [Operation timed out] |
| 10:06 | | Anno[Laptop] [annodomini@Nightstar-15c1c53b.adsl.tpnet.pl] has quit [[NS] Quit: I must go. My Uni needs me.] |
| 10:44 | | Anno[Laptop] [annodomini@F67919.F326B3.98D923.BDA7B6] has joined #code |
| 11:16 | | Anno[Laptop] [annodomini@F67919.F326B3.98D923.BDA7B6] has quit [Ping timeout: 121 seconds] |
| 11:19 | | Anno[Laptop] [annodomini@F67919.F326B3.98D923.BDA7B6] has joined #code |
| 11:24 | | Anno[Laptop] [annodomini@F67919.F326B3.98D923.BDA7B6] has quit [Ping timeout: 121 seconds] |
| 11:26 | | Anno[Laptop] [annodomini@F67919.F326B3.98D923.BDA7B6] has joined #code |
| 11:48 | | Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has quit [Connection closed] |
| 11:52 | | Anno[Laptop] [annodomini@F67919.F326B3.98D923.BDA7B6] has quit [Ping timeout: 121 seconds] |
| 11:54 | | Anno[Laptop] [annodomini@F67919.F326B3.98D923.BDA7B6] has joined #code |
| 11:59 | | Anno[Laptop] [annodomini@F67919.F326B3.98D923.BDA7B6] has quit [Ping timeout: 121 seconds] |
| 11:59 | | ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has joined #code |
| 12:00 | | mode/#code [+o ToxicFrog] by Reiver |
| 12:00 | | Anno[Laptop] [annodomini@F67919.F326B3.98D923.BDA7B6] has joined #code |
| 12:28 | | Anno[Laptop] [annodomini@F67919.F326B3.98D923.BDA7B6] has quit [[NS] Quit: Homewards.] |
| 12:36 | | cpux is now known as shade_of_cpux |
| 13:00 | | Anno[Laptop] [annodomini@Nightstar-15c1c53b.adsl.tpnet.pl] has joined #code |
| 13:03 | | gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has joined #code |
| 13:31 | | Tarinaky [Tarinaky@Nightstar-f349ca6d.plus.com] has joined #code |
| 14:34 | | kw-sleep-n is now known as kwsn |
| 14:36 | | Orthia [orthianz@Nightstar-4c98dee4.xnet.co.nz] has joined #code |
| 15:24 | | Stalker [Z@26ECB6.A4B64C.298B52.D80DA0] has joined #code |
| 15:38 | | Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has joined #code |
| 16:05 | | Orthia [orthianz@ServerAdministrator.Nightstar.Net] has quit [Connection reset by peer] |
| 16:06 | | Orthia [orthianz@Nightstar-4c98dee4.xnet.co.nz] has joined #code |
| 16:07 | | Orthia [orthianz@Nightstar-4c98dee4.xnet.co.nz] has quit [Connection reset by peer] |
| 16:10 | | Orthia [orthianz@Nightstar-4c98dee4.xnet.co.nz] has joined #code |
| 16:19 | | gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has quit [Ping timeout: 121 seconds] |
| 16:22 | | gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has joined #code |
| 16:26 | | Orthia [orthianz@Nightstar-4c98dee4.xnet.co.nz] has quit [Connection reset by peer] |
| 16:33 | | Orthia [orthianz@Nightstar-4c98dee4.xnet.co.nz] has joined #code |
| 16:39 | | Orthia [orthianz@Nightstar-4c98dee4.xnet.co.nz] has quit [Client closed the connection] |
| 16:46 | | Orthia [orthianz@Nightstar-4c98dee4.xnet.co.nz] has joined #code |
| 16:50 | | Orthia [orthianz@Nightstar-4c98dee4.xnet.co.nz] has quit [Client closed the connection] |
| 16:57 | | Orthia [orthianz@Nightstar-4c98dee4.xnet.co.nz] has joined #code |
| 17:07 | | Orthia [orthianz@Nightstar-4c98dee4.xnet.co.nz] has quit [Connection reset by peer] |
| 17:13 | | Orthia [orthianz@Nightstar-4c98dee4.xnet.co.nz] has joined #code |
| 17:17 | | Rhamphoryncus [rhamph@Nightstar-473f8685.abhsia.telus.net] has quit [Client exited] |
| 17:17 | | Orthia [orthianz@Nightstar-4c98dee4.xnet.co.nz] has quit [Client closed the connection] |
| 17:19 | | Attilla [Some.Dude@Nightstar-64e6dedf.threembb.co.uk] has joined #code |
| 17:19 | | mode/#code [+o Attilla] by Reiver |
| 17:32 | | Orthia [orthianz@Nightstar-4c98dee4.xnet.co.nz] has joined #code |
| 17:34 | | Orthia [orthianz@Nightstar-4c98dee4.xnet.co.nz] has quit [Client closed the connection] |
| 17:41 | | Orthia [orthianz@Nightstar-4c98dee4.xnet.co.nz] has joined #code |
| 17:41 | | Orthia [orthianz@Nightstar-4c98dee4.xnet.co.nz] has quit [Client closed the connection] |
| 17:49 | | Orthia [orthianz@Nightstar-4c98dee4.xnet.co.nz] has joined #code |
| 18:00 | | Attilla [Some.Dude@Nightstar-64e6dedf.threembb.co.uk] has quit [[NS] Quit: ] |
| 18:01 | <@ToxicFrog> | So I have a type heirarchy issue. |
| 18:01 | <@ToxicFrog> | Token is the basic type for "things that can be picked up and moved around". |
| 18:02 | <@ToxicFrog> | At the moment, ImageToken is a subclass (tokens which are rendered from image surfaces) and Board (tokens which can have other tokens on top of them) is a subclass of that. |
| 18:02 | <@ToxicFrog> | But really, they're all more like unrelated capabilities - can be picked up, can have things dropped on it, can be flipped, can be rotated, renders as shape, renders as image, renders as code, etc. |
| 18:11 | < Orthia> | BoardToken inherets ImageToken(){ |
| 18:12 | | * Orthia flees |
| 18:13 | <@Vornicus-Latens> | I see some commingling of model and view here. |
| 18:25 | | Ortiha [orthianz@Nightstar-abd01713.xnet.co.nz] has joined #code |
| 18:28 | | Orthia [orthianz@Nightstar-4c98dee4.xnet.co.nz] has quit [Ping timeout: 121 seconds] |
| 18:32 | <@ToxicFrog> | Vornicus-Latens: yes. One thing I have considered is having a seperate renderer heirarchy, and each token has_a renderer |
| 18:33 | <@ToxicFrog> | That doesn't help with token vs board vs spinner vs rotateable etc |
| 18:36 | <@Vornicus-Latens> | What's rotateable for? I mean, I imagine most devices can be rotated. |
| 18:38 | <@ToxicFrog> | Most stuff you won't ever need to rotate. |
| 18:38 | <@ToxicFrog> | On the other hand, if you're playing MtG you need to be able to rotate the cards, if you're playing Descent parts of the dungeon need to be rotated... |
| 18:39 | <@Vornicus-Latens> | Way I see it, just give everything the ability to rotate. |
| 18:40 | <@ToxicFrog> | Ehn. I guess if you never bind anything to it, it doesn't do any harm. |
| 18:40 | <@ToxicFrog> | However, this is still just a special case of the general problem! |
| 18:45 | <@Vornicus-Latens> | Namely that all these things have to be implemented or not. |
| 18:46 | <@ToxicFrog> | No. |
| 18:46 | <@Vornicus-Latens> | or rather, that there's an explosion of classes if you do that. |
| 18:46 | <@ToxicFrog> | That I have all of these capabilities and different objects have different capabilities and they don't form a nice heirarchy. |
| 18:46 | <@ToxicFrog> | For example, a Field acts as a Board but cannot be rotated or picked up. |
| 18:47 | <@ToxicFrog> | Descent character sheets can be picked up, but can also have stuff put on top of them. |
| 18:47 | <@ToxicFrog> | Descent character tokens cannot. |
| 18:54 | <@Vornicus-Latens> | Hokay, so, mixin time. Your module data files will have flags in it for your various abilities and build the class on the fly. |
| 18:55 | <@Vornicus-Latens> | Especially as you /will/ have an explosion of classes: Carcassonne tiles can be rotated and placed, but cannot be moved once they have been placed. |
| 18:59 | <@ToxicFrog> | Right. |
| 18:59 | <@ToxicFrog> | Easiest approach, then, in terms of not making serialization horrible, is to not permit mixins post-object-creation; each module creates its own subclass of Token or whatever and applies the appropriate mixins and method overloads. |
| 19:00 | <@ToxicFrog> | This also helps with type checking and debugging messages. |
| 19:00 | <@Vornicus-Latens> | As for rendering, I suggest that everything renders as code, but you have closures for image and shape. |
| 19:01 | <@ToxicFrog> | Well, yes, obviously everything renders as code; I just mean it's useful to have prepacked method definitions for "geometric shape" and "image surface", because those are overwhelmingly the most common. |
| 19:01 | <@ToxicFrog> | If those don't cut it you implement your own definition of :draw or :render |
| 19:21 | | Tarinaky [Tarinaky@Nightstar-f349ca6d.plus.com] has quit [Connection closed] |
| 19:44 | | Ortiha [orthianz@Nightstar-abd01713.xnet.co.nz] has quit [Client closed the connection] |
| 19:46 | | Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has quit [Connection closed] |
| 19:53 | | Orthia [orthianz@Nightstar-abd01713.xnet.co.nz] has joined #code |
| 21:23 | | Derakon [Derakon@Nightstar-1ffd02e6.ucsf.edu] has joined #code |
| 21:23 | | mode/#code [+o Derakon] by Reiver |
| 21:26 | <@Derakon> | So we have this mosaic system in the microscope. |
| 21:26 | <@Derakon> | It consists of taking a large number of 512x512-pixel exposures and stitching them together to make a high-level view of the contents of the slide. |
| 21:27 | <@Derakon> | Given that each exposure covers about 50 square microns, and the slide is 21000 square microns, we can end up with lots of exposures. In practice getting upwards of 4000 isn't uncommon. |
| 21:27 | <@Derakon> | The user can pan and zoom the view. Naturally this gets very slow when lots of exposures ("tiles") are in view. |
| 21:28 | <@Derakon> | I'd like it to be faster. |
| 21:28 | <@Derakon> | Now if I remember my OpenGL properly, it should automatically be generating mipmaps for me, which means that I don't need to worry too much about downsampling textures when you're zoomed way out. |
| 21:29 | <@Derakon> | Which makes me assume that the slowdown is largely caused by simply having to render e.g. 3k individual textures. |
| 21:29 | <@TheWatcher> | probably - every time you switch texture units, there's a potentially nontrivial overhead |
| 21:30 | <@Derakon> | By "switch texture units" you mean going from one level of detail to the next? |
| 21:30 | <@Derakon> | E.g. 512x512 => 64x64 |
| 21:31 | <@Derakon> | I was thinking of periodically rendering all of the tiles at e.g. 1/8th zoom to a single texture which I could use in place of many tiles when the user is zoomed out. |
| 21:32 | <@Derakon> | Basically pre-rendering. |
| 21:32 | <@TheWatcher> | no, each time you call glBindTexture() before glBegin() to draw each image |
| 21:32 | <@Derakon> | But that sounds like it could get complicated fast. |
| 21:32 | <@Derakon> | Ahh. |
| 21:33 | <@TheWatcher> | (this is one of the reasons uvmapped textures for objects in 3D games are so common - you usually want to call glBindTexture as infrequently as possible) |
| 21:34 | <@TheWatcher> | And yeah, prerendering sounds like a good idea to me, when possible |
| 21:34 | <@Derakon> | Part of the issue here is that the program crashes sometimes, which seems to be associated with panning/zooming while adding tiles to the mosaic. I'm guessing some kind of thread resource contention but I haven't managed to track it down yet. However, I figure if I can minimize the amount of time spent drawing, then I should be able to minimize the chance of the crash occurring. |
| 21:35 | <@Derakon> | (The crash only happens when there's lots of tiles in the mosaic already) |
| 21:35 | <@TheWatcher> | (but now, I must afk again, to make biscuits) |
| 21:35 | <@Derakon> | Righto. Thanks. |
| 21:41 | | * Derakon unplugs to take his laptop into the scope room. |
| 21:41 | | Derakon [Derakon@Nightstar-1ffd02e6.ucsf.edu] has quit [[NS] Quit: Leaving] |
| 21:56 | | Derakon [Derakon@Nightstar-1ffd02e6.ucsf.edu] has joined #code |
| 21:56 | | mode/#code [+o Derakon] by Reiver |
| 21:56 | <@Derakon> | Well, that didn't make a perceptible difference. |
| 21:57 | <@Derakon> | I noted that the scope wasn't explicitly generating mipmaps, so I replaced its texture-generation code with some I copied from Jetblade, but it's still horribly laggy when zoomed out. |
| 21:57 | <@Derakon> | Which implies the problem is indeed with just drawing thousands of textures, not with having to downsample them. |
| 21:59 | <@McMartin> | Can you do your texture work in bulk in software before uploading to the video card? We had to do that for UQM, even. |
| 22:01 | <@Derakon> | I'm not certain I understand what you're suggesting. |
| 22:01 | <@Derakon> | Do you mean e.g. concatenating tiles together to form large single textures? |
| 22:07 | <@McMartin> | Or doing that in software, yeah. |
| 22:07 | <@McMartin> | Texture upload is very expensive, in my experience. |
| 22:08 | <@Derakon> | Part of the problem is that I have to keep all of the tiles separable, since there's features to delete specific tiles, hide subsets of the tiles, etc. |
| 22:12 | <@Derakon> | So I'm thinking that basically I have a "cache", which is a subset of the tiles prerendered at a fixed zoom-out level (subset because new tiles are continually being added). |
| 22:12 | <@Derakon> | Periodically I update the cache, which means rerendering everything at that level...or I suppose I could have multiple cached tiles. Hrm. |
| 22:12 | <@Derakon> | In practice, new tiles will show up next to each other. |
| 22:13 | <@Derakon> | Most of the time. The user will generally move from one location to another and start adding tiles again, though. |
| 22:13 | <@Derakon> | (So e.g. start at (100, 100), generate tiles centered on this point for a bit, delete some of them, go to (200, 200), repeat) |
| 22:14 | | KM [---@Nightstar-4764665d.tbcn.telia.com] has joined #code |
| 22:17 | <@Derakon> | Let's say that the prendered tiles are at 1/8th zoom (so 512x512 => 64x64). That means that the entire slide space (21000x21000 pixels) can be represented by a 6x6 grid of 512x512 textures. |
| 22:18 | | * TheWatcher eyes this texture |
| 22:18 | <@TheWatcher> | No wonder the in-game image looks so crap, whoever did this was a muppet... |
| 22:18 | <@Derakon> | Heh. |
| 22:18 | <@McMartin> | ? |
| 22:19 | <@McMartin> | Derakon: Yeah, that sounds like you'd end up totally flushing your graphics cache six times a frame. |
| 22:19 | <@Derakon> | McM: what, with 36 512x512 textures? |
| 22:19 | <@Derakon> | That's only ~10MB at 1 byte per pixel. |
| 22:20 | <@TheWatcher> | It's for thief 2, so the textures are capped at 256x256 without Shenanigans - the texture in question is for the outside of a large display case, and it actually contains three identical copies of the same image, next to each other. |
| 22:20 | <@McMartin> | You're 4 almost certainly bytes per pixel, but the point is that if you're submitting 40MB of texels a frame, your fill rate is your limiter |
| 22:21 | <@McMartin> | Maybe I'm misunderstanding the architecture - are these images static and cached? |
| 22:21 | | * McMartin was assuming they were feeds. |
| 22:21 | <@Derakon> | Oh no. |
| 22:21 | <@Derakon> | We take a snapshot of what the camera sees, generating a static 512x512 B&W image. |
| 22:21 | <@Derakon> | We record where the camera was looking, and send that combination of image data + positioning to the mosaic. |
| 22:22 | <@Derakon> | The mosaic binds the image data as a texture and then draws it using glBindTexture etc. |
| 22:22 | <@McMartin> | I guess my real question is how often you call glGenTexture2d as opposed to glBindTexture. |
| 22:22 | <@McMartin> | The former is extremely expensive, to the point that naively using it in a 2D video game port from 20 years ago will lag you to shit |
| 22:22 | | * Derakon nods. |
| 22:23 | <@Derakon> | We should be only calling that once per added tile. |
| 22:23 | <@McMartin> | And not GenTexture. ImgTexture or whatever. |
| 22:23 | <@Derakon> | But this code is shit, so I should double-check that. |
| 22:23 | <@McMartin> | GenTexture is the one that just hands you a gensym to refer to in BindTexture and friends; that's cheap~ |
| 22:24 | <@Derakon> | ...hm, if I'm reading this correctly, we may be regenerating every single texture every time we get a new one. O_o |
| 22:24 | <@Derakon> | I'm gonna paste this a) so I can hurt you all, and b) so you can double-check my reading. |
| 22:25 | <@TheWatcher> | Your generosity is unbounded... |
| 22:25 | <@Derakon> | You're too kind. |
| 22:25 | <@McMartin> | Finite, but unbounded. |
| 22:25 | <@Derakon> | http://pastebin.starforge.co.uk/431 |
| 22:25 | <@McMartin> | It is a sphere's surface. |
| 22:26 | <@Derakon> | Line 135 has InitTex, which appears to be where we actually generate textures from image data (which is stored in self.m_imgArrL) |
| 22:26 | <@McMartin> | usefulX =( |
| 22:26 | <@Derakon> | Yep. |
| 22:26 | <@Derakon> | Although insertNewImg may also be doing texture generation. |
| 22:26 | <@Derakon> | I'm not too clear. |
| 22:26 | <@McMartin> | The first thing you do in INitTex, more or less, is trash all your previous information |
| 22:26 | <@Derakon> | Yes. |
| 22:26 | <@McMartin> | glDeleteTextures is going to flush the graphics card's memory, right? |
| 22:27 | <@Derakon> | I would assume so, though I don't actually know. |
| 22:27 | <@TheWatcher> | yes, it does |
| 22:27 | <@Derakon> | Note that InitTex() is called from OnPaint() if self.m_imgL_changed. |
| 22:28 | <@McMartin> | Doomed. |
| 22:28 | <@McMartin> | insertNewImg, however, is purely additive. |
| 22:28 | <@McMartin> | Any time self.m_imgL_changed is called, you're sending 40MB over your bus. |
| 22:28 | <@Derakon> | Which occurs when a tile is deleted or our contrast parameters are tweaked. |
| 22:28 | <@Derakon> | Not that often, actually. |
| 22:29 | <@McMartin> | If you actually *are* changing all the data, that's one thing |
| 22:29 | <@McMartin> | Contrast ideally would be done at a non-texel level though |
| 22:29 | <@Derakon> | Hm, these do appear to be the only times that function is called. |
| 22:29 | <@Derakon> | So InitTex() shouldn't happen often, and not during time-sensitive periods. |
| 22:30 | <@McMartin> | And those two are the only places calling glTexImage2D. |
| 22:30 | <@McMartin> | So that's OK |
| 22:32 | <@Derakon> | Jeeze, the OnPaint function is 156 lines long. |
| 22:34 | <@Derakon> | Hmm...now I'm wondering if it's _updatePositions that's taking so long, maybe. |
| 22:35 | <@McMartin> | Does python have a function level profiler? |
| 22:35 | | * TheWatcher eyes |
| 22:35 | <@TheWatcher> | I could be being dense (been up too long...) but what's with line 608? |
| 22:35 | <@Derakon> | I believe you can invoke its profiler on any function you want. |
| 22:36 | <@Derakon> | TW: not a clue. |
| 22:36 | <@Derakon> | IIRC m_gllist is basically a set of drawing directives for overlaying markers on the mosaic. |
| 22:36 | <@Derakon> | Dunno why there'd implicitly be two of 'em. |
| 22:36 | <@McMartin> | I assumed that m_gllist was first of a pair of call lists. |
| 22:36 | <@McMartin> | That does violate 0,1,A_0, but it doesn't look Obviously Wrong. |
| 22:36 | <@McMartin> | Also, call lists are hella fast |
| 22:37 | <@Derakon> | 0,1,A_0? |
| 22:37 | <@Derakon> | m_gllist is only modified from within this file, I note. |
| 22:37 | <@TheWatcher> | _updatePositions() seems to create just the one list |
| 22:37 | <@Derakon> | It does so every time the view is panned or zoomed, though. |
| 22:37 | <@Derakon> | Which can be a lot since those controls are bound to mouse motions. |
| 22:38 | <@McMartin> | The "zero, one, infinity" rule - for any construct N, allow 0 N, exactly 1 N, or any number of N. |
| 22:38 | <@Derakon> | Ah. |
| 22:38 | <@McMartin> | A_0 there being my pitiful romanization and ASCII-fication of aleph-null. |
| 22:38 | <@Derakon> | \infinity |
| 22:39 | <@Derakon> | I could speed up _updatePositions significantly with a quadtree... |
| 22:39 | <@Derakon> | Except that in the case where things are really chugging, all of the tiles are in view anyway. |
| 22:40 | <@Derakon> | Hm. Which implies that the slowdown isn't due to having to iterate over all the tiles to create the list -- panning is fast regardless of how many tiles you have, so long as you're zoomed in. |
| 22:43 | <@Derakon> | So back to prerendering, then... |
| 22:45 | <@Derakon> | On receiving a new tile, append it to a list (in addition to all the other lists we have here). When the list gets to >100 or whatever, take all the tiles out of it and render them to one of the 36 1/8th-scale textures. |
| 22:45 | <@Derakon> | Then when the zoom level is at 1/8th or less, we can use those textures instead of drawing each tile individually. |
| 22:46 | <@Derakon> | (Though we still individually draw the tiles that are in that list, so we don't pay the cost of prerendering every time) |
| 22:47 | <@Derakon> | Question: if I have an existing texture of N tiles, can I render tile N+1 onto it without having to rerender the original N? |
| 22:48 | <@McMartin> | glTexSubImage2d is the function you want, I believe. |
| 22:48 | <@McMartin> | (UQM uses it in GL mode to only update the rectangle that actually changed) |
| 22:56 | <@Derakon> | Would something like this work? http://pastebin.starforge.co.uk/432 |
| 22:57 | <@Derakon> | I'm gonna have to do some experimentation to get the actual OpenGL invocations right. I'm nowhere near as fluent in OpenGL as I'd like to be. |
| 22:57 | <@McMartin> | I don't see anything immediately wrong with it, but it's always hard to guess what's faster by sight. |
| 22:58 | | * Derakon nods. |
| 22:59 | <@McMartin> | You're going to have to semi-randomly dick around, doing science to it until it works. |
| 22:59 | | Zed [Zed@Nightstar-556ea8b5.or.comcast.net] has quit [Ping timeout: 121 seconds] |
| 23:00 | <@Derakon> | Fun. |
| 23:00 | <@McMartin> | Look at you! |
| 23:00 | <@Derakon> | ...man, sed directives are practically unreadable sometimes. |
| 23:00 | <@McMartin> | Still talking while there's SCIENCE to do. |
| 23:00 | <@Derakon> | :%g/^\s*\d*\.$/d |
| 23:01 | <@Derakon> | I'm a little reluctant because I really need to set up a minimal test app to work on this stuff instead of trying to do it directly in the microscope program, or else all the overhead will make debugging even more of a pain. |
| 23:01 | <@Derakon> | Of course, if I don't start I'll never finish... |
| 23:20 | | You're now known as TheWatcher[T-2] |
| 23:21 | <@Derakon> | Night, TW. |
| 23:26 | | * Derakon eyes the mosaic code, tries to find the point at which the image data is actually handed to OpenGL. |
| 23:27 | <@Derakon> | Nothing in insertNewImg does it. |
| 23:29 | | Orthia [orthianz@Nightstar-abd01713.xnet.co.nz] has quit [Ping timeout: 121 seconds] |
| 23:29 | <@Derakon> | Neither for that matter does InitTex. |
| 23:30 | <@Derakon> | ...oh, it happens in OnPaint. WTF. |
| 23:36 | <@Derakon> | There, I now have a test app that generates 10 512x512 textures per second. |
| 23:36 | <@Derakon> | And draws them! |
| 23:41 | | * Derakon mutters, tries to figure out where GL_SHORT, GL_INT, etc. are defined. |
| 23:41 | <@McMartin> | OpenGL.h. |
| 23:41 | <@Derakon> | This is nearly impossible given how often they're listed in other functions' documentation as potential valid values for arguments. |
| 23:41 | <@McMartin> | ... not that this helps you worth a damn |
| 23:41 | <@Derakon> | Heh. |
| 23:42 | <@Derakon> | Basically I want my generated textures to be part of a simple gradient, but I seem to be getting the size wrong because the gradient's wrapping. |
| 23:43 | | celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has joined #code |
| 23:43 | | Orthia [orthianz@Nightstar-abd01713.xnet.co.nz] has joined #code |
| 23:45 | <@Derakon> | Oh wait, the division I was doing was auto-promoting the array to float64 in Numpy. |
| 23:46 | <@McMartin> | -_- |
| 23:46 | <@Derakon> | Which would explain why specifying the datatype to Numpy wasn't accomplishing anything! |
| 23:53 | | shade_of_cpux is now known as cpux |
| 23:56 | <@Derakon> | Hm, making 1k gradient tiles like this is slower than I expected. Might have to go with something simpler. |
| 23:59 | <@Derakon> | Mm, time to go. |
| 23:59 | | Derakon [Derakon@Nightstar-1ffd02e6.ucsf.edu] has quit [[NS] Quit: Leaving] |
| --- Log closed Fri Oct 22 00:00:01 2010 |