diff options
Diffstat (limited to 'apps/codecs/dumb/docs/faq.txt')
-rw-r--r-- | apps/codecs/dumb/docs/faq.txt | 263 |
1 files changed, 263 insertions, 0 deletions
diff --git a/apps/codecs/dumb/docs/faq.txt b/apps/codecs/dumb/docs/faq.txt new file mode 100644 index 0000000000..48b5ef3fff --- /dev/null +++ b/apps/codecs/dumb/docs/faq.txt | |||
@@ -0,0 +1,263 @@ | |||
1 | TO DO: add question regarding set_close_button_callback vs set_window_close_hook | ||
2 | |||
3 | /* _______ ____ __ ___ ___ | ||
4 | * \ _ \ \ / \ / \ \ / / ' ' ' | ||
5 | * | | \ \ | | || | \/ | . . | ||
6 | * | | | | | | || ||\ /| | | ||
7 | * | | | | | | || || \/ | | ' ' ' | ||
8 | * | | | | | | || || | | . . | ||
9 | * | |_/ / \ \__// || | | | ||
10 | * /_______/ynamic \____/niversal /__\ /____\usic /| . . ibliotheque | ||
11 | * / \ | ||
12 | * / . \ | ||
13 | * faq.txt - Frequently Asked Questions. / / \ \ | ||
14 | * | < / \_ | ||
15 | * This file covers some of the common problems | \/ /\ / | ||
16 | * and misconceptions people have with DUMB. If \_ / > / | ||
17 | * your problem is not covered here, please | \ / / | ||
18 | * contact me. I'll do my best to help - but | ' / | ||
19 | * don't be offended if I just direct you to the \__/ | ||
20 | * manual! | ||
21 | */ | ||
22 | |||
23 | |||
24 | ***************************************************************************** | ||
25 | * I get a lot of strange warnings and errors when I compile my projects * | ||
26 | * with this release of DUMB. They work with older versions! What happened? * | ||
27 | ***************************************************************************** | ||
28 | |||
29 | Some parts of DUMB's API have been deprecated. See docs/deprec.txt for | ||
30 | full details, including an explanation as to why your compiler warnings | ||
31 | and errors are so unfriendly, and information on how to fix each warning | ||
32 | or error. | ||
33 | |||
34 | |||
35 | ***************************************************************************** | ||
36 | * When I try to compile DUMB with Allegro, it complains that it cannot find * | ||
37 | * 'internal/alconfig.h'! What's wrong? * | ||
38 | ***************************************************************************** | ||
39 | |||
40 | In Allegro 4.0.1, and quite likely some other versions of Allegro, the | ||
41 | msvcmake batch file does not install Allegro properly. I believe this was | ||
42 | fixed in Allegro 4.0.2, but don't take my word for it. Some include files | ||
43 | are neglected, including alconfig.h. The fix is quite easy; you need to | ||
44 | copy all of Allegro's include files to your compiler's directory. The | ||
45 | following should do this for you (alter it accordingly depending on where | ||
46 | MSVC and Allegro are installed): | ||
47 | |||
48 | cd\progra~1\msvc\include | ||
49 | xcopy/s \allegro\include\*.* | ||
50 | |||
51 | You can safely tell it to overwrite all files. | ||
52 | |||
53 | |||
54 | ***************************************************************************** | ||
55 | * When I build a project that uses DUMB, I get an error that it doesn't * | ||
56 | * find -laldmbd! What's wrong? * | ||
57 | ***************************************************************************** | ||
58 | |||
59 | See the notes for DUMB v0.8 in release.txt; the existence of libaldmbd.a | ||
60 | in DUMB v0.7 was due to a mistake in the makefiles. It should be | ||
61 | libaldmd.a, in order to maintain DOS compatibility. All subsequent | ||
62 | releases get it right, but you will have to change your project files to | ||
63 | allow for the change. If this is someone else's project, please let them | ||
64 | know that it needs changing. | ||
65 | |||
66 | |||
67 | ***************************************************************************** | ||
68 | * When I build a project that uses DUMB, I get some linker errors about * | ||
69 | * _free, _malloc, etc. already being defined in LIBC.lib! What's wrong? * | ||
70 | ***************************************************************************** | ||
71 | |||
72 | MSVC offers three different implementations of the standard libraries. | ||
73 | When you link statically with a library, you have to use the same | ||
74 | implementation that the library uses. You need the multithreaded DLL | ||
75 | implementation, which you can select by passing /MD when you compile (not | ||
76 | when you link). See howto.txt for details. | ||
77 | |||
78 | |||
79 | ***************************************************************************** | ||
80 | * I created an IT file with Impulse Tracker, but DUMB won't play it! Why? * | ||
81 | ***************************************************************************** | ||
82 | |||
83 | You probably created some patterns but didn't give any information on the | ||
84 | order in which they should be played. Impulse Tracker will also fail to | ||
85 | play your music if you press F5. Press F11 and you will have an | ||
86 | opportunity to create an order list, required for playback. | ||
87 | |||
88 | |||
89 | ***************************************************************************** | ||
90 | * I created an IT file with ModPlug Tracker and I have it fading out at the * | ||
91 | * end. Why won't it loop when I play it with DUMB? * | ||
92 | ***************************************************************************** | ||
93 | |||
94 | It loops at zero volume. This is what Impulse Tracker itself does. Fix the | ||
95 | IT file by setting the global volume explicitly (Vxx in the effects | ||
96 | column), either at the start, or right at the end before looping. Also see | ||
97 | the next two questions. | ||
98 | |||
99 | |||
100 | ***************************************************************************** | ||
101 | * My module plays too loud and distorts badly with DUMB! What can I do? * | ||
102 | ***************************************************************************** | ||
103 | |||
104 | This problem is most often caused by ModPlug Tracker, which has a complete | ||
105 | lack of regard for the playback volume of the original tracker. See the | ||
106 | next question for DUMB's official position with regard to ModPlug Tracker. | ||
107 | If you wrote your module with ModPlug Tracker, please try loading it with | ||
108 | the original tracker and see if it distorts there too. If it does, reduce | ||
109 | the volume. If not, then it's a problem with DUMB; please let me know. | ||
110 | |||
111 | If for whatever reason you cannot modify the module file itself, you can | ||
112 | make it sound better by reducing the volume passed to al_start_duh(). | ||
113 | |||
114 | |||
115 | ***************************************************************************** | ||
116 | * I created a music module with ModPlug Tracker, and DUMB doesn't play it * | ||
117 | * right! * | ||
118 | ***************************************************************************** | ||
119 | |||
120 | DUMB cannot and will not support ModPlug Tracker. Please see | ||
121 | docs/modplug.txt for details. The original trackers, which DUMB is | ||
122 | designed to mimic as closely as possible, are listed in readme.txt. | ||
123 | If you find DUMB plays your module differently from the original tracker, | ||
124 | then please contact me. | ||
125 | |||
126 | |||
127 | ***************************************************************************** | ||
128 | * My program crashes as soon as I try to load anything with DUMB! * | ||
129 | ***************************************************************************** | ||
130 | |||
131 | Please take my advice and use the debugging build of DUMB, not the | ||
132 | optimised build. Then you'll probably find it aborts instead of crashing. | ||
133 | In this case you probably forgot to register a DUMBFILE system; this is | ||
134 | necessary for loading stand-alone files, though not for loading Allegro | ||
135 | datafiles with embedded music. Follow the instructions in docs/howto.txt | ||
136 | carefully and you shouldn't have this problem. | ||
137 | |||
138 | If DUMB crashes with a specific music module, please let me know. | ||
139 | |||
140 | |||
141 | ***************************************************************************** | ||
142 | * I want to use the stdio file access functions to load stand-alone music * | ||
143 | * files, but I also want to load datafiles containing music files. The docs * | ||
144 | * say I shouldn't call both dumb_register_stdfiles() and * | ||
145 | * dumb_register_packfiles(). What shall I do? * | ||
146 | ***************************************************************************** | ||
147 | |||
148 | When you register a DUMBFILE system, it only applies to files opened with | ||
149 | dumbfile_open(), i.e. separate files. When a file is embedded in a | ||
150 | datafile, dumbfile_open_ex() is used to read it, enabling it to use | ||
151 | PACKFILEs regardless of which DUMBFILE system is registered. In short, you | ||
152 | do not need to call dumb_register_packfiles() in order to load datafiles | ||
153 | with embedded music. See the section on "Sequential File Input" in | ||
154 | docs/dumb.txt if you're interested in how all this works. | ||
155 | |||
156 | |||
157 | ***************************************************************************** | ||
158 | * I want to read a specific object in a datafile using Allegro's * | ||
159 | * "demo.dat#MY_MUSIC" syntax. Why won't it work? * | ||
160 | ***************************************************************************** | ||
161 | |||
162 | Did you call dumb_register_packfiles(), or did you call | ||
163 | dumb_register_stdfiles()? It will only work if you use the former. | ||
164 | |||
165 | |||
166 | ***************************************************************************** | ||
167 | * My program runs, but no music plays! What am I doing wrong? * | ||
168 | ***************************************************************************** | ||
169 | |||
170 | There are a number of possible causes for this. The most likely reason is | ||
171 | that you aren't calling al_poll_duh(); see docs/howto.txt for further | ||
172 | information. | ||
173 | |||
174 | Other possible causes are as follows: | ||
175 | |||
176 | - The speakers are turned down (duh) | ||
177 | - The volume of some system mixer is turned down | ||
178 | - Another program is using the sound card (not a problem for most modern | ||
179 | systems) | ||
180 | - You didn't initialise Allegro's sound system; see install_sound() in | ||
181 | Allegro's docs | ||
182 | - Allegro's drivers don't work on your system and chosen platform | ||
183 | |||
184 | In order to narrow down the cause, consider the following: | ||
185 | |||
186 | - Do you get any other sound from your program? | ||
187 | - Do other Allegro+DUMB programs generate sound? | ||
188 | - Do other Allegro programs generate sound? | ||
189 | - Do other non-Allegro programs generate sound? | ||
190 | - Does your program fail only on a specific platform (e.g. DOS but not | ||
191 | Windows)? | ||
192 | |||
193 | This problem is highly system-specific; please try hard to solve it by | ||
194 | yourself before contacting me. However, if you think this problem could | ||
195 | affect other people, please let me know what the problem is and how you | ||
196 | fixed it, if you did. Be as specific as possible. | ||
197 | |||
198 | |||
199 | ***************************************************************************** | ||
200 | * The music stutters! What can I do? * | ||
201 | ***************************************************************************** | ||
202 | |||
203 | If you have an older computer, it may not be able to cope with the load. | ||
204 | Try reducing quality options; look up dumb_resampling_quality and | ||
205 | dumb_it_max_to_mix in docs/dumb.txt, and consider changing the frequency | ||
206 | you pass to al_start_duh(). | ||
207 | |||
208 | Stuttering may not be caused by excessive load. To find out, try | ||
209 | increasing the buffer size passed to al_start_duh(). Beware of making it | ||
210 | too big though; older systems will freeze periodically if it's too big, | ||
211 | because they render larger chunks less frequently. The timing of callbacks | ||
212 | will also be less accurate, if you are using those. | ||
213 | |||
214 | If you're using the 'dumbplay' example, you can control these parameters | ||
215 | by editing dumb.ini. | ||
216 | |||
217 | |||
218 | ***************************************************************************** | ||
219 | * Why does DUMB use so much processor time compared with other players? * | ||
220 | ***************************************************************************** | ||
221 | |||
222 | This should be less so in this release than in previous releases; the | ||
223 | resampling and filtering algorithms have been optimised. | ||
224 | |||
225 | By default, DUMB uses the most expensive resampling quality option. I've | ||
226 | found on an AthlonXP 1800+ and on a Pentium 233 that it typically uses | ||
227 | about twice as much processor time as the least expensive option. | ||
228 | |||
229 | Try setting dumb_resampling_quality to DUMB_RQ_ALIASING or DUMB_RQ_LINEAR. | ||
230 | See dumb.txt for more information. If you're using the example programs, | ||
231 | you can control this variable by editing dumb.ini. | ||
232 | |||
233 | DUMB uses 32-bit ints for mixing. Some players use 16-bit ints, and are | ||
234 | therefore marginally faster (not much!) and lower quality. So you can't | ||
235 | expect DUMB to beat these players. Furthermore, DUMB is currently written | ||
236 | entirely in C. GCC does an impressive job on the C code, but that's not to | ||
237 | say some custom-written assembly language couldn't beat it ... | ||
238 | |||
239 | |||
240 | ***************************************************************************** | ||
241 | * Why does DUMB generate so much background noise? * | ||
242 | ***************************************************************************** | ||
243 | |||
244 | You're probably using the DOS build on a system with bad Sound Blaster | ||
245 | compatibility (most Windows XP systems fall in this category). This would | ||
246 | mean DUMB could only access an 8-bit driver. The Windows build will almost | ||
247 | certainly give better results. Your DOS binary will still give good | ||
248 | results on systems with better compatibility (like my Windows 98 system). | ||
249 | |||
250 | |||
251 | ***************************************************************************** | ||
252 | * I e-mailed you and you replied with "RTFM"! What does that mean? * | ||
253 | ***************************************************************************** | ||
254 | |||
255 | Read The Manual. If it's a specific problem, I'll probably be kind and | ||
256 | tell you where to look in the manual. However, if I get the impression you | ||
257 | haven't even looked for a solution in the manual, expect no mercy ... | ||
258 | |||
259 | |||
260 | Ben Davis | ||
261 | entheh@users.sf.net | ||
262 | IRC EFnet #dumb | ||
263 | See readme.txt for details on using IRC. | ||