From: Shawn Hargreaves Newsgroups: comp.os.msdos.djgpp Subject: Re: Some Allegro questions (Shawn?) Date: Wed, 5 Mar 1997 19:40:13 +0000 Organization: None Distribution: world Message-ID: References: <5fdsds$p42 AT freenet-news DOT carleton DOT ca> <5fj3dn$e3u AT freenet-news DOT carleton DOT ca> NNTP-Posting-Host: talula.demon.co.uk MIME-Version: 1.0 Lines: 107 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp 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. */