| 00:01:26 | | Quit ZincAlloy (Quit: Leaving.) |
| 00:08:51 | __builtin | danielp3344: Yes. And quake, wolf3d, and duke3d :) |
| 00:12:19 | | Join dys [0] (~dys@tmo-106-91.customers.d1-online.com) |
| 00:25:26 | fs-bluebot | Build Server message: New build round started. Revision 51d47c5, 280 builds, 10 clients. |
| 00:30:07 | foolsh | danielp3344: Get a fuze over the fuze+ if you can the touch pad is crap on the fuze+ if you want to play doom |
| 00:43:24 | speachy | speaking of the fuxe+, anyone with one have any comments on g#2087 |
| 00:43:26 | fs-bluebot | Gerrit review #2087 at http://gerrit.rockbox.org/r/2087 : Fuze+ hotkeys and quickscreen by Moshe Piekarski |
| 00:44:18 | *** | Saving seen data "./dancer.seen" |
| 00:45:12 | fs-bluebot | Build Server message: Build round completed after 1186 seconds. |
| 00:45:13 | fs-bluebot | Build Server message: Revision 51d47c5 result: All green |
| 00:45:14 | fs-bluebot | Build Server message: New build round started. Revision a18803a, 280 builds, 10 clients. |
| 00:45:55 | speachy | wow. the build screen says something I've never seen before. |
| 01:00 |
| 01:05:45 | fs-bluebot | Build Server message: Build round completed after 1231 seconds. |
| 01:05:46 | fs-bluebot | Build Server message: Revision a18803a result: All green |
| 01:11:57 | | Quit lebellium (Quit: Leaving) |
| 01:14:51 | foolsh | speachy: Seems good to me, fuze+ didn't even have a record button, and those bottom buttons have never had any other use. |
| 01:56:52 | fs-bluebot | Build Server message: New build round started. Revision 9d79cef, 280 builds, 10 clients. |
| 01:57:14 | speachy | so let's make it so. |
| 02:00 |
| 02:18:57 | fs-bluebot | Build Server message: Build round completed after 1326 seconds. |
| 02:19:02 | fs-bluebot | Build Server message: Revision 9d79cef result: 0 errors 2 warnings |
| 02:44:20 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:26:20 | foolsh | just got a working sansa c250 lets see if it runs quake! |
| 03:27:13 | fs-bluebot | Build Server message: New build round started. Revision 4209c09, 280 builds, 10 clients. |
| 03:28:51 | | Join massiveH [0] (~massiveH@ool-4352e615.dyn.optonline.net) |
| 03:53:20 | fs-bluebot | Build Server message: Build round completed after 1566 seconds. |
| 03:53:21 | fs-bluebot | Build Server message: Revision 4209c09 result: All green |
| 04:00 |
| 04:04:40 | | Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) |
| 04:10:34 | danielp3344 | foolsh: lol |
| 04:15:47 | speachy | it was gloriously green for two builds, anyway. |
| 04:17:34 | foolsh | __builtin: Got "Undefined instruction pc:018b5c84 sp:40000ad0 bt end" for duke3d and "Undefined instruction pc:01b33944 sp:40000ad0 bt end" for quake halts right after launching the plugin, target has 32mb of ram. I'll see what I can make of it tomorrow |
| 04:18:09 | foolsh | sansa c250 |
| 04:38:06 | | Quit mendelmunkis (Ping timeout: 244 seconds) |
| 04:38:16 | __builtin | foolsh: can you map it? |
| 04:44:24 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:22:58 | foolsh | __builtin:wolf3d craps out to, I'm looking at the wolf3d.map and I can't find the address "01b773d4" the closest one is "0x0000000001b773d0 plugin_start" |
| 05:25:24 | foolsh | same thing with duke3d, let me start another sdl plugin and see if there's something weird going on with sdl on this target |
| 05:26:45 | foolsh | nope the sgt-* plugins run fine |
| 05:27:19 | foolsh | just wold3d duke3d and quake all crap out right around plugin start |
| 05:34:37 | | Quit TheSeven (Ping timeout: 250 seconds) |
| 05:35:05 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 06:00 |
| 06:01:27 | | Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) |
| 06:10:28 | | Quit mendelmunkis (Ping timeout: 245 seconds) |
| 06:44:27 | *** | Saving seen data "./dancer.seen" |
| 06:59:11 | | Quit massiveH (Quit: Leaving) |
| 07:00 |
| 07:00:59 | | Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) |
| 07:26:54 | | Quit mendelmunkis (Ping timeout: 246 seconds) |
| 07:34:31 | | Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) |
| 07:40:54 | | Quit mendelmunkis (Ping timeout: 268 seconds) |
| 07:51:17 | | Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) |
| 07:53:33 | | Quit mendelmunkis (Remote host closed the connection) |
| 07:53:57 | | Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) |
| 07:58:58 | | Quit mendelmunkis (Ping timeout: 248 seconds) |
| 08:00 |
| 08:15:35 | | Quit speachy (Ping timeout: 260 seconds) |
| 08:36:03 | | Quit TheSeven (Ping timeout: 264 seconds) |
| 08:37:38 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 08:42:41 | | Quit TheSeven (Ping timeout: 250 seconds) |
| 08:44:29 | *** | Saving seen data "./dancer.seen" |
| 08:45:06 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 09:00 |
| 09:55:28 | | Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) |
| 10:00 |
| 10:08:46 | | Quit mendelmunkis (Ping timeout: 245 seconds) |
| 10:16:09 | | Join lebellium [0] (~lebellium@89-92-69-110.hfc.dyn.abo.bbox.fr) |
| 10:37:13 | | Join ZincAlloy [0] (~Adium@2a02:8108:9440:dfc:ec14:291c:83fb:9775) |
| 10:37:28 | | Quit ZincAlloy (Client Quit) |
| 10:37:38 | | Join ZincAlloy [0] (~Adium@2a02:8108:9440:dfc:ec14:291c:83fb:9775) |
| 10:37:59 | | Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) |
| 10:44:30 | *** | Saving seen data "./dancer.seen" |
| 11:00 |
| 11:17:59 | | Quit mendelmunkis (Ping timeout: 244 seconds) |
| 11:21:57 | | Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) |
| 11:29:04 | | Quit mendelmunkis (Ping timeout: 268 seconds) |
| 11:40:50 | | Quit Jinx (Ping timeout: 248 seconds) |
| 11:51:12 | | Join Jinx [0] (~Jinx@unaffiliated/jinx) |
| 11:54:21 | | Quit dys (Ping timeout: 268 seconds) |
| 12:00 |
| 12:00:34 | | Join dys [0] (~dys@tmo-103-103.customers.d1-online.com) |
| 12:09:46 | | Quit dys (Ping timeout: 268 seconds) |
| 12:30:58 | | Join dys [0] (~dys@tmo-119-166.customers.d1-online.com) |
| 12:44:34 | *** | Saving seen data "./dancer.seen" |
| 14:00 |
| 14:02:31 | | Quit pystar89 (Ping timeout: 245 seconds) |
| 14:44:36 | *** | Saving seen data "./dancer.seen" |
| 15:00 |
| 15:11:50 | | Join speachy [0] (d102414d@209.2.65.77) |
| 16:00 |
| 16:00:46 | | Join pystar89 [0] (~pystar89@ip5f58d956.dynamic.kabel-deutschland.de) |
| 16:44:38 | *** | No seen item changed, no save performed. |
| 16:57:04 | fs-bluebot | Build Server message: New build round started. Revision f85df30, 280 builds, 11 clients. |
| 17:00 |
| 17:11:31 | | Join petur [0] (~petur@78-21-55-218.access.telenet.be) |
| 17:11:43 | | Quit petur (Changing host) |
| 17:11:43 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 17:12:18 | fs-bluebot | Build Server message: Build round completed after 914 seconds. |
| 17:12:19 | fs-bluebot | Build Server message: Revision f85df30 result: All green |
| 17:20:08 | __builtin | foolsh: sgt-puzzles doesn't use SDL |
| 17:22:52 | __builtin | What build are you using? I'd like to see what exactly fault instruction is |
| 17:38:21 | fs-bluebot | Build Server message: New build round started. Revision 668eed3, 280 builds, 11 clients. |
| 17:38:48 | __builtin | foolsh: also, which version? c200v1 or v2? |
| 17:39:26 | __builtin | well, I suppose it must be v1 |
| 17:39:34 | __builtin | v2 doesn't have enough memory |
| 17:52:26 | __builtin | foolsh: I think I know what's going on |
| 17:52:41 | fs-bluebot | Build Server message: Build round completed after 860 seconds. |
| 17:52:42 | fs-bluebot | Build Server message: Revision 668eed3 result: All green |
| 17:52:43 | | Join robertd1 [0] (~robertd@186-90-13-160.genericrev.cantv.net) |
| 17:54:04 | fs-bluebot | Build Server message: New build round started. Revision d1f349b, 280 builds, 11 clients. |
| 17:59:50 | __builtin | hmm, does ARMv4T have CP15? |
| 18:00 |
| 18:02:39 | __builtin | foolsh: I guess a simple fix would be to disable setting the alignment trap in SDL's main.c |
| 18:03:05 | speachy | no, the ARM7TDMI only has a CP14 |
| 18:08:37 | fs-bluebot | Build Server message: Build round completed after 873 seconds. |
| 18:08:38 | fs-bluebot | Build Server message: Revision d1f349b result: All green |
| 18:14:13 | speachy | ... if the SDL (etc) code relies on an there being an alignment trap to fix things up, it's going to fail spectacularly on the ARM7TDMI.. |
| 18:19:01 | __builtin | The trap is just there to catch any unaligned accesses. It does nothing to fix them up. |
| 18:22:58 | __builtin | speachy: is it present for all ARM_ARCH >= 5? |
| 18:44:41 | *** | Saving seen data "./dancer.seen" |
| 19:00 |
| 19:44:41 | speachy | not sure. let me dig through the docs. |
| 19:45:18 | speachy | I know it's in ARMv6 |
| 19:51:45 | speachy | Okay, it's a hard requirement for v6 onwards, and optional in v5 or older. |
| 19:52:37 | speachy | that said it's _usually_ present in v5 implementations, and many v4 too. (notably excluding the ARM7TDMI aka v7T) |
| 19:53:13 | speachy | rule of thumb is that if the pre-v6 processor has an MMU, it has CP15. |
| 19:54:25 | speachy | er, s/v7T/v4T/ |
| 19:54:29 | gevaerts | Well, yes, but the first ARM where you could have rules of thumb was the ARM7TDMI :) |
| 19:54:39 | * | speachy groans. |
| 19:54:39 | * | gevaerts hides |
| 19:55:04 | * | speachy is reading the ARM ARM ARM. |
| 19:56:28 | gevaerts | Wait, what's the third one? |
| 19:57:10 | speachy | ARM-the-company ARM-the-architechure Architecture Reference Manual |
| 19:57:17 | gevaerts | Oh, right |
| 19:57:27 | gevaerts | I didn't think of the company |
| 19:57:49 | speachy | there's actually another ARM that can be tacked onto there but I forgot its translation. |
| 19:59:15 | __builtin | Application, Realtime, Microcontroller? |
| 19:59:47 | speachy | perhaps! |
| 20:00 |
| 20:00:03 | gevaerts | I wonder how smug the people were in the meeting where they agreed on "Architecture Reference Manual" |
| 20:00:23 | __builtin | they sure know their puns |
| 20:00:28 | speachy | There were definitely some punsters in that lot. |
| 20:01:36 | speachy | and that's just the ones I've met. :) |
| 20:02:18 | __builtin | do you work there? |
| 20:03:20 | speachy | Used to. they bought the startup I was at, then shut it all down last december. |
| 20:04:18 | __builtin | ah, that explains things |
| 20:05:01 | speachy | my group was doing bluetooth/802.15.4 radio designs. |
| 20:06:08 | Bilgus | speachy do you have a rocker? |
| 20:07:08 | speachy | yeah, broke the case but it otherwise functions |
| 20:07:29 | Bilgus | you know it needs bt integrated right?? |
| 20:07:41 | Bilgus | just sayin |
| 20:07:46 | * | speachy chuckles. |
| 20:08:00 | gevaerts | Well, speachy might have Opinions about the controller they use :) |
| 20:08:47 | Bilgus | I have opinions about the whole thing but glad to have an in production device nonetheless |
| 20:10:01 | speachy | I was doing the realtime radio control and related code, well below the BTLE stack and even further from applications. |
| 20:10:37 | * | gevaerts was just going to suggest ignorance about the upper parts of the stack as a good excuse :) |
| 20:11:41 | speachy | but in the rocker's specific case (or really, any hiby-based unit) just bolting up their existing system server stuff to a rockbox UI would be straightforward. |
| 20:12:27 | speachy | it's when you want to try and extend those pitiful capabilities that things get a lot tricker. If hiby's BT implemetation is anything like what they did to the other Linux layers... |
| 20:12:29 | * | speachy shudders. |
| 20:12:47 | Bilgus | mwhaha |
| 20:14:01 | * | speachy grumbles again about flagrant GPL violators. |
| 20:15:01 | gevaerts | I'm not actually sure if prior experience with the stuff makes that much of a difference. I mean, it definitely helps, but what *really* helps is access to debugging and tracing equipment |
| 20:15:27 | * | gevaerts fondly remembers the early days of USB on his sansa c200 :) |
| 20:16:59 | speachy | no real need for low-level debuggers since it's a full Linux system. |
| 20:17:23 | gevaerts | True |
| 20:17:34 | gevaerts | Although even then it can help |
| 20:18:33 | speachy | what would help more −− not just on the rocker but all of the hiby-based units −− is an automated way to patch the OF image. |
| 20:20:09 | * | gevaerts suddenly realises that most of the stuff he did in rockbox is more than ten years old... |
| 20:21:50 | * | __builtin is looking to get in-game music playback in quake |
| 20:23:24 | Bilgus | well it can be automated but not in the way you mean |
| 20:24:00 | Bilgus | more like we do it first then others can do the patching on their pc |
| 20:24:14 | speachy | can't be worse than trying to automate Sysgen and Vivado. |
| 20:24:15 | Bilgus | like the cracks of yesteryear |
| 20:25:13 | speachy | IIRC we have a method that works well on Linux/etc but it wasn't easily portable to Windows, where most end-users use rbutil. |
| 20:26:53 | speachy | but it's something I need to do for myself if only so I can trust the X3 bootloader builds. |
| 20:37:13 | speachy | paid work comes first though. |
| 20:41:23 | fs-bluebot | Build Server message: New build round started. Revision 448b97a, 280 builds, 11 clients. |
| 20:44:45 | *** | No seen item changed, no save performed. |
| 20:47:46 | Bilgus | who do I ask for flyspray priveliges? |
| 20:48:59 | speachy | not it! |
| 20:49:14 | | Quit robertd1 (Quit: Leaving.) |
| 20:49:59 | Bilgus | I'd settle for someone with them |
| 20:49:59 | gevaerts | Bilgus: me, I think |
| 20:50:31 | Bilgus | when you get a chance Could I get closing privileges? |
| 20:50:42 | __builtin | could we migrate all of FS over to gerrit automatically? |
| 20:51:21 | Bilgus | damn I ask for an inch __bultin asks for like 150km |
| 20:51:32 | Bilgus | :p |
| 20:51:34 | gevaerts | Well. __builtin can work on that :) |
| 20:51:51 | gevaerts | What's your flyspray username? Also Bilgus? |
| 20:52:12 | Bilgus | William W (Bilgus) |
| 20:52:42 | gevaerts | OK, I did something, so maybe you're in the developer group now instead of the reporter group |
| 20:52:57 | * | gevaerts is not a flyspray expert, merely an admin :) |
| 20:53:15 | Bilgus | I was able to close the task as fixed, Thanks! |
| 20:53:18 | speachy | flyspray is still my favorite bug tracker thingey. |
| 20:53:28 | speachy | it doesn't ry to be everything to everyone. |
| 20:56:24 | Bilgus | I like it all except that it shows the oldest bugs first |
| 20:56:42 | fs-bluebot | Build Server message: Build round completed after 920 seconds. |
| 20:56:43 | fs-bluebot | Build Server message: Revision 448b97a result: All green |
| 20:56:58 | gevaerts | I've only really ever worked with if for rockbox, but I've never really been annoyed by it, which for this sort of software is very good |
| 20:59:31 | fs-bluebot | Build Server message: New build round started. Revision 7234de5, 280 builds, 11 clients. |
| 21:00 |
| 21:00:39 | __builtin | foolsh: can you test SDL with latest git? |
| 21:00:53 | __builtin | I disabled the offending code, hopefully |
| 21:03:21 | Bilgus | anyone object to me closing the bugs from prior to 3.13? |
| 21:07:07 | * | speachy is all for it. |
| 21:07:18 | __builtin | are they fixed? |
| 21:08:27 | Bilgus | some are others who knows |
| 21:08:46 | Bilgus | but I don't think a task from 3.1 is going to help anyone figure it out |
| 21:09:15 | foolsh | __builtin: sure building now |
| 21:09:29 | __builtin | Bilgus: in that case, sure |
| 21:09:58 | speachy | I'd keep patches open though. |
| 21:10:39 | * | __builtin wonders how many devs actually check flyspray for new bugs |
| 21:13:28 | Bilgus | theres what 4 of us? |
| 21:13:30 | Bilgus | I do |
| 21:13:35 | Bilgus | speachy does lol |
| 21:14:03 | __builtin | 4 active devs? |
| 21:14:06 | speachy | oh, I don't check it for new bugs. |
| 21:14:16 | fs-bluebot | Build Server message: Build round completed after 884 seconds. |
| 21:14:17 | fs-bluebot | Build Server message: Revision 7234de5 result: All green |
| 21:14:27 | speachy | trawling around it for forgotten patches and whatnot.. |
| 21:15:56 | Bilgus | oh ok I do, I might say ^ active devs but it all depends what you classify as active |
| 21:16:02 | Bilgus | 6* |
| 21:19:34 | __builtin | hmm, does anyone have a desire to put out a new release? |
| 21:19:55 | speachy | it would be an interesting exercise. |
| 21:20:17 | __builtin | around 3.14 there were noises about bumping to 4.0 and purging all the HWCODEC code |
| 21:21:10 | speachy | does anyone active still have a HWCODEC unit? |
| 21:21:43 | gevaerts | pixelma might still have a working ondio |
| 21:22:35 | __builtin | do we have a way to get per-target download stats? |
| 21:25:21 | Bilgus | I'd really like to get rid of HWCODEC just the builds first but then all the conditional cruft that abounds |
| 21:26:05 | Bilgus | I think she said she hasn't updated it in years though |
| 21:26:36 | foolsh | __builtin: duke3d works, sounds are high pitched sounds like a chipmunk speaking, game play is smooth-ish. wolf3d plays but sounds are choppy, kind of weird considering how well duke3d plays. And quake runs until right before launching the menu with "error: Draw_pic bad coordinates" most likely the screen size thing. And I should spend some time re assigning the button's |
| 21:28:31 | * | speachy would also like to see a toolchain bump on ARM targets |
| 21:29:44 | speachy | more optimization/code size options, and will bring it up to what we're using for MIPS. |
| 21:29:55 | speachy | dunno about m68k. |
| 21:30:19 | __builtin | I think you just volunteered youself :) |
| 21:30:53 | speachy | heh, I already have a GCC 4.9.4 rb arm toolchain on this system. |
| 21:31:36 | __builtin | foolsh: could you record duke and wolf? I haven't seen (heard) high pitched audio from duke |
| 21:31:37 | speachy | before the flash on my (second) clip+ flaked out, I was using it as a daily driver |
| 21:31:53 | foolsh | __builtin: sure |
| 21:33:49 | __builtin | foolsh: and of course, I doubt John Carmack had 80-pixel displays in mind back in the day |
| 21:33:57 | speachy | do we have a proper headliner feature or targets for a new release? |
| 21:34:40 | speachy | then again I don't thing we we even have a high-level changelog. That in of itself would be an undertaking. |
| 21:34:40 | __builtin | speachy: https://www.rockbox.org/wiki/MajorChanges |
| 21:34:48 | __builtin | we do ^ |
| 21:35:20 | speachy | need to add the various new unstable targets |
| 21:35:36 | Bilgus | thats in several places |
| 21:35:39 | __builtin | when did we add Rocker support? |
| 21:35:51 | Bilgus | 2017ish |
| 21:36:22 | speachy | I committed the X3 (and IHIFI 770/800) stuff in the late 2018/early 2019 timeframe. |
| 21:36:40 | * | __builtin will go in and backdate some things in MajorChanges |
| 21:37:05 | speachy | yeah, I'll see about doing the same for the stuff I've been hacking on. |
| 21:37:15 | speachy | but that will have to wait until later |
| 21:38:17 | Bilgus | lets call it March 05, 2018 |
| 21:53:00 | foolsh | __builtin: https://www.filedropper.com/duke3d |
| 21:56:53 | foolsh | https://www.filedropper.com/wolf3d |
| 21:58:57 | __builtin | foolsh: definitely playing at twice speed, or something like that... |
| 21:59:59 | __builtin | it looks like it's zeroing the samples at a certain frequency for wolf... I saw a bug like this while porting |
| 22:00 |
| 22:00:21 | | Join Strife89 [0] (~quassel@adsl-74-250-141-229.ags.bellsouth.net) |
| 22:02:09 | __builtin | how did you record these? line in? |
| 22:03:04 | foolsh | __builtin: yes with audacity, in duke3d the waveform is choppy like its playing a sample, waiting and then playing the next |
| 22:03:19 | __builtin | you mean wolf3d? |
| 22:03:28 | foolsh | yes dang it |
| 22:03:41 | __builtin | yeah, I suspect the bugs are releated |
| 22:03:55 | __builtin | duke3d is definitely playing at exactly 2x the normal speed |
| 22:04:23 | foolsh | tiny voice to match the tiny screen FTW! |
| 22:06:15 | __builtin | ok, wolf3d looks like it plays 1024 samples and then silence for 2048 |
| 22:07:50 | __builtin | my guess for duke is that it's failing to set the 22.05KHz sample rate in rockbox, so the samples generated are 22.05KHz but are being played back at 44.1 |
| 22:08:29 | __builtin | Something similar is probably happening to wolf. Might be exhausting the mixing buffer and just playing silence |
| 22:12:00 | __builtin | aha, yep |
| 22:12:13 | __builtin | c200 doesn't support 22.05 rate |
| 22:12:23 | foolsh | hmm |
| 22:12:53 | __builtin | I'll have to force it to do 32KHz instead |
| 22:14:25 | __builtin | foolsh: can you try editing RB_SAMPR in apps/plugins/sdl/include/SDL_config_rockbox.h from SAMPR_22 to SAMPR_32? |
| 22:14:39 | __builtin | hopefully the cpu is powerful enough to handle the bump |
| 22:15:04 | foolsh | sure, but in my playback settings it only has 44.1 and 48 kHz |
| 22:15:32 | __builtin | you could try 44.1 if 32 doesn't work |
| 22:24:16 | foolsh | __builtin: duke3d seem to play fine at 32, game play speed is not affected or so it seems, wolf3d however still less choppy sounds and game play speed is effected |
| 22:24:53 | __builtin | so wolf3d is still choppy? |
| 22:25:45 | foolsh | yeah, but less so at 32 |
| 22:25:58 | * | user890104 read something about a new release... |
| 22:26:09 | foolsh | is there a way to cheaply upconvert 22 to 44 I wonder? |
| 22:26:37 | __builtin | foolsh: could you try SAMPR_44 and see if that fixes wolf? |
| 22:26:43 | foolsh | ok |
| 22:27:17 | __builtin | user890104: you're welcome to volunteer as RM :) |
| 22:28:20 | user890104 | __builtin: do you still keep your notes/checklist for 3.14? |
| 22:28:36 | __builtin | there's https://www.rockbox.org/wiki/ReleaseChecklist which I found useful for 3.14 |
| 22:29:35 | __builtin | also https://www.rockbox.org/wiki/ReleaseNotes315 |
| 22:30:31 | user890104 | i'd like to volunteer for something else first. i wonder if someone can give me moderator-like access to gerrit, so i can mark as abandoned all patches that are already merged as part of other patch or as a commit different from gerrit's |
| 22:31:00 | user890104 | i'd have to check them by hand, i guess |
| 22:34:12 | foolsh | __builtin: Alright at 44.1 duke3d still plays very well and I don't hear a difference from 32, wolf seems to stutter just like it did at 32 |
| 22:35:03 | foolsh | which is weird considering how duke3d seems that much more visually intensive |
| 22:35:30 | __builtin | low framerate, you mean? |
| 22:35:34 | foolsh | yes |
| 22:35:52 | foolsh | sound as well as fps |
| 22:36:33 | foolsh | poor little player just cant handle the awesomeness that if wolf3d |
| 22:37:39 | __builtin | I think I know a quick way to fix quake |
| 22:38:00 | __builtin | uncomment the #define BASEWIDTH / BASEHEIGHT 320/240 in sdl/progs/quake/vid_sdl.c |
| 22:38:07 | __builtin | and comment the LCD_WIDTH/LCD_HEIGHT pair |
| 22:38:24 | __builtin | that'll make SDL simulate a 320x240 buffer that it'll scale down |
| 22:39:13 | __builtin | that way we'll know if it's just wolf or if quake is affected as well |
| 22:44:47 | *** | Saving seen data "./dancer.seen" |
| 22:47:01 | fs-bluebot | Build Server message: New build round started. Revision 4ad7665, 280 builds, 11 clients. |
| 22:50:08 | foolsh | __builtin: yeah quake runs, poorly. and sampling was still at 44.1khz |
| 22:52:27 | __builtin | yay! :) |
| 22:53:09 | foolsh | when BASEWIDTH / BASEHEIGHT was still LCD_WIDTH/LCD_HEIGHT it was drawing only a portion of the background image (upper left) before launching the demo, seems like there is some thing drawing to off screen memory causing the "bad coordinates" error message perhaps |
| 22:54:02 | speachy | there are SAMPR_CAP_?? definitions that one can use for sane defaults on various targets.. |
| 23:00 |
| 23:04:13 | __builtin | foolsh: how poor is the performance with scaling and 44.1? |
| 23:05:05 | foolsh | __builtin: piss poor, even when at 32khz |
| 23:05:34 | __builtin | can you screen record it? |
| 23:05:40 | foolsh | ok |
| 23:06:08 | __builtin | if it's good enough to play a level I might just force scaling for screens smaller than 240x320 |
| 23:06:24 | | Quit lebellium (Quit: Leaving) |
| 23:07:51 | fs-bluebot | Build Server message: Build round completed after 1250 seconds. |
| 23:07:52 | fs-bluebot | Build Server message: Revision 4ad7665 result: All green |
| 23:07:53 | fs-bluebot | Build Server message: New build round started. Revision 08fd69c, 280 builds, 11 clients. |
| 23:08:54 | speachy | okay... that's strange. my last commit saw a 150-300ish byte binary size across the board.. except the Samsung YP-R0, which shrank by 30KB. |
| 23:10:17 | Bilgus | sometimes they bounce next build it'll be right perhaps? |
| 23:10:48 | Bilgus | oh 30k hmm that is a lot |
| 23:13:09 | __builtin | that doesn't make any sense |
| 23:14:01 | speachy | I don't have the toolchain for that target installed on any of my boxes. |
| 23:16:15 | speachy | we'll see if it reverts to the mean after the next build. |
| 23:18:18 | Bilgus | huh I thought I had arm-rockbox-linux-gnueabi-gcc in my toolchain but apparently not |
| 23:18:48 | __builtin | I've got it prebuilt in my docker image, I think |
| 23:26:51 | speachy | so two of the patches I have in my queue bump the sample rate for the mikmod and midiplay plugin to 44.1KHz from a hardcoded 22.05K |
| 23:27:52 | speachy | (or 44K if 22K isn't supported) |
| 23:28:02 | fs-bluebot | Build Server message: Build round completed after 1210 seconds. |
| 23:28:03 | fs-bluebot | Build Server message: Revision 08fd69c result: All green |
| 23:28:04 | fs-bluebot | Build Server message: New build round started. Revision 4d5dfab, 280 builds, 9 clients. |
| 23:30:36 | speachy | given that music playback is the point of those plugins, I think the bump is warranted. Is it a fair assumption to make that any target capable of handling realtime mp3 playback (ie all of them) shouldn't have a problem doing 44KHz mod playback? |
| 23:36:23 | | Quit beencubed (Quit: Leaving) |
| 23:37:24 | Bilgus | I wouldn't make that assumption |
| 23:38:36 | Bilgus | but.. one way to find out? |
| 23:39:04 | speachy | everything I have is relatively beefy. |
| 23:39:50 | Bilgus | figure mp3 is highly optimized I'd say if they can do realtime in a heavier codec you'd be ok |
| 23:40:19 | speachy | and none of the codec benchmarks published include mod or midi (==mod) |
| 23:42:19 | Bilgus | midi really isn't terribly complicated so idk maybe make sure there is a way to revert using conditionals and/or just push it and wait for a bug |
| 23:44:47 | speachy | the codec comparison page shows every target handling everything except for HE-AAC and some APEs. |
| 23:45:32 | | Join advcomp2019__ [0] (~advcomp20@unaffiliated/advcomp2019) |
| 23:46:24 | fs-bluebot | Build Server message: Build round completed after 1101 seconds. |
| 23:46:25 | fs-bluebot | Build Server message: Revision 4d5dfab result: All green |
| 23:47:57 | | Join beencubed [0] (~beencubed@209.131.238.248) |
| 23:48:24 | speachy | hmm. wonder if the codec_bench plugin will handle mod and midi. |
| 23:48:33 | speachy | guess I'll find out. |
| 23:48:42 | | Quit advcomp2019_ (Ping timeout: 244 seconds) |
| 23:52:14 | __builtin | midi isn't implemented through a codec, I believe |
| 23:52:53 | __builtin | and we now have at least 2 separate MIDI implementations in the plugin tree |
| 23:53:59 | speachy | we do? |
| 23:54:12 | speachy | oh for the games you mean? |
| 23:56:46 | __builtin | There's midiplay and a port of timidity under SDL |
icon identifies that the person is a core developer (has commit access).