| --- Log opened Mon Oct 09 00:00:59 2006 |
| 00:01 | | You're now known as TheWatcher[T-2] |
| 00:06 | | You're now known as TheWatcher[zZzZ] |
| 00:50 | | Janus [~Cerulean@Nightstar-10302.columbus.res.rr.com] has joined #code |
| 01:11 | < Janus> | Uh... if anyone's awake, may I ask a question please..? (this is probably a very easy one~) |
| 01:12 | < Chalcedon> | what about |
| 01:12 | | * Chalcedon is generally not very useful |
| 01:14 | < Janus> | Well... I was putting my game through some stress to see how well it would perform. However, whenever I tried to put more than 50 objects into a linked list, it would always cut it off at 50. |
| 01:15 | | * Chalcedon can't help with that sorry |
| 01:15 | < Janus> | S'alright~ |
| 01:16 | < Janus> | I figure it's just too much memory or something like that. |
| 01:19 | < Janus> | It does pretty good now with 50 characters on screen, running at 70 fps if they're standing still, and 16 if they're all moving. [/Bloat] |
| 01:33 | | ReivUni [~82d94c4d@Nightstar-29731.dsl.in-addr.zen.co.uk] has joined #Code |
| 01:57 | <@McMartin> | Janus: Probably less bloat and more "Linked Lists are expensive to sort, like we talked about before" |
| 01:59 | < Janus> | Actually, the sorting takes a very small fraction of the total time it's running. (the reason it's as low as 16 FPS is because of the interpolation functions that work on the height grayscale.) |
| 02:03 | <@McMartin> | Mm. |
| 02:06 | < Janus> | I'm guessing the computer won't allow me to allocate that many objects because it starts using swap space at around 50 to 70 entries. |
| 02:07 | <@McMartin> | ... how much memory do you have? |
| 02:07 | < Janus> | It's in the area of about 512, though I'd have to look it up to be certain. |
| 02:07 | < Janus> | *MB |
| 02:08 | <@McMartin> | And how big are these characters? |
| 02:08 | <@McMartin> | Something strange would seem to be going on. |
| 02:08 | <@McMartin> | After all, a complete 640x480 24-bit image is in the range of 1 MB. |
| 02:08 | <@McMartin> | I would guess the characters to be somewhat smaller than that. |
| 02:10 | < Janus> | The sprite sheets are about 256 to 1300 each, and every object has their own. |
| 02:10 | < Janus> | If that's not where the memory is going, then something /is/ pretty wrong. |
| 02:11 | <@McMartin> | OK, so first, two objects with the same graphics should be sharing the underlying data, at least if you're using SDL_Surface * pointers. |
| 02:11 | <@McMartin> | An SDL_Surface * pointer is, like, 4 bytes. |
| 02:12 | <@McMartin> | Width * Height / 256 should give you a guesstimate of the image memory cost, in kilobytes. |
| 02:12 | < Janus> | I know. It's a bit of a waste to have the same surface reloaded again and again, which is what I'm working on fixing right now. |
| 02:13 | <@McMartin> | Also, what's your intended screen size? |
| 02:13 | < Janus> | It's 640 by 480. |
| 02:14 | <@McMartin> | And you've got individual sprites more than twice the width of the screen? |
| 02:14 | < Janus> | Huh...? |
| 02:14 | <@McMartin> | The 1300-pixel wide sprites you mentioned above. |
| 02:14 | <@McMartin> | Or am I misinterpreting you? |
| 02:15 | < Janus> | Oh, I meant to say 1300 by 256. |
| 02:15 | <@McMartin> | OK, that does imply *something* else may be wrong, then; that's only 1.3MB even if you're using full 32-bit color. |
| 02:16 | <@McMartin> | You shouldn't be running out of memory after 50. |
| 02:16 | <@McMartin> | ... wait. Are you closing the files after you load? |
| 02:16 | <@McMartin> | (Or, well, using SDL_image to load with, which should also work) |
| 02:18 | < Janus> | The files don't stay open after they're loaded, I would assume. |
| 02:18 | <@McMartin> | You're using SDL_IMGload or whatever, right? |
| 02:18 | <@McMartin> | These are just .pngs? |
| 02:19 | < Janus> | (also, it should be said the game takes about ~90 MB, as there's already alot of memory being used for other things.) |
| 02:19 | <@McMartin> | Right, but malloc shouldn't start actually *failing* until you eat 2 GB in your Commit Charge. |
| 02:19 | < Janus> | No, these are .gifs. |
| 02:20 | <@McMartin> | ... In that case, it's 8-bit color max, which should cut your costs quite a bit in memory... |
| 02:20 | | * McMartin blinks |
| 02:20 | < Janus> | It's not that it fails to allocate the memory, but rather it doesn't even attempt it. |
| 02:20 | <@McMartin> | But there's also going to be a palette translation step every time it draws anything to screen. You may want to try doing an SDL_DisplayFormat or SDL_DisplayFormatAlpha on these after you load 'em |
| 02:21 | <@McMartin> | Unless you're also doing palette-shift animation, in the old-school style, in which case you basically have to pay the cost. |
| 02:21 | <@McMartin> | Er. Doesn't even attempt it? |
| 02:21 | <@McMartin> | Like, you refuse to load it, or SDL_IMGLoad fails? |
| 02:22 | < Janus> | Like, say, if the array of objects is less than 50, it'll work, yet it won't even attempt to put the objects into the list if it's above 50. |
| 02:23 | < Janus> | (actually, I've managed to get it to 70 characters on screen now) |
| 02:23 | <@McMartin> | I'm not being clear. Is this something you've deliberately put in, or is this a result of something mysteriously failing under the hood? |
| 02:24 | < Janus> | I haven't put this limit in. Outside of the 50 that defined the array size, and the 50 in the 'for' statement that loads them, there's no limit at all. |
| 02:25 | <@McMartin> | That sounds like a limit to me. |
| 02:25 | <@McMartin> | It's one that you'd have to recompile the code to deal with, etc. |
| 02:28 | < Janus> | I have been recompiling and rebuilding, but it still seems adament about attempting anything higher than 70. (I'm going to see just how large these objects are, hold on.) |
| 02:28 | <@McMartin> | sizeof won't do what you expect, I'm afraid. |
| 02:28 | <@McMartin> | sizeof is a compile-time thing. |
| 02:29 | <@McMartin> | C, in its infinite wisdom, has no real way of telling you how large a malloced array is, and C++ inherits this decision. |
| 02:30 | < Janus> | Ugh. |
| 02:31 | < Janus> | So it seems... |
| 02:31 | <@McMartin> | If you want to cheese through it, run it once with 10 objects, then once with 60, and divide the difference in memory usage by 50~ |
| 02:32 | | himi-heading-home is now known as himi |
| 02:34 | < Janus> | (80 - 20) / 50 come out to about 1.2 MB |
| 02:34 | <+himi> | Isn't C fun . . . |
| 02:35 | <@McMartin> | That's interesting. It implies that it's converting from GIF's 8-bit paletted to 24-bit or 32-bit TrueColor at some point. |
| 02:35 | <@McMartin> | (Well, less interesting if you have in fact done the DisplayFormat calls~)_ |
| 02:35 | < ToxicFrog|Stuff> | SDL_Image will do that transparently, I think, depending on how you invoke it. |
| 02:35 | < Janus> | It converts the surfaces to the same format as the screen. |
| 02:35 | < ToxicFrog|Stuff> | But it's been a while. I could be wrong. |
| 02:35 | <@McMartin> | Ah. |
| 02:36 | | * McMartin knows UQM doesn't do that, since it does in fact need to do palette animation |
| 02:37 | < Janus> | It supposedly makes it faster, as they don't have to fly around to convert, or ... something like that. |
| 02:37 | <@McMartin> | Yes. |
| 02:37 | <@McMartin> | Hence why I recommended it above. |
| 02:37 | <@McMartin> | Otherwise every time you did a blit it would have to do the color transform. |
| 02:45 | < Janus> | Alright, I've made it where they all use the same Surface. The limit has dissappeared, and the memory it used is practacally non-existent. |
| 02:45 | | * McMartin nods |
| 02:46 | <@McMartin> | What's the total number of sprite sheets you'll eventually have to deal with? |
| 02:46 | <@McMartin> | Because I suspect you're going to have to use some kind of texture manager to unload sheets that aren't needed at the moment and reload them before use. |
| 02:47 | < Janus> | At about 700 characters on screen, FPS is at 7. (3 frames per year if they move with the interpolation on). I'd have to say from 10 to 30, rough estimate. |
| 02:47 | <@McMartin> | Sounds like preloading should work fine, then. |
| 02:48 | | MahalWork [~Mahal@Nightstar-20316.worldnet.co.nz] has quit [Ping Timeout] |
| 02:51 | | MahalWork [~Mahal@Nightstar-11770.worldnet.co.nz] has joined #Code |
| 02:51 | | mode/#code [+o MahalWork] by ChanServ |
| 02:54 | < Janus> | I knew it wouldn't be that easy... |
| 02:55 | < Janus> | It can load 7000, but it won't even try to put them in the list if there's an even 100. |
| 02:57 | < ToxicFrog|Stuff> | Hzve you tried running it in the debugger and stepping through the list-add code to see where it fails? |
| 02:57 | < Janus> | 99 won't work either, 98 does, 97 doesn't, 96 does, and 95 loads... 60(?) Yeah, that would be a good idea. |
| 02:59 | < Janus> | ... um... |
| 03:00 | | * Janus appends the 'int n' with a ' = 0' eh-heh... |
| 03:01 | < ToxicFrog|Stuff> | ... |
| 03:03 | | * Janus gets his dunce hat and sits in the corner. |
| 03:03 | <+himi> | um |
| 03:08 | < Janus> | Thanks for the help Mr. M and Mr. Frog~ |
| 03:08 | | Janus [~Cerulean@Nightstar-10302.columbus.res.rr.com] has quit [Quit: 7%] |
| 03:11 | <+himi> | Hm |
| 03:12 | <@McMartin> | Oh, right, that doesn't get flagged as a warning unless you turn on optimization |
| 03:14 | | * himi eyes himself |
| 03:14 | <+himi> | I need to make sure I keep my hand in with C |
| 03:17 | | * himi was thinking that n there would be zeroed by the compiler, but of course that only happens with static variables |
| 03:27 | <@McMartin> | Or if you're in debug mode. |
| 03:28 | < ReivUni> | ...That's an inconvinient debug trick. |
| 03:28 | < ReivUni> | As it would work fine in debug, but not in real code? o.o |
| 03:31 | <@McMartin> | That kind of thing happens all the time. |
| 03:43 | < ReivUni> | Evil. |
| 03:45 | <@McMartin> | Note that what usually happens that in debug code it ends up crashing (because a pointer is pointing at "0", which is NULL, except when it's not, don't even get me started), while in release it kind of stumbles along scribbling over random bits of memory. |
| 03:47 | <+himi> | . . . . I'm fairly sure gcc doesn't make that kind of change if you use -g |
| 03:48 | <@McMartin> | When running in gdb, at least, it seems to not have garbage in variables... |
| 03:48 | <@McMartin> | gcc won't do any dataflow checks without at least -O1, though. |
| 03:48 | | * himi nods |
| 03:48 | <+himi> | I don't think it /can/ |
| 03:49 | <+himi> | Hm |
| 03:49 | <@McMartin> | No, it'll do "use before init" warnings, at the very least. |
| 03:50 | <+himi> | Well, I just made a test program and ran it both outside and inside gdb, and got the same behaviour |
| 03:50 | <+himi> | This is gdb 6.4 |
| 03:51 | | * McMartin shrugs |
| 03:51 | <@McMartin> | OK |
| 03:51 | <@McMartin> | May have been a MSVC thing, then |
| 03:51 | <+himi> | Yeah, that's the sort of brokenness I'd expect from them |
| 03:51 | <@McMartin> | Brokenness? It's perfectly standards-compliant. |
| 03:51 | <@McMartin> | That behavior, anyway. |
| 03:52 | <@McMartin> | The compiler is permitted to call in a nuclear strike on your grandma if you use-before-def and still be standards-compliant. |
| 03:52 | < ReivUni> | ...*snrk* |
| 03:53 | <+himi> | Yeah, but changing behaviour based on whether you're debugging or not is stupid |
| 03:53 | <@McMartin> | Repeatability for bugs costs cycles, we can't have that in release code, etc. |
| 03:56 | <+himi> | Doing something differently, particularly when it results in /consistent/ behaviour in the debugged code but inconsistent behaviour in production code, makes debugging vastly more difficult |
| 03:57 | < ReivUni> | The purists would argue you shouldn't be using a debugger~ |
| 03:57 | <@McMartin> | himi: The bug, if anything, is that the release code isn't pre-initializing everything. |
| 03:58 | <@McMartin> | Unrepeatable behavior isn't going to help the debugger any either, after all. |
| 03:59 | | ReivUni [~82d94c4d@Nightstar-29731.dsl.in-addr.zen.co.uk] has quit [Quit: Aaaaand off to do that 'learning' thing.] |
| 04:00 | <+himi> | Yeah, the bug in the code being debugged is obviously a lack of initialisation, but the fact that the debugger /is/ initialising it for you hides the nature of the error, unless it does something like initialise it with some kind of magic value |
| 04:01 | <@McMartin> | For pointers, NULL is a magic value. |
| 04:01 | <+himi> | I'm complaining about the fact that the debugger is basically lying about the behaviour of the code |
| 04:01 | | * himi nods |
| 04:01 | <+himi> | And for ints, it's not |
| 04:02 | <@McMartin> | But "The behavior of the code" is completely undefined. |
| 04:03 | <+himi> | As far as the debugger is concerned, the behaviour of the code should be defined by the behaviour of the code when it's /not/ run under the debugger |
| 04:03 | <+himi> | That's the /point/ of the debugger |
| 04:04 | <+himi> | The compiler can pick nits about the nature of the language, but the debugger is there to show the actual behaviour of the code |
| 04:05 | <@McMartin> | We clearly have different meanings of "actual behavior" here, or possibly "the code". |
| 04:06 | <@McMartin> | Running in and out of the debugger, yes |
| 04:06 | <@McMartin> | But once you recompile code which depends on what was in the stack's memory block beforehand, all bets are off |
| 04:08 | <+himi> | um |
| 04:09 | <+himi> | All I'm saying is that the behaviour of the code under the debugger should reflect the behaviour of the code on the bare metal/vm/whatever |
| 04:10 | <+himi> | I wouldn't have thought that was a controversial assertion |
| 04:12 | <@McMartin> | That part we agree |
| 04:12 | <@McMartin> | That's not what I was saying MSVC did, however. |
| 04:12 | <@McMartin> | I was saying that it had different behavior when compiling, effectively, with and without -g |
| 04:12 | <@McMartin> | Which produces two entirely different binaries. |
| 04:12 | <+himi> | Ah |
| 04:13 | <+himi> | That's . . . not so clear cut, but still bloody stupid, to my mind, unless you're using magic values to flag the uninitialised variables for an integrated debugger, or something similar |
| 04:14 | <@McMartin> | And what sparked this irritation to begin with was the fact that the bug we're talking about compiles without complaint in -g but flags a lint-style warning with -O1 |
| 04:15 | <@McMartin> | Or did the last time I got burned by it, anyway. |
| 04:15 | <+himi> | Well, -g is orthogonal to -O |
| 04:16 | <@McMartin> | As of 3.3, yes. |
| 04:16 | <+himi> | Hm |
| 04:16 | <@McMartin> | I know in 3.2 attempting to debug -g -O code was asking for Hilarity (tm) |
| 04:16 | <@McMartin> | (Disclaimer: not actually hilarious at all) |
| 04:16 | <+himi> | How so? |
| 04:16 | <@McMartin> | "Oh, hey, this function is being passed garbage!" |
| 04:16 | <@McMartin> | *step* |
| 04:17 | <@McMartin> | "Oh, hey, that argument now suddenly has the right value" |
| 04:17 | <+himi> | Odd |
| 04:19 | <+himi> | Wait, this is any optimised code? Rather than -O0? |
| 04:20 | | Syloq [Syloq@NetAdmin.Nightstar.Net] has quit [Connection reset by peer] |
| 04:22 | <@McMartin> | I believe the flags for the program in question were -g -O1, but function arguments aren't exactly prone to Common Subexpression Elimination. |
| 04:29 | | * himi suspects that may have something to do with the debugging format used being incapable of dealing operly with optimised binaries |
| 04:30 | <+himi> | I think the fix in 3.3 was changing the default to DWARF2 |
| 04:46 | <@McMartin> | That would probably do it |
| 04:57 | | MahalWork [~Mahal@Nightstar-11770.worldnet.co.nz] has quit [Quit: The computer, she is snoring now.] |
| 04:57 | | Mahal [~Mahal@Nightstar-11770.worldnet.co.nz] has joined #Code |
| 04:57 | | mode/#code [+o Mahal] by ChanServ |
| 05:20 | | ReivClass is now known as Reiver |
| 05:24 | | Thaqui is now known as ThaquiWork |
| 05:26 | | MahalWork [~Mahal@Nightstar-11770.worldnet.co.nz] has joined #Code |
| 05:26 | | mode/#code [+o MahalWork] by ChanServ |
| 05:30 | | ThaquiWork is now known as Thaqui |
| 05:43 | | Mahal [~Mahal@Nightstar-11770.worldnet.co.nz] has quit [Quit: The computer, she is snoring now.] |
| 05:54 | | Thaqui is now known as ThaquiWork |
| 06:17 | | McMartin [~mcmartin@Nightstar-9379.dsl.pltn13.pacbell.net] has quit [Quit: bbiab] |
| 06:31 | | Mahal [~Mahal@Nightstar-11770.worldnet.co.nz] has joined #Code |
| 06:31 | | mode/#code [+o Mahal] by ChanServ |
| 06:52 | | EvilSLEPLord [althalas@Nightstar-17046.a80-186-184-83.elisa-laajakaista.fi] has quit [Ping Timeout] |
| 06:57 | | Chalcedon is now known as ChalcyShopping |
| 07:03 | | Chalcy [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has joined #code |
| 07:03 | | mode/#code [+o Chalcy] by ChanServ |
| 07:04 | | EvilSLEPLord [althalas@Nightstar-17046.a80-186-184-83.elisa-laajakaista.fi] has joined #code |
| 07:05 | | ChalcyShopping [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has quit [Ping Timeout] |
| 07:13 | | Mahal is now known as MahalAFK |
| 07:13 | | MahalWork is now known as MahalPC |
| 07:30 | | EvilSLEPLord is now known as EvilDarkLord |
| 07:49 | | You're now known as TheWatcher |
| 07:55 | | Chalcy [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has quit [Ping Timeout] |
| 07:56 | | Chalcedon [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has joined #code |
| 07:57 | | mode/#code [+o Chalcedon] by ChanServ |
| 08:11 | | MahalAFK is now known as Mahal |
| 09:51 | | Mahal is now known as MahalZzz |
| 09:57 | | himi is now known as himi-heading-home |
| 10:10 | | Chalcedon is now known as ChalcyZzz |
| 11:14 | | ThaquiWork is now known as Thaqui |
| 13:14 | | ChalcyZzz [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has quit [Ping Timeout] |
| 13:53 | | Reiver is now known as ReivZzz |
| 13:58 | | EvilDarkLord is now known as EvilEaterOfHeadsLord |
| 16:13 | | EvilEaterOfHeadsLord is now known as EvilDarkLord |
| 17:24 | | You're now known as TheWatcher[afk] |
| 18:45 | | You're now known as TheWatcher |
| 18:56 | | ChalcyZzz [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has joined #code |
| 18:57 | | ChalcyZzz is now known as Chalcedon |
| 19:05 | | MahalZzz is now known as Mahal |
| 19:45 | | Mahal is now known as MahalAFK |
| 20:09 | | EvilDarkLord is now known as EvilNiNiLord |
| 21:29 | | MahalAFK is now known as Mahal |
| 22:05 | | Janus [~Cerulean@Nightstar-10302.columbus.res.rr.com] has joined #code |
| 22:28 | | Mahal is now known as Magrat |
| 23:05 | | ReivZzz is now known as Reiver |
| 23:10 | | Janus [~Cerulean@Nightstar-10302.columbus.res.rr.com] has quit [Quit: ~] |
| 23:23 | | Chalcedon is now known as ChalcyPhone |
| 23:26 | | ChalcyPhone is now known as Chalcedon |
| 23:26 | | Thaqui is now known as ThaquiWork |
| 23:31 | | Chalcedon is now known as ChalcyGone |
| 23:31 | | ChalcyGone is now known as Chalcedon |
| 23:33 | | You're now known as TheWatcher[T-2] |
| 23:36 | | You're now known as TheWatcher[zZzZ] |
| 23:41 | | Magrat is now known as Mahal |
| 23:43 | | Vornicus-Latens is now known as Vornicus |
| --- Log closed Tue Oct 10 00:00:59 2006 |