Mail Archives: djgpp/1997/03/05/22:02:11
Paul Derbyshire writes:
>> 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.
There's only one format, in which colors range 0-63. It occured to me
that you might have mistakenly used a 0-255 color range (eg. 255, 255,
255 for white), which would result in exactly the problem you described.
But if you loaded the palette from a PCX, that can't be the case...
>> Also, which graphics driver is being autodetected? Would it, by any
>
>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
I really can't help you with your problems unless you are able to devote
some small amount of effort and intelligence to investigating them. Try
running test.exe, and looking at the screen while you do so...
I also asked you whether this problem shows up with my demo game or just
your own programs: it would be good if you could answer this question.
>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".
Oh please, give us a break. This is straying off topic, so please don't
bother following up to this, but I think you are doing SciTech an
injustice here. IMHO they are doing a great job, and from personal
experience I can say that Kendall Bennett is a very nice and helpful
person. Just because he wants you to pay him for his work, there's no
need to be nasty about it.
>blit8.S
>gfx8.S
>sprite8.S
>and some others. What is the 8? DOes it refer to 256 color video?
Yup. The theory is that at some point in the future there will be a
blit16, blit32, etc...
>>>* Compiled sprites seem to have four compiled routines in them. Why?
>>
>> For mode-X. In linear graphics modes, only the first of these is used,
>
>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]?
Not quite. All four routines get called each time you draw a mode-X
sprite: the first one draws pixels 0, 4, 8, etc, the second draws pixels
1, 5, 9, and so on. This means the whole sprite can be drawn with only
four plane changes, and allows multiple pixels to be copied with 16 and
32 bit writes.
>Then, where can one obtain a FREE vesa 2.0 driver? I'm not exactly made of
Write one? Or you could hassle the hardware manufacturer about it, but
in my experience they won't be very much use, and if they do give you
something it's unlikely to work properly (out of a sample of around 30
drivers that I've come into contact with over the last couple of years,
only around 60% actually meet up to the VESA standard. Not a good
success rate :-)
>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'm not familiar with the Rhide debugger interface (Robert?) but in gdb
you can manually call functions from the program you are debugging, so
you could call allegro_exit() yourself. It would be much safer, though,
just to run through to the end, or to resume it and then press
ctrl+alt+end.
>>>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
>>
[snip]
>> 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.
Just because a planar bitmap format is a lot more awkward than onto a
linear surface (drawing lines and circles and so on is slower in mode-X
for exactly this reason). At the moment, drawing onto memory bitmaps
happens with fast linear operations, and the slowdown comes in the
linear->planar conversion as you blit to the screen. If I added planar
memory bitmaps, all the drawing onto them would be slower: sure, you'd
be able to blit them across to the screen more quickly, but what's the
point if it took longer to draw the image in the first place?
The only time when a planar memory format could be advantageous is when
the bitmap is purely an image source to be copied to the screen, and you
aren't drawing onto it in realtime. But if this is the case, why not use
a compiled sprite for maximum speed?
/*
* 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 -