Mail Archives: djgpp/1997/03/03/17:52:30
Paul Derbyshire writes:
>* Why, when using a SVGA mode e.g. GFX_AUTODETECT 640x480, does a
> fade_in(palette) or a fade_out() seem to do 4 fades in series instead of
> just 1? Fades work as expected in GFX_MODEX. Is it a bug or a "feature"?
It's a bug. Whether yours or mine, I don't know, though :-) Does this
happen with any of my test progs, eg. the demo game? (that does a lot of
pallete fades). When reporting bugs, it's helpful if you can say which,
if any, of my examples demonstrate the problem: then I know which bit of
my code is likely to be at fault, or whether the routines are just being
used wrongly...
In this case, two possibilities spring to mind. Are you sure the palette
is in the right format, ie. you haven't confused the 0-63 color format
with a 0-255 range?
Also, which graphics driver is being autodetected? Would it, by any
chance, be VBE/AF, in which case which version of UniVBE did the
vbeaf.drv come from, and does it start working if you select the VESA2L
driver instead?
>* Is the video manipulation ultimately done with super-fast nearptrs or far
> pointers? Near pointers are thought not to work on some DPMI hosts,
Far pointers. IMHO the difference between the two is a matter of
simplicity rather than speed, and when you are writing in asm that
ceases to be an issue, so there's no reason to use nearptrs...
>* What functions in allegro are typically inlined?
Load up allegro.h and search for "inline". There's a lot of them, but
most are just wrappers to implement the indirection via bitmap vtables
(a slightly roundabout approach that results from the fact that C
doesn't provide virtual functions).
>* Which graphics functions use inline asm for optimisation?
Very few: they're mostly written in seperate .S files. But most of the
low level drawing routines are in asm.
>* Was Allegro compiled with -m486?
That's a really silly question. Look at the makefile! (and yes, it is).
>* Compiled sprites seem to have four compiled routines in them. Why?
> (My guesses were: one for the screen, one for a sub bitmap of the screen,
> one for memory bitmaps, and one for a sub bitmap of a memory bitmap.)
For mode-X. In linear graphics modes, only the first of these is used,
and the others will be NULL. In mode-X, there's one for each plane of
video memory.
>* Do you know where UniVBE 5.1 can be obtained?
> It seems to be the most up-to-date version that DOESN'T cripple itself
> after 21 days.
I have no idea, and I wouldn't tell you if I did. The reason it disables
itself is that you are supposed to pay for it, because SciTech are
trying to make a living from their work.
>bunch of queer repeating and *LOUD* sound effects started coming from
>my SB! It has happened a total of 3 times now. All 3 times after an
>allegro program a) used sound and b) never got to allegro_exit.
That sounds very reasonable to me. If you program doesn't get to
allegro_exit() the hardware will be left in some strange state, and God
only knows what will happen (I'm surprised it doesn't immediately lock
up). But, when your program crashes it _should_ call allegro_exit()
automatically from a signal handler: do you get the "Shutting down
Allegro" message, or not?
>I also have a suggestion: to create a new bitmap/sprite type, say
>MODEX_BITMAP. These would be like memory bitmaps but with a planar
The trouble with this would be the code bloat produced by extra versions
of all the drawing code. You are right that it would speed up blitting
from memory to the screen, but it would enormously slow down drawing
onto the planar memory bitmap, so I don't think you'd actually gain
anything. The only benefit I can see would be storing sprites in such a
planar format, but you can use compiled sprites for that...
>Also, using an S3, and lacking a non-crippled UniVBE supporting Vesa 2.0,
>is it possible to get a "modex" mode 320x240 that is not limited to 256 k?
The easy solution is to register UniVBE: I can't recommend it highly
enough.
Alternatively you could try to implement them yourself in the S3 driver,
but I have no idea how you'd go about doing it. The BIOS doesn't support
them, so it would take a lot of very low level register twiddling to get
the right resolution...
/*
* Shawn Hargreaves - shawn AT talula DOT demon DOT co DOT uk - http://www.talula.demon.co.uk/
* Beauty is a French phonetic corruption of a short cloth neck ornament.
*/
- Raw text -