Message-Id: <3.0.1.32.19990218121801.009135a0@iut.ujf-grenoble.fr> X-Sender: sletuffe AT iut DOT ujf-grenoble DOT fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Thu, 18 Feb 1999 12:18:01 +0100 To: djgpp AT delorie DOT com From: LETUFFE SYLVAIN Subject: Re: Line frame buffer speed problem my 3D engine In-Reply-To: <36CAC0B9.6BA3@club-internet.fr> References: <3 DOT 0 DOT 1 DOT 32 DOT 19990216140256 DOT 0091b100 AT iut DOT ujf-grenoble DOT fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id GAA17243 Reply-To: djgpp AT delorie DOT com >Okay, I'll send you the LFB-detect stuff right away, it's >sort of ripped out, I'm sending the include files so include them >and call init_graphics and then you should be able to >use the descriptor "video_ds" that points to the lfb. > >You might also want to change the mode, it is actually >640x480x16bit(mode 0x111) and it's in init_lfb_graphics(). >Well, if it doesn't work, sen me a mail. > > >second: the rotation stuff: >Hm, it's not as easy as that, or, actually, it's rather easy, but >I don't have any easy code to show you "like that". >So, I'll try to write down something, and include some of >my code if you want to. Many many thanks.... > >And now a question from me: what are you using(planning to use) for >algorithm in your engine? resolution etc? Which algorithme ? (there are so many I am using and I will use !! ) - graphic resolution > all of course ( I'd like to get the most configuration as possible) But I am only workink on 8 bits colors modes for now with 320x200, 320x400, 640x480.... 1600x1200 - Map resolution > Well I am doing it (for now) in long int format and I shall go later in float But I am not sure of that yet...( speed.... ) - Main algortihms > For drawing I use the "bresenam line algorithm" it is very usefull for lines 2D, lines 3D, gouraud, phong, maping... - The wole stuff > all the map is tored in memory (and it doen't change ) All formulas are computed from one position, one direction. And the result is stored in a second memory buffer which I dump to the screen The "you" position is defined by x,y,z and the "your_direction" is define by theta and phi ( angles used in "coordonnées sphériques" ) Rotation becomes very simple ( add a value to both theta and phi ) while a translation result in an add to x,y and z. Well this looks quite good, but the "formulas" I 've told about are quit expensive in term of machine computing. And I don't really know if that'll do !!!