#pentagram@irc.freenode.net logs for 3 May 2003 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage


[00:16:01] <-- Dominus has left IRC ("enough for now")
[01:31:00] <-- DarkeZzz has left IRC (brunner.freenode.net irc.freenode.net)
[01:34:06] --> Kirben has joined #pentagram
[01:34:06] --- ChanServ gives channel operator status to Kirben
[01:38:00] <-- wjp has left IRC ("Zzzz...")
[01:55:47] --> DarkeZzz has joined #pentagram
[06:48:37] --> sbx has joined #pentagram
[07:32:39] --> Colourless has joined #Pentagram
[07:32:39] --- ChanServ gives channel operator status to Colourless
[08:48:05] <-- sbx has left IRC ("X-Chat [1.6.4]")
[08:56:22] <-- Colourless has left IRC ("l8tr")
[11:05:58] <-- Kirben has left IRC (Excess Flood)
[11:06:07] --> Kirben has joined #pentagram
[11:06:07] --- ChanServ gives channel operator status to Kirben
[12:02:58] --> wjp has joined #pentagram
[12:02:58] --- ChanServ gives channel operator status to wjp
[12:04:48] --> Colourless has joined #Pentagram
[12:04:53] --- ChanServ gives channel operator status to Colourless
[12:08:38] * wjp updates and builds :-)
[12:10:02] <Colourless> i don't do makefiles :-)
[12:10:09] <wjp> I noticed :-)
[12:10:19] <wjp> luckily I do :-)
[12:10:53] <wjp> yay! graphics!
[12:10:56] <Colourless> darke does, but he doesn't share :-)
[12:11:04] * wjp tsk-tsk's at Darke
[12:11:11] <wjp> making me do all that extra work
[12:11:26] <wjp> (i.e., adding one whole filename to module.mk... ;-) )
[12:11:32] <DarkeZzz> All that extra work? All you had to do was add a single extra line! *grin*
[12:11:34] <Colourless> ok, now that you see it works. there is something missing. npcs aren't added to the per glob items lists
[12:12:03] <wjp> rendering appears to take 55ms here
[12:12:07] <Colourless> not a 'huge' problem, but it is something that needs to be fixed at some stage :-)
[12:12:27] <wjp> I didn't really do anything with NPCs yet
[12:12:39] <Colourless> optimizations on or off?
[12:12:49] <Colourless> with optimzations off it's pretty slow for me
[12:12:58] <wjp> -g -O2
[12:13:10] <Colourless> ok, what cpu then?
[12:13:21] <wjp> athlon xp 1800+ (or whatever they call it)
[12:13:28] <wjp> default resolution, non-fullscreen
[12:13:46] <Colourless> odd, faster cpu than me
[12:13:49] <Colourless> yeah well, you can't make it fullscreen yet
[12:14:19] <Colourless> regardless object sorting is less than optimized. need to add in gross object culling
[12:14:33] <Colourless> to do that i need to use the per glob lists, but npcs aren't in them
[12:15:59] <Colourless> ideally i would want a 'getObjectList(int cx, int xy) function in CurrentMap
[12:16:37] <Colourless> that of course is simple to add
[12:16:46] * DarkeZzz wonders if the --enable-3dnow and --enable-mmx would make it faster. -O3 should anyway. *grin*
[12:16:48] <Colourless> s/getObjectList/getItemList/
[12:16:59] --- DarkeZzz is now known as Darke
[12:17:02] --- ChanServ gives channel operator status to Darke
[12:17:32] <Colourless> they 'might' make some things faster, but i don't think that much
[12:18:00] <wjp> well, 58% of CPU usage is in X itself here
[12:18:08] <wjp> pentagram is only taking up about 33%
[12:18:35] <Colourless> most odd. probably software emulation of the surface or some such is causing pain
[12:19:04] <Darke> Weird. 75%-85% is pentagram here, X never gets above 15%.
[12:19:22] <Colourless> 99% pentagram here :-)
[12:19:54] * Darke has athlon 1ghz, -O2 --enable-3dnow --enable-mmx.
[12:20:11] <Darke> Colourless: Only 'cause windows doesn't bother to split the numbers up. *grin*
[12:20:52] <Darke> Hmm... Is there a config option to make it fullscreen?
[12:22:58] <Colourless> can't make it fullscreen yet
[12:24:08] <Colourless> http://www.users.on.net/triforce/usage.png
[12:25:50] <wjp> hm, running exult in 640x400 pushes X to 60% too
[12:26:02] <wjp> (exult itself stays below 10%)
[12:26:23] <Darke> Weird. I don't get more then 70% cpu usage in total running exult.
[12:26:49] <wjp> um, neither do I... 60% + 10% = 70% :-)
[12:27:23] <Darke> Ahh. But you've got 80% more cpu then I do... or something. *grin*
[12:27:46] <wjp> which bitdepth are you using?
[12:27:53] <wjp> and which resolution?
[12:28:19] <Darke> X is running at 24bit/1600x1200 with nvidia's drivers for a geforce2ultra.
[12:28:35] <Colourless> i'm using 1024x768 32 bit here, not that me being in windows is much help to you (funny thing called directdraw)
[12:29:31] <wjp> 1600x1200x24 here too (nvidia drivers for a tnt2 ultra)
[12:29:37] <Colourless> i'm sure if i was using a windib sdlsurface things wouldn't be good
[12:29:38] <Darke> exult runs at 800x600x2xSaI.
[12:30:24] <wjp> 320x200 with 2x point scaling here
[12:31:49] * wjp hits X
[12:31:54] <Darke> Just tried it then with a realtively recent exult (before DrCode added the new party flocking stuff), exult sits around 25-40%, X between 6% and 12%.
[12:32:25] <wjp> I wonder what's causing X to take up 60% here
[12:33:15] <Darke> Hmm... actually just got exult/X to spike up to 50%/15%, but that's the highest I've seen it.
[12:33:23] <wjp> would having a tnt2ultra instead of geforce2 make a difference?
[12:33:45] <Colourless> i really wouldn't think so
[12:34:07] <Colourless> 2d cores of the cards would be virtually identical
[12:34:09] <Darke> Dunno. It's not doing any 3d stuff.
[12:34:41] <wjp> Darke: you already upgraded to X 4.3.0 right?
[12:35:29] <Darke> wjp: Yup. But I still was getting reasonable numbers (never above 20%) for X long before I upgraded.
[12:35:56] <Darke> Sure you've got the 'nvidia' rather then 'nv' drivers installed for X?
[12:36:27] <wjp> yeah :-)
[12:36:52] <Darke> Given we're running pretty much the same OS, I'm really not sure what the difference might be. *grin*
[12:38:18] <wjp> I think I'll go upgrade X and see what happens
[12:38:25] <Darke> You've run 'opengl-update nvidia'?
[12:38:36] <wjp> think so
[12:38:48] <wjp> at least opengl things run at acceptable framerates
[12:39:33] <wjp> hm, I haven't upgraded to the latest nvidia drivers yet either
[12:39:50] <Darke> Fairly standard cflags? Mine are: CFLAGS="-march=i686 -O3 -pipe"
[12:40:24] <wjp> hm, mine are -O2
[12:41:08] <wjp> no, wait
[12:41:14] <wjp> that's the make.globals one
[12:41:15] <Colourless> oh no, i forgot to commit the ChangeLog, that's done now, and i've slightly changed the timing info output. it now includes some extra info
[12:41:27] <wjp> make.conf sets it to "-march=athlon-xp -mcpu=athlon-xp -O3 -pipe"
[12:43:50] <Darke> Weird. Only other thing I can think of is kernel parmeters, such (as mtrr 'n such) not being turned on, and thus pessamising things.
[12:44:26] <Colourless> well, just check my new updated timing stuff, and tell me exactly the times it's giving you for sorting and painting
[12:44:34] <Darke> WIll do.
[12:44:48] <Colourless> i get about 20 for sorting and 8 for painting
[12:45:03] <wjp> sort 11, paint 5
[12:45:09] <wjp> rendering time, 55 :-)
[12:45:16] <wjp> (somehow that doesn't add up :-) )
[12:45:21] <Colourless> well, it aint pentagram :-)
[12:47:12] * Darke gets multiple definitions of ItemSorter. We obviously 'fixed' the missing .o file in different places. *grin*
[12:47:37] <wjp> see, you should've committed it :-)
[12:48:19] <Darke> Completely unstable between 19/20 and 8/9. Which apparently adds up to around 38-40. *grin*
[12:48:40] * Darke pokes his tongue at wjp.
[12:49:19] <Colourless> nice to know similar cpus on different platforms are giving the same results :-)
[12:49:44] <wjp> and faster CPUs are giving worse results? :-)
[12:50:18] <Colourless> the adding up is the total time it has taken to do 1 complete loop. it's not just actual rendering
[12:50:25] <Darke> At rest my system's using aroung 5% cpu to do background tasks and such. If I was *really* keen I'm sure I could speed it up a few more frames. *grin*
[12:51:03] <Colourless> sort is how long it's taken to iterate and sort the items, paint obviously is how long it took to paint the items that are on screen, to the rendersurface
[12:52:12] <wjp> hm, I might as well upgrade my kernel too while I'm at it
[12:52:24] * wjp notices he still hasn't 'really' upgraded to 2.4.20
[12:52:27] <wjp> (just emerged it)
[12:52:51] <Darke> Have fun! *grin*
[12:54:36] <Colourless> well, Darke, you know, wjp will now try anything to get his systems speed up. It's totally unacceptable for people with slower cpus, one of them even uses windows, to run pentagram faster than him :-)
[12:54:56] <Darke> Colourless: *grin*
[12:55:12] <wjp> lol
[12:55:40] <wjp> don't distract me! I'm trying to speed up my system here! ;-)
[12:58:03] * Darke snickers.
[12:59:50] <Darke> The only difference between -O2 and -O3 is the numbers are much more stable, staying almost only on 19/20 and 8/9, rather then regularly varying off them.
[13:03:05] * Darke waits for wjp to try to compile pentagram with -O9 -mmake-it-faster-dagnabbit!
[13:04:33] <wjp> pentagram doesn't really seem to need that... X does, however :-)
[13:05:03] <Darke> *nodnod* Your X seems to *really* need it! *grin*
[13:07:51] <wjp> k, built new kernel... brb after a hopefully quick reboot :-)
[13:07:53] <-- wjp has left IRC ("brb")
[13:12:46] <Colourless> i think he's died :-)
[13:16:52] <Darke> Oooh! Can I inherit exultbot then?
[13:17:22] <Colourless> hmm, that i would have to consider
[13:17:26] * Darke just thinks wjp forgot to recompiler compile the nvidia kernel drivers when he recompiled his kernel, along with the alsa-sound drivers if he was using those too. *grin*
[13:17:40] <Darke> s/recompiler /re/
[13:17:55] <Colourless> :-)
[13:18:27] * Darke blinks. Optimising for an i686 made pentagram *slower*? How... odd.
[13:21:28] <Colourless> hm, i think i might play with the platform options
[13:29:04] <Colourless> heh, the default 'Blend' platform option (supposed to be best for all) was fastest for me, but only slightly over pentium, which was fractionally faster than pentium pro
[13:30:48] <Darke> Hmm... all in all, nothing really speeds pentagram up at this end either. So does this mean we've got very, very good code? Or just plain bad code? *grin*
[13:30:59] <Colourless> :-)
[13:31:37] <Colourless> i think we are problem memory access limited
[13:31:55] <Colourless> one of those new pentium 4s might run pentagram very well
[13:32:33] <Darke> Or a dual-channel ddr machine.
[13:33:36] * Darke wonders if he can be bothered to drag one of the new staff P4's at uni out of the closet and compile pentagram on that?
[13:33:47] --> wjp has joined #pentagram
[13:33:47] --- ChanServ gives channel operator status to wjp
[13:33:52] <Colourless> he lives
[13:33:56] <wjp> barely :-)
[13:33:59] <Colourless> or he's undead
[13:34:11] <wjp> anyway, new kernel and new nvidia drivers
[13:34:17] <Colourless> he talks, so it's unlikely he's undead
[13:35:00] <Darke> Yay! Forgot to recompile your nividia kernel drivers did you? *grin*
[13:35:23] <wjp> *cough*.. umm... no... I decided to delay that until after two reboots.. *cough* :-)
[13:35:58] * Darke snickers.
[13:36:21] <wjp> but that wasn't the main problem... I think one of my HDs partition table isn't entirely right
[13:36:35] <wjp> so I can't use LBA32 for lilo, and grub fails altogether
[13:36:42] <Colourless> question, why do (part of) your video card drivers need to be compiled into your kernel?
[13:36:42] <wjp> and of course I forgot about that when running lilo :-)
[13:37:35] <wjp> because they need to talk to the hardware?
[13:37:48] <Darke> They don't need to be compiled into it, just loaded as a module. It's just that you need to remember to recompile them, so they'll have the correct linkage to your current kernel version.
[13:37:58] <wjp> yay!
[13:38:01] <Colourless> i see
[13:38:02] <wjp> 35ms, 30FPS
[13:38:30] <wjp> although the numbers are indeed quite jumpy
[13:38:32] <Colourless> much better for you
[13:39:10] <Darke> wjp: For me too. The more optimisations you add, the more stable the numbers seem to get for some weird reason.
[13:39:12] <wjp> X 20%, pentagram 77%
[13:39:37] <Colourless> wjp: just curious, what sort of memory do you have
[13:39:55] <wjp> 512Mb of ddr sdram or something
[13:40:33] * Darke has 'normal' sdram.
[13:41:57] <Darke> Hmm... looks like turning on profiling worked, 32/12 is quite a bit slower. *grin*
[13:42:10] <Darke> A fairly solid 16fps.
[13:42:49] <Colourless> i have PC133
[13:42:51] * Darke tries to remember the magic commands to get gprof to tell him what he wants.
[13:43:12] <Darke> Me too, two sticks of 512Meg.
[13:43:38] <Colourless> quite possibly why our systems performace in pentagram is so similar :-)
[13:43:58] <Darke> Yup.
[13:44:00] <Colourless> as i said, i thought that the sorting and painting code was mostly memory limited
[13:44:13] <Colourless> wjp with ddr would be much faster than us, and he is :-)
[13:44:50] <Colourless> of course i have no proof of such things
[13:45:13] <wjp> I still kind of wonder what caused the earlier slowness
[13:45:40] <wjp> hm, interesting... Darke: MTRR was indeed disabled in my old kernel
[13:46:35] <Darke> wjp: Mine too. Had to upgrade kernel to upgrade drivers. *grin* I'm pretty sure it wasn't that for me.
[13:47:19] <wjp> hm, it seems I still haven't upgraded gcc to 3.2.2
[13:47:51] <Darke> Slowcoach. *grin*
[13:50:28] <Darke> ItemSorter::AddItem got called 26 million times in 50 seconds? *blinkblink* Maybe I'm reading this wrong...
[13:50:52] <Colourless> that wouldn't surprise me
[13:50:58] <Darke> It was apparently around 10% of execution time.
[13:51:02] <wjp> 17K times per frame
[13:51:40] <Darke> SoftRenderSurface::Paint got galled half a million times in the same timeframe, but was 15% of the execution time.
[13:51:46] <Colourless> [21:44] <Colourless> regardless object sorting is less than optimized. need to add in gross object culling
[13:52:12] <Colourless> all the objects get passed to ItemSorter::AddItem() it then culls them
[13:52:19] <Darke> Item::setupLerp was also called around 26 million times, and was 6.5% of execution time.
[13:52:43] * Darke nods.
[13:52:47] <Colourless> setupLerp() is called before AddItem() is called
[13:53:15] <wjp> I wonder what would happen to these rendering times if we add in scaling
[13:53:21] <Darke> The only other biggie is SoftRenderSurface::Fill32, which was only called about a thousand times, but used 7.7% of execution time.
[13:53:35] <wjp> that's once per frame I guess?
[13:53:39] <Colourless> yeah
[13:54:23] <Colourless> i was actually thinking writing some asm for Fill32 for us x86 users :-)
[13:54:33] <Colourless> it's not efficent
[13:54:48] <Darke> Any other profiling bits anyone's interested in before I recompile it back to an acceptable speed? *grin*
[13:54:50] <Colourless> problem is we can't use memset
[13:55:19] <Colourless> so, was only SoftRenderSurface::Paint being called?
[13:55:29] <Colourless> if so, then i forgot to uncomment some code
[13:56:11] <Darke> BaseSoftRenderSurface was being called.
[13:56:27] <Colourless> lines 548 and 549 of world/ItemSorter.cpp, uncomment them, recompile
[13:56:30] <Darke> Am I looking for something in specific? *grin*
[13:56:47] <wjp> couldn't we add some specializations of Fill32 that can use memset?
[13:57:13] <Colourless> well, yeah, in some cases, but not always
[13:57:22] <Colourless> memset fills chars
[13:57:42] <wjp> yeah, and we need uint32's usually
[13:57:50] <Colourless> uint32 or uint16
[13:58:05] <wjp> unless we fill with grays
[13:58:08] <Darke> Wow. Got a full *extra* fps under profiling with that change. *grin*
[13:58:18] <wjp> which is probably quite common
[13:58:29] <Colourless> generally, if we are filling white, black or grey with 32 bit surface, then memset can be used
[13:58:40] <Colourless> memset and grey will not work with 16 bit sadly
[13:59:02] <wjp> yeah
[13:59:08] <Darke> It's now down to about 31/10 at 17fps.
[13:59:14] <wjp> can't be helped :/
[13:59:27] <wjp> does SDL have any well-optimized fill code?
[13:59:46] <Colourless> no idea. don't think so
[13:59:58] * Colourless loads sdl sources
[14:03:03] <wjp> does look like they're using some assembly there
[14:03:10] <Colourless> yeah they do
[14:03:14] <wjp> for the SDL_memset4 macro
[14:03:18] <Colourless> SDL_memset4
[14:03:39] <Colourless> for gnu only
[14:03:39] <Colourless> grr
[14:04:00] <wjp> but that's just an asm syntax issue probably?
[14:04:10] <Darke> SoftRenderSurface::Fill32 is at 14.5%... ItemSorter::AddItem at 19.2%, Item::setupLerp at 13%, SoftRenderSurface::Paint is at 5%, SoftRenderSurface::PaintNoClip is at 19%... but pentagram ran twice as long this time. I think that usecode execution is messing up my timing.
[14:04:28] <wjp> why not just kill usecode execution then?
[14:04:41] <Colourless> gnu's inline assembler is unusual. msvc's inline assembler format is fairly normal
[14:04:44] * Darke is doing so at the moment. *grin*
[14:04:58] <wjp> Colourless: that depends on your perspective :-)
[14:05:24] <wjp> (note that I don't know either inline asm format)
[14:05:45] <wjp> I must say the SDL_memset4 macro looks rather arcane, though :-)
[14:05:49] <Colourless> msvc is like this
[14:05:52] <Colourless> __asm {
[14:06:01] <Colourless> opcode reg0, reg1
[14:06:08] <Colourless> opcode reg0, reg1
[14:06:11] <Colourless> };
[14:06:16] <Colourless> and so on
[14:06:23] <wjp> that sounds fairly normal, yes
[14:06:41] <Colourless> i probably would have written the code to compile with nasm
[14:07:23] <wjp> hm, SDL_memset4 is just repeating a store, right?
[14:07:33] <Colourless> yeah, that's the fastest way
[14:08:14] <wjp> hm, getting hungry; I'll go get some lunch; brb
[14:11:39] <wjp> b
[14:13:07] <Colourless> that wasn't long
[14:13:32] <wjp> I was just getting it, not eating it :-)
[14:14:09] <wjp> (i.e., walk downstairs, get food, walk back upstairs :-) )
[14:14:16] <Colourless> :-)
[14:15:23] <wjp> anyway... let's go fix some stuff...
[14:15:28] <wjp> so NPCs need to be added to CurrentMap
[14:17:17] <Darke> Here we go. Got some reasonable numbers now. *grin* The top few times for a runtime of 155 seconds...
[14:17:28] <Darke> % cumulative self self total
[14:17:31] <Darke> time seconds seconds calls s/call s/call name
[14:17:31] <Darke> 21.88 33.95 33.95 85676886 0.00 0.00 ItemSorter::AddItem(Item*)
[14:17:31] <Darke> 20.11 65.16 31.21 1352340 0.00 0.00 SoftRenderSurface<unsigned>::PaintNoClip(Shape*, unsigned, int, int)
[14:17:31] <Darke> 15.30 88.90 23.74 4098 0.01 0.01 SoftRenderSurface<unsigned>::Fill32(unsigned, int, int, int, int)
[14:17:31] <Darke> 13.77 110.26 21.36 85676886 0.00 0.00 Item::setupLerp(int, int, int)
[14:18:14] <Colourless> only 85 million calls :-)
[14:18:15] <Darke> 8.31 123.16 12.90 4098 0.00 0.02 World::SetupDisplayList(ItemSorter*)
[14:18:15] <Darke> 5.80 132.16 9.00 6613577 0.00 0.00 SoftRenderSurface<unsigned>::Blit(Texture*, int, int, int, int, int, int)
[14:18:15] <Darke> 4.73 139.50 7.34 409800 0.00 0.00 SoftRenderSurface<unsigned>::Paint(Shape*, unsigned, int, int)
[14:18:34] <Darke> *Only*. *grin*
[14:19:51] <Darke> Everything else is pretty negligible, the next 12 range from 2% down to 0.02% and the rest are immiterial. *grin*
[14:21:46] <Colourless> simple:
[14:21:47] <Colourless> inline void memset32(void *buf, uint32 val, uint32 len)
[14:21:47] <Colourless> {
[14:21:47] <Colourless> __asm {
[14:21:47] <Colourless> mov ecx, len
[14:21:47] <Colourless> mov edi, buf
[14:21:49] <Colourless> mov eax, val
[14:21:51] <Colourless> repne stosd
[14:21:54] <Colourless> };
[14:21:56] <Colourless> }
[14:22:33] <Colourless> len is the number of dwords, not the number of bytes
[14:22:47] <wjp> yeah, I understand
[14:23:07] <wjp> since ecx gives the number of repeats
[14:24:46] <wjp> the 'mapnum' field in an item is only interesting for NPCs isn't it?
[14:24:53] <Colourless> yes
[14:25:10] <Colourless> contains garbage for other items
[14:25:34] <Colourless> or at least, data of unknown use, if it is indeed used at all :-)
[14:25:43] <wjp> :-)
[14:26:46] <wjp> ok, now NPCs are added, but I need to make sure they aren't written back to the Map object.. *sigh*
[14:26:57] <Colourless> :-)
[14:27:20] <Colourless> FLG_IN_NPC_LIST perhaps?
[14:27:44] <wjp> or maybe a more general NO_MAP_OBJECT
[14:28:01] <Colourless> of course that flag might be for other objects that are posessed by a npc
[14:28:37] <Colourless> you could just to the easy, if (item_num < 256) continue; :-)
[14:28:49] <wjp> speaking of which... I don't think I handle inventories at all currently
[14:35:46] <Colourless> if i 'really' wanted to, i could write a mmx memset64 :-)
[14:37:12] <wjp> I don't think we'll really need that :-)
[14:37:21] <wjp> I don't think I'll see the difference between 32 and 64 bit pixels ;-)
[14:37:48] <wjp> (besides, this old X version doesn't even support a 64 bit colourdepth ;-) )
[14:37:57] <Colourless> well you can fill 2 32 bit pixels at a time , or 4 16 bit pixels :-P
[14:40:52] <wjp> ok, I'll commit this NPC-in-list code I guess
[14:42:19] <wjp> it might even work... *cough*
[14:59:17] <Colourless> i think it would be a good idea if World::assignObjId() checked to make sure the object didn't already have an ObjId
[14:59:40] <wjp> oh, I didn't do that yet?
[14:59:45] <Colourless> no
[15:00:30] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[15:00:38] <wjp> if (obj->getObjId() != 0xFFFF) return obj->getObjId();
[15:00:40] <wjp> ?
[15:01:29] <Colourless> no
[15:01:44] <Colourless> should also check to see if objects[obj->getObjId()] == obj
[15:01:59] <wjp> that would be an assert
[15:02:05] <Colourless> who knows, obj->getObjId() might return an invalid ObjId
[15:02:53] <wjp> it shouldn't :-)
[15:04:03] <wjp> hm, what would you guess the complexity of the item sorter is?
[15:04:53] <Colourless> honestly, i don't know.
[15:05:13] <wjp> I'm thinking that if a 'normal' amount of objects is passed to it, the runtime would probably decrease quite a lot
[15:05:28] <Colourless> yeah it should
[15:05:50] <Colourless> there normally wouldn't be many objects on a 320x240 screen
[15:05:59] <wjp> since it's most likely slower than linear, it'll probably put it under a millisecond
[15:06:46] <Colourless> only overlapping objects are sorted, but there is a fair amount of setup involved for each item
[15:07:21] <Colourless> problem is much of the setup is done before the objects are culled for being offscreen
[15:07:23] <wjp> ok, so it would roughly be linear for reasonable amounts of objects then?
[15:07:57] <wjp> but when using per-'glob' item lists that changes?
[15:08:39] <Colourless> yeah, i can cull objects before passing them to addItem
[15:09:32] <Colourless> you only call addItem for items the could reasonably be on screen
[15:09:34] <wjp> ok, sounds like the sorting time won't be too much of a problem in the 'final' version then
[15:10:22] <Colourless> with old glob eggs were culled before they were expanded
[15:11:08] <wjp> ok, that speeds things up enormously :-)
[15:11:52] <wjp> I wonder how slow running usecode is
[15:12:07] <wjp> (and how many processes will typically be running)
[15:13:18] <Colourless> well, i'm sure without the opcodes being printed it will be fairly fast :-)
[15:13:28] <wjp> that should help, yes :-)
[15:13:29] <Colourless> the code isn't hugely complex in most cases
[15:13:48] <wjp> but it looks so cool to see opcodes scrolling by! ;-)
[15:14:03] <Colourless> :-)
[15:14:27] <Colourless> loading pentagram for me takes 'ages' because it has to wait for all the silly unable to create item message to be printed
[15:14:40] <wjp> yes, same here :-)
[15:14:59] <wjp> maybe I should write some egg stubs? :-)
[15:15:10] <Colourless> sounds like an idea :-)
[15:15:53] <Colourless> or at least, comment out that message :-)
[15:16:10] <wjp> oh, btw, any idea what the 'reagent' item class means exactly?
[15:16:21] <Colourless> another thing, pentagram should auto select the map to start on, being the map npc 1 is currently on
[15:16:23] <wjp> my guess would be something like randomly respawning objects
[15:16:43] <Colourless> yeah probably
[15:16:52] <Colourless> there are a number of 'spawn' type eggs
[15:17:03] <wjp> how far did you have to go away for reagents to respawn?
[15:17:11] <wjp> you didn't have to leave the map, right?
[15:17:13] <Colourless> honestly, i can't remember
[15:17:21] <wjp> no... you don't
[15:17:39] <wjp> I remember running back and forth in Stone Cove to get blackmoor :-)
[15:18:20] <Colourless> :-)
[15:18:28] <Colourless> ah necromancy
[15:18:45] <Darke> Probably just respawns on enterFastArea.
[15:19:27] <wjp> anyway, something to check out once we have egg handling up and running
[15:20:07] <wjp> let's see... I think I'll create an Egg class
[15:20:09] <Colourless> well, i'm sure it will show itself pretty obviously
[15:20:15] <wjp> UnkEgg, MonsterEgg, TeleportEgg would inherit from that
[15:20:25] <wjp> GlobEgg won't, I think
[15:20:51] * Darke of course would have been nasty and kept a flag scheduled to be changed in X minutes, that would only respawn them on enterFastArea should it be cleared. *grin*
[15:22:25] <Colourless> they might have done that
[15:24:47] <Darke> Hmm... which class would we be looking at for a reagent? What are the reagents anyway? *grin*
[15:25:29] <Colourless> shpdisp should tell you
[15:26:03] <Darke> Hmm... ERTHREAG looks to be one class, but it only has a ::look() function.
[15:26:30] <Darke> Which does the obvious convoluted if/else thing to popup the name. *grin*
[15:27:37] <Colourless> i'm guessing then that the 'reagent' class doesn't have anything special involved other than it stacks
[15:28:30] <wjp> the respawning could be egg-handled of course
[15:28:51] <Colourless> yeah it would be
[15:29:16] <Darke> Ahh. ETHEREAG has look() use() enterFastArea() and leaveFastArea().
[15:30:04] <Colourless> numbers please :-)
[15:30:20] <Darke> Eye of Newt/Bat Wing/Snake Skin/Dragon Blood/Jar of Newt Eyes. That one look like the one you want? *grin*
[15:30:44] <Darke> Usecode class 399 (018F ETHEREAG)
[15:31:01] <wjp> ok, the number of "Couldn't create item" message is very small now
[15:31:09] <wjp> (but non-zero, strangely)
[15:33:09] <Colourless> well you have missed something
[15:33:12] <Darke> "push global butthead" Umm...
[15:33:23] <wjp> it seems to be having trouble creating some magic weapons
[15:33:26] <wjp> and one item of magic armour
[15:33:39] <Colourless> maybe you should add extra info to the error message
[15:33:48] <wjp> (shapes 64, 816,817,818,819,820)
[15:35:00] <Colourless> all have an equip type specification
[15:36:24] <wjp> family 15
[15:37:44] <Colourless> i missed out some of the names maybe
[15:38:26] <wjp> where did you get the names from?
[15:39:46] <Colourless> u8.exe, where else :-)
[15:49:38] <wjp> I added family names for the unnamed ones in old's shpdisp
[15:49:49] <wjp> (Family10, ..., Family15)
[15:49:56] <wjp> just so they show up :-)
[15:50:24] <Darke> Always useful. *grin*
[15:50:39] <Colourless> :-)
[16:40:53] <Darke> wjp: Yes, I just noticed that typo earlier too, and corrected it. You know, you really should stop committing changes that I've made, before I've had the chance to. *grin*
[16:48:16] <wjp> making me do double work _again_? ;-)
[16:48:35] * Darke looks innocent.
[17:27:06] --- Darke is now known as DarkeZzz
[17:36:03] <wjp> hm, whatever it was I did to make X run faster makes Fallout in Wine run a lot smoother too :-)
[17:36:20] <Colourless> :-)
[17:37:20] <wjp> bbl, dinner
[17:37:25] <Colourless> k
[17:41:22] <Colourless> i should go
[17:41:23] <-- Colourless has left IRC ("casts invisibility")
[19:47:24] --> twentyminutes has joined #pentagram
[19:47:32] <twentyminutes> Hello.
[19:50:51] <twentyminutes> Is everyone idle?
[20:10:05] <-- twentyminutes has left IRC ()
[23:19:25] <-- wjp has left IRC ("Zzzz...")