--- Log for 25.12.117 Server: hobana.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 3 days and 21 hours ago 00.09.14 Quit JdGordon (Ping timeout: 260 seconds) 00.16.05 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 00.31.47 Quit ZincAlloy (Quit: Leaving.) 00.39.08 # <__builtin> hmm, licensing actually might be a slight issue 00.40.27 # <__builtin> the apogee code is all GPLv2 or later, which is fine 00.42.19 Quit JdGordon (Ping timeout: 264 seconds) 00.47.21 # <__builtin> but the Build engine code is under a custom BUILDLIC.txt, which prohibits commerical distribution 00.53.03 Quit dys (Ping timeout: 248 seconds) 00.54.48 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 01.09.33 *** Saving seen data "./dancer.seen" 01.15.59 # I don't want dirty hack in the vuprintf 01.17.04 # <__builtin> ah, yes 01.17.18 # <__builtin> I don't think it actually needs it, to be honest 01.18.18 # <__builtin> that was more for quake, actually 01.18.19 Quit michaelni (Ping timeout: 264 seconds) 01.18.36 # One secret: if you format a string and it doesn't understand the format, the formatter is output unchanged 01.19.28 # <__builtin> by the way, are you fine with everything being enabled in vuprintf? 01.19.37 # that means after formatting, the %f s will be left there do with whatever you like. it won't read the parameters out either 01.19.56 # I don't care. I just didn't want to enable more that was being used. 01.21.06 # it probably won't add too much because it uses one formatter for all compatible types 01.24.03 # <__builtin> as for licensing, the Build engine source can remain under the original BUILDLIC, right? 01.24.47 # <__builtin> if someone wants to make a commerical fork, they'll just have to know that part is not GPL-compatible and remove it 01.26.12 Join dys [0] (~dys@tmo-123-62.customers.d1-online.com) 01.31.03 # I can't answer that one 01.31.15 Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) 01.33.48 # <__builtin> for now I'll leave it as-is until someone complains :) 01.38.51 Quit Moarc (Ping timeout: 256 seconds) 01.47.55 Quit jhMikeS (Ping timeout: 256 seconds) 01.48.05 Join Moarc [0] (~chujko@a105.net128.okay.pl) 01.55.59 Quit pamaury (Ping timeout: 260 seconds) 03.03.03 Quit Moarc (Ping timeout: 252 seconds) 03.06.02 Join Moarc [0] (~chujko@a105.net128.okay.pl) 03.09.34 *** Saving seen data "./dancer.seen" 04.35.45 Join Piece_Maker [0] (~Acou_Bass@host-89-241-247-251.as13285.net) 04.38.30 Quit Acou_Bass (Ping timeout: 272 seconds) 04.38.30 Nick Piece_Maker is now known as Acou_Bass (~Acou_Bass@host-89-241-247-251.as13285.net) 04.46.47 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 04.47.15 # __builtin: does duke have a lot of floating point? 04.47.29 # <__builtin> very little 04.47.46 # <__builtin> I think the engine is completely integer-based 04.48.18 # <__builtin> well, almost 04.48.42 # <__builtin> the sound code uses some floats, though 04.49.14 # <__builtin> there's probably enough in there to slow it down a bit 04.50.54 # I wonder if it would help if it were compiled with softfp or hard would help for arm v6 04.51.28 # <__builtin> have you tried it on the gigabeast? 04.51.44 # no, that's why i"m wondering 04.51.50 # I was going to though 04.52.12 # the vfp should be enabled already 04.53.24 # where are the gcc opts set for that? 04.53.43 # <__builtin> apps/plugins/sdl/sdl.make 04.53.53 # <__builtin> SDLFLAGS 04.55.41 # that will set it for the game itself and the SDL lib? 04.56.05 # <__builtin> yes, duke is built with SDLFLAGS as well 04.57.02 # <__builtin> our gcc doesn't support hard float, does it? 04.58.36 # I don't know. I don't know why the vfp was enabled (not by me) if it didn't 04.59.51 # I tried softfp which puts the arguments in normal registers not straight into fp registers 05.00.32 # <__builtin> -mfloat-abi=hard gives, "unimplemented" 05.02.10 # it got through with softfp 05.02.30 # <__builtin> yeah, but will that give any benefit? 05.03.06 # yeah, it's still hw floating point instructions but arguments are passed with the standard ABI (r0-r3, [sp]) 05.03.55 # <__builtin> interesting, I'll test 05.04.32 # which output file should I disassemble to verify? 05.04.57 # <__builtin> apps/plugins/sdl/progs/duke3d/Game/src/audiolib/mv_mix.c 05.06.24 # <__builtin> hmm, running the output with softfp gives a freeze 05.07.06 # <__builtin> looks like it is generating FPU instructions, though 05.09.37 # yep, they're there 05.09.38 *** Saving seen data "./dancer.seen" 05.10.02 # maybe I should double check the setup 05.10.29 # <__builtin> does it run on your gigabeat? 05.10.51 # I didn't know you had a beast 05.11.09 # <__builtin> I don't, only ipod6g 05.11.42 # does that have vfpu? 05.12.04 # * __builtin should probably check... 05.12.36 # beast is working fine 05.13.44 # <__builtin> where is VFP support enabled for the beast? 05.15.07 # in it's crt0 05.15.13 # it's working fine 05.15.48 # firmware/target/arm/imx31/crt0.S 05.16.50 # <__builtin> the VFP isn't mentioned in the datasheet 05.16.52 # line 286 05.17.05 # <__builtin> (for the ipod6g's CPU) 05.17.44 # oh, no idea about that one 05.17.53 # <__builtin> ARM926EJ-S 05.18.18 # well, it definitely works if there's an enabled vfp 05.19.06 # maybe the same coprocessor instruction works across all? 05.19.17 # <__builtin> I imagine any speed benefit would be hard to see on the beast 05.19.31 # seems to be getting an FPS boost but can't say if it's that doing it. need a control test 05.19.43 # <__builtin> you mean the code to enable the VFP? 05.20.20 # yeah, I don't know how on that SoC 05.20.50 # <__builtin> I don't think it even has any floating-point hardware 05.24.46 # it can definely be enabled for armv6 anyway 05.25.24 # <__builtin> yes, as long as the hardware exists, at least 05.26.10 # <__builtin> apparently the "F" in a core name signifies VFP presence 05.26.55 # <__builtin> the beast has an arm1136jf-s core, while my ipod6g has an arm926ej-s 05.30.23 # <__builtin> jhMikeS: do you have any other device that can run duke? 05.31.26 # vfp is worth about 3 fps at the game start (just sit there and wait for FPS to settle) 05.31.51 # there's also dips due to sounds that don't happen with the vfp enabled 05.32.28 # I haven't tried gigabeat-f but that has the same screen size as the beast and isn't nearly as powerful 05.33.04 # <__builtin> the reason I'm interested is that someone has told me that it crashes on a device I don't have 05.33.15 # hmmm actually vfp looks like it's getting 4-5 fps inscrease 05.35.41 # which one? 05.35.51 # <__builtin> the Zen X-Fi 05.36.06 # I don't have that 05.36.29 # <__builtin> anything else that can run duke? 05.38.40 # the 2nd most powerful thing I have right now would be gig-f, otherwise it's sandisk players, some PP and coldfire targets 05.39.34 # <__builtin> I'd be interested to see how it runs on PP or sandisk players with a small screen 05.39.41 # <__builtin> could you test on those? 05.40.14 # <__builtin> in the meantime I'll see why it won't build for m68k 05.41.59 # for armv6 definely add SDLFLAGS += -mfloat-abi=softfp 05.41.59 # SDLFLAGS += -mfloat-abi=softfp 05.43.10 # I'll try gigabeat f then 05.43.47 # oh, yeah, sure 05.44.05 # don't expect much though the screens are much smaller 05.44.12 # which seems to help a lot 05.44.30 # <__builtin> honestly I'm expecting it to crash 05.46.02 # <__builtin> could I add that flag in tools/configure instead? 05.46.42 # maybe but really it shouldn't be in the core. I think you brought FP libs into the core which bloated the hell out of it 05.49.16 # h10-20 gb, h10-6gb, e200-v1, clip-v1 (ha), fuze-v2 ? 05.49.52 # <__builtin> what's the question? 05.50.09 # any preference? 05.50.14 # <__builtin> it won't run on the clip 05.50.18 # <__builtin> no greylib support 05.51.20 # <__builtin> try either h10, e200v1, and fuzev2 in any order you prefer 05.54.14 # which files do I need again. I still have timidity, that goes in .rockbox, right? 05.54.53 # <__builtin> correct 05.55.12 # <__builtin> you need duke3d/* and timidity/* both under .rockbox 05.55.27 # <__builtin> you may want to delete duke3d.cfg when copying 05.56.50 # gigabeat f gives undefined instruction at 01a4ef70 05.57.11 # <__builtin> can you map that? 06.01.36 # well, it's on the audiobuffer 06.03.55 # <__builtin> hmm, are the addresses in the ELF correct? 06.07.07 Quit TheSeven (Ping timeout: 265 seconds) 06.08.41 # * __builtin goes to bed 06.09.12 # goodnight. I think somehow vfp instructions got made 06.11.15 # threre's a vpush in initgroupfile 06.12.53 # somehow the vfp thing got set even though I had #if ARM_ARCH >= 6 around it 06.17.09 # ok it runs but audio is going way too fast 06.19.10 # crap, forgot makefile isn't preprocessed :p no wonder it did that 06.33.25 # did a completely clean build to be sure. the sample rate setup is wrong 06.40.17 Quit JdGordon (Ping timeout: 248 seconds) 06.47.00 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 06.48.01 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 06.49.43 # __builtin (logs): e200 gets stuck on Checking sound inits 06.50.11 # soft lockup (backlight still works with hold) 06.55.44 Quit JdGordon (Ping timeout: 252 seconds) 07.08.10 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 07.09.42 *** Saving seen data "./dancer.seen" 07.13.31 Quit JdGordon (Ping timeout: 268 seconds) 07.34.49 Join go2m [0] (~goom@cpe-173-174-162-201.satx.res.rr.com) 07.35.56 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 07.36.20 Part go2m 07.48.29 Quit JdGordon (Ping timeout: 272 seconds) 07.55.08 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 08.08.17 Quit JdGordon (Ping timeout: 248 seconds) 08.19.12 Join ender` [0] (krneki@foo.eternallybored.org) 08.20.19 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 08.27.57 Quit JdGordon (Ping timeout: 240 seconds) 08.35.27 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 08.43.32 Quit JdGordon (Ping timeout: 252 seconds) 08.50.34 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 08.53.51 Join johnb6 [0] (~johnb2@p5B3AFF63.dip0.t-ipconnect.de) 09.02.17 Quit this_is_a_nick (Read error: Connection reset by peer) 09.09.43 *** Saving seen data "./dancer.seen" 09.12.05 Quit johnb6 (Ping timeout: 240 seconds) 09.25.23 Join johnb6 [0] (~johnb2@p5B3AFF63.dip0.t-ipconnect.de) 09.55.29 Quit johnb6 (Ping timeout: 248 seconds) 10.09.37 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:bda9:6d24:4436:b425) 10.09.49 Quit ZincAlloy (Client Quit) 10.10.30 Quit aphirst (Ping timeout: 268 seconds) 10.11.52 Join aphirst [0] (~aphirst@unaffiliated/aphirst) 10.44.44 Quit JdGordon (Ping timeout: 264 seconds) 10.51.30 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 11.02.40 Quit JdGordon (Ping timeout: 252 seconds) 11.09.44 *** Saving seen data "./dancer.seen" 11.09.46 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 11.51.15 Join johnb6 [0] (~johnb2@p5B3AFF63.dip0.t-ipconnect.de) 11.51.36 Quit johnb6 (Client Quit) 12.10.55 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:b93c:b4eb:426c:e26) 12.11.05 Quit ZincAlloy (Client Quit) 12.20.10 Join b3z [0] (~Thunderbi@host-198.58.elzappero.net) 12.21.21 # Hello I have a Sansa clip zip with Rockbox firm. with a broken screen. Its there any way to still use it remotely or in some useful way or should i treat it as trash? 12.32.14 Quit JdGordon (Ping timeout: 256 seconds) 12.38.20 Join ZincAlloy [0] (~Adium@ip1f12fa2e.dynamic.kabel-deutschland.de) 12.38.44 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 12.40.41 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 12.42.46 Quit bzed (Ping timeout: 252 seconds) 12.44.34 Quit ZincAlloy (Quit: Leaving.) 12.44.49 Join bzed [0] (~bzed@shell.bzed.at) 13.04.31 Quit JdGordon (Ping timeout: 272 seconds) 13.09.45 *** Saving seen data "./dancer.seen" 13.27.05 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 13.28.32 Quit dys (Ping timeout: 264 seconds) 13.40.37 Quit pamaury (Ping timeout: 272 seconds) 13.41.21 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 13.43.27 Quit jhMikeS (Ping timeout: 240 seconds) 13.46.17 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:84e4:e073:abd2:d32b) 13.56.33 Join dys [0] (~dys@tmo-123-29.customers.d1-online.com) 14.01.05 Quit dys (Ping timeout: 260 seconds) 14.01.20 Quit JdGordon (Ping timeout: 248 seconds) 14.08.35 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 14.18.23 Quit JdGordon (Ping timeout: 248 seconds) 14.21.15 Quit ZincAlloy (Quit: Leaving.) 14.27.41 Join ZincAlloy [0] (~Adium@31.18.250.46) 14.30.44 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 14.36.16 Join johnb6 [0] (~johnb2@p5B3AFF63.dip0.t-ipconnect.de) 14.36.59 # you can activate voice for menu entries and title and use it in "blind mode". 14.38.43 Quit ZincAlloy (Quit: Leaving.) 14.40.46 Quit akaWolf (Quit: leaving) 14.41.25 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 14.42.03 Quit johnb6 (Ping timeout: 272 seconds) 14.48.07 Quit akaWolf (Quit: leaving) 14.48.15 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 14.50.43 Quit akaWolf (Client Quit) 14.57.48 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 15.09.49 *** Saving seen data "./dancer.seen" 15.10.32 Quit sanchaez (Ping timeout: 264 seconds) 15.23.35 Join sanchaez [0] (~sanchaez@95.67.87.200) 15.25.50 Quit sanchaez (Read error: Connection reset by peer) 15.27.46 Quit b3z (Read error: Connection reset by peer) 15.27.57 Join b3z [0] (~Thunderbi@host-198.58.elzappero.net) 15.28.31 Join sanchaez [0] (~sanchaez@95.67.87.200) 15.50.07 Join dys [0] (~dys@tmo-101-22.customers.d1-online.com) 15.53.29 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:2833:829d:6a9:8ce6) 15.53.44 Join this_is_a_nick [0] (~amofiuhr_@ip150-155-64-186.ct.co.cr) 15.55.31 Join johnb6 [0] (~johnb2@p5B3AFF63.dip0.t-ipconnect.de) 16.02.40 Quit ZincAlloy (Quit: Leaving.) 16.17.09 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:2833:829d:6a9:8ce6) 16.20.31 Quit JdGordon (Ping timeout: 248 seconds) 16.21.52 # <__builtin> b3z: we have several users who operate it without the screen 16.25.50 # <__builtin> jhMikeS (logs): from that it looks like it's crashing in SoundStartup() 16.27.31 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 16.35.24 # <__builtin> also, for the Makefile, you'll have to do some shell ickery to compare values 16.44.53 Quit johnb6 (Quit: Nettalk6 - www.ntalk.de) 16.56.40 Quit ZincAlloy (Quit: Leaving.) 17.09.50 *** Saving seen data "./dancer.seen" 17.34.27 Join Jinx [0] (~Jinx@unaffiliated/jinx) 17.38.34 Join johnb3 [0] (~johnb2@p5B3AFF63.dip0.t-ipconnect.de) 17.48.26 # <__builtin> it seems that the MV_MixFP* functions in mv_mix.c are responsible for a large amount of the overhead of sound 17.58.19 # <__builtin> I'm going to attempt to rewrite them as fixed-point 18.23.20 Quit alexweissman (Remote host closed the connection) 18.24.32 Join alexweissman [0] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net) 18.31.26 Quit aphirst (Ping timeout: 240 seconds) 18.33.11 Join aphirst [0] (~aphirst@unaffiliated/aphirst) 19.04.34 Quit this_is_a_nick (Ping timeout: 272 seconds) 19.09.51 *** Saving seen data "./dancer.seen" 19.21.47 Quit JdGordon (Ping timeout: 268 seconds) 19.23.13 Quit alexweissman (Remote host closed the connection) 19.28.21 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 19.39.31 Quit b3z (Remote host closed the connection) 19.39.59 Quit johnb3 (Quit: Nettalk6 - www.ntalk.de) 20.09.27 Join JannF [0] (~jann@HSI-KBW-046-005-019-085.hsi8.kabel-badenwuerttemberg.de) 20.16.50 Quit JannF (Quit: Leaving.) 20.44.51 Join alexweissman [0] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net) 21.09.53 *** Saving seen data "./dancer.seen" 21.34.29 Join this_is_a_nick [0] (~amofiuhr_@201.207.214.75) 21.44.13 Join Soap [0] (~Soap@rockbox/staff/soap) 21.46.10 Quit Soap_ (Ping timeout: 252 seconds) 21.52.53 Join ZincAlloy [0] (~Adium@31.18.250.46) 21.58.43 Quit dys (Remote host closed the connection) 22.10.23 Quit TheSeven (Ping timeout: 265 seconds) 22.13.54 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 22.29.44 Quit ZincAlloy (Quit: Leaving.) 22.55.13 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:a0d2:828:e453:413) 23.08.58 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 23.09.54 *** Saving seen data "./dancer.seen" 23.24.14 Join cela [0] (c24b1876@gateway/web/freenode/ip.194.75.24.118) 23.26.17 Join [Saint] [0] (cb64d42d@rockbox/staff/saint) 23.27.47 # Duke3d works well on Fuze+ nice work, tried on Sony NWZ-E384 stops with message "ATOMIC 1.5 ->CRC You should try to ge" text gets cut off, will test with other arm color devices and report back. :-) 23.29.18 Quit cela (Quit: Page closed) 23.47.40 Quit this_is_a_nick (Ping timeout: 272 seconds) 23.51.00 Join cela [0] (c24b1876@gateway/web/freenode/ip.194.75.24.118) 23.52.52 # Duke 3d runs well on Zen X-Fi, only issue it seem I cant find a button to get back to the game menu, only to restart the level, so you have to play Duke nuke'em forever! 23.52.57 # <[Saint]> OK, so, theme update: 23.53.35 # <[Saint]> To extend the range of support, I'm going to have to end up doing something I didn't want to do, and split the theme up into small/medium/large categories. 23.53.39 Quit cela (Client Quit) 23.54.39 # <[Saint]> The reason why I need to do this is a somewhat complex one, but I need to do it to bring the minally supported resolution down. 23.54.50 # <[Saint]> errr, *minimally. 23.56.29 # <[Saint]> Even though the assets are loaded and displayed dynamically, the theme still needs to survive being parsed by the skin engine on any given target. 23.57.00 # __builtin: I seem to have unstuck the build system a few times recently by restarting one of my build clients. It's of course possible that the client is at fault, but my suspicion is that the server sometimes gets stuck but can wake up again if *something* happens, and disconnecting a client is something 23.57.42 # So maybe next time it's stuck you could try connecting a client, or even just connecting to the server port 23.57.56 # <__builtin> OK 23.58.44 # <[Saint]> If a theme is loaded with out of bounds values, it will be discarded. To minimise the chances of this happening I'll be splitting the theme up in to three smaller sub-themes of small, medium, and large, each supporting a range of four different font glyph sizes.