delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/03/04/21:11:51

From: leathm AT solwarra DOT gbrmpa DOT gov DOT au (Leath Muller)
Message-Id: <199703050200.MAA14982@solwarra.gbrmpa.gov.au>
Subject: Re: Floating Point vs. Fixed Point
To: orly AT gibson DOT eee DOT upd DOT edu DOT ph (Orlando Andico)
Date: Wed, 5 Mar 1997 12:00:20 +1000 (EST)
Cc: bryan AT alpha DOT hcst DOT com, djgpp AT delorie DOT com
In-Reply-To: <Pine.SGI.3.93.970305092443.8941J-100000@gibson.eee.upd.edu.ph> from "Orlando Andico" at Mar 5, 97 09:26:07 am

> Which brings up another point: wasn't Quake targeted at Pentiums and up?
> then why is there a slew of 16.16 fixedpoint code in it? doesn't the
> Pentium run FP faster than integer??? (snarl.. this is one of the reasons
> I've hit a snag on my Quake-on-SGI-and-SPARC port -- those &*%^^ fixed
> point routines are in Intel assembly <ack>)

There is fixed point so Quake can process 16 pixels at a time using affine
texture mapping while a perspective divide is running on the next perspective
correct calculation. I think the inner loop would be something like: (well,
I do it this way and Quake is about 1/2 cycle quicker per pixel)

	fdiv	leftpoint;
	get	leftu, leftv;
	get	rightu, rightv;
loop:
	fix	(rightu - leftu) >> 4;
	fix 	(rightv - leftv) >> 4;
	fdiv	next_right_point;
	calc	offsets in texture for u,v;
	calc	UV step Nocarry, UV step carry;
	unrol	loop to map 16 pixels in the middle;
	<fdiv	finished>
	mov	right point values, left point values
	loop;

Remember, Quake was designed specifically for Intel CPU's. If your porting
to another platform, you have to do all the dirty work.

Leathal.

- Raw text -


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