[rjc862003]

the stutter is related to it being ioquake 3

there is a lot of small issues with ioquake 1.35 that snowball into a greater problem
1. SDL 1.2 sucks period it has a array of bugs that crop up and cause all manner of havoc
2. Libjpeg6 is slower then libjpeg8 by a factor of 2
3. 1.35 suffers from some threading issues on modern hardware 1.36 doesn't (some timer bug irc)
4. frankyV's suggestions as per usual aren't even close to being anyware near the right mark
5. if you are compiling ioquake 3 with VS DON'T its broken as hell use minGW 4.0 or higher 3.x has some bugs that can make the quake 3 engine ... more buggy .. mainly related to the QVM interpreter
6. if you are compiling with minGW don't use -O3 use -O2 and DO NOT use anything like -march both cause serious issues to crop up in the engine (if you don't know what you are doing and what your target machine is) conversely failure to use -O2 cause some performance issues
7. ioquake 3 1.35 is also slower at loading and running animations
1.35 TL:DR you really need to merge your codebase into the 1.36 tree
THIS^ is what you need to be doing first before you hack up 1.35 anymore get the code merged to 1.36 where you have maintained and known good codebase

[24/7.x3r]

rjc862003, on 29 April 2013 - 06:27 AM, said:

the stutter is related to it being ioquake 3

there is a lot of small issues with ioquake 1.35 that snowball into a greater problem
1. SDL 1.2 sucks period it has a array of bugs that crop up and cause all manner of havoc
2. Libjpeg6 is slower then libjpeg8 by a factor of 2
3. 1.35 suffers from some threading issues on modern hardware 1.36 doesn't (some timer bug irc)
4. frankyV's suggestions as per usual aren't even close to being anyware near the right mark
5. if you are compiling ioquake 3 with VS DON'T its broken as hell use minGW 4.0 or higher 3.x has some bugs that can make the quake 3 engine ... more buggy .. mainly related to the QVM interpreter
6. if you are compiling with minGW don't use -O3 use -O2 and DO NOT use anything like -march both cause serious issues to crop up in the engine (if you don't know what you are doing and what your target machine is) conversely failure to use -O2 cause some performance issues
7. ioquake 3 1.35 is also slower at loading and running animations
1.35 TL:DR you really need to merge your codebase into the 1.36 tree
THIS^ is what you need to be doing first before you hack up 1.35 anymore get the code merged to 1.36 where you have maintained and known good codebase

Maybe you could offer to help FS make this change?

[[Sk&Bh]Txc]

rjc862003, on 29 April 2013 - 06:27 AM, said:

the stutter is related to it being ioquake 3

there is a lot of small issues with ioquake 1.35 that snowball into a greater problem
1. SDL 1.2 sucks period it has a array of bugs that crop up and cause all manner of havoc
2. Libjpeg6 is slower then libjpeg8 by a factor of 2
3. 1.35 suffers from some threading issues on modern hardware 1.36 doesn't (some timer bug irc)
4. frankyV's suggestions as per usual aren't even close to being anyware near the right mark
5. if you are compiling ioquake 3 with VS DON'T its broken as hell use minGW 4.0 or higher 3.x has some bugs that can make the quake 3 engine ... more buggy .. mainly related to the QVM interpreter
6. if you are compiling with minGW don't use -O3 use -O2 and DO NOT use anything like -march both cause serious issues to crop up in the engine (if you don't know what you are doing and what your target machine is) conversely failure to use -O2 cause some performance issues
7. ioquake 3 1.35 is also slower at loading and running animations
1.35 TL:DR you really need to merge your codebase into the 1.36 tree
THIS^ is what you need to be doing first before you hack up 1.35 anymore get the code merged to 1.36 where you have maintained and known good codebase

I have suggestion for you :

Seven of Nine, on 25 March 2013 - 10:56 PM, said:

In a stream I did with BladeKiller she mentioned "contact [at] urbanterror [dot] info" for applying.

don, on 29 April 2013 - 02:13 AM, said:

Thanks for putting words in my mouth; although, in Bulgaria, perhaps it's the norm to assume physical and mental disabilities go hand-in-hand?

One handed swordsman? Pretty sure Jaime got his ass kicked trying to fight one handed ;)

...

To put words which are already there is quite unneeded .
In your last comment you generalised as disabilities .
If you have some problems to understand then you shouldn't respond or just say you don't understand .

Nothing wrong in confessing when lose in discussions , too .
It actually is a positive thing ;) .

In Bulgaria by disabilities means the same as in the rest of the world .
It is usually refered to such as invalids , not people with disabilities .

Don't know who that Jaime is ( I suspect naiveness & sarcasm intended , big fail ) .
It will be hard to test it since the ''one handed swordsman'' is lived centuries ago ...
Also it is not sure if it was real person or fiction . But that is not the point of that simple example , which you obviously missed .

[rjc862003]

x3r, on 29 April 2013 - 08:36 AM, said:

Maybe you could offer to help FS make this change?

https://github.com/u.../UrTDevs-Client
issues
1. ut42 demo support doesn't work
2.\rate \cl_maxpackets \cl_packetdup: have been renamed to \net_rate \net_maxpackets \net_packetdup for crossc compatibility with 4.1.sacc
should be enough of a example to help them port from a Vanilla 1.36 tree

This post has been edited by rjc862003: 29 April 2013 - 10:55 PM

[Diggs]

Txc, on 29 April 2013 - 09:10 PM, said:

Don't know who that Jaime is .....

Hmmm.... "Game of Thrones" must be a Stateside thing.

[GlaD-don]

Txc, on 29 April 2013 - 09:10 PM, said:

If you have some problems to understand then you shouldn't respond or just say you don't understand .

ironic, no?

[FS BladeKiller]

The stutter happened to me when I increased my rate and cl_maxpackets to match my fps. I had to go back to the defaults and restart to get rid of the stutter. Of course, the stutter only happens on line in this case.

[rjc862003]

BladeKiller, on 30 April 2013 - 10:07 PM, said:

The stutter happened to me when I increased my rate and cl_maxpackets to match my fps. I had to go back to the defaults and restart to get rid of the stutter. Of course, the stutter only happens on line in this case.

you are most likely getting the "stutter" because \rate is kicking in and throttling it because you have it locked to god dam low for 125 packets on a populated server AY MINIMUM it needs to be at least 38000(Current max is 32000) (assuming at 10 slot server)
more slots = more rate is needed to prevent it from throttling
the initial function of \rate was to prevent quake 3 from monopolizing a dialup connection to the point of causing it to flood out.

\RATE is a throttle BladeKiller: iv said this a few times it only kicks in _as_needed_.
and at 125FPS/125 packets per frame (assuming cl_packetdup 0)(thats 384 bits per second per frame 3.8KB/s Average >= /rate 32000) if=tld:dr, set the god dam \rate cvar to 125000 and forget about it it doesn't DO ANYTHING unless you are exceeding the "limit" it doesn't use ANYMORE bandwidth regardless of the setting cl_packetdup and cl_maxpackets AND frame-rate are what defines how much bandwidth it uses I am not sure how much clearer I can say it.

further more whats more impotent the the limits is the initial settings
it still defaults to cl_maxpackets 30 and rate 16000 and that's just retarded you are talking about settings that _nobody_ changes unless there instructed to cl_maxpackets 60 and \rate 125000 should be the defaults there is no reasion not to 62 would everyone the best of both meaning so long as you can get more then 30FPS you are golden and should have no negative effects BUT if you get more then 60 you will see a improvement in smoothness

and yes I am going to keep riding you until you fix it its these dead simple oneline fixes that make all the difference in the world when you ignore them they snowball most of the "n00bs" that play 4.1 run with \rate 8000 and \cl_maxpackets 30 and it compounded the hit-detection problem

cause 2:
if you are using -O3 at compile-time then this is probably the cause never use anything higher then -O2 with quake3/urt it does cause HITCHING and stuttering (don't belive me NP ask TTimo)
just in case i wasn't clear enough


\RATE IS NOT A BANDWITH CONTROL ITS A DELAY-LIMITER
cl_maxpackets X cl_packetdup X Frameate X CLIENTS=Bandwidth-Requirements
and you wonder why people rageout on you sheesh

This post has been edited by rjc862003: 01 May 2013 - 06:01 AM

[wraith]

i've had cl_maxpackets 42 and rate 25000 in my autoexec for years lol...

[GlaD-don]

rjc862003, on 29 April 2013 - 10:46 PM, said:

https://github.com/u.../UrTDevs-Client
issues
1. ut42 demo support doesn't work
2.\rate \cl_maxpackets \cl_packetdup: have been renamed to \net_rate \net_maxpackets \net_packetdup for crossc compatibility with 4.1.sacc
should be enough of a example to help them port from a Vanilla 1.36 tree

isn't it hilarious how stupid easy it is to bypass the limits imposed on "locked" cvars?


hoping that the, uh, anticheat can catch attempts to do so for less innocuous cvars.