#706 posted by necros on 2014/03/10 00:00:32
It may be due to the solid and movetype settings:
self.solid = SOLID_TRIGGER;
self.movetype = MOVETYPE_FLY;
I believe I've had problems with interpolation when using SOLID before.
The code uses the stock path_corner functionality that monsters use, but instead of using a movetogoal (that would not work for vertical differences) there's a single think function that does:
dir = self.goalentity.origin - self.origin;
dir = normalize (dir);
dir = dir * self.speed;
setorigin (self, self.origin + dir);
self.angles_x = self.angles_x - 60;
self.avelocity_x = 60;
Note also that the frames are not actually use and that the model is rotated via code so interpolation for rotation shouldn't be a problem.
FYI
This is what I mean.
DirectQ -
https://www.dropbox.com/s/l03v8gop65zp17k/dq.png
Fitz V -
https://www.dropbox.com/s/jvpqijeux9wdeyh/fitzv.png
Fitz is garbled. I think it's trying to stretch the texture somehow so both sides are the same length/width. There are lots of examples of this, pretty much all the door textures, the slipgate textures, a lot textures I used in q-deck.
People tend to revere Fitz but, as good as it is, it's still far from perfect. It's a shame Baker no longer works on it really.
Texture Scaling
#708 posted by Preach on 2014/03/10 00:45:13
That looks like the effect in stock glquake of resizing textures to be power-of-2 dimensions. Which is odd as fitzquake was one of the first engines I can remember addressing this problem, by padding the textures rather than scaling them. Unless I've misremembered and that was only performed on models and not on wall textures - or could it be that when you apply nearest neighbour render mode the fix gets reversed out somehow?
Confirmed Re: Texture
#709 posted by necros on 2014/03/10 01:04:40
it does look effed up, in both FQ085 and QS 0.85.9
#710 posted by Spike on 2014/03/10 03:02:39
needs support for GL_ARB_texture_non_power_of_two.
basically find the rounding code and bypass it if that's supported. no more uglyness.
directq, dp, fte should all support this, no idea about rmqe.
@Preach, the fitzquake padding hack thing only works on non-tiling surfaces, which means 'not on world'.
#711 posted by metlslime on 2014/03/10 03:41:39
fitzquake is using bilinear interpolation to upscale the texture, i think directq uses hardware support for non-power-of-2 textures. That support would be a good thing to add to a fitzquake branch. (See Spike's comment)
Preach:
#712 posted by metlslime on 2014/03/10 08:35:40
yes, there is a distance limit that disables interpolation for one frame to catch teleports. From the code, it looks like 100 unit delta on any one axis will be considered a teleport.
R_wateralpha Problem
#713 posted by ToMaHaKeR on 2014/03/10 13:40:21
There is also a transparency problem in the latest QuakeSpasm. The screenshots below are taken with r_wateralpha 0.5, the map is E1M1. As you can see, the water is transparent only when you get really close to the waterline:
http://postimg.org/gallery/4jagxy5q/
#714 posted by dwere on 2014/03/10 14:36:04
Wow. I didn't know Fitz can't handle NPOT wall textures. This is kinda disappointing.
I've also noticed that it has some minor problems with UV coordinates. This can screw up pixel-precise detailing on model skins a bit.
Re: 713
#715 posted by necros on 2014/03/10 17:50:11
This is not an engine issue, the original id maps do not have transparency visibility calculations, so the engine reads the map file and sees that there is nothing behind the water when you are on the other side of it. You will need to find the patch that either recompiles the maps with transparency, comes with maps already compiled or has .vis files (i think it's .vis?) that has new visibility calculations (fitzquake engines do not support that afaik, so this isn't an option if you want to use this engine, you will need replacement maps).
Re:713
#716 posted by metlslime on 2014/03/10 20:40:24
What necros said, plus: if you want to fix this in a hacky way, set r_novis to 1. This will make your framerate worse on large maps, but will fix the visual issue.
Re:714
#717 posted by metlslime on 2014/03/10 20:42:00
Are these UV problems different when compared to other engines? Does GLQuake do it wrong too?
Metlslime:
#718 posted by ToMaHaKeR on 2014/03/10 21:50:14
r_novis 1 works, but the moving brushes are not visible through the water. They show up only when you enter the water. Secret door in E1M2:
http://s29.postimg.org/agce9rf07/spasm0000.jpg
#719 posted by dwere on 2014/03/10 22:08:23
Looks like GLQuake has the same problem. I made a few shots to illustrate.
WinQuake:
http://i.imgur.com/TqDpxj0.png
Quakespasm:
http://i.imgur.com/NRFNIGg.png
GLQuake (Bengt Jardrup's build, but it was the same in vanilla):
http://i.imgur.com/6A0d4bx.png
DirectQ:
http://i.imgur.com/fbLkr1O.png
Look at the weapon's clip. WinQuake and DirectQ shots represent the way it's supposed to look.
@Necros
#720 posted by Baker on 2014/03/11 02:55:54
Mark V supports .vis files
I Broke QS Again!
#721 posted by ijed on 2014/03/21 01:34:50
With a very odd error;
QUAKE ERROR: SZ_GetSpace: overflow without allow overflow set
Googling around, all I can get is this;
if (!buf->allowoverflow)
Sys_Error ("SZ_GetSpace: overflow without allowoverflow set");
Which is engine code and I think means "map is too big"
Most of the explanatory stuff I could find is either 404 or related to Quake2 config files being over 8k.
The map I'm working on is actually close to finished, I hoped to have the beta ready for tomorrow. Anyone on the QS team able to lend a hand?
It is a very big and complex map, but compiles in about 25 minutes and was last running in the engine this morning :[
The dropbox folder is updated with the broken bsp if anyone who already has the link to that wants to take a look.
I Can Have A Look
#722 posted by ericw on 2014/03/21 02:33:11
mind firing me the dropbox link? email's in my profile.
It seems to be a generic "buffer filled up" error, but it should be obvious from seeing the stack trace exactly what limit is being hit.
We Tracked It Down
#723 posted by ericw on 2014/03/22 18:42:04
There were more edicts than would fit in the signon buffer (in SV_CreateBaseline).
Bumping these constants fixed it:
net.h:
-#define NET_MAXMESSAGE 32000 /* johnfitz -- was 8192 */
+#define NET_MAXMESSAGE 65536 /* johnfitz -- was 8192 */
quakedef.h:
-#define MAX_MSGLEN 32000 // max length of a reliable message //johnfitz -- was 8000
+#define MAX_MSGLEN 65536 // max length of a reliable message //johnfitz -- was 8000
I got the larger values from RMQEngine. Searching for uses of these constants, it looks safe to bump them; i.e. doesn't seem to break the protocol.
Works Fine For Me!
#724 posted by ijed on 2014/03/22 19:29:59
#725 posted by Spike on 2014/03/23 01:39:55
65k? owowowowow!
the actual limit is a bit lower than 65k due to header overhead of 8 bytes, so the protocol limit is actually 9 below that (ignoring limits not imposed by data types).
make sure you don't try sending a datagram that big. datagrams larger than 1448 bytes will always be problematic.
not that you have a choice, but whatever.
#726 posted by ericw on 2014/03/23 02:54:35
ok, thanks for the info. Fyi the numbers for ijed's map are:
2130 edicts
32176 byte signon buffer
#727 posted by necros on 2014/03/23 03:48:30
ijed, is there no way to delay spawning some entities? That's the usual way of solving signon buffer problems. Either with delay spawn monsters or if you've got lots of map models or some such, you could spread out the setmodel() calls after 1 second a bit with random thinks so the engine doesn't have to do everything on the first frame.
#728 posted by ijed on 2014/03/23 12:35:20
Yes, I need to look into that next. The qc is pretty standard and therefore not really optimized for this type of large map. I'll be putting in some random delays to spread the load before release.
Thanks
Committed. But i'm always weary of limits on 2^N. If there is an off by 1 error, they arent always easy to catch. (2^N)-1 is easier for me to take. I'm not much of a C guru, laugh.
65536
#730 posted by szo on 2014/03/25 08:28:56
Lowered those to 64000 (see Spike's post #725.) I am not happy with this limit bump at all, but let's see how it will turn out..
|