| --- Log opened Sun May 16 00:00:04 2010 |
| 00:06 | <@Vornicus> | eh. |
| 00:08 | <@Vornicus> | In any case, art required to include Seafarers: Ships, Pirate; C&K: red die, event die, 25 cards, 3 card backs, 3 tokens, 3 city layouts, 6 knights, 15 buildings, either 2 or 7 barbarians depending, merchant. |
| 00:14 | < Tarinaky> | Someone talking about Settlers? |
| 00:14 | < Tarinaky> | Isn't the Pirate just a recoloured ship? |
| 00:14 | <@Vornicus> | Technically yes |
| 00:15 | <@Vornicus> | Which makes Seafarers actually even easier to do art for. |
| 00:15 | <@Vornicus> | Then there's T&B which I don't even /know/ what's in there. |
| 00:17 | < Tarinaky> | T&B? |
| 00:18 | < Tarinaky> | Oh. You missed something btw. |
| 00:18 | <@Vornicus> | DOubtless |
| 00:18 | < Tarinaky> | K&C has that larger black ship for the Invaders. |
| 00:18 | < Tarinaky> | The invader count-down. |
| 00:19 | <@Vornicus> | That's the 2 or 7 barbarians |
| 00:19 | < Tarinaky> | Oooo. |
| 00:19 | <@Vornicus> | 2 if I want a static track + a ship, 7 if I want a separate image for each distance |
| 00:20 | < Tarinaky> | I see. |
| 00:21 | <@Vornicus> | Though I did miss the metropolis tokens - the "tokens" i mentioned are actually the commodities, which I thought circles looked better than cards. |
| 00:21 | < Tarinaky> | Ah. |
| 00:21 | < Tarinaky> | K&C is too complicated. You're a braver man than me for implementing it. |
| 00:22 | <@Vornicus> | K&C imo /needs/ automation. |
| 00:23 | < Tarinaky> | Eh. I still don't think it's fun. |
| 00:24 | <@Vornicus> | T&B, by the way, is Traders & Barbarians - nine variants in one box, including the Fishermen (now including a lake), the Rivers (now with two rivers), the Event Cards, and some others. |
| 00:25 | | Serah [Z@26ECB6.A4B64C.298B52.D80DA0] has quit [Ping timeout: 121 seconds] |
| 00:27 | | celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has quit [[NS] Quit: *hums* Can't stay now!] |
| 00:28 | | Reiv[Graduate] [orthianz@Nightstar-9f94dbd6.xnet.co.nz] has joined #code |
| 00:30 | <@Vornicus> | T&B also needs rather a lot of miscellaneous crap in it. |
| 00:39 | < Tarinaky> | Ahh. |
| 00:39 | < Tarinaky> | The Event Cards being the dice replacement right? |
| 00:41 | <@Vornicus> | Yes |
| 00:41 | < Tarinaky> | Well, you're best off implementing T&B variant by variant. |
| 00:42 | < Tarinaky> | As a set of optional rules... Rather than a fixed varient like K&C is. |
| 00:42 | < Tarinaky> | :/ |
| 00:42 | < Tarinaky> | Then again. You probably knew this already. |
| 00:42 | < Tarinaky> | As an aside: Am I the only one who doesn't like those cards? |
| 00:43 | <@Vornicus> | I've never actually played with them |
| 00:43 | < Tarinaky> | Ah. Well. It's fun to play with them once or twice just for the novelty. |
| 00:43 | < Tarinaky> | But I view them as strictly inferior :/ |
| 00:43 | <@Vornicus> | But they're one of the previously-published things that also shows up in T&B |
| 00:44 | < Tarinaky> | We also had the problem that you don't have dice to pass around the table so it becomes a little harder to keep track of who'se turn it is if you get side-tracked. |
| 00:44 | <@Vornicus> | heh |
| 00:45 | | Reiv[Graduate] [orthianz@Nightstar-9f94dbd6.xnet.co.nz] has quit [Client closed the connection] |
| 00:45 | < Tarinaky> | IIRC we ended up doing a weird thing with angling the cards to face the player who 'drew' them. |
| 00:45 | < Tarinaky> | In the deader pile. |
| 00:48 | <@Derakon> | Hrm. Something has gone horribly wrong in my attempt to tweak the player's physics to behave more like Super Metroid Samus's. |
| 00:48 | <@Derakon> | Now he can't jump. |
| 00:48 | | You're now known as TheWatcher[T-2] |
| 00:49 | <@Derakon> | Oh, wait, that's it. |
| 00:49 | <@Derakon> | I had the sign on the initial vertical component of jump velocity wrong. |
| 00:49 | <@Derakon> | So hitting the spacebar caused the player to slam into the ground and instantly stop. |
| 00:49 | < Tarinaky> | Hehe. Sign Errors <3 |
| 00:52 | <@Derakon> | Night, TW. |
| 00:53 | | Reiv[Graduate] [orthianz@Nightstar-9645a61d.xnet.co.nz] has joined #code |
| 00:53 | | You're now known as TheWatcher[zZzZ] |
| 01:34 | | gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has quit [[NS] Quit: Z?] |
| 01:40 | <@McMartin> | Tarinaky: ITYM >3 |
| 01:54 | | Reiv[Graduate] [orthianz@Nightstar-9645a61d.xnet.co.nz] has quit [Client closed the connection] |
| 02:02 | | Reiv[Graduate] [orthianz@Nightstar-9645a61d.xnet.co.nz] has joined #code |
| 02:42 | <@Derakon> | I got some speed and acceleration numbers from some Super Metroid TASers, with the idea of making my protagonist's motion similar to Samus's. |
| 02:42 | <@Derakon> | These numbers are all expressed in pixels per frame, and the SNES of course runs at 60 frames per second. |
| 02:43 | <@Derakon> | Of course, Super Metroid's world is smaller-resolution than mine. IIRC each block is 16px in SM, and they're 50px in Jetblade. |
| 02:43 | <@Derakon> | And Jetblade only updates physics 30 times per second, though display updates as fast as possible. |
| 02:44 | <@Derakon> | So it seems to me that to get a conversion of a velocity from SM to Jetblade, I should multiply by 50/16 * 2. |
| 02:44 | <@Derakon> | Does that sound right? |
| 02:44 | <@Vornicus> | Should. Accel will be harder. |
| 02:45 | <@Derakon> | Yeah, I noticed that acceleration seemed really slow. |
| 02:45 | <@McMartin> | Don't display updates as fast as possible. |
| 02:45 | <@McMartin> | Cap it at 100FPS or so. |
| 02:45 | <@Vornicus> | 50/16*4 I think |
| 02:46 | <@Vornicus> | Yes, that's the right number. |
| 02:46 | <@Derakon> | McM: Pygame's buffer swap will block based on the refresh rate of the monitor, I think. |
| 02:46 | <@Derakon> | Certainly I'm naturally capping at 60FPS in a simple scene. |
| 02:47 | <@McMartin> | Derakon: Yeah, not all cards do that right. |
| 02:47 | <@McMartin> | This was why BEat Hazard was making people's cards suddenly start hitting 85C and stuff |
| 02:47 | <@McMartin> | Becuase it would suddenly stop hearing about VSync |
| 02:47 | <@Derakon> | Ah. |
| 02:47 | | * Derakon makes a /todo. |
| 02:48 | | Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has quit [Connection closed] |
| 02:48 | <@McMartin> | THat *might* have been his library, but better safe than sorry, imo |
| 02:48 | <@Derakon> | Of course, I'm using software rendering right now, so the graphics cards should be safe~ |
| 02:49 | <@McMartin> | (When I triggered it in FRAPS, it went from 60 FPS stable, to choking a little and dropping to about 20, then suddenly rocketing to 950) |
| 03:06 | | * Derakon eyes Jetblade, which is giving him 30FPS in a very simple scene. |
| 03:07 | <@Derakon> | I appear to be spending about a quarter of my time filling the screen with black. |
| 03:07 | <@Derakon> | This only happens once per frame, though. |
| 03:15 | <@Derakon> | My other major timesuck is blitting images. |
| 03:15 | <@Derakon> | It seems weird that drawing is sucking up so much time given that I'm not drawing all that much stuff. |
| 03:16 | <@Derakon> | Mm...though it is true that each block is contained in a 100x100 image even though most of them aren't much larger than 50x50. |
| 03:16 | <@Derakon> | I guess that could mean I'm working...oh, about three times harder to draw terrain then I theoretically need to. |
| 03:17 | | celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has joined #code |
| 03:43 | | Reiv[Graduate] [orthianz@Nightstar-9645a61d.xnet.co.nz] has quit [Client closed the connection] |
| 03:51 | | Reiv[Graduate] [orthianz@Nightstar-9645a61d.xnet.co.nz] has joined #code |
| 04:00 | | Reiv[Graduate] [orthianz@Nightstar-9645a61d.xnet.co.nz] has quit [Client closed the connection] |
| 04:14 | | Reiv[Graduate] [orthianz@Nightstar-9645a61d.xnet.co.nz] has joined #code |
| 04:14 | | Reiv[Graduate] [orthianz@Nightstar-9645a61d.xnet.co.nz] has quit [Client closed the connection] |
| 04:22 | | Reiv[Graduate] [orthianz@Nightstar-9645a61d.xnet.co.nz] has joined #code |
| 04:46 | | celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has quit [[NS] Quit: *hums* Can't stay now!] |
| 04:58 | | gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has joined #code |
| 05:53 | < Reiv[Graduate]> | hm. Coding a regex parser. |
| 05:53 | < Reiv[Graduate]> | This should be... fun |
| 05:53 | <@Vornicus> | whee |
| 06:05 | | * Derakon quickly implements a continuous zoom mode, determines that it completely nukes his performance. |
| 06:05 | <@Derakon> | Go go 1FPS~ |
| 06:06 | <@Vornicus> | Heh. |
| 06:06 | <@Vornicus> | That kind of shit /requires/ opengl. |
| 06:07 | <@Derakon> | Yeah. |
| 06:09 | <@Derakon> | Hm. Switching to OpenGL would also mean that I don't have to be picky about my draw order. |
| 06:09 | <@Derakon> | I can just vary the Z depth of objects slightly so the background is actually behind the foreground instead of just being drawn before it. |
| 06:10 | < Reiv[Graduate]> | that would be a good idea, yes. |
| 06:10 | <@Vornicus> | Actually there is a situation where the draw order matters |
| 06:10 | <@Vornicus> | Transparency. |
| 06:11 | <@Derakon> | Howso? |
| 06:11 | <@Vornicus> | A transparent thing sets the z distance for the fragment; this means that anything with a greater z distance that comes after the transparent object won't be rendered. |
| 06:12 | <@Derakon> | Um, I didn't follow that. |
| 06:12 | < Reiv[Graduate]> | I did. |
| 06:12 | < Reiv[Graduate]> | Um. |
| 06:12 | <@Vornicus> | OpenGL decides whether to render a polygon in a particular place based on the z distance of the closest thing so far - transparent or not. |
| 06:13 | < Reiv[Graduate]> | AKA: It doesn't render items behind the first thing it 'sees'. |
| 06:13 | <@Derakon> | Ah, so if you render front-to-back and there's a transparent thing close to the camera, then things behind it aren't rendered. |
| 06:13 | < Reiv[Graduate]> | If it's a transparent object, though... |
| 06:14 | <@Vornicus> | What this means is, if you render a transparent thing, and then try to render a wall behind it /after/, then the wall won't get rendered, only the transparent thing. You can see this in some games - sometimes a thing will pass behind a transparent object and be invisible back there. |
| 06:14 | <@Derakon> | Mm, and given that I know that every single one of my terrain tiles has a transparent border around it... |
| 06:15 | <@Derakon> | ...I wonder, would OpenGL be able to cleanly handle baking the terrain tiles into a massive texture? |
| 06:15 | <@Derakon> | And would it help any? |
| 06:17 | <@Vornicus> | It'd probably be a better idea - bake 512x512 or 1024x1024 chunks, then bake a fresh one each time you need a new one, they'll tile more cleanly that way. |
| 06:17 | <@Vornicus> | But why do your terrain tiles have a transparent border anyway? It might turn out easier to get your graphics model to use a slightly different setup than your physics model. |
| 06:18 | <@Derakon> | They have a transparent border because I need to be able to treat tiles of different styles the same way, and different terrain types have different visual boundaries. |
| 06:19 | <@Derakon> | For example, the jungle/grass terrain has grass that extends outside the tile's 50x50 physical region, while the hotzone/techpipe terrain matches its 50x50 region exactly. |
| 06:19 | <@Derakon> | If I had tightly-cropped the techpipe images, then I'd have to use different drawing offsets for them compared to the jungle/grass images. |
| 06:19 | <@Derakon> | I could put drawing offsets into the config somewhere, but then I have to do special math every time I come up with a new terrain type. |
| 06:20 | <@Derakon> | So basically, thus far it's been more hassle than it's worth. |
| 06:20 | <@Vornicus> | I mean, if I were doing this I'd have my graphics prebaked in the studio, with the grass, for instance, making its own tile. |
| 06:20 | <@Derakon> | Ah. |
| 06:20 | <@Derakon> | That explodes the number of tile types tremendously. |
| 06:20 | <@Vornicus> | Somewhat harder doing it pcg, I grant, but still possible. |
| 06:21 | <@Derakon> | Here's the current selection of map tile types for the jungle/grass terrain: http://derakon.dyndns.org/~chriswei/games/jbrl/models/block11.png |
| 06:21 | <@Derakon> | Keep in mind that any time you see a grass edging, it overlaps the 50x50 boundary in both directions. |
| 06:22 | <@Derakon> | Also, pcg? |
| 06:22 | <@Vornicus> | procedural content generation |
| 06:22 | <@Vornicus> | ...why is there grass on the ceiling? |
| 06:23 | < Alek> | moss? |
| 06:23 | < Reiv[Graduate]> | Because it's a jungle tile :D |
| 06:23 | <@Derakon> | Because this place is just that conducive to growth. |
| 06:25 | < Reiv[Graduate]> | And it was straightforward? >_> |
| 06:26 | <@Derakon> | Heh. |
| 06:43 | | Orth [orthianz@Nightstar-798213f0.xnet.co.nz] has joined #code |
| 06:44 | | Derakon is now known as Derakon[AFK] |
| 06:45 | | Reiv[Graduate] [orthianz@Nightstar-9645a61d.xnet.co.nz] has quit [Ping timeout: 121 seconds] |
| 07:14 | | AnnoDomini [annodomini@Nightstar-075c0a5b.adsl.tpnet.pl] has joined #code |
| 07:14 | | mode/#code [+o AnnoDomini] by Reiver |
| 08:43 | | Vornicus is now known as Vornicus-Latens |
| 09:07 | <@AnnoDomini> | Hm. Can you use 1 and 0 instead of true/false when assigning bools in C++? |
| 09:14 | < Tarinaky> | McMartin: What does ITYM mean? |
| 09:15 | <@AnnoDomini> | I think you meant. |
| 09:17 | <@McMartin> | Man, Haskell. |
| 09:18 | | * McMartin works on a system to automatically solve Traffic Jam puzzles. |
| 09:18 | <@McMartin> | Lazy evaluation means exceptions are optional entirely too often |
| 09:19 | <@McMartin> | "Just return this value. Sure, it's theoretically part of some huge other computation but those bits won't be referenced in the failure case so they don't happen." |
| 09:20 | <@McMartin> | This then lets me write |
| 09:20 | <@McMartin> | isValid = (/= Nothing) . decompose |
| 09:36 | < Tarinaky> | Sign Errors >3 is not more sensical than Sign Errors <3... :/ |
| 09:36 | < Tarinaky> | *no more |
| 09:39 | | You're now known as TheWatcher |
| 09:40 | <@AnnoDomini> | Arguably, you could have left the not. |
| 09:52 | <@McMartin> | It's a sign error, see~ |
| 09:52 | <@AnnoDomini> | More like a character flaw~ |
| 09:53 | <@McMartin> | "Few people realize that Jamie has actually performed surgery with a forklift." |
| 10:29 | | Alek [omegaboot@Nightstar-c5f3565b.il.comcast.net] has quit [[NS] Quit: ] |
| 10:57 | | celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has joined #code |
| 11:09 | | Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has joined #code |
| 12:23 | < celticminstrel> | ...so Chrome decides to crash while restoring my tabs, thus losing all of them. :| |
| 12:26 | <@AnnoDomini> | That's not gneiss. |
| 12:35 | < Tarinaky> | Gaaah. I can't remember what an eigenvalue is :/ |
| 12:36 | < celticminstrel> | That makes two of us. |
| 12:37 | <@AnnoDomini> | It's a vectory property, IIRC. |
| 12:37 | < celticminstrel> | As for the tabs, I think I've restored them all (by delving through the history). |
| 12:37 | < celticminstrel> | Um, it's matrices. |
| 12:37 | < Tarinaky> | AnnoDomini: It's on my vector&matrices paper. |
| 12:37 | < celticminstrel> | Eigenvalue is a property of matrices, I thought. |
| 12:37 | < Tarinaky> | I can't find any reference to it in the text but I know it's there :/ |
| 12:37 | <@AnnoDomini> | Vectors are just one-dimensional matrices. |
| 12:37 | < Tarinaky> | I just can't see it. |
| 12:37 | < Tarinaky> | Eigenvalues and Eigenvectors. |
| 12:40 | <@AnnoDomini> | Hmm. Can preprocessor directives in C++ be nested? |
| 12:41 | < Tarinaky> | I believe so. I'd recommend trying a test case. |
| 12:42 | <@AnnoDomini> | I'm getting funky results. |
| 12:43 | < Tarinaky> | Eugh... I have an exam on this tomorrow afternoon and I'm still so rusty I can hear creaking :/ |
| 12:44 | < celticminstrel> | If you mean if/then, yes they can. |
| 12:47 | <@AnnoDomini> | I'm getting it work. |
| 12:47 | < celticminstrel> | Huh? |
| 12:47 | <@AnnoDomini> | Still not sure why it things DEBUG_ANAL is not defined. |
| 12:47 | <@AnnoDomini> | *thinks |
| 12:47 | < celticminstrel> | Maybe show me? |
| 12:48 | <@AnnoDomini> | One moment. |
| 12:49 | <@AnnoDomini> | http://pastie.org/962461 |
| 12:50 | <@AnnoDomini> | Oh, I just forgot using namespace std; |
| 12:53 | | Serah [Z@26ECB6.A4B64C.298B52.D80DA0] has joined #code |
| 13:15 | <@AnnoDomini> | Hm. C++ compilers will optimize integer division by a multiple of 2 into shifts, right? |
| 13:16 | < Tarinaky> | They should do. |
| 13:17 | < Tarinaky> | If you're explicitly wanting to perform shifts it may be easier to read if you explicitly perform shifts though. |
| 13:19 | <@AnnoDomini> | No, I'm just worried about processing time. |
| 13:20 | < Tarinaky> | Compiler optimisations are compiler specific. They're only garenteed to be correct. |
| 13:21 | < Namegduf> | I'd argue worrying about the compiler not doing it would be premature optimisation. |
| 13:21 | < Namegduf> | It should, I'd think. |
| 13:22 | < Namegduf> | And I'm sure I've heard of it doing so. |
| 13:22 | < Tarinaky> | Any C compiler that -doesn't- optimise arithmetic isn't a very good compiler. |
| 13:24 | <@AnnoDomini> | Well, I'm dealing with genetic algorithms. Testing it requires the unoptimized user code to produce something in a time considered adequate. |
| 13:26 | < Tarinaky> | I'd call it premature optimisation. It doesn't take that long, on a modern box to do arithmetic the 'long' way. |
| 13:27 | < Tarinaky> | Unless you're doing a lot of it. |
| 13:28 | <@AnnoDomini> | 'Doing a lot of [arithmetic]' fits into genetic algorithms. |
| 13:29 | < Tarinaky> | Well it should perform multiplication and division through factorisation. |
| 13:29 | < Tarinaky> | And similar tricks. |
| 13:29 | <@AnnoDomini> | Okay. I wasn't sure, I asked. |
| 13:29 | < Tarinaky> | But it's compiler specific because, of course, some Processors have such tricks implemented with special OP codes themselves. |
| 14:53 | <@ToxicFrog> | AnnoDomini: performance is nothing until you can prove you don't have it. |
| 14:58 | < Namegduf> | That's a little extreme; common sense at the point of designing things is important, as is complexity. But worrying about things which can safely be pulled out and replaced with a more optimised version later if benchmarks show it inoptimal... |
| 15:00 | | Searh [Z@26ECB6.A4B64C.298B52.D80DA0] has joined #code |
| 15:01 | < Namegduf> | I wonder if every pattern has an antipattern. |
| 15:02 | < Namegduf> | (Or multiple) |
| 15:02 | < Namegduf> | I can't think of anything which isn't bad beyond a certain point. |
| 15:02 | | Serah [Z@26ECB6.A4B64C.298B52.D80DA0] has quit [Ping timeout: 121 seconds] |
| 15:04 | <@AnnoDomini> | I see. |
| 15:05 | < gnolam> | The rules of optimization apply. |
| 15:05 | < Namegduf> | But, yeah, pretty sure that's one of the examples of compiler optimisation I always hear about. And if it benchmarks otherwise... |
| 15:05 | < gnolam> | 1st rule of optimization: don't do it. |
| 15:05 | < Namegduf> | Pull one line out, slot in another. |
| 15:05 | < gnolam> | 2nd rule of optimization (experts only): don't do it /yet/. |
| 15:06 | < gnolam> | If and when you discover you have a performance problem, it's time to dig out the profiler. |
| 15:14 | < gnolam> | (Of course, profiling is actually less than trivial, but one needs to learn it sooner or later) |
| 15:36 | | Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has quit [[NS] Quit: This computer has gone to sleep] |
| 18:18 | | Stryker [c0mand@Nightstar-bec1add2.dyn.optonline.net] has joined #code |
| 18:24 | | Stryker [c0mand@Nightstar-bec1add2.dyn.optonline.net] has quit [[NS] Quit: IRcap 8.6 ] |
| 19:23 | | Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has joined #code |
| 21:00 | | AbuDhabi [annodomini@Nightstar-728ec168.adsl.tpnet.pl] has joined #code |
| 21:00 | | Searh is now known as Serah |
| 21:02 | | AnnoDomini [annodomini@Nightstar-075c0a5b.adsl.tpnet.pl] has quit [Ping timeout: 121 seconds] |
| 21:08 | | Vornicus-Latens is now known as Vornicus |
| 21:21 | | Vornicus is now known as Finerty |
| 21:23 | | Tarinaky [Tarinaky@Nightstar-8800f89b.adsl.virginmedia.net] has quit [Ping timeout: 121 seconds] |
| 21:34 | | shade_of_cpux [Moo@Nightstar-20a84089.dyn.optonline.net] has joined #code |
| 21:36 | | Tarinaky [Tarinaky@Nightstar-e5712c38.adsl.virginmedia.net] has joined #code |
| 21:37 | | cpux [Moo@Nightstar-20a84089.dyn.optonline.net] has quit [Ping timeout: 121 seconds] |
| 21:37 | | shade_of_cpux is now known as cpux |
| 22:20 | | PinkFreud [WhyNot@NetworkAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds] |
| 22:42 | | PinkFreud [WhyNot@NetworkAdministrator.Nightstar.Net] has joined #code |
| 22:50 | | AbuDhabi [annodomini@Nightstar-728ec168.adsl.tpnet.pl] has quit [[NS] Quit: Gnafler.] |
| 23:07 | | Derakon[AFK] is now known as Derakon |
| 23:49 | | You're now known as TheWatcher[T-2] |
| 23:54 | | You're now known as TheWatcher[zZzZ] |
| --- Log closed Mon May 17 00:00:06 2010 |