delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/06/03/05:18:54

From: "Thomas Harte" <T DOT Harte AT btinternet DOT com DOT REMOVE_THIS_BIT>
Newsgroups: comp.os.msdos.djgpp
Subject: Allegro sprite scaling : the fastest?
Date: 27 May 1997 23:25:45 GMT
Organization: SoftySoft
Message-ID: <01bc6af5$49b40e80$e83663c3@default>
NNTP-Posting-Host: host5-99-54-232.btinternet.com
Lines: 27
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

	I've probably initiated a flame war with this title, but before you all
start saying 'no, library x is better than Allegro because it triple dirty
triangles the blit buffer by itself . . .', I am asking this with a
specific case in question.

	I am playing about with ray casting at the minute, and have just completed
the very very first test code ie, it works but with graphical glitches
thanks to rounding errors, and is very slow because it is 100% floating
point, and 0% designed for speed - it even uses square root functions, as
opposed to sine / cosine via look up tables I plan to use.

	Being ray casting, naturally I am rendering the display via scaled
slithers. What I want to know is - are there faster algorithms than the
Allegro 'stretch_blit', bearing in mind I am using slithers (effectively
sprites 1 pixel across by some other amount down, probably a multiple of
two)? It's just that the test code performs worse than I would have
thought, in the order or a good speed when the walls are small, and a bad
one when they are close by. This is exactly the opposite of what I would
have expected because of the way ray casting operates. The only bottleneck
I can think of is that the sprite scaling is slower when the walls are
rendered bigger.

	For reference, the scaling is done between two memory bitmaps. Is there a
thing faster than Allegro's general purpose routines for this specialised
case?

		-Thomas

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019