[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Shawn Hargreaves <shawn@xxxxxxxxxx> writes:
> The biggie is X support. Michael: care to give us a quick progress report on
> this?
It is in the same state as month ago. Some pieces for setting DGA
mode but no code for making bitmap from video surface. No progress on
windowed mode. I have test programs for setting DGA mode and getting
access to arbitrary window (except for getting keyboard input from
root window, but that is not a big problem). Just I wanted to add
support for setting arbitrary window as video surface and that
requires a fair amount of conditionals and careful thinking about
design. Perhaps I should not add this feature yet and just make
something that works reliably.
> This would be a really nice thing to have in because it would make
> sure that just about every Linux user has a way to get graphics working no
> matter what their hardware. I've never programmed X before, but I'd be happy
> to help out if you can point me in the right direction, or otherwise I'll
> just shut up and let you get on with it: whatever you prefer :-) If you are
> busy with other stuff and a long way short of having any finished X graphics
> code, how long would it take to do a quick bodge and just copy across the
> graphics stuff from the existing XWinAllegro package?
About 2 weekends, without adding new features. I will have more spare
time now and will try to finish X-windows version ASAP (but without
code for setting custom window as screen).
>
> On my machine, the OSS sound driver fragment size defaults to 4096, but that
> results in about a 2 second delay before sound is heard. I can decrease it
> down to about 128 without any problems, and with that value, even DIGMID
> music works perfectly, but presumably this will depend on the machine and
> soundcard type. How carefully chosen is the 4096 value? If that was just a
> guess, should we perhaps try to collect data about what values work best for
> a range of different people, or maybe try to calibrate it based on processor
> speed?
There might be some problem with this setting. Buffer size means
samples per buffer, when playback rate is set to 44kHz, one buffer
should play in samples/(samples_per_sec) = 4096/44000 = ~0.1 sec.
>
> Is there any way to autodetect OSS support for mono/stereo and 8/16 bits, or
> do we need people to configure this manually? On my machine I get a vast
> quality improvement (obviously) after I change from mono 8 bit to stereo 16,
> but experience on DOS shows that most people will never bother changing this
> sort of config setting, so if we can't autodetect it, they will be stuck
> with poor quality sound. That's their fault for being dumb, of course, but
> it would still be nice to do the right thing by default :-)
We can choose highest values, but device driver might use lower value,
and then it will return actual value. The problem is, we need to
know parameters for playback (stereo/mono, 16/8 bits, playback rate)
before calculating preferred buffer size, but buffer size must be set
first. It might be possible to open device for the first time, set
playback parameters and obtain values selected by device driver. Then
close device, open it again and now request buffer with correct size,
and set parameters again.
--
Michael Bukin