- \inc and \dec commands for increasing and decreasing cvar values.

so it's almost like varMath in defrag, awesome <3

so freaking awesome

"\inc and \dec commands for increasing..."
Awesome.

Just one notice: new dlights are much better in terms of quality and even a bit faster (on modern hardware) than legacy

Counting your feedback - I will change cvar modification function to single prefix \varfunc add|etc and add more functions like mul,div,rand,date,time etc.

this aa cg_shadows 2 and those dlights maaan my kwek is so boootifuuul

screenshot please!

I'll post some after work

here m8

much obliged, looks good.... my gaming pc died just a week ago so i couldnt check it out myself : )

del

https://dl.dropboxusercontent.com/u/69413951/shot0012.jpg
https://dl.dropboxusercontent.com/u/69413951/shot0011.jpg
With r_bloom set to 1 the bloom bleeds to the opposite side of the screen as you can see from these screenshots. I'm using an older version of q3e so I'm not sure if you fixed this but just wanted to let you know.

This was fixed some time ago and doesn't happen in recent builds anymore.

Thanks.

* Added better dynamic lights with \r_dlightMode 2 - now almost every (incl. on-hand weapons) model will be correctly illuminated from multiple sources: http://imgur.com/a/3MDMM
* Added CPMA hacks
* Added sin,cos,rand to \varfunc
* Fixed stereo/anaglyph rendering with new dlights
* Fixed missing models during stereo/anaglyph rendering

Those dynamic lights looks so sexy, can't wait to try this with wolfcam

Its surrounded by USE_PMLIGHT definitions in 1.32e code so backporting sholdn't be a big problem - comparing to line-by-line digging in a very outdated cnq3 sources

del

Working com_maxfps > 125 and dynamic lights out of the box

del

decrease \r_dlightScale

del

I understand you: vq3 uses different blending mode - color modulation - when you can't light black pixels at all, new dlight uses color addition which looks 'stronger'. Atm there is no way to control this - I will add r_dlightIntensity soon

Many fixes
Fix: list all available demos that matching valid protocols (66-71)
Fix: indicate actually opened demo file instead of command line argument
Fix: color blending on some old Intel GMA's
Fix: missing dlights on q3dm4 and maybe other maps too
Fix: dlights on q3wcp17
Fix: portals now correctly works with \r_fastky 1
Chg: raize MAX_POLYS and MAX_POLYVERTS defaults to 8k and 32k respectively
Chg: \r_noportals 1 - disable only portals, 2 - mirrors + portals
Chg: scissor viewport by portal model bounds
Chg: print extension for tab-completed demos
Cgh: rename \r_dlightSpecExp to \r_dlightSpecPower and set default to 8.0
Add: \r_dlightIntensity - decreases dlight intensity but not radius
Add: \r_dlightSpecColor - color base for specular component
<= 0 - use current texture and modulate by abs(r_dlightSpecColor)
> 0 - use constant color with RGB components set to \r_dlightSpecColor
default is -0.25

IMHO, \r_dlightSpecColor < 0 produces best possible dlights I've ever seen

Hi, many great additions past couple of months, thank you. One problem I have run into, since:

26-Sep-2016:
Chg: undefine FORCE_DM68_EXT

all demos will be in dm_71. OK, but now I cannot view these demos from quake3e menu, only dm_68 is showing up, I have tried several client versions between august 2016 up through most recent, Nov. 2nd. So, dm_71 gives us UDP spoofing protection, which sounds good, but compatibility with various mods seems to be a problem, at least in CPMA it is. Maybe a cvar that will let people choose dm_68 or dm_71?

Thank you for report.
I will explain why I disabled FORCE_DM68_EXT: if you connecting to dm_68 servers - all demos will be recorder with usual dm_68 extension. But when you connecting to dm_71 server (ioq3/1.32e) and client negotates that protocol - you may receive (and record) network data that may crash older clients during demo playback - thats why all such demos MUST have dm_71 extension.
Clean solution: update demo UI to list dm_71 extension too (what I will do in edawn soon) .
Dirty but fast solution: change extension of all demos from dm_71 to dm_68 via simple ren *.dm_71 *.dm_68

Extracted the 64bit.exe to a folder and got this

[img]https://s18.postimg.org/oruls2lud/quake3e.png[/img]




I cannot find ANY of the 'pak.

Do you have Q3A in Steam or pak[0..8].pk3 somewhere?

fixed it ty!

New release, noticeable changes:
* Now you can \record during demo playback :P
* now all demos has *.tmp extension at record startup, then renamed to dm_68 or dm_71 depending from recorded data - which provides two major benefits:
- if it doesn't have *.tmp extension - you can be 100% sure that demo is complete and not corrupted because of client crash/etc.
- you will have .dm_68 output most of the time even when playing on .dm_71 servers

Also, starting from this date I will no longer create zip with sources, look in public Quake3e repository

hey there,

i rly tried many ways to fix it (replaced default q3config.cfg with a modified) but everytime im running quake with the 1.32e version and i want to join the !exy servers i get instant DC'ed
console msg:
Need paks: @baseq3/eadm.pk3@baseq3/eadm.pk3
URL:http://ex.us.to/pub/maps/baseq3/eadm.pk3
Server disconnected: disconnected

when im running the 1.32 version the downloads for the missing maps/*.pk3's starts without any problems

hope someone can tell pls how to fix it :x


edit: 1 time it worked with the 1.32e patch no clue why :/

Thank you for report, fixed

request: nopicmip lava/slime/water and teleports

Major changes:
- mod-independent multiview procotol
- server-side multiview demo recording

Minor changes (win32 specific):
- you can move game/console window without any lags from now
- faster dedicated console rendering

Cyrax you've done so many changes and added and removed so many cvars a new person is overwhelmed


Can you link to a full list of commands you removed and cvars you added? I want to try quake3e but I can't keep up with the pace of your changes

If you mean 1.32e engine - nothing was removed, look in \docs folder for additions

Download link broken? :sob:

Added direct link to archive for now

tyvm my good friend ilu

Cyrax,

This is cxe, I am a big deal in the CPMA community. Have a few questions and concerns:

I can't launch 64-bit quake3e but I think u mentioned 32bit is actually more efficiently optimized so it's OK. I get a weird error on that gl thing, colorbits r mode 3 bull. Whatever. Is 32 still better than 64 perfromance wise

Also, I try in cpma-quake3e to take screenshot with JPEG.

All my screenshot turn out black. I n3v3r had this isSue with cnq3 or quake3. How do I take a proper screenshot in game?

These may not be quake3e related questions but just general ones

why ur r_znear default to 2 instead of 4.

Lastly, is quake3e like cnq3 where if I do depthbits texture color stencil 0 it auto does 32/24/8.

Why stencil 0 in console still does 8

Hope to hear from you. I used quake3.exe for 5 years. Recently converted to cnq3 and realized I been playing with lags my whole career. Now I switch to quake3e and get even more smoothness and framers rate...so happy u made for me to cpm

- I need more info about your HW/OS configuration to spot screenshot bug
- 64-bit version is faster on 64 bit systems
- z_near was adjusted to avoid clipping near walls at high fov
- yes, 0 for color/texture/depth will result in 32/32/24, color may be 24 on linux visual
- stencil value may depends from driver-provided pixel formats

Windows 7 64 bit. On an Intel hp mini quad core desk station

Stencilbits is just for shadows though right ?

Why u think 64 won't launch me

Might be some group policy or system setting

Yes, stencil is a part of depth buffer so disabling it may increase depth buffer precision

This may take a lot of time to detect/reproduce so I suggest you to register there and PM or go to IRC and try to catch me on following channels:
#edawn at quakenet
#ioquake3 at freenode

I can run 64 bit now my only issue is that my screenshot turn out black screens wonder why.

How does com affinity mask work cyrax

How do I make sure I benefit from my 4 cores with hyper threading (8)

Also I have cg autoaction 0 and cl autorecorddemo 0 but some servers still record a demo how do I stop that

Cxe the community favorite

By default all new process uses all cores - which may add ~25ms lag when OS decides to migrate process to another core. So with \com_affinityMask you can bind Q3A client to particular core to avoid such lags but it will reduce performance a bit.

cg_autoaction is mod-dependent and mod can force cl_autorecord value by server request so I can't tell anything about that

Nuke this troll???

What's best combination yieldCPU setting

Cze pro community favorite

ignore this shit troll

Is yield cpu 0 give better frame rate than default of 2

Any risks to it

Cxe community favorite cpm

Why don't you try it and find out

\yieldCPU 0 will burn your CPU for a slightly reduced lag, you dont need that in 99.5% cases because you can bind process to one core via \com_affinityMask to avoid that.
Also, hot CPU on mobile systems will reduce thermal packet available for GPU.
So non-zero \com_maxFps + \com_yieldCPU > 0 + \com_affinityMask = cool cpu and stable framerate

Yo you are the best man

Guess I'll keep my 8 core with the yield at 2

Ur the best man

Cxe community big deal cpma fave

Stability update:
- handle client gamestate overflow
- set sv_levelTimeReset default to 0
- restart server every 12 hours when sv_levelTimeReset is 0 (vs 10 days for sv_levelTimeReset=1)
- potential hang in tty_FlushIn()
- much more correct suspend/resume (SIGTSTP/SIGCONT i.e. CTRL+Z and following fg) for unix console
Add: CTRL+L hotkey support for unix console

It is highly recommended to update

Is it possible for a minor uncapping of cg_fov :D? Just that my monitors aren't getting any smaller and 130 looks a lot less like 130 >:[

This is not engine limitation, ask cpma/osp/your mod developers

Cheers

Fix: black screenshots at \r_fastSky 1
+ Rework screenshot code so we can take two screenshots (tga+jpg) per frame, each with different name
+ Avoid situation with multiple screenshots (of the same type) being taken during one frame - which doesn't have any sense
+ Now screenshot code doesn't use render command buffer so it will always success (in case of overflow etc).
Chg: default screenshot naming scheme from shotNNNN to shot-YYYYMMDD-HHmmSS[-NN]

is there a way to make the console resolution smaller, or up the fontsize in the console?

not possible atm

Important linux fix and UrbanTerror-4.3.2 compatibility

Noticeable changes:
- \fs_game defaults to ""
- \sv_timeout works as expected
- big memory usage reduction on server side:
sv_maxclients 8: 14.3MB -> 8MB
sv_maxclients 16: 28.5MB -> 9.5MB
sv_maxclients 32: 57.0MB -> 12.5MB
sv_maxclients 64: 114MB -> 18.3MB
- some CPU usage reduction as well

* Add: backport and use alternative huffman encoder from uberdemotools - means reduced CPU usage on server-side
* Chg: avi segments naming scheme to "filename-NN.avi" instead of corrupting extension by '_' suffix
* Chg: max avi file size to 4GB
* Fix: black video frames with \r_faskSky 1
* Fix: crash on video recording
* Fix: reversed timescale during video recording
* Fix: check for ZIP archive signature before writing any received data
* Fix: several bugs in video recording code
* Add: \r_mapGrayScale
* Chg: alphabetically sort cvars for \writeconfig, will affect \cvarlist too
* Fix: renderer crash on negative \r_fullscreen values
* Misc: add SSE math to QVM, speed optimizations
* Fix: switch back to old mod if downloading new mod on \connect has been failed
* Chg: use q3config_server.cfg as config file for dedicated server binaries and do not write key bindings to that as well
* Chg: increase SHADER_MAX_VERTEXES from 1000 to 1536
* Misc: reduce CPU usage on server side
* Add: unlagged input for win32 mouse
* Add: \in_lagged to simulate old behavior for win32/raw mouse
* Chg: clamp \com_yieldCPU values to [0,1]
* Chg: increase max allowed \r_displayRefresh value to 250
* Fix: crash caused by long filenames inside pk3 files
* Fix: demo filename truncation
* Fix digits input on numpad in numlock mode
* Fix local console history not loaded when client is connected to pure server
* Stop demo recording on first download packet to avoid recording downloaded data
* Skip download blocks parsing during demo playback
* Replace some buggy shaders on mapel4b
* Fix non-working effect colors is OSP mod
* Try to handle some non-fatal errors during shaders loading
* A bit faster shader loading
* Add support for loading .shaderx files - to add or replace any existing shader
* Add "depthFragment" shader stage parameter - to store non-transparent (with alpha >=0.85) fragments into depth buffer, very useful for sprites (cg_simpleitems)
* Do not print each loaded shader name in developer mode
* Change some client defaults:
cl_maxpackets 30 -> 60
snaps 20 -> 40
* Bugfixes and network layer optimizations
* Experimental: add CVAR_NODEFAULT flag - to avoid writing cvar into config file if its value matching reset(default) string
this will reduce config file size and will help with upgrading archive cvars that most users never changing
also it will increase cross-plaftorm config compatibility for cases where some archive cvars may have different default values on different platforms
* Add \in_forceCharset - to use EN/US keyboard layout not depending from current language settings, enabled by default
* Add vsync workaround for linux opensource drivers
* Add negative \r_picmip values support - to apply picmip only on worldspawn textures
* Add \r_fbo - opengl framebuffer support, partially backported from cnq3, disabled by default
- gamma correction in windowed mode
- support for screenshots/video recording with larger resolutions
- allow window minimizing during video recording
* Increase max.count of file handles in win32, needed for defrag mod
* Fix '.' translation on numpad
* Fix last-standing frameloss bug (stuck waves at very big sv.leveltime)
* Fix early print to client console
* Remove \r_measureOverdraw
* MinGW compilation support
* Win32: parse and set vid_xpos and vid_ypos from command line
- for dedicated binary it will set console position
- for client binary it will set main window position
* Win32: correctly restore main window position from vid_xpos and vid_ypos in multi monitor configurations
* Disable DPI scaling on windows 10
* Detect and verbose a weird opengl error under linux

Full changelog is about 9kb long so only significant changes/additions:

* Mulimonitor support for Linux
* Unconditional \callvote command agrument completion for all mods
* Added \cl_mapAutoDownload - automatic map download from \cl_dlURL for non-pure servers and demo playback, disabled by default
* Added \video-pipe command - to record video from demo and use ffmpeg as encoder (vs traditional avi+mjpeg), you need to install ffmpeg package (on linux) or put ffmpeg binary near quake3e executable (on windows)
* Added \screenshotBMP and "\screenshotBMP clipboard" commands
* Added \s_muteWhenUnfocused and \s_muteWhenMinimized cvars
* Added \r_hdr - to use high dynamic range pixel format for framebuffers, improves visual quality
* Changed [automatic] demo naming scheme from demoXXXX to demo-YYYYMMDD-HHmmSS[-NNN]
* Added \r_vbo 1 - GPU-accelerated static map geometry caching, map-dependent, typically adds 5-20% FPS on modern GPUs, but even 200%+ FPS increase was observed as well as zero difference cases
* Implemented \r_renderWidth and \r_renderHeight, see documentation
* Fixed precision in collision detection module (to avoid inconsistency between 32 and 64-bit builds), very important for mods like Defrag
* No more zone allocation errors, no need to tune \com_zoneMegs at all, reduce \com_zoneMegs from 25 to 9 by default

Making Q3 great again! <3

BOSS

Hi Cyrax, could you post downloads via github releases & provide a checksum please? appreciate your work m8!

I'm not very familiar with github, maybe later

Is this mod compatible with wolfcam?

Q3e is an engine, but if you mean supplied pak8a.pk3 - it may if woflcam engine supports q3a modifications

alright I guess not then. I hoped to make my QL demo replay shiny :)

Highlights from another big changelog:

* Much improved netcode, all known bugs/attack vectors were fixed so this is the most secure and reliable Q3 engine you may get for now
* Renderer pefrormance improvements & bugfixes
* Added some experimental features like super-sample antialiasing and `screenMap` shader key to simulate real-time world reflections, for example: https://www.youtube.com/watch?v=2TasVrBvB-8
* Added permanent rcon support - so you can always manage your server
* Added rconPassword2 support - invisible rcon super-password than can be specified only from command-line to manage server, revoke compromized rconPassword and so on.
* Raized filesystem limits - so you may host more than 20.000 pk3 files (vs <1000 before) on your system and it all will start in a few milliseconds
* Improved OSP compatibility (demo UI now works + fixed server-side exploit)
* Improved Defrag compatibility (demo UI under linux, etc.)
* Many other fixes and improvements

If we could only go to this and use it as a foundation for a our community.

unlikely, people play shitty games because they (think) they can make money doing so

they play whatever the companies tell them to play

Awesome work, as always:)

However, in the days of 240 hz monitors the renderer running 125 fps at the same rate as the "physics part of the game" for optimal physics (OSP/baseq3) is becoming an annoyance. Going from 250 fps QL to Q3 doesn't feel too good.

I understand that this maybe hard to do but it would really make q3 keep up with time more then anything else.

Anything "physics"-related is a subject of a particular mod, not engine.

Q3e has no client-side FPS limit, even with some mods like CPMA-1.48 -- I even talked to some player to remove similar limits in OSP but heard something like "keep it untouched"

yep. Thats why that part and the actual renderer should be separated and run in their own threads which will be the hard part:)

It is not possible because mod issues render commands and calculates physics in the same frame, you can't decouple that without mod sources

Ok, thx. We're doomed in that regard then:)

Time to update, most noticeable changes:

* Vulkan renderer, you may expect 30%..200% fps increase depending from map
* novlcollapse shader key support - to bypass \r_vertexLight 1 setting
* SDL2 support, configurable at compile-time
* Client country detection on server side
* Many other bugfixes and improvements

Hi, 1v4n94 here. THANKS FOR THE UPDATE! I've encountered strange behaviors since last update:

* Regeneration powerup caused my player to make the hurt sound when adding health points (I can't remember if it played simultaneously with the regen sound).
* I spawned next to Sarge in Q3TOURNEY1. I remember this didn't happen with regular Quake 3. If there was only 2 players on a map, then they would never be respawned next to each other. This can clearly be seen against Crash in Q3DM0.
* When a player is killed under water, the drown sounds start playing (I don't know if this is a new feature or just a bug).
* When some players were killed, their models got on their feet, and had no collision (this one scared me a little bit; I saw Slash get killed by another bot, and when I tried stepping over her body, her model was standing there when she was killed).

Overall, a weird experience, for sure. By the way, I'm using the Steam version of the game.

That is related to cgame/game modules,hard to tell anything without knowing what mod files you're actually loading from steam

Q3A OSP uses ~30% of my CPU (two of six cores at close to 100%); I've just tested Q3E, all versions (x32, x64, Vulkan) idle at around 3, 4% for the same (125) FPS. So yeah, you got some good optimization going on there ;)

Edit: also, you fixed an issue where Q3A would not react to gamma settings (game would remain very dark) when a second monitor is connected to my gfx card.

Also, Q3A would stop demo playback when I changed Windows volume via the shortcuts on my keyboard. That also doesn't happen anymore with Q3E.

Where is the source code?

First link in google for Quake3e -> https://github.com/ec-/Quake3e

I dont quite get the current state of things. Is edawn Quake3e? It was renamed? where is the official link so I don't download anymalwares? also could you add checksums to guarantee its your build?

I assume this is it:

https://github.com/ec-/Quake3e/releases

However, im not sure what im getting there:

http://www.edawn-mod.org/download.php?style=classic

What is the difference between Quake3e and edawn?

Also, which mouse settings should I use to translate my QL settings into perfect 1:1 settings for Q3? my QL settings are the ones that ignore the position of the mouse speed settings in Window. According to my latest mouse settings in QL's cfg im using:

seta in_mouse "2"
seta in_mouseMode "win32(Raw)"

I put the same on the q3 cfg?

Finally: Can you make the aspect ratio show up properly? It looks stretched, im using custom widht and height values to achieve 1920x1080, looks stretched compared to QL.

Edawn is a game modification, like CPMA, Defrag and others.

Quake3e is an engine you may use to run these modifications.

To fix wide-aspect issues you need that fix in a game modification, not engine, I'm already shipping q3e with small pak8a to fix this issue, but it will work only witn localhost or non-pure baseq3 servers, and you have no luck with other modifications.

There is no need for a checksums on github releases because:
1) you can always compile from sources
2) attacker (if that happens) can edit checksums too

Well, I can come and ask you personally if the checksum matches the one being hosted on the site.

$ cyrax-sum -a blah123 edawn.exe
1337133713371337133713371337

Is it this q3 client or the other I can't remember the name that was compromised with malware? Never mind it was ioquake3 : https://ioquake3.org/news/

What, what malware did this have? it is open source

What i've read in a quick search is related to autodownload.

From last update:
* Client: automatically rescale console chars height for resolutions greater than FullHD
* Added support for Raspberry Pi 4, Vulkan renderer seems to work fine with its beta driver
* Added very fast bytecode compilers for 32/64-bit ARM processors, slight improvements for x86
* Allow changing extension for \video-pipe output files
* Fixed "ResampleTexture: max width" error in renderers
* Fixed crash in linux client caused by unitialized cvars, added backtrace output for debug builds
* Win32: try to catch exceptions instead of silent crashing
* Win32: made unhandled exceptions non-fatal
* Sound: backported some fixes from ioq3, improved skip protection and reduced latency
* Client: made console hide/display speed do not depend from \timescale
* Client: updated built-in jpeg library version from 8c to 9d
* Client: allow setting window title via command-line cl_title cvar
* Renderers: avoid using detail textures for lighting stage
* Renderers: fixed shader parsing regression introduced by optional 'firstPerson' key
* Renderers: reverted color correction for external lightmap atlases
* Vulkan: list all available GPUs at startup
* Vulkan: added option to automatically select discrete/integrated GPUs via \r_device values -1 and -2
* Vulkan: changed \r_device default to -1 (auto-select first discrete GPU)
* Vulkan: fixed potential crash caused by incorrect index offset bond
* Vulkan: implemented super-sample anti-aliasing, can be enabled via \r_ext_supersample 1, requires \r_fbo 1
* Vulkan: added \r_presentBits to support HDR monitors, added \r_dither to control dithering in such cases
* Vulkan: added more multitexturing optimizations
* OpenGL: fixed incorrect image capture with supersampling and renderscale enabled
* OpenGL: fixed texture generation for environment-mapped shaders in VBO
* OpenGL: disable bloom if multitexturing was disabled via \r_ext_multitexture 0
* Renderers: dereference $vid_width and $vid_height to actual rendering width/height inside extended shaders
* Win32: fixed crash on nvidia systems when using Vulkan renderer and Win+D hotkey
* Win32: fixed accidental focus losses when using high-dpi mice
* Win32: fixed non-working \in_minimize in windowed mode
* Win32: catch rare DescribePixelFormat() crash
* Fixed error raised by messagemode 3/4 called without running cgvm
* Fixed another crash in FixRenderCommandList()
* Fixed potential crash with fog table
* Allow \reconnect to work after client restart
* Added warnings in developer mode to know why and when a sound isn't played
* Added \r_dlightSaturation
* Unlocked \r_lodCurveError
* Check integrity of loaded maps and models
* SDL2+Wayland compatibility fixes
* QVM: more correct hanling of NaNs in bytecode compilers
* QVM: fixed non-working RocketArena3 server code
* Cvars: avoid misleading warnings when changing ROM variables
* Cvars: allow override "protocol" from command-line
* Sound: reduced lag during video capture
* SDL2: (somewhat) fixed non-working console key for non-US keyboard layouts
* Vulkan: fixed some broken debug features
* Vulkan: fixed resource leaks and incorrect layout transitions during image capture
* Vulkan: avoid redundant scissor updates
* Vulkan: use correct texture bundle for lighting, use static uniform location to avoid pushing garbage from stack variables
* Vulkan: fixed crash with \r_showtris 1 and \r_fastsky 1, fixed environment shader selection
* OpenGL: fixed crash with \snd_restart
* Do not light up shaders whose sort comes after insertion point (SS_FOG)
* Unified gamma correction between OpenGL and Vulkan renderers

I appreciate that you work on maintaining and improving this, however don't you feel Q3 lacks a good anti cheat?

Would it be possible to develop an anticheat? I gets on my nerves playing Q3 because I know any idiot can download a dll and have WH and autoaim. It sucks that technically with quake3e Q3 is technically superior to QL but we lack an anti cheat so I end up going back to QL for some duels.

You may develop it and keep it private/secret or it will quickly become obsolete once published by GLP 2 terms requirements - for me that means "not worth an effort", so play on well-supported servers with active admins

You mean the anti cheat part?

I dont see why a mod has to be open source. In an ideal world we would have a github of an standard OSP type mod that gets updated forever.

What an odd thing to say in 2021. Almost no one plays Quake 3 these days. And the very few that do are unlikely to play strangers because, well, how do you even find people to play with?

On the other hand, is there a modern anti-cheat system that does not rely on having completely unrestricted access to one's PC? Man, the Windows world is crazy.

There's always people in the russian OSP servers.

hows the FPS on the Raspberry Pi 4?

Near 80 fps with latest Vulkan drivers

quake3chad vs the incelquake3