My demo updated again ... now this time it should really wor

On 2002-02-23 04:08, Galilee wrote:
hehe
I don't know why I would lie about that. In some areas of the demo I hit 120-130fps. Mostly it hovers around 70-90 and minimum I have seen is 60.

I flied around myself and managed to get almost 200fps in one very dark area ;)

<font size=-1>[ This Message was edited by: Galilee on 2002-02-23 04:12 ]</font>

I do :LOL:
 
Please no fighting!
----------------

Ran the updated version... much faster (about 30%) on my Radeon 8500LE using 6032 drivers.

Seems you have changed the visuals slightly as well Humus.

Great work.
Now you have the core ready I would like to see more demos based on this engine :smile:
 
On 2002-02-23 01:55, Dave B(TotalVR) wrote:
Hehe, so how do I get it to work on my KYRO then? it mons abotu two gl_extensions:

gl_ext_texture_edge_clamp
and
GL_arb_texture_env_crossbar/gl_nv_texture_env_combine4

Im sure the clamp thing should work, ist that really basic? But what about the other?

The GL_EXT_texture_edge_clamp is just basic clamp to texture edge functionality, should be supported by every card since voodoo1. Maybe they have done the same mistake as nVidia did in the early days, thinking that the GL_CLAMP parameter in the core API should do this while it's actually clamping to texture border (which isn't the same thing).

GL_ARB_texture_env_crossbar/GL_NV_texture_env_combine4 offers functionality such that you can access arbitrary texture units from any arbitrary texture stage in the standard multitexture pipeline, and not just the output from the texture unit before it. This way I can squeeze the coloring of the diffuse lights into the equation without requiring another texture unit to be enabled.
 
On 2002-02-23 06:12, misae wrote:
Ran the updated version... much faster (about 30%) on my Radeon 8500LE using 6032 drivers.

Seems you have changed the visuals slightly as well Humus.

Great work.
Now you have the core ready I would like to see more demos based on this engine :smile:

The performance increase comes from the frustum culling I've implemented, it can cull half the BSP tree at once (if we're lucky), nothing that's outside of the frustum will ever pass the rendering code, saves lot's of state change overhead, which I suspect is a limiting factor, I used to get 120 fps when looking straight into the black roof with nothing but the roof visible, now I get 430 fps doing so :smile:
But in the fillrate heavy situations the difference is much smaller.

Anyway, I'll be producing more stuff based on this, gonna implement other cool stuff into it, planing on putting refraction through transparent surfaces in there. Coronas may find it's way into it too, shouldn't be too hard to implement.
But currently I'm more concerned about the extreme brightness of diffuse lit surfaces on GF3.
 
Athlon 800
Win2k
DX 8.1
512MB ram
GF3 27.30 drivers

this is what I see:


EDIT: Crap...how do you attach images here?

EDIT: Ok, since I can't figure this out and don't have a site to post do, I can describe the error as what the screen looks like in Quake when you clip out of the level and everything gets all scrambled.


<font size=-1>[ This Message was edited by: borzwazie on 2002-02-23 17:59 ]</font>
 
AHA!
The problem is with Anisotrpic....
Turn it off, and the demo works fine!
Getting 50+ fps (mostly exactly 50, i have vsync on, 100hz refresh :smile:)
 
Phew ... I think I've solved the extreme brightness bug now. And if it still doesn't work as it should you can at least enjoy the very beautiful coronas I've added around the lights with soft in and out of visibility. :smile:

Redownload boys :p
http://hem.passagen.se/emiper/3d.html
 
great work :smile:
Works fine now, the colors are much better.

humus_again.jpg


Would it be hard to make a timedemo of it? Calculate the average in one round in the demo.

In this version the performance is a little better. On the center position (enter) I now get around 10fps higher, changeing between 70 and 90 instead of between 60 and 80.


<font size=-1>[ This Message was edited by: Galilee on 2002-02-23 23:00 ]</font>
 
wow, i was impressed to see this updated version running on my oldie GF1 SDR :smile:
well actually i got 0 fps, but i saw the initial image (wouldn't move anytime soon to not loose my patience :p)

guess i'll need to upgrade my gfx soon just to watch your demo :smile:
 
WOW :eek:

Mam, if you add some bots and weapons you could sell it !!!!

Still getting 43fps, my vsync on at 75hz.
 
On 2002-02-23 22:45, Galilee wrote:
Would it be hard to make a timedemo of it? Calculate the average in one round in the demo.

In this version the performance is a little better. On the center position (enter) I now get around 10fps higher, changeing between 70 and 90 instead of between 60 and 80.

It should be quite easy to make a timedemo out of it, perhaps I should add a benchmark option in the .ini file, shouldn't be too much work.

The performance improvement btw is not because of any engine optimizations, but just because I've made the light in the middle a little smaller, 800 -> 700. Saves some fillrate ... and I thought it looked a little better that way too.
 
On 2002-02-24 01:04, pascal wrote:
WOW :eek:

Mam, if you add some bots and weapons you could sell it !!!!

Still getting 43fps, my vsync on at 75hz.

Too bad I suspect bots is the hard part ...
But I'll at least going to put in some models, maybe doing some multiplayer game of it. Btw, do anyone know of a plugin or something to maya so that I can export models into a more friendly format like .ase (or perhaps .3ds so I can load it up in 3d studio max and export as .ase)? I've done a model I think I might want to use. Btw, do anyone know how to convert a nurbs model into a polygonal model in maya?
 
On 2002-02-24 01:21, Althornin wrote:
Great work Humus, looks great!
Any ideas why aniso on the gf3's kill it?

Nope, must be a driver bug. I've sent a mail to nVidia about it, hopefully they'll reply soon (if we're lucky ...)
 
On 2002-02-23 14:03, Humus wrote:
The GL_EXT_texture_edge_clamp is just basic clamp to texture edge functionality, should be supported by every card since voodoo1. Maybe they have done the same mistake as nVidia did in the early days, thinking that the GL_CLAMP parameter in the core API should do this while it's actually clamping to texture border (which isn't the same thing).

GL_ARB_texture_env_crossbar/GL_NV_texture_env_combine4 offers functionality such that you can access arbitrary texture units from any arbitrary texture stage in the standard multitexture pipeline, and not just the output from the texture unit before it. This way I can squeeze the coloring of the diffuse lights into the equation without requiring another texture unit to be enabled.

...but how do I get it to work on my KYRO? re-write the driver to support those extensions?:D

Any plans to suppourt standard multitexturing for the difffuse lighting so it works on DX7 hardware?

Dave
 
On 2002-02-24 00:19, Rambler wrote:
wow, i was impressed to see this updated version running on my oldie GF1 SDR :smile:
well actually i got 0 fps, but i saw the initial image (wouldn't move anytime soon to not loose my patience :p)

guess i'll need to upgrade my gfx soon just to watch your demo :smile:

Well I get the music and a white fuzzy screen with a lite in the middle with my Geforce annillator pro. I would say it is about time for upgrade.

Sabastian :LOL:
 
On 2002-02-24 01:48, Humus wrote:
On 2002-02-24 01:21, Althornin wrote:
Great work Humus, looks great!
Any ideas why aniso on the gf3's kill it?

Nope, must be a driver bug. I've sent a mail to nVidia about it, hopefully they'll reply soon (if we're lucky ...)

hehe, your "game" is the first game that has been messed up with aniso on. Really strange if you are the first to run into this bug.
 
Back
Top