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