--- Log for 15.01.115 Server: sendak.freenode.net Channel: #rockbox --- Nick: logbot- Version: Dancer V4.16 Started: 7 days and 23 hours ago 00.04.03 Quit AlexP (Remote host closed the connection) 00.12.47 Join pystar89 [0] (~pystar89@ip-178-203-30-225.hsi10.unitymediagroup.de) 00.20.06 Quit xorly (Ping timeout: 252 seconds) 00.21.13 Quit ender1 (Quit: Religion is regarded by the common people as true, by the wise as false, and by the rulers as useful. -- Seneca) 00.24.22 # [Franklin]: I was thinking, if you wanted to keep the random track generation, which I like who wants to play the same old tracks everytime, you could copy the first N track features over the last N track features and then setting Z to zero would be smooth as a babies bottom 00.26.12 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 00.28.53 Quit fs-bluebot (Ping timeout: 244 seconds) 00.29.42 Quit bluebrother^ (Ping timeout: 272 seconds) 00.30.03 Join fs-bluebot [0] (~fs-bluebo@f053155105.adsl.alicedsl.de) 00.33.39 Quit bertrik (Remote host closed the connection) 00.36.35 Quit ZincAlloy (Quit: Leaving.) 00.38.18 *** Saving seen data "./dancer.seen" 00.42.02 Quit prof_wolfff (Ping timeout: 264 seconds) 01.08.58 Quit fs-bluebot (Quit: connection lost?) 01.09.00 Join fs-bluebot [0] (~fs-bluebo@f053155105.adsl.alicedsl.de) 01.12.28 Quit fs-bluebot (Ping timeout: 276 seconds) 01.12.48 Quit markun (Ping timeout: 244 seconds) 01.13.09 Join fs-bluebot [0] (~fs-bluebo@g226068253.adsl.alicedsl.de) 01.13.15 Quit bluebrother (Ping timeout: 264 seconds) 01.17.27 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 01.33.29 Quit RiD (Quit: A good plan today is better than a perfect plan tomorrow.) 01.34.18 Quit d33tah (Ping timeout: 244 seconds) 01.35.34 Quit TheLemonMan (Quit: leaving) 01.41.30 Join d33tah [0] (~d33tah@kolos.math.uni.lodz.pl) 02.07.25 # <[Franklin]> foolsh: I'm doing that now 02.07.41 # <[Franklin]> I'm just trying to get track looping fixed, and then I'll push 02.11.11 # <[Franklin]> right now it loops, but there's a gap between the end and beginning of the track 02.16.40 # <[Franklin]> another method I tried doesn't have the gap, but there's a slight delay between loops 02.19.40 # <[Franklin]> I give up 02.19.46 # <[Franklin]> I'll just push the one that has a gap 02.23.34 # <[Franklin]> huh? patch set 16 to patch set 18?! 02.25.18 Join AlexP [0] (~alex@rockbox/staff/AlexP) 02.38.21 *** Saving seen data "./dancer.seen" 02.47.38 # <[Franklin]> ok... now for some fog! 02.59.18 Quit AlexP (Remote host closed the connection) 03.15.35 # <[Franklin]> foolsh: I'm guessing I could optimize this a lot by only calling project() once per segment, because 1 point of the segment is shared with the previous 03.36.30 Quit [Franklin] (Quit: Lost terminal) 04.14.03 Join prof_wolfff [0] (~prof_wolf@213.37.219.26.dyn.user.ono.com) 04.14.04 Quit krabador (Quit: Sto andando via) 04.16.07 Join Strife89 [0] (~Strife89@adsl-98-80-223-97.mcn.bellsouth.net) 04.18.37 Quit Marex (Ping timeout: 245 seconds) 04.20.39 Join Marex [0] (~Marex@195.140.253.167) 04.38.23 *** Saving seen data "./dancer.seen" 04.38.38 Join titanium [0] (~n00b81@253.sub-70-192-5.myvzw.com) 04.39.16 # happy holidays everyone! :P http://y2u.be/G_MdLl0061s 04.39.26 Quit titanium (Client Quit) 04.45.23 Join chrisb [0] (~chrisb@li482-205.members.linode.com) 05.02.46 Quit TheSeven (Disconnected by services) 05.02.56 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 05.16.10 Quit Marex (Ping timeout: 244 seconds) 05.23.26 Quit bzed (Remote host closed the connection) 05.28.13 Join Marex [0] (~Marex@195.140.253.167) 05.33.24 Quit dfkt (Read error: Connection reset by peer) 05.33.37 Join dfkt [0] (dfkt@unaffiliated/dfkt) 06.01.54 Quit chrisb (Ping timeout: 256 seconds) 06.04.05 Join bzed [0] (~bzed@devel.recluse.de) 06.16.54 Join rela [0] (~x@pdpc/supporter/active/rela) 06.21.47 Quit rela (Ping timeout: 265 seconds) 06.33.15 Join rela [0] (~x@pdpc/supporter/active/rela) 06.38.19 Quit rela (Ping timeout: 272 seconds) 06.38.27 *** Saving seen data "./dancer.seen" 06.44.52 Quit Strife89 (Ping timeout: 240 seconds) 06.49.22 Join rela [0] (~x@p2003006684269A00A1EF2F4985AEED60.dip0.t-ipconnect.de) 06.49.38 Join xorly [0] (~xorly@m180.dkm.cz) 06.49.38 Quit rela (Changing host) 06.49.38 Join rela [0] (~x@pdpc/supporter/active/rela) 06.54.10 Quit rela (Ping timeout: 265 seconds) 07.05.33 Join rela [0] (~x@pdpc/supporter/active/rela) 07.10.36 Quit rela (Ping timeout: 265 seconds) 07.21.45 Join rela [0] (~x@pdpc/supporter/active/rela) 07.27.04 Quit rela (Ping timeout: 272 seconds) 07.28.13 Quit williamtdr (Quit: Connection closed for inactivity) 07.38.02 Join rela [0] (~x@pdpc/supporter/active/rela) 07.42.59 Quit rela (Ping timeout: 265 seconds) 07.46.51 Quit pystar89 (Ping timeout: 264 seconds) 07.52.20 Join pystar89 [0] (~pystar89@ip-178-203-30-225.hsi10.unitymediagroup.de) 07.54.06 Quit xorly (Ping timeout: 256 seconds) 07.54.17 Join rela [0] (~x@pdpc/supporter/active/rela) 07.58.56 Quit rela (Ping timeout: 265 seconds) 08.02.11 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 08.05.14 Quit rasher (Remote host closed the connection) 08.10.30 Join rela [0] (~x@pdpc/supporter/active/rela) 08.15.12 Quit rela (Ping timeout: 272 seconds) 08.15.58 Quit Guest75680 (Ping timeout: 244 seconds) 08.17.47 Join rasher [0] (~rasher@rockbox/developer/rasher) 08.22.42 Join ender` [0] (krneki@foo.eternallybored.org) 08.26.45 Join rela [0] (~x@pdpc/supporter/active/rela) 08.29.04 Join Guest75680 [0] (Slayer@69.143.14.62) 08.30.44 Join petur [0] (~petur@rockbox/developer/petur) 08.31.40 Quit rela (Ping timeout: 272 seconds) 08.35.20 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 08.38.30 *** Saving seen data "./dancer.seen" 08.43.00 Join rela [0] (~x@pdpc/supporter/active/rela) 08.47.45 Quit rela (Ping timeout: 265 seconds) 08.59.16 Join rela [0] (~x@pdpc/supporter/active/rela) 09.03.58 Quit rela (Ping timeout: 272 seconds) 09.07.34 Join maruk1 [0] (~papier@titanium.v6.sdv.fr) 09.16.21 Join mortalis [0] (~kvirc@212.44.150.238) 09.18.01 # Hey, concerning G#887, can someone tell me if it's reasonable to assume that drawing the display after starting playback of a sound bit is expected to interrupt the playback on certain (slow) targets? 09.18.06 # 3Gerrit review #887 at http://gerrit.rockbox.org/r/887 : 3Enhancement of the metronome plugin: by Thomas Orgis 09.19.06 Quit pamaury (Ping timeout: 256 seconds) 09.34.23 Join edhelas [0] (~edhelas@193.172.124.224) 09.42.10 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 09.43.04 # sobukus: Yes it can. It is target specific if irqs are prioritized and if nested irqs are allowed. 09.48.02 # wodz: Thanks. I modified the patch now to draw the display first, then start playing the sound. 09.48.59 # I guess the YH820 is a platform that has trouble running the Doom plugin;-) 09.51.16 # wodz: Hm, I looked at the amazon page for the YH820 ... first reviewer says "iriitating stumbling/jumps/gaps while playing music". So I guess if my metronome works on that one without hickup, I'm fine. 09.53.39 # YH820 is PP so dual core arm7tdmi running at 80MHz max. Thats a bit outdated technology. Do not have high expectations :-) 09.55.03 Join pamaury [0] (~quassel@sphinx.lix.polytechnique.fr) 09.55.03 Quit pamaury (Changing host) 09.55.03 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 09.55.22 # pamaury: did you test hwstub failover? 09.58.53 # wodz: Dual Core! that sounds fancy;-) 09.59.30 # sobukus: yes, but you need to make explicit use of that 09.59.35 # * sobukus wonders if porting libmpg123 decoder into rockbox would help that target, too. 09.59.39 # 3Gerrit review #123 at http://gerrit.rockbox.org/r/123 : 3Add an alternative analogic touchpad sensitivity setting by Jean-Louis Biasini 09.59.56 # ... as the fixed-point mpg123 needs less cpu than mad (for 16 bit accuracy, not 24) 10.00.00 # 3Gerrit review #123 at http://gerrit.rockbox.org/r/123 : 3Add an alternative analogic touchpad sensitivity setting by Jean-Louis Biasini 10.00.17 # sobukus: codecs are highly optimized. We diverged from mad quite much 10.00.57 # and mp3 decoder makes use of dualcore actually 10.03.08 # Oh, then there's no chance. On a test I saw mpg123's ARM fixed-point decoder needing 86 s compared to 130 s for madplay ... that might not be enough to catch your opts + dual core. 10.03.16 # 3Gerrit review #123 at http://gerrit.rockbox.org/r/123 : 3Add an alternative analogic touchpad sensitivity setting by Jean-Louis Biasini 10.03.16 # 3Gerrit review #86 at http://gerrit.rockbox.org/r/86 : 3LAMP plugin PLA integration (main code + manual) by Jean-Louis Biasini 10.03.21 # (that was on debian) 10.03.34 # Poor fs-bluebot :) 10.04.20 # wodz: You might forgive me the though as I happen to maintain mpg123;-) 10.04.25 # 3Gerrit review #123 at http://gerrit.rockbox.org/r/123 : 3Add an alternative analogic touchpad sensitivity setting by Jean-Louis Biasini 10.04.55 # fs-bluebot is too inquisitive :-) 10.06.05 # Of course our mp3 decoder only makes use of dualcore on dualcore DAPs 10.06.39 # So if it were only that, there might be more room 10.06.56 # I should actually look into what you did there. It's not obvious for me right there what parts you parallelized. 10.07.43 # And I must admit that mpg123's recent speed is not due to me but to a guy from Asia who is really good with assembly. 10.07.48 # 3Gerrit review #123 at http://gerrit.rockbox.org/r/123 : 3Add an alternative analogic touchpad sensitivity setting by Jean-Louis Biasini 10.09.20 # oh, shut up stupid bot! 10.09.44 # Maybe we need to call it mpgonetwothree in here :) 10.10.36 # take a look at http://git.rockbox.org/?p=rockbox.git;a=tree;f=lib/rbcodec/codecs/libmad;h=1f60d2f87d482326cbf1b4efb15a5462a2531eec;hb=HEAD 10.10.53 # or ask saratoga or preglow 10.11.18 # Or n1s, if he shows up 10.13.54 # Or possibly amiconn 10.14.57 Quit nialv7 (Ping timeout: 255 seconds) 10.19.49 # wodz: trying right now... 10.24.06 # wodz: it works 10.24.24 # pamaury: goodie. I think it should go in 10.24.51 # go on 10.25.00 Join markun [0] (~markun@rockbox/developer/markun) 10.25.29 # Build Server message: 3New build round started. Revision 2cdfc43, 254 builds, 26 clients. 10.27.47 # pamaury: Arm part could use the same approach as mips to avoid non obvious double register restore but I really don't care 10.28.14 # wodz: what is your approach ? 10.29.43 # pamaury: If I understand correctly you save both pc (well pc+8 actually) and lr in context and exploit the pc+8 thing. But you can load PC with lr directly and avoid saving PC and double restore 10.30.29 # Build Server message: 3Build round completed after 301 seconds. 10.30.31 # Build Server message: 3Revision 2cdfc43 result: All green 10.31.07 # pamaury: you need to update status flags on return but this can be made with movs or something 10.32.08 # ah yes possibly, but there is the issue of sp I think 10.32.32 # which issue? 10.33.04 # you need to restore sp_sys 10.34.48 # honestly I don't remember the details right now, I would need to open the assembly manual 10.36.02 # anyway I wouldn't bother. There is a few ways to do this probably. 10.36.09 # *are 10.38.31 *** Saving seen data "./dancer.seen" 10.38.41 # pamaury: the first ldmia does everything except PC restore, right? so instead of second ldmia it could be simple subs pc, lr, #4, no? 10.40.08 # yes the second ldmia could be simplified indeed 10.40.42 # hum, except I'm not sure 10.40.56 # so instead of second ldmia it would be move r0, #1 to signal error and subs pc, lr, #4 to do the comeback 10.41.59 # because the first ldmia restores user registers, so after the ldmia, lr is the is still lr_abt and not lr_sys 10.42.26 # I don't remember if those are the same or not 10.44.25 # so it's bit more tricky I think 10.58.11 Join AlexP [0] (~alex@rockbox/staff/AlexP) 11.15.08 Quit preglow (Quit: leaving) 11.23.11 Join LinusN [0] (~linus@giant.haxx.se) 12.02.17 Join preglow [0] (~thomj@2001:840:4243:3:1010:1010:1010:1010) 12.33.08 Join pamaury_ [0] (~quassel@rockbox/developer/pamaury) 12.38.32 *** Saving seen data "./dancer.seen" 12.51.21 Quit wodz (Read error: Connection reset by peer) 13.03.45 Join TheLemonMan [0] (~lemonboy@unaffiliated/thelemonman) 13.06.15 Quit AlexP (Remote host closed the connection) 13.18.34 Join AlexP [0] (~alex@rockbox/staff/AlexP) 13.34.00 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 14.00.53 # pamaury: reading this: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471g/Ciheidgb.html and http://www.ic.unicamp.br/~celio/mc404-2013/arm-manuals/ARM_exception_slides.pdf I think that on ARM this should work: http://pastie.org/9833257 14.02.02 # wodz: I'm not so sure, the ldmia will restore sp and lr in sp_abt and lr_abt, not in sp_sys and lr_sys ? 14.02.19 # for lr that's ok but for sp I think there is a problem 14.02.37 # pamaury: I explicitely switch to sys with msr cpsr, #0xdf 14.03.32 # ah sorry, I spoke too fast 14.08.21 # I think this should work, I'll try it on target, thanks :) 14.10.16 Quit bluebrother (Ping timeout: 245 seconds) 14.10.36 Quit fs-bluebot (Ping timeout: 252 seconds) 14.11.27 Join fs-bluebot [0] (~fs-bluebo@g226071209.adsl.alicedsl.de) 14.12.40 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 14.14.26 Quit pamaury_ (Ping timeout: 276 seconds) 14.38.35 *** Saving seen data "./dancer.seen" 14.56.26 Quit wodz (Read error: Connection reset by peer) 15.15.09 Join chrisb [0] (~chrisb@li482-205.members.linode.com) 15.29.55 Join amayer [0] (~amayer@mail.weberadvertising.com) 15.58.14 Quit mortalis (Ping timeout: 264 seconds) 16.14.05 Quit JanC (Read error: Connection reset by peer) 16.21.42 Quit TheLemonMan (Quit: leaving) 16.28.41 Join JanC [0] (~janc@lugwv/member/JanC) 16.38.37 *** Saving seen data "./dancer.seen" 17.21.58 Quit edhelas (Ping timeout: 246 seconds) 17.49.02 Quit eeeeeta (Quit: Server rebooting, be back in a tick!) 18.01.57 Quit the-kyle (Remote host closed the connection) 18.05.23 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 18.09.13 Join RiD [0] (~RiD@bl22-15-59.dsl.telepac.pt) 18.09.22 Join the-kyle [0] (~kyle@kyle.tk) 18.24.06 Quit Ivoah (Quit: Leaving...) 18.36.50 Quit pamaury (Remote host closed the connection) 18.38.38 *** Saving seen data "./dancer.seen" 18.52.57 Join edhelas [0] (~edhelas@77-173-17-40.ip.telfort.nl) 19.11.29 Join xorly [0] (~xorly@m180.dkm.cz) 19.18.57 Quit maruk1 (Quit: Leaving.) 19.19.27 Quit chrisb (Ping timeout: 255 seconds) 19.22.57 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 19.26.14 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 19.30.02 Join chrisb [0] (~chrisb@li482-205.members.linode.com) 19.31.10 Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) 20.13.41 Quit edhelas (Ping timeout: 245 seconds) 20.21.46 Join rela [0] (~x@pdpc/supporter/active/rela) 20.22.43 Join TheLemonMan [0] (~lemonboy@unaffiliated/thelemonman) 20.35.58 Join amayer_ [0] (~amayer@mail.weberadvertising.com) 20.37.04 Quit amayer (Ping timeout: 252 seconds) 20.38.39 *** Saving seen data "./dancer.seen" 20.56.38 Join krabador [0] (~krabador@unaffiliated/krabador) 20.59.01 Join Ivoah [0] (~Ivoah@dsl-216-227-122-44.taconic.net) 21.19.59 Join wodz [0] (~wodz@89-75-106-221.dynamic.chello.pl) 21.23.09 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 21.35.05 Quit y4n (Quit: 6,000,000 ways to die — choose one.) 21.43.39 Quit krabador (Quit: Sto andando via) 21.43.41 Join Jinx [0] (Dojo@unaffiliated/jinx) 21.58.18 Join lebellium [0] (~chatzilla@89-93-177-161.hfc.dyn.abo.bbox.fr) 22.14.40 Quit LinusN (Quit: disconnecting from stoned server.) 22.18.42 Join LinusN [0] (~linus@giant.haxx.se) 22.38.43 *** Saving seen data "./dancer.seen" 22.41.13 Join [Franklin] [0] (~franklin@unaffiliated/franklin) 22.41.48 # <[Franklin]> does someone here have an iPod nano 6g? 22.41.53 # <[Franklin]> (no typo there) 22.42.14 # <[Saint]> I do. 22.43.15 # <[Franklin]> woops... wrong channel :[ 22.43.35 # <[Franklin]> moving to #freemyipod 22.46.55 # [Franklin]: I think valleys should be added to xrace (as opposite to hills) 22.47.26 Join edhelas [0] (~edhelas@77-173-17-40.ip.telfort.nl) 22.47.28 # <[Franklin]> then do it :P 22.47.34 # <[Franklin]> wodz: it's pretty difficult 22.48.04 # I'll stick to giving good advices :-) 22.48.11 # <[Franklin]> wodz: the game represents the world as an array of segments 22.48.31 # <[Franklin]> the segments are infinitely wide and aligned to the x-axis 22.48.40 # <[Franklin]> so it's not possible now 22.49.07 # <[Saint]> If hills are possible, valleys are too... 22.49.16 # <[Franklin]> yes, but it ain't easy 22.49.24 # <[Franklin]> (plus, it'll run slow) 22.49.42 # <[Saint]> I love that... 22.49.42 # <[Saint]> "its not possible" 22.49.49 # <[Saint]> "you can do it but..." 22.50.11 Quit rela (Ping timeout: 265 seconds) 22.50.17 # <[Franklin]> not now, at least with the framework that's in place 22.51.09 # <[Franklin]> for now, let me optimize the thing :P 22.51.11 # <[Saint]> If it runs slowly, that would seem to imply some form of code/optimization error. Arcade machines with a LOT less hardware were doing this over twenty years ago. 22.51.40 # <[Franklin]> I would think so 22.51.52 # <[Franklin]> doing valleys would require true 3d projection and rotation, I'd think 22.51.55 # you probably know that early optimization is asking for trouble, right? 22.52.08 # <[Saint]> ^ this 22.52.28 # <[Franklin]> eh... true 22.54.08 # <[Franklin]> anyhoo... I'll try to get track looping in place 22.55.38 # <[Saint]> I suppose its a bit unfair that these early arcade games are using assembly, but, yeah - there theoretically shouldn't be any reason why even the least powerful of our supported devices couldn't generate worlds on-the-fly with reasonable results. 22.55.57 # <[Franklin]> valleys? 22.56.06 # <[Franklin]> ohhhh....... 22.56.20 # <[Franklin]> I thought you meant hills at the /side/ of the road 22.56.20 # <[Saint]> Perhaps (almost certainly, actually) you're concentrating on aesthetics too much. 22.57.11 # <[Saint]> Adding fog, for instance. 22.57.28 # <[Franklin]> yeah 22.57.38 # <[Franklin]> but looping the track is pretty important, no? 22.57.50 # <[Saint]> I should think so, yes. 22.58.22 # <[Franklin]> wodz: the game supports valleys and hills 22.58.32 # <[Franklin]> I misunderstood you at first 22.59.13 # [Franklin]: I fired it a few times and only hills were present 22.59.48 # <[Franklin]> by valleys you mean downhills followed by uphills? 23.00.50 Quit amayer_ (Quit: Leaving) 23.00.51 # <[Saint]> He likely means travelling through a valley, as opposed to over it. 23.01.01 # <[Franklin]> ??? 23.01.56 # <[Saint]> http://i.guim.co.uk/static/w-620/h--/q-95/sys-images/Guardian/Pix/pictures/2014/9/22/1411398610361/a473b38f-0992-484c-a015-995f43cac8f4-620x372.jpeg 23.01.59 # <[Saint]> example 23.02.05 # <[Saint]> see either side of the road? 23.02.07 # <[Franklin]> this can do that 23.02.39 # <[Saint]> I don't mean the plane in front and rear of the vehicle, and I suspect wodz doesn't either. 23.02.48 # <[Saint]> I mean the plane on either side of the vehicle 23.02.56 # <[Saint]> just to be totally clear. 23.03.14 # <[Franklin]> so driving through a valley, not down and up? 23.03.17 Quit thomasjfox (Quit: Konversation terminated!) 23.03.19 # <[Saint]> right 23.03.22 # <[Franklin]> as in, the walls are at your sides? 23.03.26 # <[Saint]> right 23.03.31 # <[Franklin]> oh... no 23.03.41 # <[Saint]> wodz, that's what you were referring to, yes? 23.05.18 Join williamtdr [0] (uid27909@gateway/web/irccloud.com/x-cvabgzknpvakadha) 23.05.39 # <[Franklin]> or this: https://mediacru.sh/QuGP8X-q-Ppx 23.06.10 # [Saint]: both. First I thought why it does only uphills followed by downhills only, later I thought about something like on the picture 23.07.29 # * [Saint] nods 23.10.05 # <[Franklin]> wodz: the road generation is completely random 23.10.05 # <[Franklin]> it can generate uphills and downhills randomly 23.10.14 # <[Franklin]> in the future, I might want to have it randomly generate hills or valleys 23.10.33 # <[Franklin]> and also use floats for at least the Y coordinates to smooth out the hills 23.10.48 # [Franklin]: I must have been unlucky then 23.11.01 # <[Franklin]> yeah 23.11.16 # <[Franklin]> also, you can recompile with a longer road length/draw distance 23.11.49 # [Franklin]: Are you kidding? The very first thing which will make performance boost is to stick with integer only math. 23.12.15 # <[Franklin]> true... 23.12.25 # the macro ROUND() is terrible as casting first to float and then again to integer. ugggh 23.12.38 # <[Franklin]> how should I do it? 23.12.44 # Also, four billion different altitudes not good enough for you? 23.14.43 # <[Franklin]> maybe messing with the camera depth would make the y intervals smaller 23.14.47 # <[Saint]> Hahahaha 23.15.24 # <[Saint]> Its like watching a very slow motion train wreck. 23.15.41 # <[Franklin]> hmm? 23.17.26 # <[Franklin]> a lower camera depth seems to give smaller y intervals 23.18.16 Join krabador [0] (~krabador_@unaffiliated/krabador) 23.18.29 # a 32 bit integer is good enough to span the entire altitude range on earth (lowest bit of seafloor to higherst mountaintop) with an accuracy of 4.6 micrometers 23.18.41 # Is that not good enough? 23.18.50 # <[Franklin]> I want the moon! 23.19.18 # gevaerts: LOL 23.20.02 # <[Saint]> [Franklin]: https://www.youtube.com/v/wY6insZjCfU 23.29.45 Quit aevin (Ping timeout: 252 seconds) 23.32.08 Quit wodz (Quit: Leaving) 23.36.11 Quit chrisb (Ping timeout: 245 seconds) 23.37.03 Join aevin [0] (eivindsy@unaffiliated/aevin) 23.42.44 # <[Franklin]> I suppose I'll add on-the-fly FOV compuation 23.43.00 # <[Franklin]> cam_depth=LCD_WIDTH/tan(FOV/2) 23.43.02 Quit scorche (Disconnected by services) 23.43.06 Join scorche` [0] (~scorche@rockbox/administrator/scorche)