 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
This is more exciting than almost any new game release! Some great changes listed, thank you for your continual work on this, metl.
As for this... Does this finally mean no more having to worry about keeping Quake's original engine limits now that Fitzquake can play maps that exceed them? Yes, but I look forward to watching with amusement as people complain that they're hitting the new limits in 1-2 months... different to that used in other engines? It seems to be a bit more jerky and/or delayed than something like aglquake. Using r_lerpmodels 1 and r_lerpmove 1.
disables r_lerpmodels and r_lerpmove
It's too weird when Quake's awesome jerky animation is suddenly all smooth :) Still, nice release. I think the engine limits stuff is the most important this time round. p.s. I still love you, Metl yes, it's different. I looked at the tutorial code found on QER, which i think is where most people get their code, but wrote my own based on what i learned there.
Can you tell me what seems jerky? With r_lerpmodels 1, some specific things aren't interpolated, such as the firing frames of weapons and monsters, and all frames of various torch models. If you want to enable interpolation all the time for everything, try r_lerpmodels 2. that was it. I was used to seeing everything interpolated so when I saw it in lerpmodels 1, I could notice the difference when certain frames were not interpolated (especially when monsters fired).
thanks. This one was long awaited for sure! I will try to run Warpspasm on this! Thanks for your hard work!
metl, did you sneakily add double precision angles into your new protocol? Because I swear I can feel the difference...
Yeah, the new protocol has two-byte angles for client aiming (implied by the "Improved crosshair accuracy" feature) :)
Monsters move prefectly smooth now on my Radeon 9000 Pro and Fitz 85.
Couldn't get it with Fitz 80 (really choppy movement at first, then slowly gets better around the middle of the game). Previously only Aguirre's GL ran pefectly for me. Now I got all those nice to try out, and still, the best looking animated sky ! None right now. I plan to look at aguirre's convdem tool to see if I could add support for this new protocol, otherwise I may write my own.
great job!, yeah, there is a big difference between 080 and 085 as said previously :)
What's the technical solution used for "gl_flashblend 0" effects? Firing rockets with that setting is a real fps killer on my hardcore intel integrated graphics :( (apart from that FQ runs very well)
the app keeps local copies of all lightmaps; when dynamic lights touch a surface, the dynamic light is added to the static light levels and the new data is uploaded to the texture using glTexSubImage2D.
Does fitzquake 0.85 actually run slower than earlier fitzquakes, or any other glquake ports with the same setting? vanilla Glquake also runs fine so I guess it has to be related to some of the changes you've made.
I'm mostly interested in figuring out the limits of the graphics card (GMA4500mhd) to avoid running into problems with projects of my own. It seems the intel drivers are lagging far behind in OpenGL support compared to DirectX and so far the lesson seems to be to stay away from OpenGL if you want to be safe :| well, adding colored light capability in 0.75 probably increased the total amount of upload data somewhat (3 bytes per sample instead of 1) but if you also have the problem in 0.70 i'm not sure what it could be.
Fitzquake 0.80 had graphics problems on my Intel G945 card, but not 0.85. Aguirre's nehquake works fine also.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2025 John Fitzgibbons. All posts are copyright their respective authors. |