Really nice work with the new version dimman!

on another note, will you ever code in so we can use q3maps in ezquake?

oh yeah, love the /find command!

Is there something you miss in latest ezQuake 3 alpha? Or something that doesn't work?

We're basically reaching a point where it's getting time for a "stable" release, however if you have some bugs or features you think must make it to 3.0 then please let us know ASAP.

(Development will continue with 3.1 or whatever we decide to go for of course )

EDIT: Thanks Muff1ns q3bsp support will have to come at a later stage, but not impossible no .

With cl_newhud 0 (ie oldschool/original hud) it doesn't shows the pre selected ammo/gun icon---the sg/ssg ammo keep showing on the screen (when using sg 'script') and not the pre selected gun.
With newhud 1 it's fine.

Is that a bug or am I missing something?

Feature request:
* A more viable map pick/toss scenario for bo3/bo5.
/1on1 <BO#> <predefined mappool> [lock in current players on server]

Example:
/1on1 bo3 tb5
Console: dimman vs. Meag - BO3 on TB5
Console: coin tossing Meag to start tossing
Console: available maps: dm2 - dm4 - dm6 - aero - ztn
/toss dm2 (as Meag)
Console: Meag tosses dm2
Console: available maps: dm4 - dm6 - aero - ztn
Console: dimmans turn to toss
...

Just printed a few ideas how it could look. Open for improvement or better ideas. But the concept as a whole, could it be done?
I think it would simplify official games alot and remove awkward moments like "who picks first?", "what's the map pool" etc. Cheers.

Isn't that more KTX/MVDSV related?

Yes, it should be server side

s_bass and s_treble would be nice. Not sure if that is possible thou...

Suggestion:
Since I play with lego-settings (big quare block textures), I can't see what's on the wall in bigroom. What I've always wanted is a way to override the lego-settings for this texture only, so that I can set a custom image on there (I think that texture is called muh_bad.jpg for big-wall).
Would this be possible? Cheers.

Sorta like this?

Neat idea. I put together a basic ktx /toss command, since this is a lot like /rnd and /captain. I wouldn't recommend it in the main repository in its current state because I only handle two players and a real version should handle two team tossing maps from a pool. Commit and Screenshots

Note that /1on1 and /4on4 already have a multi-argument form. The extra arguments are used to set the match tag, which appears in count down screen and in demos. This is often used for tournament games. For example: "/1on1 Duelmania". So in my quick version I just put everything on "/toss".

Exactly. How do you do this?

It's a bit of a dirty trick. I made a 2560x1536 upscaled version of muh_bad, which I think is about as large as you can make it. Since it is only 8x the original size, it can only survive up to picmip 3 without being reduced below original quality, so I used gl_miptexlevel 2 (which does not affect external textures) to lower the quality of the map even more.

In q3/OSP there was gl_nomip (i think that was the name), a bit mask which would exclude some things from beeing picmiped when using higher picmip values. So you could have erverything picmip except explosions, player models or such. Maybe in ezquake there could be something like this:
gl_nomip = "muh_bad" "other_texturesname" "yet_another_one"
so that those textures would be rendered at normal size . I have no idea if it is possible to do this way in ezquake though.

im confirming, something changed with the sound on the last few nightlys.
I am using very low s_mixahead 0.025. Before connecting to server (whilst being only in console) im getting massive sound crackling.
Back under 1155 FPS connected to a server, all crackling is gone though. That wasn´t happening before, s_mixahead didnt behave different in 3d or 2d and gave me jitterfree sound @ mixahead 0.025

On another note, im having a sexy external firewire interface here and i´d LOVE to be able to use my native ASIO drivers, sadly EZQ limits me to use Windows Audio WDM? Too bad i cant get my sound down to 64 buffers, minimum latency. Can you get ASIO support in ?

Cheers,
onefingerman

We're currently in the works of rewriting the sound code to mix sound in its own thread, meaning that mixahead will go away (no delay there) bringing sound latency down even further than ezquake 2.x compared to todays higher latency. Unfortunately no there's no plans for ASIO driver support on our level since we're focusing on doing as much as possible with SDL2.

Holy fuck the FOV calculation change threw me for a loop

Thanks for your response Dimman,
I am pleased to read your reducing latency. As an audio guy, latency really throws me off.
mixahead is a really creepy thing imho. If you just consider the following theme: An "Average" humans reaction time is about 272ms as per google^^. Lets argue that a trained qw player, knowing map, position and action, will put out a rocket or shaft out of his pocket in less than 150 ms. Having s_mixahead 0.1 = 100ms or s_mixahead 0.025 = 25ms sound delay, does in relation to that make a HUGE difference. I´m not saying 25ms will give you a big advantage, but 75ms is definatly an impact in this setting. It will basically tell the guy using it, HALF of the other non-using dude´s reaction time earlier - his itempickup, jumps & general sounds.

ADDITIONALLY i believe, Ping ofc adds to the latency you get for Audio (means: add 12ms for best possible ping, and 30ms for avarage? for every qw player globally)! Delay some packets to 150ms pingland, and hear how long the sounds THEN take. Dunno, avarage sound response time on a medium pingy server with standart mixahead is unbelievable high considering both NOW.

Audio latency for working with hardware or studio software above 10ms would be considered inacceptable (just throwing that in, im 100% aware that windows audio or SDL won´t deliver this performance - naturally and expected)

So thumbs up, looking forward for reworked audio! <3
Cheers,
OFM

No it's not

I will repeat this again:
In ezQuake 2.x the "real" fov was for 4:3 resolutions, so if you had fov 115 on a 4:3 screen and then switched to a 16:10 widescreen you'd to change fov to 124 to get equivalent view. If you change to say a 21:9 resolution you will need to find a new fov that matches that resolution...

In ezQuake 3.0 you only use the real fov no matter what resolution you have, thus fov 115 for both 4:3 and fov 115 for 16:10. If you want to change to something else in the future you can still use, you guessed it, fov 115.

If you are on widescreen and cant remember what "original" fov you had, there is a command in ezQuake 3.0 to calculate it: /calc_fov XXX where XXX is your current ezQuake2 widescreen fov.

vb-: This is how you calculate it: fov= atan(((tan((oldfov/2)*PI/180))/1.2))*360/PI (basically reverting ezQuake 2.x wideaspect)

Cool. I hadn't tried 3.0 until Povo sent me his gl_minlight binary, read a few short docs, loaded it up, and after adjusting everything else to my taste was bamboozled by the apparent change in aspect ration. I tried a few Googles and couldn't work it out from what I spent an hour reading, possibly from poor choice of query terms

I eventually found a cached forum post where JJ or BD mention that fov 13 1/3 is equivalent to fov 120 at the same resolution as pre-3 . I derived the equation I stated from a sample size of 2; 13 1/3 = 120, and my own FOV from antiquity 118 (106.2). Being that 120 and 118 are so close together (by design of me in 1999 due to noob GLQuake hall of mirros bug experience) it wouldh avebeen prudent to test a more diverse (and numerous) range

Pardon any inaccuracies and thank you for the information. I could have actually read the code but I'm a lazy drunk stoner from Australia and have to fight constant barrages of wallbies & echindas

BTW after setting 106.2 it reports as 106.199997 in console

*cough* Read first post in this thread *cough*

dimman, for me and others ezquake 3 likes to crash on alt-tab. Here's a backtrace from gdb:
#0 0x00000eaf618fe7d6 in SCR_HUD_DrawGroup (hud=Variable "hud" is not available.
) at hud_common.c:2158
2158 if (pic != NULL && pic->height > 0)
(gdb) bt
#0 0x00000eaf618fe7d6 in SCR_HUD_DrawGroup (hud=Variable "hud" is not available.
) at hud_common.c:2158
#1 0x00000eaf618eb957 in HUD_DrawObject (hud=0xeb18bac2700) at hud.c:1452
#2 0x00000eaf618eba38 in HUD_Draw () at hud.c:1495
#3 0x00000eaf618d66af in SCR_DrawElements () at cl_screen.c:3316
#4 0x00000eaf618d73f4 in SCR_UpdateScreen () at cl_screen.c:3451
#5 0x00000eaf618c2977 in CL_Frame (time=Variable "time" is not available.
) at cl_main.c:2546
#6 0x00000eaf61840f18 in Host_Frame (time=0.0043760000000929722) at host.c:464
#7 0x00000eaf61985275 in main (argc=2, argv=0x7f7fffff78c8) at sys_posix.c:347
(gdb)

I guess pic is freed but not set to NULL and points to invalid memory.

Thanks for reporting and backtrace. Who are others and what OS are they running? OpenBSD? Any specific builds? This is the first time i hear about it thats why I ask

I did mate. I had no idea it was FOV to begin with and barked up the wrong tree for a while

It's an older build on amd64 OpenBSD here. I don't know what dhamer runs though.
I'll upgrade to the latest soon and see if I can reproduce it.


version says:
ezQuake 3.0 alpha r4754~71e4a9e
exe: Feb 20 2016 10:32:15
compiled with gcc version: 4.2.1 (1427675686)
GCC Optimization: Optimized for speed
GCC Optimization: Functions currently inlined into their callers

Ok. I'm not sure dahmers problem is the same, I think he's running a test binary I gave him which has a bug in it causing the client to crash when streaming from QTV. I'll need to ask him when he gets around if that's what he means or if its specifically when alt-tabbing in/out immediatly.

I talked to him on qtv and it was my understanding that his crashes were caused ALT-TAB. However there was a lot of noise on qtv so I may have gotten it wrong.

ok, upgraded to the latest, so far I couldn't reproduce the crash anymore. Will report if it happens again.

Status on this?

Please, in general, if you want us to look at something, provide us with as much info as possible on how we can reproduce the issue or theres a big risk that it won't be looked at in any near future. We have to prioritize what to focus on and the single most important thing is if something is reproducable or not.