Re: Graphics & game speed testing
- Posted by Talvitie <smtoa at SAUNALAHTI.FI> Apr 23, 1999
- 490 views
Molasses wrote: >>Does anybody have a clue where hardware I/O stuff could be found? Does = any >manufacturer release information 'bout using >their/general (f.ex. = graphics) >cards? > >Are you familiar with 3dfx's Glide API? >Unlike Direct 3D and OpenGL, it is not a 3D engine, rather it is a = small set >of functions to directly access any 3dfx card. >You still need to write your own 3d engine (as you've said, you've done >that), and you use Glide for texture mapping, z buffering, alpha = blending, >fog, etc (the things that are slowest in software). > >As I mentioned not so long ago, I've been writing a wrapper for Glide = 3x. >Well, the wrapper part is complete, the documentation and demos are = not. If >you believe your 3d rendering method is as fast as you say it is please >email it to me or i could send you my Glide wrapper if you want (it's = very >easy to use). Don't worry, I would not steal any of your code, take any >credit for your work, etc. We have the mailing list as witness to your >claims, so it would be obvious if I stole anything. > >Curious but sceptical, > >-molasses Well, I have made my own improved ZBuffer. ofcourse it would be great, = if this could be done by hardware. My question is what pharemetres does = it need? My Horizline takes these:=20 -- procedure HorizLine(atom x1, atom x2, atom y, atom z1, atom z2, = integer col) where x1, x2 and y are the visual place(!) on screen, z1 and z2 are = distance to camera(that's the data sended to ZBuf) and col is ofcourse = color. The procedure draws a horizontal line to screen. This may be the slowest = process in 3D engine, alltought I have and will optimize it a lot more.=20 I finished half a year ago my 3D engine project with QB. It had a lack = of speed, shading and texture mapping, and it had several bugs. The work = I've been doing with Euphoria is rewriting the previous source, fix the = bugs and then add the shading and texture mapping. I know how to do this = all, but it takes some time. I've created my own methods how to handle = things like objects, etc. alltought I quess other engines use pretty = much samekinds of. I haven't done any optimation yet. Why's that? I = don't want the source to be messy cause there just might be some bug(s) = in this point. Now I'm testing flat faces(face with one solid color), = and it's almost done. I'm really interested to use your wrapper. It could save enough time to = make games even for p133 with 3Dfx card(or duke nukem 3D type games for = slower ones). I might send the source to you, when my engine is = finished/ready for 1st demo release, but this time it's not much use. = Please, send the wrapper to me(hope it has some documentation :) , so = that I could modify my engine to work with it. If and when I deside to = use it, I'm still going to do my own Z/BSP-Buffering, etc., so that the = engine would work with machines without 3D card. BTW, all you 3D programmers. Wanna know where to get documentation 'bout = making 3D engines? Ica (from Finland also :) has made a pretty good = text. He's also included a lot of examples (VESA required) with it . The = only minus is that the documentation and the examples are for C, but so = what? I think it's better to think everything by yourself, rather than = copy it without even bothering to look the source, and the documentation = itself don't need almost any knowledge bout C. So go to the site and = download: http://www.hut.fi/~ipelkone I haven't read the english version, but the finnish ( version is a = pretty humoristic. I had made my own QB 3D engines rendering before I hadn't read any 3D = documentation, so I render different way than others (but with more = speed :) , but the Ica's text helped me a lot with Z, S and BSP-tree = buffering, Mip Mapping, texture mapping, shading, etc. etc. go to the = site! Highly recommented! And finally I'd like you all see what Hawke claims bout his TrueColor = library: >naturally, drawing to screen pixel by pixel is slow... >read the docs and discover how to improve speeds with >pixel plotting (ie:plot several pixels in each pixel() call >instead of one by one) >also, use virtual screens and page flip them... >it really is faster if you use appropriate techniques... >stay away from 'images' of sequences and use >full blown virtual screens... >its very easy to get 20-30 fps at 640x480x16.7M >on a p133 (i've done it many times) >and got 18-20 fps at 800x600x16.7M on the >same p133... >i can usually sustain 25fps or more on a p200mmx... > >technically, in some ways, Neil is faster, if your >card is fully vesa2.0 compliant (or UNIVBE can >make it 2.0 compliant) but, it is a lot harder to use... If this is true(haven't tested yet), as I quess it is (no doupts :), = he's TrueColor lib could be fast enoug for me(you have to remember that = the game itself tooks some time too). I'm still lack of those good 8- = and 16-bit colors... -- Tapani Molasses, mail me to smtoa at saunalahti.fi