Engoo

[leileilol]

I didn't make this to put other engines out of commission. It already killed the GoldQuake project (which was sajt's early attempt at bringing darkplaces features to WinQuake). I don't want it killing anything else. Keep developing and stop worrying about this whole "relevant" thing; and besides, the majority of quake players will just be misled by forum posts everywhere to use Ezquake or Dakrplaces+"Epsilon Ultimate patch" as "the only way to play quake", so they won't be bothered to try any of our engines.

It does need two more things to complete the modern use. a Direct3D or OpenGL output mode for SteamOverlay, and streaming music playback. CD audio was sadly regressed and I couldn't debug it under Windows 7. It does support MIDI playback however, but lol good luck transcribing quake ambience to midi. (The mission packs are less of a problem however, because there's some semblance of actual song in there)

At one point I wanted to make two surfacecaches - one for texture, one for lighting, and blend it in a spans so I could dither between light levels, and maybe bring realtime light in. Similarly I also wanted to try deferred lighting (with a THIRD buffer) but my issues with the water reflection buffer getting lagged made me change my mind about it.

[sock]

I went to the Engoo site and downloaded the win binaries. I tried to look at my ITS stuff with the engine but I can't increase the maximum amount of entities. I looked for the max_edict command but it is not supported. I really like the screenshots of what you are doing but I cannot run the engine. Is there a way to increase the entity limit?

[qbism]

The irony moving forward is that '8-bit color software rendering' only exists as a simulation in the plastic virtual world it is raging against.

[leileilol]

That 2010 build is very old. It doesn't even run Marcher. I did attempt to debug the engine months ago into running ITS but got lost in the crashes and just gave up since it seemed to involve the entity system and some high limit not covered by the once-existing QSB standard vOv

[leileilol]

Some build of revision 255

mainly some embarrassing things fixed since that stupid 252 release I had on here and pulled (weapon in chase view, normal lighting bugged, fog message spam)

Also MIDI playback's enabled. sound/cdtracks/track###.mid etc. Warning, i've had a midi crash on map load before though... dunno why

Mods untested.



Also does anyone have an extreme resolution monitor setup and confirm if Engoo works on some ludicrously high resolution settings? (i.e. 3k+ width minimum)



It should adapt to Hor+ properly

[sock]

Wow I love what you have done with the torches! They look amazing with the fog. I tested it with my MOD and got some problems.
* Alpha flag does not work on models
* When I shot monsters I did not get any blood particles
* I cannot set a windowed resolution higher than 800x600 on the menu
* It is difficult to lose window focus and switch to another applications
* The console sometimes fills up with 'packet overflow' and I am not sure why
* The fog seems to be very flat like it lacks colour depth. It seems to band very quickly, I thought it would be more subtle.
* Is there a list of what the new console commands do?

Awesome stuff, looking forward to the next release.

[leileilol]

* QC alpha is half-implemented- The model and sprite alpha drawing code is actually in there though (along with even the colormap+additive trick), it's the protocol that didn't get expanded to support it properly, because when I tried I just kept running into illegible message errors since the network code is so scary, even if it's locally run. So it's temporarily disabled. Sorry. Also there are no brush alphas yet.
* Did you disable blood? r_particleblood -1 actually does disable blood and hide gibs (a very hackeneyed censoring feature). Also, the "Glquake" and "2001" particles require that sprite file to be installed (it'll run without it but it'll disable these effects that use it)
* The video modes menu is broken, forgot to mention that. vid_describemodes and resizing the window itself should work. The video modes menu really needs a rewrite to accomodate the variable resolutions. There's even a bug where it'll just be 1x1.
* Right now, to unlock the mouse cursor you'll need to pause the game. I've yet to do it for the main menu or entering the console (LH suggested it to me once in 2010 that I kinda forgot, thanks for reminding me to do this)
* MAX_DATAGRAM isn't increased in this release much so the standard Quake packet overflow thing still applies. because if I increase that, even for single player, i'll be "evile" because it'll break network play - which is still completely untested. Might as well increase it to 4096 or 8192 for build 256.
* Well, it is a fast attempt at fog - it'll be subtle if you use low values like 0.01 and use a higher screen resolution. I tried to match DirectQ's fog exponent. Maybe I did something wrong? I know this sounds like an excuse, but I did used to have precise Laser Arena-style fog and it ran way too slow and I couldn't get it working with viewsize and virtual resolution.
* The readme has a partial list, and I was going to update the site. Most arent' even console commands. Some experimental things I tried to keep in the engoo_ cmd list

Thanks for the feedback!

[sock]

Did you disable blood? r_particleblood -1

No I just used the default settings, but I am generating 1000+ entities when starting my MOD and I kept getting packet overflow errors. Once I have a more stable version of my MOD I will send you a copy so you can see for yourself.

[Spike]

* MAX_DATAGRAM isn't increased in this release much so the standard Quake packet overflow thing still applies. because if I increase that, even for single player, i'll be "evile" because it'll break network play - which is still completely untested. Might as well increase it to 4096 or 8192 for build 256.

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.

[mankrip]

Some build of revision 255

I've just tested it.

Seems like you disabled the drag-border-to-resize feature.

Mouse support is broken in dual monitor setups. My primary monitor is on the right, my secondary monitor is on the left, and the view just keeps spinning very fast. Happens both in windowed (when manually enabling mouse input) and in fullscreen. ([edit] this is also happening in other engines)

I've tried setting vid_config_x to 3200 so I could test the support for extreme resolutions, but it didn't work. It would be tricky to work anyway, since the window would have had to be spread across both monitors, and the vanilla vid_win.c code simply doesn't support that.

For some reason vid_describemodes lists two custom windowed resolutions (modes 5 and 6). Both worked, but I didn't see any difference.

The speed seems really great, but as I couldn't use the mouse I didn't test it much.

[Spike]

Mouse support is broken in dual monitor setups. My primary monitor is on the right, my secondary monitor is on the left, and the view just keeps spinning very fast. Happens both in windowed (when manually enabling mouse input) and in fullscreen. ([edit] this is also happening in other engines)

probably an unsigned int - the top left of the primary screen is at '0 0', stuff to the left+top of that ends up at negative positions, hence the weirdness when it tries to position the mouse at the center of a negative (and thus really big) window position.

[mankrip]

I thought of trying to get the mouse to work properly by disabling Synergy+ and the secondary monitor in Windows, but since Makaqu also have this problem, and other games such as Doom³ and Rage doesn't have it, I'm going to leave it as is until I get around to fix it in the engine.

[qbism]

Some build of revision 255

I built this in 2010 Express. Sorry. Runs about the same. The model shading and water refraction are awesome. Refraction performance seems faster than 252. I did not open code to see how/where, but can viewmodel drawing be moved further downline to avoid interaction with refraction 'shader'?

I could not get any of the fullscreen modes to activate, setting them just resized the window.

[leileilol]

I built this in 2010 Express.

My source is buildable? Cool. I thought I forgot a few files. It wasn't until this week that the engine was built by someone else so I didn't even know if I had a complete working source tree up on the svn. No one has told me if the tree worked until now..... which makes me kinda sad actually...

I do know that GCC hates it and the assembly, therefore i'm not even going to try to risk my sanity to get it going through MinGW. Reckless is good at that persistent GCC debuggering i hear though, hope he gets better

Refraction performance seems faster than 252.

Probably VC2010 optimization with buffer reads for that one. There are no performance enhancements for refraction since 252. The only performance enhancement has been the new "low colored lighting" option which does it through smaller lookup tables.

[qbism]

Well, I didn't try using the asm, left id386 undefined. The only other thing left out is midi. Otherwise it was a straightforward project import.

mingw does fine with the asm, but setup is weird, like naming all assembly source from ".s" to ".S" as passed to the compiler. Must be capitalized... but do not actually have to capitalize the file name! Also set compiler variable to CPP for assembly.