Mail Archives: djgpp/1997/03/05/06:09:45
Shawn Hargreaves (Shawn AT talula DOT demon DOT co DOT uk) writes:
> 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?
There are two formats? I've just seen one in all the allegro docs... the
PALLETE and RGB pair.
If you're wondering where the pallete comes from, it is loaded using
load_pcx and a dummy .pcx (subformat version 5) called paltempl.pcx, which
is just a blank image made in Paintshop Pro 4.0 and with the colors
chosen, then the image saved as .pcx. It is a 256-color pcx of small
dimension with no worthwhille image data.
BITMAP *junk;
PALLETE my_pallete;
junk=load_pcx("paltempl.pcx",my_pallete);
destroy_bitmap(junk);
> 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?
VESA2L requires that I find a f*cking video driver that doesn't whine
about money and die after 21 days. Did these video companies ever discover
that the world has students in it? Have they ever seen, let alone paid
for, a tuition?
I haven't a clue what's autodetected. Since I have an S3 video card, I
would assume it autodetects S3. Since I don't have a vesa driver, no
thanks to power and money hungry people who obviously don't seem to adhere
to the GNU/FSF philosophy, I doubt it's any driver whose name involves
"VESA" or "VBE".
(What is "VBE" anyways? VESA is Video something Standard something I guess.)
>>* 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).
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.
When I downloaded 2.2 and ran make, I noticed a few .S files. There were:
blit8.S
gfx8.S
sprite8.S
and some others. What is the 8? DOes it refer to 256 color video?
(That implies that you at least left room for expansion to other color
modes...:))
>>* Was Allegro compiled with -m486?
>
> That's a really silly question. Look at the makefile! (and yes, it is).
I did, when I ran make on the downloaded 2.2. It answered my question.
-m486 -O3 -fomit-frame-pointer, the same combo I am using on my pet project.
>>* 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.
That was my other guess... the routines correspond to the four possible
alignments of the sprite and the screen then? I.e., when you
draw_compiled_sprite (bmp,spr,x,y) it calls draw[x%4]?
This would mean the compiled sprites don't suffer the slowdown of other
operations from memory to a mode x screen.
>>* 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.
Then, where can one obtain a FREE vesa 2.0 driver? I'm not exactly made of
money. In fact not only do I live on a student budget, but I am more broke
as of a week ago than usual even. Besides, to order that sort of crap you
need a credit card and/or snail mail access. With this income I don't have
a credit card. Without snail mail access I can't mail money orders.
>>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?
This wasn't a crash; I ran it with a breakpoint, then inspected some
variables, edited, and recompiled. Is there any way to call allegro_exit
after such a thing without having to run the program all the rest of the
way through?
>>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.
Why would it? Especially if you made a second set of drawing functions, or
else used that vtable thingie.
> 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.
If you tell me a way I can quickly get fifty-some-odd bucks and then
teleport it to their sales department, sure.
> 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...
--
.*. Where feelings are concerned, answers are rarely simple [GeneDeWeese]
-() < When I go to the theater, I always go straight to the "bag and mix"
`*' bulk candy section...because variety is the spice of life... [me]
Paul Derbyshire ao950 AT freenet DOT carleton DOT ca, http://chat.carleton.ca/~pderbysh
- Raw text -