View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000613 | Gameplay + OpenGL | [All Projects] Bug | public | 2017-04-21 08:06 | 2017-04-23 02:07 |
Reporter | Major Cooke | ||||
Assigned To | |||||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | resolved | Resolution | fixed | ||
Summary | 0000613: OpenAL console errors | ||||
Description | https://puu.sh/vrt0H/cc3f5ca7be.jpg Upon starting a new game, using D4D. The good news, LOOP_ tags are at least working. | ||||
Tags | No tags attached. | ||||
Looks like it's trying to specify a loop_end that's beyond the size of the buffer. The end point can't be greater than the number of samples in the buffer, so it needs to be clamped. Something like this: |
|
Seems like some more fixes are needed. Like Graf asked in 0000409 could someone craft a small example with bunch of cases covered? Like start tag only, end tag only, both tags, sample and time formats, invalid values, etc. I'm trying to do it myself but it's easy to miss something. |
|
To be honest, I think the only thing needed here is to remove the error check or to change it to be more expressive. What do I care that there was an error in line 1291 of the source file, I want to know what's wrong with the loop tags! | |
There are several issues with the current implementation: start and end points are not clamped (i.e. out of range case), start beyond end isn't handled too, start at zero is a valid loop point for FMOD, probably something else I didn't discovered yet. | |
In other words: It doesn't handle cases well, where the data is not correct. What should be done there? Normally I'd just say, let OpenAL decide and just don't print an error message if it finds the data is not correct. The fallback in all cases should be to ignore the loop because the conditions for looping are never met. And start = 0 has to be a valid case, if that is enough to make OpenAL puke, it's an error in OpenAL. |
|
Actually it doesn't matter as specifying CHAN_LOOP will loop whole sound anyway. However the case with non-zero start point and no end point is not covered yet, whole sound will loop in this case. |
|
Now that loop_end is clamped to the buffer's sample count, reverting this commit should work. The default loop_end would be ~0u (UINT_MAX) again, which if no proper LOOP_END tag is specified, gets clamped to the end of the buffer. A non-zero loop start would then cause it to loop between the specified start point and the end, as desired. EDIT: Made PR 302 to fix that. |
|
Date Modified | Username | Field | Change |
---|---|---|---|
2017-04-21 08:06 | Major Cooke | New Issue | |
2017-04-21 09:31 | Graf Zahl | Status | new => resolved |
2017-04-21 09:31 | Graf Zahl | Resolution | open => fixed |
2017-04-21 16:06 | Chris | Note Added: 0001507 | |
2017-04-22 00:52 | _mental_ | Status | resolved => needs review |
2017-04-22 03:23 | _mental_ | Status | needs review => feedback |
2017-04-22 03:23 | _mental_ | Note Added: 0001514 | |
2017-04-22 04:03 | Graf Zahl | Note Added: 0001518 | |
2017-04-22 06:30 | _mental_ | Note Added: 0001519 | |
2017-04-22 08:12 | Graf Zahl | Note Added: 0001521 | |
2017-04-22 08:25 | _mental_ | Note Added: 0001522 | |
2017-04-22 08:41 | _mental_ | Note Edited: 0001522 | View Revisions |
2017-04-22 08:52 | _mental_ | Note Edited: 0001522 | View Revisions |
2017-04-22 11:14 | _mental_ | Status | feedback => resolved |
2017-04-22 16:41 | Chris | Note Added: 0001530 | |
2017-04-22 17:36 | Chris | Note Edited: 0001530 | View Revisions |
2017-04-23 00:33 | _mental_ | Status | resolved => needs review |
2017-04-23 00:33 | _mental_ | Resolution | fixed => reopened |
2017-04-23 02:07 | Graf Zahl | Status | needs review => resolved |
2017-04-23 02:07 | Graf Zahl | Resolution | reopened => fixed |