Re: Graphics & game speed testing

new topic     » goto parent     » topic index » view thread      » older message » newer message

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 ( smile 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

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu