Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2020-10-06

00:03:25 Quit TheSeven (Ping timeout: 240 seconds)
00:03:56 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
00:34:09***Saving seen data "./dancer.seen"
01:00
01:19:04 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de)
01:23:44 Quit ZincAlloy (Ping timeout: 272 seconds)
01:24:03_bilgus_I got the set framebuffer to do what I wanted like 2 years ago when I made the RLI image library
01:24:27_bilgus_Looks like there will be some new things and some redundant code
01:32:01 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:75cf:9f02:2818:2d19)
01:33:14 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr)
01:36:55 Quit ZincAlloy (Ping timeout: 272 seconds)
01:40:59bluebrotherg#2802
01:54:04 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de)
01:54:04 Quit ZincAlloy (Client Quit)
02:00
02:01:03 Quit lebellium (Quit: Leaving)
02:05:03 Quit Tsesarevich (*.net *.split)
02:05:05 Quit heredoc_ (*.net *.split)
02:05:05 Quit SammysHP (*.net *.split)
02:05:05 Quit koniu (*.net *.split)
02:05:06 Quit blbro[m] (*.net *.split)
02:05:06 Quit APLU (*.net *.split)
02:05:08 Quit kadoban (*.net *.split)
02:05:08 Quit kugel (*.net *.split)
02:05:08 Quit fs-bluebot (*.net *.split)
02:05:08 Quit vup (*.net *.split)
02:05:08 Quit lemon_jesus (*.net *.split)
02:05:08 Quit genevino (*.net *.split)
02:05:08 Quit bluebrother (*.net *.split)
02:05:08 Quit paulk-leonov (*.net *.split)
02:05:08 Quit jerwin (*.net *.split)
02:05:08 Quit Moarc (*.net *.split)
02:05:08 Quit Topy44 (*.net *.split)
02:05:08 Quit St3ak (*.net *.split)
02:05:08 Quit J_Darnley (*.net *.split)
02:05:09 Quit sh4 (*.net *.split)
02:05:09 Quit tobbez (*.net *.split)
02:05:09 Quit pixelma (*.net *.split)
02:05:09 Quit user890104 (*.net *.split)
02:05:09 Quit Oksana (*.net *.split)
02:05:09 Quit lonoxmont (*.net *.split)
02:05:09 Quit ParkerR (*.net *.split)
02:05:09 Quit advcomp2019 (*.net *.split)
02:05:09 Quit t0mato (*.net *.split)
02:05:09 Quit Acou_Bass (*.net *.split)
02:05:10 Quit speachy (*.net *.split)
02:05:10 Quit Ckat (*.net *.split)
02:05:10 Quit TheSeven (*.net *.split)
02:05:10 Quit _bilgus_ (*.net *.split)
02:05:10 Quit amiconn (*.net *.split)
02:05:10 Quit bzed (*.net *.split)
02:05:10 Quit mendel_munkis (*.net *.split)
02:05:10 Quit ufdm (*.net *.split)
02:05:10 Quit mikroflops (*.net *.split)
02:05:10 Quit emacsomancer (*.net *.split)
02:05:10 Quit rasher (*.net *.split)
02:05:10 Quit Guest93825 (*.net *.split)
02:05:10 Quit aevin (*.net *.split)
02:05:10 Quit JanC (*.net *.split)
02:05:10 Quit Rondom (*.net *.split)
02:05:10 Quit amdj (*.net *.split)
02:05:10 Quit prg318 (*.net *.split)
02:05:10 Quit WakiMiko (*.net *.split)
02:05:10 Quit asaba (*.net *.split)
02:05:10 Quit bleb (*.net *.split)
02:05:10 Quit gevaerts (*.net *.split)
02:05:10 Quit plum (*.net *.split)
02:05:10 Quit copper (*.net *.split)
02:05:10 Quit CommunistWitchDr (*.net *.split)
02:05:10 Quit akaWolf (*.net *.split)
02:05:10 Quit Xeha (*.net *.split)
02:05:10 Quit michaelni (*.net *.split)
02:05:10 Quit galaxy_knuckles (*.net *.split)
02:05:10 Quit Soap_ (*.net *.split)
02:05:10 Quit toruvinn (*.net *.split)
02:05:10 Quit ps-auxw (*.net *.split)
02:05:10 Quit trfl (*.net *.split)
02:05:11 Quit fauweh (*.net *.split)
02:05:11 Quit ChanServ (*.net *.split)
02:05:11 Quit prof_wolfff (*.net *.split)
02:05:11 Quit __builtin (*.net *.split)
02:05:11 Quit Strife89 (*.net *.split)
02:05:11 Quit XDjackieXD (*.net *.split)
02:05:11 Quit _3dsv (*.net *.split)
02:05:11 Quit benedikt93 (*.net *.split)
02:05:12 Quit dys (*.net *.split)
02:05:12 Quit blackyus- (*.net *.split)
02:05:12 Quit shrizza (*.net *.split)
02:05:12 Quit beencubed (*.net *.split)
02:05:12 Quit kirvesAxe (*.net *.split)
02:05:12 Quit mutax (*.net *.split)
02:05:12 Quit olspookishmagus (*.net *.split)
02:05:12 Quit yosafbridge (*.net *.split)
02:05:12 Quit tchan (*.net *.split)
02:05:12 Quit rogeliodh (*.net *.split)
02:05:12 Quit ecs (*.net *.split)
02:05:12 Quit TorC (*.net *.split)
02:05:12 Quit SiliconExarch (*.net *.split)
02:05:12 Quit braewoods (*.net *.split)
02:05:12 Quit ender| (*.net *.split)
02:05:12 Quit TheSphinX^ (*.net *.split)
02:05:12 Quit rudi_s (*.net *.split)
02:05:12 Quit xcin (*.net *.split)
02:05:12 Quit tbaxter (*.net *.split)
02:05:12 Quit ArsenArsen (*.net *.split)
02:05:12 Quit danielp33441 (*.net *.split)
02:05:12 Quit igitoor (*.net *.split)
02:05:12 Quit Galois (*.net *.split)
02:05:12 Quit Jack87 (*.net *.split)
02:05:13 Quit atsampson (Write error: Broken pipe)
02:10:19 Join atsampson [0] (~ats@cartman.offog.org)
02:10:19 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
02:10:19 Join t0mato [0] (~t0mato@193.32.127.158)
02:10:19 Join kugel [0] (~kugel@rockbox/developer/kugel)
02:10:19 Join CommunistWitchDr [0] (quassel@024-217-039-226.res.spectrum.com)
02:10:19 Join fs-bluebot [0] (~fs-bluebo@55d418c6.access.ecotel.net)
02:10:19 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
02:10:19 Join sh4 [0] (shapeless@unaffiliated/sh4)
02:10:19 Join ecs [0] (esawady@d2evs.net)
02:10:19 Join tobbez [0] (tobbez@sagiri.wrya.net)
02:10:19 Join asaba [0] (~asaba@103.113.159.184)
02:10:19 Join _bilgus_ [0] (~bilgus@2605:a000:1301:89f6:1809:d12b:b118:9706)
02:10:19 Join pixelma [0] (marianne@rockbox/staff/pixelma)
02:10:19 Join amiconn [0] (jens@rockbox/developer/amiconn)
02:10:19 Join tbaxter [0] (~Adium@pool-100-34-20-58.phlapa.fios.verizon.net)
02:10:19 Join Oksana [0] (~Wikiwide@Maemo/community/ex-council/Wikiwide)
02:10:19 Join prof_wolfff [0] (~prof_wolf@26.red-83-54-195.dynamicip.rima-tde.net)
02:10:19 Join akaWolf [0] (~akaWolf@88.201.205.56)
02:10:20 Join JanC [0] (~janc@lugwv/member/JanC)
02:10:20 Join TorC [0] (~Tor@fsf/member/TorC)
02:10:20 Join __builtin [0] (~quassel@rockbox/developer/builtin)
02:10:20 Join Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
02:10:20 Join beencubed [0] (~beencubed@209.131.238.248)
02:10:20 Join Rondom [0] (~rondom@modo.nonmodosedetiam.net)
02:10:20 Join bzed [0] (~bzed@shell.bzed.at)
02:10:20 Join tchan [0] (~tchan@lunar-linux/developer/tchan)
02:10:20 Join Xeha [0] (~Xeha@unaffiliated/xeha)
02:10:20 Join mendel_munkis [0] (~mendelmun@65-128-170-32.mpls.qwest.net)
02:10:20 Join lonoxmont [0] (~lonoxmont@024-180-058-254.res.spectrum.com)
02:10:20 Join paulk-leonov [0] (~paulk-leo@leonov.paulk.fr)
02:10:20 Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at)
02:10:20 Join kirvesAxe [0] (kirvesaxe@aulis.sange.fi)
02:10:20 Join Tsesarevich [0] (Tsesarevic@fluxbuntu/founder/joejaxx)
02:10:20 Join danielp33441 [0] (danielp334@gateway/shell/matrix.org/x-xyozojawqtsamnyv)
02:10:20 Join blbro[m] [0] (blbrostrat@gateway/shell/matrix.org/x-zeqtkveknhcuzkja)
02:10:20 Join Strife89 [0] (sid399903@gateway/web/irccloud.com/x-hvumcjonbkillfpb)
02:10:20 Join XDjackieXD [0] (~jackie@tureis.comfix.cc)
02:10:20 Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net)
02:10:20 Join mikroflops [0] (~yogurt@c188-150-217-176.bredband.comhem.se)
02:10:20 Join jerwin [0] (~flippy-fl@unaffiliated/flippy)
02:10:20 Join galaxy_knuckles [0] (~gknux@unaffiliated/galaxy-knuckles/x-1756549)
02:10:20 Join Soap_ [0] (~Soap@rockbox/staff/soap)
02:10:20 Join Moarc [0] (~chujko@a105.net128.okay.pl)
02:10:20 Join ArsenArsen [0] (~Arsen@kshare/developer/ArsenArsen)
02:10:20 Join heredoc_ [0] (heredoc@2a01:7e01::f03c:91ff:fec1:de1d)
02:10:20 Join APLU [0] (~mulx@2a03:7220:8081:2900::1)
02:10:20 Join SiliconExarch [0] (sewiredci@gateway/shell/matrix.org/x-wzebjxbnvvolmxco)
02:10:20 Join braewoods [0] (~braewoods@learnprogramming/staff/braewoods)
02:10:20 Join _3dsv [0] (~3dsv@068-184-255-059.res.spectrum.com)
02:10:20 Join Topy44 [0] (OOvo1SKgJD@bellatrix.uberspace.de)
02:10:20 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
02:10:20 Join St3ak [0] (St3akk@freebnc.bnc4you.xyz)
02:10:20 Join benedikt93 [0] (~quassel@unaffiliated/benedikt93)
02:10:20 Join speachy [0] (~speachy@209.2.65.77)
02:10:20 Join ParkerR [0] (~ParkerR@unaffiliated/parkerr)
02:10:20 Join mutax [0] (~mutax@ip5f590aa6.dynamic.kabel-deutschland.de)
02:10:20 Join SammysHP [0] (~SammysHP@faol.sammyshp.de)
02:10:20 Join ender| [0] (~ender1@2a01:260:4094:1:6045:6fff:fedd:cbf3)
02:10:20 Join genevino [0] (~genevino@m2m.pm)
02:10:20 Join amdj [0] (~aaron@freenode/staff/atheme.amdj)
02:10:20 Join rogeliodh [0] (~rogeliodh@rogeliodh.dev)
02:10:20 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)
02:10:20 Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be)
02:10:20 Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr)
02:10:20 Join vup [0] (~~~~@46.101.193.235)
02:10:20 Join kadoban [0] (kadobanmat@gateway/shell/matrix.org/x-jdkdmdayzlobouuw)
02:10:20 Join lemon_jesus [0] (~lemon_jes@c-73-9-49-209.hsd1.il.comcast.net)
02:10:20 Join Guest93825 [0] (~alex@meowface.org)
02:10:20 Join prg318 [0] (~prg@deadcodersociety/prg318)
02:10:20 Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko)
02:10:20 Join bleb [0] (~cm@unaffiliated/bleb)
02:10:20 Join aevin [0] (~brootvors@unaffiliated/aevin)
02:10:20 Join igitoor [0] (igitur@unaffiliated/contempt)
02:10:20 Join Ckat [0] (~Ckat@xn--z7x.xn--6frz82g)
02:10:20 Join emacsomancer [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net)
02:10:20 Join TheSphinX^ [0] (~briehl@srv001.nosupamu.de)
02:10:20 Join Galois [0] (djao@efnet-math.org)
02:10:20 Join yosafbridge [0] (~yosafbrid@static.38.6.217.95.clients.your-server.de)
02:10:20 Join toruvinn [0] (~toruvinn@178-37-200-229.adsl.inetia.pl)
02:10:20 Join user890104 [0] (~Venci@freemyipod.org)
02:10:20 Join gevaerts [0] (~fg@rockbox/developer/gevaerts)
02:10:20 Join fauweh [0] (~root@ithaqua.unzane.com)
02:10:20 Join ps-auxw [0] (~arneb@p548c61b6.dip0.t-ipconnect.de)
02:10:20 Join rasher [0] (~rasher@rockbox/developer/rasher)
02:10:20 Join dys [0] (~dys@116.203.150.34)
02:10:20 Join copper [0] (~copper@unaffiliated/copper)
02:10:20 Join plum [0] (~plum@unaffiliated/plum)
02:10:20 Join ChanServ [0] (ChanServ@services.)
02:10:20 Join trfl [0] (~ed@static.59.110.40.188.clients.your-server.de)
02:10:20 Join shrizza [0] (~shrizza@oki-180-131-209-187.jptransit.net)
02:10:20 Join blackyus- [0] (~blackyus1@ip189.ip-144-217-213.net)
02:10:20 Join xcin [0] (~x@159.203.132.140)
02:10:20 Join rudi_s [0] (~simon@bmi.informatik.uni-erlangen.de)
02:10:20Mode"#rockbox +o ChanServ " by wilhelm.freenode.net
02:10:20 Join Jack87 [0] (Jack87@nasadmin/admin/jack87)
02:34:10***Saving seen data "./dancer.seen"
03:00
03:10:31 Join petur [0] (~petur@77.77.179.66)
03:10:31 Quit petur (Changing host)
03:10:31 Join petur [0] (~petur@rockbox/developer/petur)
03:10:49 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
03:38:20 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
04:00
04:23:50 Quit pamaury (Ping timeout: 256 seconds)
04:34:12***Saving seen data "./dancer.seen"
04:49:26 Join livvy [0] (~livvy@gateway/tor-sasl/livvy)
05:00
05:30:12 Join mendel_munkis_ [0] (~mendelmun@97-127-7-101.mpls.qwest.net)
05:33:28 Quit mendel_munkis (Ping timeout: 256 seconds)
05:35:16 Join pamaury [0] (~pamaury@maths.r-prg.net.univ-paris7.fr)
05:35:16 Quit pamaury (Changing host)
05:35:16 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
05:57:01 Quit ArsenArsen (Ping timeout: 265 seconds)
06:00
06:02:02 Join ArsenArsen [0] (~Arsen@kshare/developer/ArsenArsen)
06:33:14 Quit TheSeven (*.net *.split)
06:33:14 Quit _bilgus_ (*.net *.split)
06:33:14 Quit amiconn (*.net *.split)
06:33:14 Quit bzed (*.net *.split)
06:34:16***Saving seen data "./dancer.seen"
06:34:39 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
06:34:39 Join _bilgus_ [0] (~bilgus@2605:a000:1301:89f6:1809:d12b:b118:9706)
06:34:39 Join amiconn [0] (jens@rockbox/developer/amiconn)
06:34:39 Join bzed [0] (~bzed@shell.bzed.at)
07:00
07:02:35speachy_bilgus_: fs#13243 appears to be a core bug rather than target-specific
07:02:37fs-bluebothttp://www.rockbox.org/tracker/task/13243 Tree scrolling not showing end of text (bugs, unconfirmed)
07:02:43speachy(yay, bluebot!)
07:05:23 Join akaWolf1 [0] (~akaWolf@188.243.245.20)
07:08:40 Quit akaWolf (Ping timeout: 246 seconds)
07:38:56 Quit lemon_jesus (Ping timeout: 260 seconds)
07:41:37 Join lemon_jesus [0] (~lemon_jes@c-73-9-49-209.hsd1.il.comcast.net)
08:00
08:03:47 Quit Stanley00 (Remote host closed the connection)
08:07:28speachyhuh, the Allwinner FC100s and FC200s look like good candidates
08:12:05speachyARM926EJs, 32/64MB DRAM on-package, built-in audio codec.. pretty similar to the imx233 overall
08:30:01speachyAnd the Sochip S3, 1.2GHz Cortex-A7 with 128MB DDR3 on-package. has onboard PCM with lineout, and also supports proper I2S.
08:30:11speachyaka Allwinner V3
08:31:44speachythe S3/V3 looks _very_ promising. It's meant for video encoding applications but we obviously don't care about any of that.
08:33:59 Join MrZeus__ [0] (~MrZeus@2a02:c7f:70d0:6a00:d82b:a02a:a6ea:a96a)
08:34:20***Saving seen data "./dancer.seen"
09:00
09:15:47 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
09:58:54 Quit akaWolf1 (Read error: Connection reset by peer)
09:59:03 Join akaWolf [0] (~akaWolf@akawolf.org)
10:00
10:08:15 Quit akaWolf (Ping timeout: 258 seconds)
10:24:33 Quit petur (Quit: Connection reset by beer)
10:34:22***Saving seen data "./dancer.seen"
10:43:05 Quit vup (Remote host closed the connection)
10:43:08 Quit massiveH (Quit: Leaving)
10:44:22 Join vup [0] (~~~~@46.101.193.235)
11:00
11:24:59_bilgus_speachy I concur same behavior on clipzip
11:25:23speachyoff-by-one error in the manual scroll limit check?
11:26:37_bilgus_maybe looks like its off by two or 3
11:27:02speachyoff by one "Scroll ratio"
11:27:48_bilgus_I'll reply back to him and get back to it my tree is a mess atm with re-integrating lua and the framebuffer
11:29:08_bilgus_extremely excited at the prospect of less code that way I can implement more on the C- side for 'blazing' speed lol
11:38:09 Quit J_Darnley (Ping timeout: 260 seconds)
11:38:27 Join J_Darnley [0] (~J_Darnley@d51a44418.access.telenet.be)
11:43:41_bilgus_I think BBN has been working with FS what aboutg#2800
11:44:01_bilgus_G#27000
11:44:21_bilgus_but still not gerrit
11:45:18speachythere haven't been any changes on the infra side.
11:47:03speachywell, other than the automatic ssl cert refresh
11:48:00_bilgus_you'd think if he works with fs#1234 then hed work withg#2345
11:48:13fs-bluebothttp://www.rockbox.org/tracker/task/1234 CPUAdrEr at 55555555 (bugs, closed)
11:50:06mendel_munkis_hardcoded cert?
11:50:09 Nick mendel_munkis_ is now known as mendel_munkis (~mendelmun@97-127-7-101.mpls.qwest.net)
11:53:24speachyaven that was a month ago.
11:59:09 Join Telehubis [0] (594cb4e3@89-76-180-227.dynamic.chello.pl)
11:59:33 Quit Telehubis (Remote host closed the connection)
12:00
12:04:38 Quit pamaury (Quit: Konversation terminated!)
12:06:04_bilgus_probably more likely he isn't able to get something from gerrit? I guess it could be a cert issue
12:07:21 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:8c6c:293e:55c6:6dbc)
12:09:23_bilgus_weell damn I had hoped moving to using Rbs framebuffer code would lead to faster screen writing but its exactly the same
12:10:00_bilgus_guess its not really a surprise since they do the same computations on the back
12:11:04_bilgus_but it does allow me to get some code out of lua so still a win
12:11:27 Quit ZincAlloy (Ping timeout: 240 seconds)
12:20:19 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:8c6c:293e:55c6:6dbc)
12:24:49 Quit ZincAlloy (Ping timeout: 272 seconds)
12:34:24***Saving seen data "./dancer.seen"
12:37:27 Quit ArsenArsen (Ping timeout: 240 seconds)
12:40:36 Join ArsenArsen [0] (~Arsen@kshare/developer/ArsenArsen)
12:46:56 Quit kugel (Ping timeout: 260 seconds)
12:47:29 Join kugel [0] (~kugel@rockbox/developer/kugel)
12:52:04 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:d5fe:860d:a844:1a05)
13:00
13:14:18_bilgus_speachy you and braewoods were discussing flexible array members I just ran across this one in lua https://github.com/Rockbox/rockbox/blob/master/apps/plugins/lua/rocklib_img.c#L67
13:14:46_bilgus_I thought that was always allowed or does a FAM have [] empty size?
13:15:20speachyFAMs are by definiton [] or [0]
13:16:38_bilgus_i guess then you get rid of the *data part which is why this way works
13:17:04speachynot sure what the point of having *data and dummy[][] is in this struct; I'd have to see the code using it.
13:17:24_bilgus_so what advantages does the FAM have over this way besides the extra pointer
13:17:25speachy(assuming data points at dummy[][]..
13:17:37_bilgus_data references dummy
13:17:39_bilgus_yeah
13:17:46_bilgus_its all in that code unit
13:18:12_bilgus_I actually just expanded that it was already there when I got it
13:18:25speachynotionally "cleaner" syntax, more obvious what's going on. the compiler can sanity check things a little better, and make it a little harder to shoot yourself in the foot
13:18:37speachy(mind you, it's still _very_ easy to do the latter..)
13:19:23speachyyou won't also accidentally malloc(sizeof(struct rocklua_image)) −− I think in the case of FAMs the compiler will actually barf on you.
13:19:52_bilgus_well already in here doing what I wanted to do the first time round i'll try making it a FAM
13:19:55 Quit ZincAlloy (Ping timeout: 240 seconds)
13:20:30_bilgus_in the other one thatd make a image with one element (pixel)
13:20:34speachyback in the day I used to use dummy[0] a lot, but that was a GCC-ism before C99 formalized the [] syntax.
13:20:55_bilgus_suppose similar to windows GDI
13:21:26speachysizeof() works with FAMs, because that way you can do malloc(sizeof(struct bla) + data_len)
13:21:38speachyhad a little brain fart there. :D
13:22:03 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:3c92:be9f:77bb:edc9)
13:23:42_bilgus_I'm going to start making the images carry around their viewport extra 40 bytes per image but that will allow me to integrate it with the lcd_calls
13:24:41_bilgus_that is where I failed the last time
13:25:15speachysounds like a sane approach
13:25:49_bilgus_wish I could get rid of the element conversion too but the blit stuff needs it to walk the image
13:25:56speachybtw, [ab]using the viewport stuff is probably our only viable path to running on a pure touch-based player −− throwing a permanent button viewport on-screen.
13:26:29speachyand the theme/etc running on the remainder section. don't know how well the plugins/etc would handle that though..
13:27:09_bilgus_well we could reuse the SBS stuff
13:27:30_bilgus_it inserts its own viewport when true
13:28:41_bilgus_viewport.c viewport_set_defaults
13:30:38 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr)
13:31:18speachymakes me wish I hadn't nuked the buttonbar stuff as part of the archos purge
13:31:27_bilgus_the changing of the aspect ratio with that approach might be a bit odd
13:31:43speachyyeah.
13:31:54_bilgus_probably be better to make a floating overlay
13:32:11_bilgus_semi transparent or something
13:32:23_bilgus_an allow the user to move it or hide it or something
13:32:42speachythat's going to be worse from a usability perspective I think
13:32:46_bilgus_swipe over and it pops
13:38:46speachythe way the old buttonbar was implemented was that specific "screens" had to opt-in explicitly, and effectively shrink their own viewports by enabling the buttonbar.
13:39:20_bilgus_fine for core but hell for plugins
13:39:37speachyI'd want to work the other way; the core owns hte BB and presents an appropriate VP.
13:41:01speachybecause without that "BB" there would be no ability to handle input.
13:41:11_bilgus_thats not going to work in plugins that take their own buffer (what I'm doing here) or for ones that set up their own viewports
13:41:18speachyyeah.
13:41:31speachybut there's realistically no other way to do it.
13:41:57_bilgus_keep the full screen vp and overlay the others on it
13:42:25speachywhich is going inevitably hide the part of the screen that matters, no matter where it gets put.
13:42:52speachy(ie the plugins will have to adjust themselves based onwhere they want the fake controls to be displayed)
13:43:09_bilgus_basically give core cartblanche access and let it draw as it pleases
13:44:02speachyhmm. we _could_ change the plugin API to allow the core to restrict the presented viewport.
13:44:18_bilgus_same idea
13:44:20speachy(or rather, the "screen" dimensions
13:44:38speachyso the plugin would continue to think it has the whole screen
13:44:53_bilgus_yeah just process the viewport in set_viewport and alter it accordingly
13:44:58speachyand add another hook to allow the plugin to use a custom "button" scheme
13:45:29speachyI imagine a lot of games would benefit from not being restricted to a DAP-optimized button layout
13:46:20_bilgus_that could pretty easily get integrated into the existing PLA stuff
13:46:48_bilgus_also be a good place to start a stand on button mapping
13:47:08speachyfor any given viewport the core would need to know what coordinates map to which buttons
13:47:45_bilgus_i'd say a little more abstract just an index to which 'button'
13:48:06_bilgus_make the bar a grid of button spaced boxes
13:48:24speachy ... a plugin input rework has value in of itself.
13:50:34_bilgus_luckily most of the plugins use the pla way of doing it
13:51:45speachy(at least) 47 plugins have custom keymaps.
13:52:16_bilgus_yeah but that uses the plugin context function
13:53:09_bilgus_and a lot of that would disappear with some careful perl and intelligent defaults
13:53:13speachymost of those really have no business using custom keymaps.
13:53:26speachypaging Mr. Somebody..
13:54:02_bilgus_I figure we can agree on a way forward and make incremental steps till somebody steps up or we get to it
13:58:56speachyyeah, in my infinite free time I can convert some of those plugins to use the PLA stuff..
14:00
14:00:46_bilgus_:) ok just let me know when its done
14:02:34_bilgus_kidding lol
14:03:21bluebrotherg#27000
14:03:44bluebrotherg#2802
14:03:46fs-bluebotGerrit review #2802 at http://gerrit.rockbox.org/r/2802 : alsa: Refactor pcm_dma_apply_settings_nolock() by Solomon Peachy
14:03:53bluebrotherah :)
14:04:00speachywooo!
14:04:08speachyfs-bluebot: Welcome back
14:04:24speachyfs-bluebot: Now back to he dungeons for you.
14:06:41bluebrotheroutdated script to scraping cgit didn't work.
14:06:51bluebrotherfs-bluebot: .explain yourself
14:06:51fs-bluebotyourself: I'm a simple bot to help out with things in #rockbox.
14:07:10speachyhmm; the gitweb->cgit rewrite rules should have still worked
14:08:01speachy(I mean, I didn't turn it off intentionally..)
14:08:56bluebrotherthe problem is that gitweb was using rss, cgit returns an atom. So the xml parsing has to look for different tags. So that outdated script failed and returned nothing :)
14:09:30speachyyeah.. but it was working well after the transition to cgit. wonder what caused it to fail this time..
14:10:24bluebrotherit was working because I fixed it back then. It broke because I changed something on my end, and ended up using an outdated version that was still using the old gitweb code.
14:10:38speachyaaaah, okay. glad it wasn't me this time.
14:10:54bluebrothernah, this time was on me.
14:19:28mendel_munkisspeachy: are none of the native targets fast enough to be worth enablingg#2760?
14:19:30fs-bluebotGerrit review #2760 at http://gerrit.rockbox.org/r/2760 : codecs: Add support for the 'VTX' ZX Spectrum chiptunes format. by Solomon Peachy
14:19:44speachymendel_munkis: none of the native targets (other than the X3) have an FPU.
14:20:10speachyand while the X3 does, its threading code doesn't store/restore the FPU state.
14:20:24mendel_munkisand you can't run floating point operations on a CPU (at a higher cost)?
14:20:56speachywell, we could, but.. results are likely to be quite poor. you're more than welcome to try.. :D
14:21:30speachytbh that patch is only in gerrit because it came along as part of the M3K dump I received.
14:22:14mendel_munkisso to rephrase my question do we have any native targets where the results of running VTX is likely to be worth it?
14:23:23speachyI don't know. the as3525v2 (most sansas) and imx233 (eg fuze+) might be fast enough.
14:24:17speachysince I think their ARM9s are the fastest (native) ARM ports.
14:26:15speachyjust don't know how truly CPU intensive that codec is.
14:27:03speachyoh, worth mentioning that all of the DSD->PCM decoders I could fine also rely on floating point, so they're in the same boat.
14:34:25***Saving seen data "./dancer.seen"
14:51:52 Join johnb5 [0] (~johnb2@p5b3af293.dip0.t-ipconnect.de)
14:57:08speachymendel_munkis: I've compiled the codec, but I haven't attmpted to run it, not even in a simulator.
14:57:24speachydon't have any files to run through it either
14:58:46 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
15:00
15:00:33 Join sakax [0] (~r0b0t@unaffiliated/r0b0t)
15:06:12_bilgus_emulating fp comes at a steep cost on the clip+ I imagine its similar for the rest
15:07:01mendel_munkisI am updating my local build. (from before the HWCODEC purge so it will be a while) afterwords I'll test on i.mx233 and let you know.
15:07:41speachyFWIW I'd recommend firing it up in a sim build to make sure it even works. :)
15:07:47 Quit johnb5 (Ping timeout: 240 seconds)
15:07:47speachy(which is more than I've done!)
15:51:44_bilgus_and again I get crashes in the lcd image routines
15:51:58_bilgus_I wonder if someone isn't respecting the vieport
15:52:49speachydoes your vp match the actual display?
15:53:01speachy(ie full-screen)
15:59:01_bilgus_not at the time of crash what I want is to set my image as the current fb and use the rb image routines on it
15:59:29_bilgus_I set the viewport as such but it seems drawline doesn't respect the vp perhaps
16:00
16:00:27_bilgus_and I vaguely remember this being the issue last time but I was thinking it crashed with everything
16:02:42_bilgus_hmm it clearly has the checks :/
16:08:02mendel_munkis_bilgus_: what platform?
16:09:02_bilgus_platform?
16:09:15mendel_munkistarget.
16:09:21_bilgus_sim currently
16:09:45_bilgus_targets show same behavior as the sim though if memory serves
16:12:48_bilgus_ok so over allocating the image works
16:13:18_bilgus_now I just have to figure out who isn't respecting the viewport I have selected into the lcd
16:22:52mendel_munkiswhat's line 561 of announce status supposed to be getting a button from?
16:23:26_bilgus_is it the ifdef debug one?
16:23:38mendel_munkisyes
16:24:16_bilgus_it can be removed originally I had it respect the usb insertion but since it doesn't have open file handles its not needed
16:24:44mendel_munkisit needs to be removed.
16:25:35_bilgus_feel free :)
16:30:25mendel_munkismind commitingg#2809?
16:30:27fs-bluebotGerrit review #2809 at http://gerrit.rockbox.org/r/2809 : Fix DEBUG builds by Moshe Piekarski
16:31:12mendel_munkisspeachy: fwiw I can compile the codec but not the metadata.
16:34:27***Saving seen data "./dancer.seen"
16:56:52speachymendel_munkis, I brought that up to bilgus a few days ago.. he was going to fix it properly.
16:57:40mendel_munkiswhat'snot proper about it?
17:00
17:05:03speachyI mean, it fixes the compile problem, but instead of deleting the incomplete code, I think he wanted to finish writing it.
17:06:54mendel_munkisah thats why I asked if it was meant to be doing anything.
17:07:40speachywhoops, I see that now. (bad speachy for not reading the backlog before your question)
17:09:24fs-bluebotBuild Server message: New build round started. Revision cb9280c, 282 builds, 9 clients.
17:18:18 Quit ZincAlloy (Quit: Leaving.)
17:22:33mendel_munkisI don't have any local codecs to compare against, however it appears to be working in sim.
17:23:47fs-bluebotBuild Server message: Build round completed after 862 seconds.
17:23:51fs-bluebotBuild Server message: Revision cb9280c result: All green
17:23:58mendel_munkisthat was a fsat build
17:24:21speachyccache is wonderful
17:28:22speachyI recommend you use the codec_benchmark plugin on the actual target
17:29:02speachymetadata didn't compile? let me see..
17:29:59mendel_munkisThe bad news is that it can't play without reading the metadata first, but on native targets the metadata parser needs codeclib (to be more accurate malloc and strlen) which isn't accesible to codecs
17:30:21mendel_munkiss/codecs/metaddata parsers/
17:33:38speachyheh, (further) patches welcome. :)
17:34:41_bilgus_I thought codecs still had buflib
17:36:26speachythe codec used straight-up malloc()
17:40:21_bilgus_so just alloc a big chunk and use buflib as malloc?
17:40:39_bilgus_what am I missing here?
17:40:54speachynothing, as far as I'm aware.
17:41:12speachymendel_munkis's attempt was the first non-sim/hosted build of that codbase.
17:41:41_bilgus_ah ok I was reading that as it wasn't possible
17:43:30mendel_munkiswhat you are missing is that I don't know enough about memory management to do that.
17:45:18speachythe metadata parser tries to allocate a buffer sized for the entire file
17:46:59speachyheh, the metadata parser leaks memory too.
17:48:05mendel_munkisin that case the codec (which also uses malloc) is also likely to have a memory leak
17:48:33speachyyeah, same leak
17:48:57speachyall of the strings it reads from the VTX header are malloc()d but never freed afterwards.
17:51:32_bilgus_buflib frees when plugins exit automagically doesn't codeclib do same?
17:52:14speachyah, I see why it was done this way −− the codec uses pstrings, no null termination.
17:52:42_bilgus_pstrings like windows bstr?
17:52:56speachyexplicit length
17:53:05speachyI take that back, wtf.
17:53:14mendel_munkiswhere are you finding format information?
17:53:15speachywhis is braindead.
17:59:24speachywhis is braindead.
18:00
18:02:36 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
18:07:32 Quit lebellium (Quit: Leaving)
18:08:25 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
18:13:36 Quit Stanley00 (Ping timeout: 260 seconds)
18:26:57speachymendel_munkis: I updated the vtx codec. it'll at least build cleanly on native now. no promises it won't catch fire and murder kittens.
18:34:29***Saving seen data "./dancer.seen"
18:37:50speachyrewrote the metadata parser to not do that braindead malloc and string parsing. the actual codec I left alone after fixing the memory leak.
18:38:05 Quit pamaury (Ping timeout: 258 seconds)
18:38:51mendel_munkisthanks.
18:39:13mendel_munkisI was just looking for reference material on the format
18:40:53 Quit _bilgus_ (Remote host closed the connection)
18:42:08 Join _bilgus_ [0] (~bilgus@2605:a000:1301:89f6:8ca8:8387:b13d:7123)
18:44:04mendel_munkisBTW it assumes the existenceg#2804
18:44:06fs-bluebotGerrit review #2804 at http://gerrit.rockbox.org/r/2804 : WIP New port: FiiO M3K by Solomon Peachy
18:44:08 Quit _bilgus_ (Remote host closed the connection)
18:44:25speachyyeah
18:45:37 Join _bilgus_ [0] (~bilgus@2605:a000:1301:89f6:8ca8:8387:b13d:7123)
18:46:30mendel_munkisI think the reason for it's braindeadness is that it's a minimal change port from https://github.com/asashnov/libayemu/blob/master/src/vtxfile.c
18:48:25speachyyep. memory leaks are there in the original
18:49:08mendel_munkisno in the original it calls ayemu_vtx_free
18:50:04speachyaaaah, ok.
18:56:24 Quit sakax (Remote host closed the connection)
19:00
19:09:07 Quit t0mato (Quit: Ping timeout (120 seconds))
19:09:21 Join t0mato [0] (~t0mato@193.32.127.158)
19:11:11mendel_munkisyour edits broke string handling. (on the sim as well)
19:11:57mendel_munkisIt also seems too slow to be worth it on my fuze+
19:12:00speachyin the metadata, I assume?
19:12:21mendel_munkis(without actually litening)
19:12:35speachygot a URL to a sample file?
19:12:54mendel_munkisyes. the title and author are a long galrbled mess
19:13:26mendel_munkishttp://bulba.untergrund.net/My_Songs.rar
19:15:25braewoods_bilgus_: that's a hack of sorts. FAM is single dimensional with no given size afaik.
19:22:03speachytitle is sane, author was garbled..
19:22:52mendel_munkisI was playing a rondom track I got out of a set and had both garbled.
19:23:41speachythat rar file only has one in it
19:24:31mendel_munkishttp://bulba.untergrund.net/Tr_Songs.7z Authors/Time keeper/ lost_madness.vtx
19:25:35speachywhoops, I see the issue
19:25:51braewoodsvtx?
19:25:54braewoodswhat's vtx?
19:26:10mendel_munkisZX spectrum ripped audio
19:26:19mendel_munkiswhat's the issue?
19:26:53braewoodsoh, another format in that area... i thought it was some obscure digital audio format.
19:27:07speachyupdated.
19:27:30mendel_munkisis it likely to cause aslowdown?
19:27:47speachyoh, not at all
19:27:55braewoodswell... those types require hardware emulation which is slower than just decoding regular audio usually
19:28:01braewoodsbut maybe not thise format
19:28:06speachyemulated floating point is s...l..o...w
19:28:25mendel_munkisoh no this isslow indeed. (mostly becauseoffloating pointI think)
19:28:46braewoodsso for optimal performance it's better to encode to something else
19:28:52braewoodsbut depends if you can afford the space
19:29:20mendel_munkisOh I dont use the format. I'm just testing it.
19:29:25braewoodsok.
19:29:55braewoodsspeachy: any ideas if opus is slow too? afaik it has alternate decoders for devices that don't have hardware FP.
19:30:17speachypretty sure we can do opus sveral times realtime on even our slowest targets
19:30:28braewoodsok. good.
19:30:32speachyopus is actually pretty CPU-efficient
19:30:47braewoodsnice thing about opus is how good it is at preserving audio quality at low bitrates
19:31:04braewoodsso it's pretty space efficient relative to mp3
19:31:47braewoodsthough i don't see many players support it
19:31:51braewoodsmainly rockbox
19:32:41speachyopus nearly became the new standard bluetooth audio codec
19:33:24 Join fs-bluebot_ [0] (~fs-bluebo@55d41728.access.ecotel.net)
19:33:27braewoodstoo bad
19:33:29 Quit bluebrother (Disconnected by services)
19:33:34 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother)
19:33:50braewoodsso is bluebot still feeling blue?
19:35:15mendel_munkistest_codec with or without DSP ?
19:35:44 Quit fs-bluebot (Ping timeout: 260 seconds)
19:37:57speachywithout, not that it will matter all that much. :)
19:53:48speachyxduoo now has a US site, with support and a forum in english
19:56:10_bilgus_braewoods opus has a fixed point option
19:56:47_bilgus_speachy, OH?
19:57:07_bilgus_ah they already told me to FO in regards to that manual
19:58:04speachyyeah, for reasons that were vaguely related to "intellectual property concerns" the BT folks decided to create a new codec instead. conveniently with lots of IP owned by the makers of BT chipsets. :D
19:58:48braewoodsspeachy: yea, they're concerned about not being able to profit from it.
19:58:50braewoodsLOL
19:59:10braewoodsfunny when standards exist just to line the pockets of the people making it
19:59:54speachyactually, no −− by contributing it to the BT effort, it falls into the general BT IP pool that all licensed BT members get to use.
20:00
20:00:09braewoodsah.
20:00:33braewoodsafaik opus isn't even patent encumbered
20:00:37braewoodsso why pick one that is?
20:00:53speachythe stated concern was that there might be some submarine patent on the stuff in opus that nobody knew about, and they'd ratehr go through the effort of desigining a new one to be sure it was kosher.
20:01:30braewoodswell in 20 years it'll probably be moot anyway
20:01:44braewoodsany patents would have expired
20:01:53speachybut truthfully I think ti was just a NIH thing. the audio-over-BTLE thing was around the time that the BT SIG kinda jumped the shark
20:02:37speachy(I nearly ended up with the task of doing the benchmarking for the codec options they were considering)
20:05:56 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
20:07:33speachy(I say this IMO, not claiming to represent anyone or anything, bla bla bla. Left the BT world behind completely about 2 years ago)
20:10:40 Quit Stanley00 (Ping timeout: 256 seconds)
20:20:55 Quit MrZeus__ (Ping timeout: 240 seconds)
20:34:30***Saving seen data "./dancer.seen"
21:00
21:41:56mendel_munkistest_codec no dsp with boost got 12% realtime on my fuze+
21:45:44speachy...and that's a 454MHz ARM926
21:46:02 Quit ac_laptop (Quit: WeeChat 2.9)
21:56:18_bilgus_lol
22:00
22:34:32***Saving seen data "./dancer.seen"
22:38:15 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
22:44:18speachy_bilgus_, __builtin, http://www.shaftnet.org/~pizza/rb-apply.txt
22:44:50speachyit's my current draft of the initial SFC application/inquiry request.
22:46:49speachyprobably too much detail for the initial inqury, but I'm assuming I'll be the point of contact for the process and wanted to try and cover at least the general bases.
22:53:36_bilgus_I like it, I don't know about names mattering, I'm not sure who we are speaking for or what rockbox the organization implies
22:54:27_bilgus_i guess whomever steps up and is game I mean you don't like it you fork yourself :p
22:55:19speachyI just wanted to show that there's more than one of us that thinks this is a good idea.
22:55:33speachy(assuming there is, heh)
22:56:20mendel_munkiswhy not put bovik on "the board" as well?
22:57:48speachy_bilgus_: Having folks stomp off and fork rockbox would at least mean they _care_ enough to contribute!
22:57:54_bilgus_well fork me I just saw the Issue FBADDR(x, y) (lcd_framebuffer + ((y) * LCD_FBWIDTH) + (x))
22:58:23mendel_munkiswhy is thata problem?
22:58:28_bilgus_the define fixes the stride to FBW
22:58:47mendel_munkisright.
22:58:54mendel_munkishen would it not be?
22:59:12_bilgus_the draw functions use it and therefore my small fb gets way out of bound
22:59:43speachy_bilgus_: but to really fix that you'd have to pass the FB stride and the viewport stride into the macro.
23:00
23:00:40_bilgus_lol I already have the conversions written as part of the RLI lib lol
23:00:50speachyoutsmarted yourself!
23:00:54mendel_munkishow do you have a fb smaller than the lcd?
23:01:14_bilgus_I should just make the viewport struct have all the buffer info in it
23:01:15mendel_munkisoh i seenow.
23:01:40_bilgus_already has h w might as well carry stride and a data pointer
23:03:24_bilgus_basicall mendel I want to leverage the lcd draw function on my own buffers
23:03:51_bilgus_that way I don't have to rewrite all the line drawing text drawing
23:04:54mendel_munkisisnt stride always width (or height on one target) * FB_DATA_SZ?
23:05:13_bilgus_when dealing with the screen yes
23:06:06_bilgus_but an arbitrary bitmap the stride is w
23:06:18mendel_munkisnot w* data_size?
23:06:28_bilgus_now I don't think bmp has anything but vertical stride
23:07:24_bilgus_yes w * the fbsize
23:07:55_bilgus_so 1 bit target 1 byte is 8 pixels
23:08:09mendel_munkiswhich means that viewport should already have all the neccasary information for stride.
23:08:35_bilgus_mm good point but not really
23:08:59_bilgus_the viewport may be a piece of a bigger memory area
23:09:09mendel_munkisso?
23:09:22_bilgus_so lets say i make a 100 x 100 bmp and wanted to set a vp centered
23:09:54mendel_munkisoh I thought the VP code already handled that.
23:11:02_bilgus_if you were to look at coord 0,0 of the whole area versus coord 0,0 in that viewport and then tried to move 51 pixels it'd end up at the wrong position
23:11:57_bilgus_so in the case of the whole area being the screen the FB STRIDE is right but if the whole area is my little bitmap memory it is not
23:12:30_bilgus_now coordinate transforms are probably the elegant way to handle this
23:12:36speachy_bilgus_: with the assumption your vp data pointer points into the raw/full screen buffer.
23:13:01speachy(as opposed to your vp having its own buffer that's blitted into the full fb)
23:13:07_bilgus_or a similarly sized one
23:13:35_bilgus_yeah it totally makes sense now
23:13:42_bilgus_lol
23:14:07_bilgus_so i'm thinking store stride in vp and a data pointer
23:14:50_bilgus_that effectively allows decoupling them from the FB
23:15:12_bilgus_then we get rid of set FB and handle it in VP
23:15:40mendel_munkisfunny. I was trying to decouple the FB from whatever I could at the other end.
23:16:27_bilgus_the only question is how to do the blit from your vp into the fb for that final display
23:17:03_bilgus_normally you'd set the fb add your data and it gets updated on lcd_update
23:17:03 Quit livvy (Ping timeout: 240 seconds)
23:17:25_bilgus_that would play into that mendel
23:18:51_bilgus_there is a viewport update function maybe I could use that
23:19:26_bilgus_no there wouldn't be a need for a blit it just need to be copied to display ram
23:19:54_bilgus_gah i'm going to need to think about the implications for a bit
23:20:32mendel_munkiswhat exactlyare you trying to do?
23:20:51_bilgus_which part?
23:21:03_bilgus_overall?
23:21:09mendel_munkissure.
23:21:47_bilgus_I already said I want to leverage lcd_draw functions on variably sized bitmap buffers
23:22:32mendel_munkisright forgot about that.
23:25:33mendel_munkisdo you want to blank the rest of the screen?
23:26:55_bilgus_hmm?
23:27:20_bilgus_think of sprites in a side scroller
23:27:34mendel_munkisI see
23:27:39_bilgus_you build them first and later blit them in
23:28:31mendel_munkishow is that different then what the icons do?
23:28:36_bilgus_so in lua I want to be able to do simple image manipulations and either do that to the screen or to a memory bitmap
23:29:11mendel_munkisoh lua. that's a language I don't speak.
23:29:55_bilgus_the best I could do in the current situation is to make a screensized buffer and do everything in that and superimpose the bitmapped memory on top of that
23:30:36mendel_munkisand you can't do that directly in the FB?
23:30:45_bilgus_but then I want an image strip longer than the screenwidth guess what I have to do it in chunks because the rb fb code refused
23:31:07_bilgus_going through the steps that made me make rli lib lol
23:31:20mendel_munkisrocklua img?
23:31:46_bilgus_the interface between lua and rb
23:32:26_bilgus_I didn't speak lua either its not a hard syntax
23:32:57_bilgus_I personally don't like it but it is fast to develop in
23:33:00mendel_munkisI know. I just never feel like learning it and have never needed to do big edits on files in it
23:33:20_bilgus_edits in lua suck IMO
23:33:39_bilgus_its so very verbose
23:33:49mendel_munkisjust wait until you have to do your lua editing in he rockbox text editor
23:33:57_bilgus_been there
23:34:02mendel_munkisouch
23:34:41_bilgus_yeah its unbearable on the clip+ ntb on the fuze+
23:35:04_bilgus_I don't rem who I made the BF interpreter for
23:35:12mendel_munkisthat was me
23:35:16_bilgus_thats worse than lua :p
23:35:28_bilgus_but the game was worth it lol
23:35:39mendel_munkisluckily I never had to do anything with lua on my clip+
23:35:43mendel_munkiswhich game?
23:35:48mendel_munkisthe text adventure
23:36:17_bilgus_uh text rpg go into the mountains after being in a old cabin go to garden everythings dead
23:36:25_bilgus_fill the lamp with oil
23:38:02_bilgus_jonripley
23:38:28_bilgus_https://jonripley.com/i-fiction/games/LostKingdomBF.html
23:40:06_bilgus_so lcd_update uses a hardcoded stride as well
23:40:27mendel_munkisI am in awe of that feat of programming. (i ampretty sure some kind of transpiler was involved somewhere)
23:42:02_bilgus_oh theres no way its not
23:42:39mendel_munkiswhat you wouldn't write a text parser from scratch ? :)
23:42:46_bilgus_not to mention some of the braindead conversions it wasn't an optimizing bf compiler to say the least
23:43:07mendel_munkiswhat do you mean?
23:43:43_bilgus_long lines of shifts and + where loops would have been more efficient
23:44:18_bilgus_like if I was writing it by hand I'd use any available construct top type less
23:44:27_bilgus_-p
23:44:39mendel_munkisah. I saw it was over a MB and noped out of analysing it.
23:47:14_bilgus_hmm so I really only want the putsxy stuff for lua I wonder if it would be easier to twist that to my desire
23:55:35_bilgus_mendel_munkis, do you have something in flight inregards to this fb stuff?
23:56:09mendel_munkisjustg#2415
23:56:10fs-bluebot_Gerrit review #2415 at http://gerrit.rockbox.org/r/2415 : make the plugin API frambuffer agnostic by Moshe Piekarski

Previous day | Next day