--- Log for 11.01.115 Server: sendak.freenode.net Channel: #rockbox --- Nick: logbot- Version: Dancer V4.16 Started: 3 days and 23 hours ago 00.03.38 Quit xorly (Ping timeout: 264 seconds) 00.09.15 Join xorly [0] (~xorly@m180.dkm.cz) 00.15.52 Quit y4n (Quit: MOTHER EUROPA CALLING ME!) 00.24.21 Quit lorenzo92 (Ping timeout: 240 seconds) 00.36.29 *** Saving seen data "./dancer.seen" 00.40.56 # wodz (logs): I'm in the process of porting qeditor, see g#1131, at the moment it compiles (but I excluded the edit tab from compilation) and I can browse registers, I haven't tried reading some values yet but it's a good start :) 00.41.01 # 3Gerrit review #1131 at http://gerrit.rockbox.org/r/1131 : 3regtoosl/qeditor: port to the new description format by Amaury Pouly 00.47.29 Quit pamaury (Ping timeout: 244 seconds) 00.59.41 Quit thomasjfox (Quit: Konversation terminated!) 01.07.22 Quit bertrik (Remote host closed the connection) 01.09.02 Quit Rower (Ping timeout: 264 seconds) 01.33.02 # hm, not quite execute code on n5g, but rather bypass sigchecks on n7g or whatever the current one is called 01.33.22 # those sigchecks don't directly allow code execution, but open up a lot of additional attack surface 01.33.39 # MarcAndersen: ^ 01.47.58 # <[Saint]> Likely confusing 4 and 5G, I posit. 01.48.22 # <[Saint]> Where there is execution, but no access to storage, so its a very limited playground. 01.50.04 Join AlexP [0] (~alex@rockbox/staff/AlexP) 02.08.07 Quit xorly (Ping timeout: 245 seconds) 02.18.26 Quit ender` (Quit: It's nice to know that my launch to orbit won't have any pesky back-up systems weighing me down. -- Andy Weir: The Martian) 02.23.58 Quit AlexP (Remote host closed the connection) 02.34.51 Quit lebellium (Quit: ChatZilla 0.9.91.1 [Firefox 35.0/20150106233618]) 02.36.31 *** Saving seen data "./dancer.seen" 02.48.52 Quit RiD (Quit: A good plan today is better than a perfect plan tomorrow.) 02.55.44 Join lunarl0n [0] (~lunarl0n@cpe-76-187-18-40.tx.res.rr.com) 03.03.59 Part lunarl0n 03.14.02 Quit ZincAlloy (Quit: Leaving.) 03.29.01 Join GreyGhost [0] (3bb71761@gateway/web/freenode/ip.59.183.23.97) 03.30.39 Quit krabador (Quit: Take the time.) 03.30.59 Quit GreyGhost (Client Quit) 03.32.23 Join GreyGhost [0] (3bb71761@gateway/web/freenode/ip.59.183.23.97) 03.34.36 Join krabador [0] (~krabador_@unaffiliated/krabador) 03.34.37 # [Saint], Hello.. I was wondering if the ipod 6g usb driver rewrite for the rb toolchain is in need of testers or does it need someone to fix it? Cos I could volunteer for the former :P 03.35.00 # <[Saint]> I needs no testing. No. 03.35.16 # <[Saint]> It needs to be completely re-written. 03.35.56 # wodz fixed the bitfield stuff etc. a while ago, but apparently broke something else in the process 03.35.59 # that needs a closer look 03.36.29 # [Saint)], ok then.. Can't help there.. 03.37.26 # Is there any hope for rockbox on the nano 5g? 03.38.02 # TheSeven, btw.. Using the classic as OTG is working great now.. Copied over some 2.5 gb of data without freeze. With the old driver it froze even on a few hundred mbs.. 03.38.23 # <[Saint]> MarcAndersen: I'll say this much, no one is working on it. 03.38.32 # <[Saint]> MarcAndersen: so, for the forseeable future...no. 03.38.42 # * GreyGhost is TheNewGuy whom you gave the patched rockbox amd emcore copy 03.38.46 # do we need to take one apart? 03.38.49 # <[Saint]> No. 03.39.12 # ok. so it's software problems? 03.39.14 # GreyGhost: that's a good data point... now if only wodz's version would work... 03.39.39 # MarcAndersen: nobody managed to defeat apple's mechanisms that are trying to prevent us from running any code on that device yet 03.40.02 # <[Saint]> MarcAndersen: its a "no viable or confirmwd exploit and no one who can do the work who actually cares or owns the device" problem. 03.40.09 # (unlike some older generations, where we successfully managed to circumvent those) 03.40.13 # it's kinda like iphone jailbreaking 03.40.31 # <[Saint]> These new iPods are more like iPhones than the older generation iPods. 03.40.44 # <[Saint]> bah - beat me to it again. Damn you 7! :p 03.41.34 # TheSeven, yeah.. That's why I came by to see if I can offer any help.. Sadly all I could do was test (so not much real help :P) 03.41.40 # <[Saint]> I used to care. 03.41.50 # I would like to help if I can, but don't know where to start at this pone... 03.41.52 # <[Saint]> But most, if not all, of my development time now goes towards Android. 03.42.03 # *one 03.42.06 # <[Saint]> I mean, honestly, Android handsets are a LOT more interesting. 03.42.12 # <[Saint]> To me at least. 03.42.37 # <[Saint]> I could bust my ass working on a DAP that _does not want_ me inside it. 03.42.45 # <[Saint]> Or work on a largely free and open platform that does. 03.42.46 # android is not as accessible to the blind as button based playiers I think 03.42.51 # <[Saint]> pretty easy choice. 03.43.20 # <[Saint]> MarcAndersen: that's largely untrue. Android is very highly usable with Google's TalkBack engine, no? 03.43.40 # <[Saint]> I've witnessed totally unsighted people use Android many a time. 03.43.51 # <[Saint]> even as power-users. 03.44.04 # <[Saint]> but, anyhoo - topic, sorry to devolve the conversation. 03.44.17 # Anyway I'll continue to lurk around the IRC logs and pop in of i see any driver related activity.. Thanks.. 03.44.19 # Sure. But I still think running rockbox on a full operating system is a bit strange 03.44.29 # *if 03.44.51 Quit the-kyle (Remote host closed the connection) 03.45.23 # <[Saint]> MarcAndersen: aha, right, yeah I agree somewhat. My Android development involves practically zero Rockbox work these days. 03.45.46 # <[Saint]> I got sick of trying to shoot a moving target with the ART runtime, and then got bored with it. 03.45.50 # <[Saint]> I should pick it back up. 03.46.23 # <[Saint]> Rockbox being stuck on 4.4.4 means I have to deliberate NOT update at least one of my devices, which is a bit of a PITA. 03.46.30 # But if there is a rockbox for android, why not make it for ios and put it in cydia? 03.46.42 # <[Saint]> I got it to not crash *immediately* on 5.x...but I got bored and stopped. 03.46.57 # <[Saint]> MarcAndersen: because none of us care about iOS. 03.47.02 # <[Saint]> If you do, go for it. 03.47.17 # hahaha I use symbian 03.47.18 # <[Saint]> We work for ourselves, not the public. 03.47.30 # <[Saint]> If the public gets a kick out of it, great, but its the developers project. 03.48.22 # <[Saint]> We don't align what is worked on with popular public opinion. 03.48.31 # <[Saint]> The supported device list should demonstrate that. 03.48.59 # [Saint]: That's a good point 03.49.47 # Can I get rockbox for android in the play store_ 03.50.56 # <[Saint]> I only stick around these days tohandle support really. 03.51.07 # <[Saint]> My Rockbox development time is next to nil. 03.51.32 # <[Saint]> I work on what takes my interest at the time, and for better or worse, that hasn't been Rockbox for a while now. 03.52.00 # <[Saint]> MarcAndersen: due to the way we handle builds, no, no you can't. 03.52.17 # <[Saint]> you /could/, but we'd need to upload a build for _every_ supported resolution. 03.52.22 # <[Saint]> ...which is plainly stupid. 03.52.53 # <[Saint]> there's no "one size fits all" build, and no clear and/or sane path to get there. 03.53.34 # <[Saint]> Nothing anyone can agree on at least. And a lack of anyone to do it if there were. 03.54.49 # [Saint]: ok 03.55.15 # <[Saint]> I understand that's not what you wanted to hear, but that's the state of things as I understand it. 03.55.37 # I only run android in virtual box at the moment 03.56.29 Join CaptainKewl [0] (~captainke@207-237-110-248.c3-0.nyr-ubr2.nyr.ny.cable.rcn.com) 04.07.43 Quit GreyGhost (Ping timeout: 246 seconds) 04.27.13 Join ploco [0] (dce9b7f9@gateway/web/freenode/ip.220.233.183.249) 04.29.34 # [Saint]: one Chinese user report back a non-crash case with 5.0 when using my old build which disable the power thread....but play will cause a immediate FC 04.30.17 # <[Saint]> I have a build that dies after 3 or 4 seconds. Instead of immediately. 04.30.18 # that leads to two things. 1 notification handle, 2 Android threads. 04.30.20 # <[Saint]> ...progress? ;) 04.30.56 # I got nothing to debug. waiting for a CM12 port 04.31.25 # <[Saint]> Ah, that's right, you're on some legacy device yeah? 04.31.47 # yes, st18i really old 04.31.53 # <[Saint]> whoah. 04.31.55 # <[Saint]> yep. 04.32.32 # <[Saint]> Sadly, you'll never see an official cm-12 port either. 04.32.44 # <[Saint]> there's hope from the community, though, maybe. 04.33.47 # actually I don't care, I could just use a Android 5.0 VM and debug from there. might do it when I have a little bit more time next month 04.36.35 *** Saving seen data "./dancer.seen" 04.43.52 Quit ploco (Quit: Page closed) 04.47.10 Join djruffkutz [0] (~djruffkut@ool-43563765.dyn.optonline.net) 04.47.35 Quit djruffkutz (Excess Flood) 05.11.31 Quit TheSeven (Ping timeout: 244 seconds) 05.12.40 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 05.28.52 Quit mshathlonxp (Ping timeout: 256 seconds) 05.36.12 Quit krabador (Quit: Take the time.) 06.36.39 *** Saving seen data "./dancer.seen" 06.44.55 Quit CaptainKewl (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) 07.33.42 # [Saint]: woohoo! I took a sample and did a count, 0 adults and two eggs, and the aggs look brown and shriveled, I wonder if the mixture I'm using inhibits the reproductive cycle? 07.34.02 # * foolsh is happier today 07.34.27 # <[Saint]> I don't think you're where you think you are. 07.34.34 # lol opps :) 08.35.17 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon) 08.35.52 Quit JdGordon (Ping timeout: 256 seconds) 08.36.41 *** Saving seen data "./dancer.seen" 08.56.33 Join lorenzo92 [0] (~chatzilla@host101-104-dynamic.25-79-r.retail.telecomitalia.it) 09.07.33 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 09.33.39 Quit rela (Quit: Leaving) 09.49.46 Quit bertrik (Remote host closed the connection) 10.19.10 Quit bzed (Remote host closed the connection) 10.36.43 *** Saving seen data "./dancer.seen" 10.42.02 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.16.54 Join MMlosh [0] (~MMlosh@2001:470:6f:23:24f:63ff:fe01:4900) 11.25.19 Join ender` [0] (krneki@foo.eternallybored.org) 11.40.53 Join xorly [0] (~xorly@m180.dkm.cz) 11.47.48 Quit lorenzo92 (Ping timeout: 244 seconds) 11.53.57 Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) 12.01.28 Join Babydylanw02 [0] (44697471@gateway/web/freenode/ip.68.105.116.113) 12.05.03 Quit Babydylanw02 (Client Quit) 12.14.06 Quit JanC (Ping timeout: 264 seconds) 12.19.48 Join lorenzo92 [0] (~chatzilla@host101-104-dynamic.25-79-r.retail.telecomitalia.it) 12.23.09 Quit APLU (Quit: !sucide) 12.23.11 # wodz (logs): qeditor is working with hwstub and the new register desc, see the gerrit task ^^ 12.27.20 Join JanC [0] (~janc@lugwv/member/JanC) 12.32.12 Join APLU [0] (~mulx@eva.aplu.fr) 12.36.45 *** Saving seen data "./dancer.seen" 13.18.43 Join lebellium [0] (~chatzilla@89-93-177-161.hfc.dyn.abo.bbox.fr) 13.20.06 Join TheLemonMan [0] (~lemonboy@unaffiliated/thelemonman) 13.45.53 # logf("logf") calls are opted out when not compiling with logf support, right? 13.47.32 Join RiD [0] (~RiD@bl22-61-170.dsl.telepac.pt) 13.50.56 # i.e. the string is not even in the final executable? 14.36.46 *** No seen item changed, no save performed. 15.48.34 # bluetooth implementation so far is going fine, but slowly ^^ anyway, rockbox is now able to initialize all the hardware, and specifically the bcm20xx with some vendor specific commands. plus a debug screen to toggle the basic controller state (pin-level) 15.49.13 # next, i would like to fix "firmware blob" update aka patchram. this one is not essential, but OF does provide one 16.06.02 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 16.07.18 Quit JdGordon_ (Ping timeout: 245 seconds) 16.11.31 Quit lorenzo92 (Ping timeout: 245 seconds) 16.15.03 Quit pystar89 (Ping timeout: 264 seconds) 16.21.02 Quit Zambezi (Ping timeout: 264 seconds) 16.21.46 Join Zambezi [0] (Zulu@bnc.from.dotbnc.com) 16.22.15 Quit Galois (Ping timeout: 264 seconds) 16.36.47 *** Saving seen data "./dancer.seen" 16.42.24 Quit TheLemonMan (Quit: leaving) 16.57.43 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 17.15.36 Join ZincAlloy [0] (~Adium@pD9EEA182.dip0.t-ipconnect.de) 18.02.09 Join AlexP [0] (~alex@rockbox/staff/AlexP) 18.03.23 # Build Server message: 3New build round started. Revision cfbd9cb, 255 builds, 25 clients. 18.05.31 # * gevaerts waits excitedly to see if everything is still green! 18.07.12 # you are not alone ;) 18.07.30 # We probably have different reasons though 18.07.38 # though I did grep those variables before modifying them... 18.07.54 # If everything goes as expected, fs-bluebot should now properly report yellows and reds 18.08.05 # all of them? 18.08.32 # sometimes the SDL app outputs over 120 yellow warnings. It looks like the compiler settings sometimes change... 18.08.35 # Well, a total. The same data the CIA bot used to give us 18.09.00 Join bzed [0] (~bzed@devel.recluse.de) 18.09.21 # We'll see :) 18.11.22 # CIA bot retired when the switch from svn to git was done? 18.11.33 # Build Server message: 3Build round completed after 490 seconds. 18.11.34 Join [Franklin] [0] (~franklin@unaffiliated/franklin) 18.11.39 # No. The server that ran on had a disk accident, and they lost all data 18.12.05 # So the people running that service decided not to bother restarting it 18.12.11 Quit bzed (Remote host closed the connection) 18.12.40 # does fs-bluebot only output a diff in yellow/red or should it report the two reds for the "Recorder" build? 18.13.05 # I'm confused! 18.13.35 # why? 18.14.01 # fs-bluebot outputs exactly what the build server reports. Since that report was wrong in the past its filtered out 18.14.09 # Oh 18.14.14 # Right :) 18.14.15 # I'll change that. Judging from the log it should be ok now 18.14.22 # Anyway, my client didn't get the line... 18.14.29 # That's mostly what confuses me 18.14.45 # I can do more static stuff if a commit is needed ;) 18.15.04 # Anyway, yes, it should be fixed now. This is the first build with the fix though 18.16.37 Join pystar89 [0] (~pystar89@ip-178-203-30-225.hsi10.unitymediagroup.de) 18.17.48 # bluebrother: let me know when the filter is removed and I'll commit g#1119 18.17.52 # 3Gerrit review #1119 at http://gerrit.rockbox.org/r/1119 : 3Improve readability by adding parenthesis by Thomas Jarosch 18.18.39 # thomasjfox: should work now 18.18.52 # <[Franklin]> thomasjfox: have you looked at G#887? 18.18.52 Join bzed [0] (~bzed@devel.recluse.de) 18.18.56 # 3Gerrit review #887 at http://gerrit.rockbox.org/r/887 : 3Enhancement of the metronome plugin: by Thomas Orgis 18.19.02 # [Franklin]: no 18.20.08 # Build Server message: 3New build round started. Revision 85c98bc, 255 builds, 25 clients. 18.22.32 Quit bzed (Remote host closed the connection) 18.26.59 # Build Server message: 3Build round completed after 412 seconds. 18.27.00 # Build Server message: 3Revision 85c98bc result: 2 errors 0 warnings 18.27.06 # Yay! 18.27.15 # <[Franklin]> finally :D 18.27.33 # is someone running a fairly recent build on an Iaudio X5/M5 or maybe M3? I'm getting an STKOV voice (when enabled and voice file present) quite often with a build from beginning of last year or so and I fear it just got worse 18.28.03 # hmm, would it be possible to mask the two errors for the Recorder build? 18.28.20 # <[Franklin]> or better yet, fix it? :P 18.28.29 # [Franklin]: go ahead! 18.28.48 # I'm wondering if it makes sense at all to keep trying to auto-build it 18.28.54 # <[Franklin]> perhaps a better compressor would do 18.29.47 # It's similar enough to recorderv2 and fmrecorder for breakages to slip through, I'd say 18.31.01 # * [Franklin] seems to have "xracer" working 18.31.12 # <[Franklin]> just that the poly fill function is not working :( 18.31.32 # [Franklin]: that was also what you were missing for sgt-puzzles, wasn't it? :) 18.31.41 # <[Franklin]> yeah 18.31.51 # <[Franklin]> but this has a set number of points 18.31.55 # <[Franklin]> 4 max 18.32.15 # <[Franklin]> so just 2 tris 18.32.28 # <[Franklin]> but it's the ARGUMENTS to that function, to be more precise 18.32.35 Join einhirn [0] (~Miranda@p4FC118DC.dip0.t-ipconnect.de) 18.35.24 # gevaerts: \o/ 18.36.17 # masking them is problematic, at least for the bot: it doesn't know those are the recorder errors, it just mirrors the result it gets from the build master 18.36.37 # <[Franklin]> just subtract two ;) 18.36.46 # and simply extracting the number and substracting 2 is ... well. 18.36.49 *** Saving seen data "./dancer.seen" 18.37.00 Quit einhirn (Ping timeout: 264 seconds) 18.37.06 # <[Franklin]> sed 's/2 errors/0 errors/' 18.37.31 # plus, that means the bot had even more dependencies on the format of the messages the build master sends. Nothing I'd like to have there. 18.38.00 # [Franklin]: and if it reports 3 errors because there is another one? Won't work that way :) 18.38.30 # <[Franklin]> when there's an error, there's a big number 18.39.04 # <[Franklin]> bluebrother: BTW, where does fs-bluebot get the messages from? 18.39.29 # [Franklin]: from the build server. It interacts with a build client running on the same machine. 18.39.33 # probably it's best to say good bye to the Record build or ask one last time on the mailinglist if someone (with the hardware) is willing to fix it 18.40.01 # <[Franklin]> just "deprecate" it 18.40.15 # thomasjfox: as much as I hate to say so but I do agree with that. It simply doesn't make much sense anymore :( 18.40.32 # gevaerts already asked on the ML :D 18.40.49 # :) 18.41.45 # he should get a hug for that 18.42.57 Join bzed [0] (~bzed@devel.recluse.de) 18.43.27 # like that? https://pbs.twimg.com/media/BkG6xwACYAAoCvO.jpg 18.43.33 # ;-) 18.44.09 # exactly like that :D 19.00.22 Quit d33tah (Quit: WeeChat 1.0.1 - the better Irssi! http://www.weechat.org/ [that's not the default quit msg]) 19.00.29 Join d33tah [0] (~d33tah@kolos.math.uni.lodz.pl) 19.02.20 # <[Franklin]> foolsh: take a look at "xracer" now 19.04.18 # <[Franklin]> barely working, but kind of working 19.04.21 # <[Franklin]> :D 19.05.38 # ah nice, let me see what it looks like on a target 19.06.29 # <[Franklin]> wait... I got alternating colors working now 19.06.33 # <[Franklin]> let me push first 19.07.01 # <[Franklin]> ok 19.08.39 Join Strife89 [0] (~Strife89@adsl-98-80-232-132.mcn.bellsouth.net) 19.16.20 Join Water255 [0] (~chatzilla@99.102.69.55) 19.16.28 # I see where you're going with, neat, heh some z depth culling issues on the sim, it might be fixable by placing the view port slightly forward 19.18.12 # Hello all. I just want to say that I've used a lot of software, and I've had some of my best experiences with open-source programs. God bless you guys and gals. 19.18.47 Quit Water255 (Client Quit) 19.21.33 # <[Franklin]> foolsh: it's /very/ messy code rightn ow 19.21.53 # :) yeah 19.22.07 # <[Franklin]> but it's scrolling 19.24.37 # <[Franklin]> not sure what's causing the grass on the road, though 19.26.42 # xracer, the x makes it cooler :D 19.26.53 # <[Franklin]> lol XD 19.28.00 # <[Franklin]> ok yay borders working 19.28.11 # <[Franklin]> now just got to get the left side of the road working :D 19.28.23 # * [Franklin] suspects a signedness issue 19.30.01 # <[Franklin]> foolsh: I mainly chose "xracer" not to annoy [Saint] 19.30.16 # <[Franklin]> otherwise I would have done "rockracerbox" :P 19.30.36 # that's a hidious name :D 19.30.52 # <[Franklin]> or "racebox" 19.31.18 # <[Franklin]> that's actually not that bad 19.31.31 # On the real fuze+ target, it looks the same but runs slightly slower, of course 19.31.49 # <[Franklin]> try the latest patch set 19.31.58 # <[Franklin]> it moves the camera a bit higher and faster 19.32.04 # <[Franklin]> so the scrolling's more obvious 19.32.42 Join TheLemonMan [0] (~lemonboy@unaffiliated/thelemonman) 19.39.02 # <[Franklin]> foolsh: does it scroll smoothly on target? 19.39.09 # hmm, maybe too obvious... but boxracer? 19.39.42 # <[Franklin]> [Saint] would murder someone for that :P 19.44.31 # nice touch with the track border, so are you feeling "Pole Position" or "Outrun"? 19.44.56 Join petur [0] (~petur@rockbox/developer/petur) 19.46.16 # <[Franklin]> more Pole Position 19.46.30 # <[Franklin]> does it only draw the right side on target too? 19.47.05 # hang on let me build 19.49.20 # Hmm, it's more of an actual 3D engine now than before? 19.49.20 Join wodz [0] (~wodz@89-75-106-221.dynamic.chello.pl) 19.49.33 # <[Franklin]> foolsh: yes 19.49.33 Quit MMlosh (Quit: Bye...) 19.49.45 # <[Franklin]> it could easily be extended to 3d 19.50.08 # <[Franklin]> currently it's only 1.5D projected hacked into 3D 19.50.32 # yes on target renders just the same as the sim 19.50.39 # <[Franklin]> I'm reworking the scroll code now so it loops 19.50.41 # * [Saint] eye twitches 19.51.04 # <[Saint]> rock*.rock or *box.rock makes me want to kick puppies 19.51.22 # <[Franklin]> how about rock*box.rock? 19.51.36 # * foolsh kicks two puppies 19.51.45 # gevaerts: I know we have more _ prefixed functions. I have nothing against internal functions like this but I think its silly to have target specific functions needed by the core to be named like this 19.52.40 # gevaerts: and finally I touched _buttonlight_* also :-) 19.52.56 Join MMlosh [0] (~MMlosh@2001:470:6f:23:d4af:3e66:6efc:9273) 19.52.57 # wodz: if you feel strongly about it, I won't object :) 19.53.36 # ok, then I'll push the button when I have time to hang around to fix emerging reds/yellows 19.53.54 Quit eeeeeta (Remote host closed the connection) 19.55.15 Join eeeeeta [0] (~eeeeeta@gateway/tor-sasl/eeeeeta) 19.55.27 Quit eeeeeta (Remote host closed the connection) 19.56.32 Join eeeeeta [0] (~eeeeeta@gateway/tor-sasl/eeeeeta) 20.00.21 # [Franklin]: I see you have some procedural elements and some render elements, perhaps use a procedure to draw the grass first, and then render the track on top will stop the left side from doing that 20.00.46 # <[Franklin]> that's what it does now 20.01.06 # <[Franklin]> it seems it's just that the road's not covering the grass 20.03.07 # sorry, I meant in a seperate render_road fuction perhaps, the are mixed in together and gets called all at once 20.03.19 # they* are mixed 20.03.20 # <[Franklin]> ah yes 20.04.58 Quit MMlosh (Quit: Bye...) 20.05.48 # so every frame, draw_grass then render_raod, I guess would fix it 20.06.12 # <[Franklin]> no, it (shouldn't) wouldn't 20.06.20 # <[Franklin]> same code, just function-ized 20.06.30 # <[Franklin]> that's what's being done now 20.06.41 # <[Franklin]> draw_grass draw_border draw_road 20.06.55 # <[Franklin]> just in one big function 20.07.53 # Ah its draw where we can see it drawing, needs a buffer to flip and flop, 20.08.23 # <[Franklin]> no, rockbox is double-buffered by default 20.08.29 # <[Franklin]> nothing shows until lcd_update() is called 20.14.27 # Ah, I have it this time, you call an extra lcd_update on line 209, only need one per frame 20.15.01 # <[Franklin]> aha! 20.15.25 # Dang, nope it still doesn't draw the left side correctly 20.15.38 # <[Franklin]> I think it's a signedness issue 20.15.48 # <[Franklin]> probably something with project() 20.16.25 Join the-kyle [0] (~kyle@kyle.tk) 20.16.52 # <[Franklin]> bah... forget that 20.16.54 # <[Franklin]> I'll get lanes working 20.18.49 # if it's a signedness problem, translate the origin far enough away so the scene never passes over zero 20.19.20 # <[Franklin]> signedness with x-coord 20.19.26 # <[Franklin]> so not that 20.26.30 # needs key some kind of handling, I have to manually kill the process for the sim each time 20.26.56 # <[Franklin]> yeah 20.27.01 # <[Franklin]> too lazy :P 20.27.21 # <[Franklin]> I'll get to it ;) 20.28.12 Quit Strife89 (Ping timeout: 265 seconds) 20.29.15 # I would look at cube.c it's basicly what you've done here but with backface culling, and see how they handled projectioning it from origin to screen 20.29.41 # * foolsh has sleepy finger again 20.29.52 # guess I'm safe with boxracer then :P 20.31.15 # <[Franklin]> foolsh: changing SEGMENT_LENGTH to 1000 draws part of the left side of the road 20.32.13 # <[Franklin]> it also makes the border of the road jagged 20.36.50 *** Saving seen data "./dancer.seen" 21.03.03 # I sort of fixed it 21.03.16 # <[Franklin]> how? 21.03.40 # line 158 fill_poly(x1-w1, y1, x1+w1, y1, x2-w2, y2, x2+w2, y2, color); 21.03.54 # <[Franklin]> what's different? 21.04.06 # line 158 was fill_poly(x1-w1, y1, x1+w1, y1, x2+w2, y2, x2-w2, y2, color); 21.04.41 # <[Franklin]> thanks foolsh 21.06.09 # so it was a signedness error :) 21.07.30 # now the brder is jagged 21.07.42 # <[Franklin]> yeah 21.17.43 Join krabador [0] (~krabador_@unaffiliated/krabador) 21.19.28 Join Ivoah [0] (~Ivoah@p-74-209-19-63.dsl1.rtr.chat.fpma.frpt.net) 21.21.12 Quit eeeeeta (Remote host closed the connection) 21.22.54 Join eeeeeta [0] (~eeeeeta@gateway/tor-sasl/eeeeeta) 21.25.35 # <[Franklin]> foolsh: it doesn't seem to help 21.25.44 # <[Franklin]> I think it's the fill_poly function now 21.26.10 Part BobJonkman1 21.27.33 # <[Franklin]> foolsh: it's assuming that the coordinates are given in the correct order 21.27.41 # <[Franklin]> which they're not 21.27.57 # <[Franklin]> so I just need to reorganize them so that they are 21.30.25 # opps I forgot about the change I did to line 122 pt_2d->w = scale * ROAD_WIDTH * LCD_WIDTH/2; shouldn't it be pt_2d->w = scale * ROAD_WIDTH * (LCD_WIDTH/2); 21.31.30 # nope I see no difference 21.34.55 # <[Franklin]> this code is dizzying 21.35.09 # <[Franklin]> I'm getting a headache looking at it 21.36.54 # <[Franklin]> I guess I'll make fill_poly sort the coords 21.41.20 # * thomasjfox prepares for yellow 21.41.49 # Build Server message: 3New build round started. Revision 2a3e162, 255 builds, 25 clients. 21.41.59 # <[Franklin]> .show HEAD 21.50.51 # [Franklin]: Is there grayscale support in xworld? 21.51.00 # <[Franklin]> nope, sorry 21.51.04 # Aww :( 21.51.11 # <[Franklin]> the game looks terrible in grayscale anyway 21.51.14 # Okay6 21.51.16 # *Okay 21.51.23 # <[Franklin]> Ivoah: in theory its totally possible, though 21.51.34 # Any more work on z80e? 21.51.41 # <[Franklin]> Ivoah: no, on xracer 21.52.00 # Is xracer going to support grayscale? 21.52.08 # <[Franklin]> Ivoah: it should 21.52.33 # <[Franklin]> nothing's color-specific yet 21.59.16 # hmm, shouldn't there be a message from fs-bluebot? 21.59.24 # * [Franklin] slaps fs-bluebot 21.59.24 # [Franklin]: ouch! 22.02.18 # hmm, interesting. My client has been temporarily disabled because of some error 22.02.56 # aaah. It tried to build the html manual on that machine, but it only supports pdf 22.03.09 # * bluebrother should fix this 22.03.51 # strange it worked before 22.05.04 # usually that machine gets the pdf manual 22.05.30 # seems the build master tried to give it the html version as well this time 22.08.35 # <[Franklin]> how can I fill a quad in rockbox? 22.11.05 # <[Franklin]> tris work to some extent, but they're dependent on input order 22.11.17 # <[Franklin]> sorting them at runtime is too expensive 22.16.00 Quit petur (Quit: Leaving) 22.18.54 # You'll have to use triangles, quads only work with 90 degree angles I believe 22.19.06 # at least the last time I looked 22.19.30 Quit thomasjfox (Ping timeout: 264 seconds) 22.19.38 # <[Franklin]> yeah 22.20.13 # is this about the track border? 22.20.16 # <[Franklin]> w00t! it works! 22.20.36 Join choki [0] (5b729d16@gateway/web/freenode/ip.91.114.157.22) 22.20.47 # <[Franklin]> the border and the road 22.20.48 # anyone with a sansa clip + in here? 22.20.56 # btw hello =) 22.20.58 # I wonder if I should do some more poking on G#887 to indicate that it's ready for merging (from my POV). 22.21.03 # choki: Yes. 22.21.04 # 3Gerrit review #887 at http://gerrit.rockbox.org/r/887 : 3Enhancement of the metronome plugin: by Thomas Orgis 22.21.21 # sobukus: how is the sound quality compared to ipod touch 5g? 22.21.37 # sobukus: would you buy one even 2015? 22.21.40 # choki: I cannot compare, but I have nothing to complain about with the sansa. 22.22.11 # Sound quality lives in your headphones ... 22.22.47 # choki: Yes, I did buy an additional one last year. Though, I'm using it as metronome for drum practice. 22.23.04 # Especially with Rockbox, it's a darn useful device. 22.23.24 # sobukus: oh. can u recommend some headphones below 100$? 22.24.30 # Well, I got those Sony MDR Q68LW, but not because of sound (they're rather light on bass, but OK) but because I don't get entangled in cords! 22.24.49 # xD 22.24.57 # I liked some philips clip-ons some time way back, sound-wise. 22.25.08 # But they fell apart eventually. 22.25.24 # I got some specific headphones for a relativfe some time back. Let me remember ... 22.25.40 # sobukus: do you think those headphones about 200$ are really worth the money? is it worth to get them for a sansa clip mp3 player? 22.26.30 # Ah, yes, AKG K-450, those are fine, too. 22.27.14 # cheap and good? :D 22.27.26 # I didn't look into super-expensive headphones apart from Beyerdynamic DT-990 Pro (or DT-770) for studio work 22.27.42 # For HiFi, I prefer by tower speakers. 22.28.23 # u r a sound guy :D 22.28.31 # I'm a drummer. 22.28.41 # why u up so late? ^^' 22.29.00 # It's not that late. 22.29.14 # <[Franklin]> sobukus: speaking of G#887, I guess you'll have to wait a bit if no one sees it 22.29.20 # 3Gerrit review #887 at http://gerrit.rockbox.org/r/887 : 3Enhancement of the metronome plugin: by Thomas Orgis 22.29.25 # <[Franklin]> though hopefully gevaerts is here listening :) 22.29.48 # [Franklin]: It's fine, I was just wondering if there is some action missing on my part of if it's just down to waiting. 22.29.59 # <[Franklin]> just wait ;) 22.30.11 # <[Franklin]> poke people a bit if you want 22.30.37 # choki: One point about headphones for me is if they are comfortable to wear. My ears don't like a lot of them. 22.30.49 # do you think standalone mp3 players are still alive today? 22.30.55 # The beyerdynamic ones are super-comfy and have decent sound. win-win. 22.31.15 # choki: Yes, but only if they have something to set them apart from smartphones. 22.31.22 # choki: The Clip+ has. 22.31.34 # <[Franklin]> a phyiscal keypad to play games on :P 22.31.39 # It's a lot smaller and lighter, has decent battery life. 22.31.48 # in terms of sound quality?? i cant believe smartphones are so much bad O_o 22.31.57 # And, if the battery of the MP3 player is flat, you can still call folks on the phone;-) 22.32.10 # xD 22.32.15 # i need a feature phone :D 22.32.41 # I can switch out the SD card on the Clip+ without prying open some backside covering. 22.33.02 # Again, it's small and light, so I can just clip it onto a T-Shirt for jogging/cycling. 22.33.03 # hahaha, it seems to be made exactly for doing this i guess 22.33.37 # I believe in devices for certain purposes. 22.34.11 # <[Franklin]> foolsh: fixed xracer 22.34.19 # I can place the clip somewhere at a venue to record a concert and not worry about some stage hand carrying off my pocket computer with all my contacts, messages, naked pictures, etc. 22.34.24 # <[Franklin]> not really a "fix" though 22.34.37 # <[Franklin]> just changed the poly drawing routine a bit 22.35.31 # choki: Guitarists _could_ just use some apps on their smartphones for processing sound, but for some reason they insist on stomp-boxes;-) 22.36.52 *** Saving seen data "./dancer.seen" 22.36.58 # [Franklin]: yeah line 103 was the ticket 22.39.04 # <[Franklin]> :D 22.39.06 # <[Franklin]> now to make it a game 22.39.19 # <[Franklin]> first curves and hills though 22.39.32 # <[Franklin]> but maybe a drag-racing game wouldn't be so bad :D 22.40.15 # <[Franklin]> for a game, I'll need some libre sprites 22.40.27 # polygons 22.40.40 # choki: Coming back to the ipod touch ... for that I really have trouble seeing how it's not obsoleted, if even by your second smartphone that's still working but not in fashion anymore. 22.40.44 # <[Franklin]> possible but... really? :P 22.41.14 # if you use bitmaps won't they have to be diffent sizes for the different targets? 22.41.21 # <[Franklin]> yes 22.41.31 # lot's of extra work IMO 22.41.41 # <[Franklin]> gimp can scale pretty easily 22.43.38 # <[Franklin]> plus, if the game were to have multiple cars, they'd have to be scaled at run-time anyway 22.44.11 # [Franklin]: well then just a large one for each car, large enough to not crap out on a target with a large screen resolution, then scale it down onthe fly 22.44.21 # <[Franklin]> yeah 22.44.25 # <[Franklin]> now to find one 22.45.51 # <[Franklin]> I suppose I could use Blender to make some 22.46.37 # <[Franklin]> but I'm not an expert blender artist 22.47.15 # http://pixabay.com/en/car-pictogram-rear-automobile-159674/ 22.47.17 # :D 22.47.26 # <[Franklin]> sure! 22.48.46 # You definitely didn't try scaling at such low resolutions. The output will look crap. 22.49.33 # <[Franklin]> I think I should get curves and hills working first, though 22.49.56 # pamaury: ping 22.50.14 # wodz: pong but I'm going to bed 22.50.24 # so I can answer a quick question ^^ 22.50.26 # sobukus: u think the ipod touch is end of life? i mean it is still a good alternative to iphone :D 22.50.56 # pamaury: I am working on atj hwstub to survive bad things like unaligned access and such 22.51.12 # wodz: you can inspire from my patch I guess on ARM 22.51.34 # pamaury: not really mips is quite different here 22.51.52 # ok 22.51.59 # pamaury: anyway how do you signal in your ARM patch that recovery process took place? 22.52.20 # pamaury: I mean do you expose this somehow? 22.52.26 # I just report read/write failure, by stalling 22.53.01 # how? 22.53.07 # by stalling 22.53.22 # yes but how do you pass this information from exception? 22.53.46 # I mean how upper level code knows something wrong happened? 22.54.29 # ah, with some setjmp/longjmp like code, let me find the code 22.55.02 # g#980 22.55.07 # 3Gerrit review #980 at http://gerrit.rockbox.org/r/980 : 3hwstub: implement read/write data abort recovery by Amaury Pouly 22.55.10 # thanks 22.55.25 # basically I call a function called set_data_abort_jmp() 22.55.27 # choki: I think it's too similar to a phone. 22.55.36 # But just my personal opinion. 22.55.40 # it returns 0 on the first call, and returns 1 on exception (it can returns twice) 22.55.50 # yeah but only if u have smartphone :D 22.56.02 # it saves the current context and on exception it jumps back to the calling point and returns again 22.56.44 # the implementation details are ARM specific of course but the principle should work on any platform I think 22.57.01 # will look at this 22.57.20 # look at system.S, it quite commented :) 22.57.30 # <[Saint]> choki: are you aware what channel this is? 22.57.44 # sorry im silent now xD 22.57.59 # <[Franklin]> choki: -> #rockbox-communnity 22.58.01 # <[Saint]> I'm just curious, it wasn't me saying to be silent. 22.58.15 # <[Saint]> Its just the the iPod Touch has absolutely zero relevance to Rockbox. 22.58.40 # It could have if rockbox was ported to it or ios 22.59.01 # <[Saint]> That's a _huge_ if. 23.00.08 # wodz: I'm going to bed, feel free to ask tomorrow if you have more questions 23.00.20 # pamaury: ok, thanks 23.00.22 # im just think about if i get a sandisk clip+ and get rid of all that stuff in my pants :D 23.00.49 # Hey, is there any specific reason why the monkeys audio codec decodes so slowly? 23.03.21 # <[Franklin]> MarcAndersen: because it's an expensive algorithm, I'd think 23.03.59 # yes, but no other codec is so slow to decode. 23.04.33 Quit pamaury (Ping timeout: 256 seconds) 23.04.47 # <[Franklin]> because no other codec is designed to such extreme specifications 23.04.56 # I have a file where it plays one second of it, then there is 10 seconds of silance and then a second of audio again and so on 23.05.37 # I will just stick to flac 23.05.59 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 23.06.11 # <[Saint]> If you can demonstrate an actual regression, its worth looking into. 23.06.19 # <[Saint]> But in general, its a rather insane codec. 23.06.39 # <[Saint]> And precisely nothing that should influence decoding speed has been changed in a long time. 23.06.45 # this is not #codec :D 23.07.37 Mode "#rockbox +o [Saint]" by ChanServ (ChanServ@services.) 23.07.44 # <[Saint]> we wanna play this game huh? ;) 23.07.56 Nick [Franklin] is now known as [ATFranklin] (~franklin@unaffiliated/franklin) 23.08.12 Nick [ATFranklin] is now known as [Franklin] (~franklin@unaffiliated/franklin) 23.08.12 Mode "#rockbox -o [Saint]" by ChanServ (ChanServ@services.) 23.08.17 Nick [Franklin] is now known as [ImAnOperator] (~franklin@unaffiliated/franklin) 23.08.19 Nick [ImAnOperator] is now known as [Franklin] (~franklin@unaffiliated/franklin) 23.08.31 # but you only get a few more bytes of compression on monkeys audio insane besides preset 8 of flac 23.08.41 # <[Franklin]> yep 23.08.49 # <[Franklin]> it's stupid, APE 23.09.36 # <[Saint]> Anyway, as stated, if you can demonstrate an actual regression. I mean, if we've _actually_ gotten worse in decoding APE, which I doubt, it is definitely worth looking into. 23.10.01 # <[Saint]> In general its terrible on all but the fastest devices. 23.10.18 # I just think it's the codec. my computer needs a second before even beginning to play, or when i seek in the file... 23.10.22 # <[Saint]> There's really no good reason to use it over more conventional lossless codecs. 23.10.50 # <[Franklin]> disk is cheap 23.12.08 # <[Saint]> see: http://www.rockbox.org/wiki/CodecPerformanceComparison 23.12.10 # disk may be cheap, but you have to backup too 23.12.21 # <[Saint]> it really isn't the best choice at all. 23.12.24 # <[Saint]> by a wide margin. 23.12.44 # <[Franklin]> foolsh: I got curves working now 23.12.47 # <[Franklin]> faked curves, that is 23.14.33 Quit bluebrother (Disconnected by services) 23.14.34 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 23.15.11 # wow! a target on around 8% realtime with ape... that is insane 23.15.35 Join williamtdr [0] (uid27909@gateway/web/irccloud.com/x-ivmwswuxxyeoeaaa) 23.16.03 # <[Saint]> compared to the gigabeat with flac: 23.16.03 Quit fs-bluebot (Ping timeout: 245 seconds) 23.16.04 # <[Saint]> flac_5.flac 5395.70% realtime Decode time - 3.26s 9.78MHz 23.16.04 # <[Saint]> flac_8.flac 4997.15% realtime Decode time - 3.52s 10.56MHz 23.16.08 # <[Saint]> lol 23.16.12 # <[Franklin]> SPAM! :P 23.16.38 # woooow! 23.17.48 # do u listen to flac or mp3 guys? 23.18.03 Join fs-bluebot [0] (~fs-bluebo@f053152109.adsl.alicedsl.de) 23.18.18 # <[Saint]> Cook RA on the MSM7227 (ARMv6) is nuts...I wonder why its _so_ efficient to decode on that SoC in particular? 23.18.27 # <[Saint]> pity is an awful codec, but, wow. 23.18.47 # I have tin ears, and I only listen to compressed audio 23.19.09 # <[Franklin]> forget sound 23.19.21 # <[Franklin]> rockbox is the ultimate mobile gaming experience :D 23.19.21 # <[Saint]> If I'm streaming from my home server (which I usually do), I se mp3@320 23.19.30 # <[Saint]> on-device, I use flac8 23.20.22 # <[Saint]> I should so some flac decode numbers on the Snapdragon 801 23.20.29 # <[Saint]> I bet that's be damn impressive. 23.20.47 # <[Saint]> likely somewhere in the order of 10,000% realtime 23.20.52 # <[Saint]> if not more. 23.21.50 # <[Saint]> if a wee single core MSM7227 ARMv6 can do it at ~7000% realtime, imagine what four times the CPU and four times the cores can do. 23.22.12 # <[Saint]> there's a point, though, where it just gets silly. 23.23.03 # <[Franklin]> I doubt that you need 40,000% realtime 23.23.19 # <[Saint]> precisely. 23.23.31 # <[Saint]> I doubt it'd scale linearly like that, but, yeah. 23.24.24 # <[Saint]> There's a lot more factors than just how many MHz and how many cores you can throw at decoding that make this difference. 23.25.03 # <[Saint]> but, yeah, I would posit the Sanpdragon 801 and 805 would barely break a sweat at flac or wav at all. 23.25.32 # <[Franklin]> wav!? 23.25.48 # <[Franklin]> even a z80 could decode wav at 1000% realtime 23.26.06 # <[Franklin]> what "decoding" is there to do? :P 23.26.26 # * [Saint] posits that number is more than a slight exaggeration. 23.26.36 # <[Saint]> drastically so, but, whatevs. 23.28.13 # <[Saint]> I also wonder if you're talking about the 2.5, 4, or 20MHz variants. 23.28.34 # <[Saint]> Though I sincerely doubt any of them could do 1000% realtime flac decode. 23.28.41 # <[Saint]> quite sincerely. 23.28.41 # <[Franklin]> wav 23.29.13 # <[Saint]> and? 23.30.34 # <[Saint]> If you can get a z80 to do 1000% realtime decode of flac8, hell, I'll let you away with flac5, on a z80, any z80 variant (2.5/4/20MHz), there's hats to be eaten. 23.31.02 # <[Saint]> gah, sorry, wavpack. 23.31.19 # <[Franklin]> yeah... ;P 23.32.42 Quit wodz (Quit: Leaving) 23.32.57 # <[Saint]> The Classic can't even do it. ;) 23.33.47 # <[Saint]> The Gigabeats can, just. 23.34.53 # * [Saint] should really get around to fixing his Beast 23.35.37 # <[Saint]> (Gigabeat S - aka. The Badass, DAP of Doom, Destroyer of Codecs) 23.35.47 # <[Franklin]> DAP of DooM? 23.36.04 # * [Franklin] imagines that DooM is quite nice on the DAP of Doom 23.36.32 # * choki is listening to E.S. Posthumus :3 23.37.09 Join saratoga_ [0] (123e1c4f@gateway/web/freenode/ip.18.62.28.79) 23.37.20 # WAV isn't decoded, its just copied directly from the disk to the DAC 23.37.33 # if you benchmark wav decoding its really just a hard disk benchmark 23.38.01 Quit ender` (Quit: Two possibilities exist: Either we are alone in the Universe, or we are not. Both are equally terrifying. -- Arthur C. Clarke) 23.38.28 # <[Franklin]> saratoga_: sobukus thinks that G#887 is "ready" 23.38.32 # 3Gerrit review #887 at http://gerrit.rockbox.org/r/887 : 3Enhancement of the metronome plugin: by Thomas Orgis 23.38.45 # pretty much anything with a hardware 32 bit multiply instruction will decode flac 23.39.04 # <[Franklin]> though you may want to read the latest review 23.39.49 # could someone else look at this? i'm kind of busy this week and don't have time to fool around in case it breaks on some target 23.40.12 # <[Franklin]> I've just glanced through it 23.43.51 Quit xorly (Ping timeout: 240 seconds) 23.51.23 Quit lebellium (Quit: ChatZilla 0.9.91.1 [Firefox 35.0/20150108202552]) 23.55.12 Join xorly [0] (~xorly@m180.dkm.cz) 23.56.40 Join Karmadealer [0] (59844aaa@gateway/web/freenode/ip.89.132.74.170) 23.57.47 Quit choki (Quit: Page closed)