This raises an interesting difference between NVIDIA and AMD hardware - NVIDIA seem to have a much more efficient anisotropic filtering implementation. On AMD on the other hand, even going to 4x filtering will cut your framerates by 25%.
Of course at this kind of speed it's essentially meaningless, but what it is also is totally consistent in everything I've tested so far.
Intel on the other hand are the strange child in the family - on one older machine I saw a small but significant performance increase going to 4x filtering (which was the highest it could take).
Resolved an odd timer glitch today; it transpires that at lower values of host_maxfps my old code was sometimes running server frames (and sending client data to the server) at half the rate it should - every 27.888 milliseconds (instead of every 13.999) - even worse, it was oscillating between the two at a quite irregular rate that was hardware-dependent. Ouch. Didn't see that one coming. Things are better now.
Tuesday, March 6, 2012
1258 fps
Subscribe to:
Post Comments (Atom)
9 comments:
Random brainfart: I wonder if at these kind of speeds it's possible to do some kind of temporal blurring or supersampling to condense it into 60fps and get realistic motion blur on everything.
With all these pictures of the Marcher Fortress, I can't help but notice the crappy lighting ;-P The enormous flames seem to give off absolutely no light, and the main entrance is just black.
I think most of the lighting in that shot is probably just skylight; there are loads of glitchy places in it too where you get black splodges where multiple surfaces join at angles.
The motion blur idea is interesting. You could probably accumulate multiple frames into a floating point render target then scale it back down for a final present. That's quite a nice idea actually; I may yet provide that as an option (something worthwhile to do with stupidly high framerates).
I'm a little bit off-topic here. I've just released UQE Quke and I'm moving onto Quake2.
I've done a few fixes, but I've seen on a thread you also replied to "Quake2 engines" on inside3d. People are referring to two specific bugs in Quake2. Some sort of viewport bug and some 10hz bug. Do you have an idea what those are about and where I could look at in the code of a source port with these fixes?
Apologies for the off-topic comment... I don't know how else to get hold of you over email or something.
Awesome, downloaded. :)
I'll need to check out the I3D thread before I can comment further on those Q2 bugs. Every now and then I get a fit to work on some Q2, but it's been a while and I'm a little rusty.
I'll PM you my email on I3D or QuakeOne.
By the way, I recommend using the DarkPlaces naming convention for replacement skins: "enforcer.mdl_0.jpg" - mainly because ID1 content has both "s_light.mdl" and "s_light.spr".
Off-topic is cool. Interesting things can come from off-topic (like the "condense to 60fps" idea above).
Lord knows you're busy with the Direct3D 11 porting work, but have you had an opportunity to revisit the idea of a modern, Direct3D-native Doom engine? The ZDoom software renderer's nice enough, but GZDoom's a snuffling pig.
No Doom for me.
I did take a long look at the main contenders and the way it pans out is something like this.
Basing a port on the original id code is just nuts. Far too much work involved to get even basic stuff working.
Basing a port on one of the bigger engines is not something I'd do. I personally don't approve of the "depend on lots and lots and lots and lots of external DLLs and content" approach (that doesn't mean it's wrong - I just don't like it) and they all use that.
The only serious contender in my eyes would be Carmack's iOS port. That would mean moving over the platform-specific code then tackling the renderer.
I think the end result would be of very marginal appeal. Maybe one or two people might use it, but the Doom community - and I'll admit that I don't really keep tabs on it regularly - seems very set in their preferences.
In a way it's like certain parts of the Quake community - they have their preferred engines and there is just no way an alternative option is going to break in there.
An engine needs a unique selling point; it needs a reason to exist. I don't see anything I might do as having a strong enough reason, so the end result would be me fooling around with it in spare time. Not much interest in doing that.
It's kind of a pity as I have some ideas for what I'd like to see in a Doom engine - proper water warps instead of animated textures, an in-game WAD browser, basic stuff that they all seem to lack but nothing too far beyond what the original game was. I've no interest in MD2s, external textures, adding a console, mouselooking or anything like that. So quite marginal appeal it is.
If you add a wad browser to one of the Doom ports, it might be taken up by others and you might then see it in more engines. Gradual improvements instead of full engine?
Anyway, I like PRBoom because it's fast and works and I only ever play Knee-Deep in the Dead, anyway :-p
I once got partway through the second episode. :)
Doom doesn't really do it for me in terms of gameplay, I'm afraid, and I can never sustain myself through it for too long.
Regarding a WAD browser, the way I see that working is rather than having to use a launcher, it just picks up whatever WADs you have, defaults to doom.wad or doomu.wad or whatever, then adds a menu option letting you change them. All part of my "don't make the player have to work" philosophy.
Post a Comment