Engoo

[r00k]

SIDE NOTE:

make it client specific. if the client has proquake's increased angle stuff then give it bigger datagrams too (as the client *probably* already has increased limits, or is at least presumed to be somewhat maintained - ie: their fault not yours). demos won't be 100% identical, but nq demos don't distinguish between reliables and datagrams in demos anyway.
1024 byte datagrams are a joke for most stuff when combined with NQ's wasteful networking. also, make sure you're not unconditionally sending bsp entities in every packet regardless of whether they're actually visible.

releasing the mouse cursor when going to the console (when windowed) is a feature that I wish all engines supported.

Shouldnt ALL proQuake SERVERS use

Code: Select all

#define   MAX_DATAGRAM      32000         // max length of unreliable message

JPG and Baker left it a 1024....

[mankrip]

Why 32000, and not 32768?

[Spike]

why 32768 and not 65535?.. needs the same number of bits.
I just hope your machine allows fragmented ip packets that large.

the proquake thing is just some 'maintained' hint marker, rather than any formal feature.
clients can easily be made to support larger datagram sizes (client->server datagrams will not change size anyway), but servers can't exceed 1024 unless they ensure that the client is not vanilla, as a vanilla client will disconnect if it receives a 1025+ byte datagram.
but if one (maintained) client gets error messages when vanilla (+qrack+dp+fte+rmqe+directq+etc) doesn't, people will blame the client rather than the server (disconnect rather than truncation), and the client will hopefully eventually be given support for receiving larger datagrams. Evil, i know.
poor proquake clients. :s

[qbism]

MSVC++ 2010 Express project for Engoo. WinQuake_vcxproj_engoo.zip
Quickly put together and unsupported. asm and midi would need to be undefined in source (or rectified).

[leileilol]

Thanks. Does VC2010 Express not have any MASM? Did they take out assembly compiling?


By the way Incase you're wondering how the TQ_RAIN and TQ_SNOW effects appear like in the engine...

(the sound effect of dripping is the scrag spike hit noise played at a random high pitch which works well, and since it's always precached in Quake it's no harm done to compatibility)

[qbism]

VC++ Express kept asm as a file type. I set up 2008 VC++ once but don't remember if separate masm download is needed.

The rain effect is uncanny because the bounce physics is so realistic for the Quake setting.

[ceriux]

those effects look awesome! great stuff! does it have a bad frame impact ?

[mankrip]

Line particles!

I wonder how it would look if they became round after touching the ground, though.

[ceriux]

i personally prefer the square shaped pixels. they match quake very well and imo look better than the pixelated circles.

[leileilol]

I don't. Those don't scale well for high resolutions.


By the way the line particle drawing code has been partially recycled and gutted from FTEQW's abandoned software renderer
just to get that out of the way. BTW for some reason in VC6 Service packs the particles screw up causing every line particle to draw from worldspawn. Also they're feeling a little obsolete since textured particles... I might have to deprecate them. Sorry Spike =(

[Spike]

they're fine when falling, but they do look a bit goofey when bouncing...

[leileilol]

I tried to do something about the line positions between particle movement code. I used to have regular particles and lines on the same particles with the line coming before the particle (instead of after which just looked weird)

They could also use some curving too, like changing to beziers if it's a particle with gravity...

by the way anyone tried playing Quake with the violence level set to brutal and the particles set to classic or glquake? Do that and go fire some supernailguns at heads....

[leileilol]

I've committed a preliminary Q2 ref_soft colored lighting renderer backported from Engoo (the mipblock functions are simply copy and pasted over!). Unfortunately it currently has issues with blues showing up and the orange lighting isn't all too hot, the palette's not as good as Quake apparently. Models aren't coloredly lit as of yet, so the functionality is almost close to SiN's colored lighting mode (though I have no idea how exactly SiN's lighting worked, compared to any of Engoo's modes)

I might try making a "glsuck" mode, since the dark saturated badly gammaed look of Quake2 is something of a false "how it should be played" by the playerbase.

Despite having a Q2 source tree in the repository, i'm going to make this clear: I am NOT making a new Quake2 source port. I'm tracking my changes to Quake2 hopefully for other, much better and actively maintained ports to adapt (such as r1q2)

p.s. I might do the same thing with Hammer of Thyrion - i'd love to backport as many Engoo features to it, although some of it may compromise assembly routines - which I hope would lead to being options instead.

[leileilol]

rev 270

[Spirit]

Wow, that is a great options menu. I love the pixel scaling modes and the gore options.



Wine locked up when I chose "my choice" from the presets. I had to kill it. Water ref*tions did not work but I have not read the readme yet.

(I used sv_standstill to make some nice screenshots in combat, kinda similar to DP's sv_freezenonclients but easier to handle. Thanks!)