Mail Archives: djgpp/1997/03/07/07:56:30
Shawn Hargreaves (Shawn AT talula DOT demon DOT co DOT uk) writes:
> 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...
Actually, some of the colors for text drawing (colors 249-255) and special
things are defined separately and edited after the palette is loaded.
Maybe those should be moved to the .pcx. (The .pcx has the llast 20 colors
black.)
>>> 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...
S3.
> 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.
Nada...
>>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.
Hm.
>>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?
Simple. I was thinking of using only 2 operations on a
modex-memory-bitmap: aligned blits and draw_compiled_sprite.
Right now, I have a Mode X screen with room for three of the 320x240
screen. Two are used for page flipping. One holds an image of the
background, which is scrolled and then blitted (plane-aligned) to the
active page.
The thing is, it would be nice to be able to stuff this in RAM. Then I
could store up more layers of parallax background and stuff than the 256K
modeX limit allows. And I could triple-buffer the actual screen, thus
reducing time spent waiting around for the retrace.
--
.*. 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 -