News | Forum | People | FAQ | Links | Search | Register | Log in
What - Realistically - Do You Want To See In Quake In 2018??
Let's assume that a full HD but true-to-spirit Quake remake, guaranteed 200 maps, AD 3.0, and PC Gamer cover shots fall under "un-realistic", but there might be other exciting ideas and desires that will come true.

So what do you want?? Map-wise, theme-wise, mod-wise, meta-wise?? Let's get the hype started....
First | Previous | Next | Last
Qmaster 
Quark,what good is that for anymore?

I use Quark4.07 for lots of model additions, may be old but gold for me. 
 
QuArK duplicates all vertices belonging to both front-faced and back-faced triangles. 
I See 
Good for view, not for saving

I miss QuakeWebTools. The dragndrop rocked and worked for viewing sprites and models and exporting skins. What happened to that? 
#329 - It's On Github 
Quake Web Tools
You should be able to run it by yourself. 
Quark 
Another remarkable fact, although nowadays not so important, is that models loaded in quark and saved again tend to incline a lot of size.

What I'm trying to say is, when a model has a size by example 800kb one upload to Quark and saving it again reduces it to 200kb, without noticing changes.

I have no idea why this is so, but it saves some space, especialy with large models. 
Madfox 
Models saved in qME 3.0 contains additional higher-accuracy vertex coordinates (which are ignored by the engine, but are useful when modifying the same model again). Re-saving them in another editor will delete that data.

qME 3.1 changed that behavior, storing the higher-res vertex coordinates in its MDO format only.

There may also be other kinds of extra metadata stored in MDL files. 
Ah 
That explains a lot. Never paid attention to it.
I can't see no difference between both. The grid is rather rough I thought, 512x512. 
 
Quake 2 Stuff, mainly now that we will have the tools and ports to it.

A Tenbebrae Reborn with Quakespasm and vkQuake stuff, or vice versa with vkQ. 
Uncapped Frame Rate 
All I really want is to get an engine like quakespasm to have the ability to use a frame rate higher than 72 without the physics messing up 
#336 
Use QuakeSpasm-Spiked then. 
@A_COCONUT 
Type host_maxfps 0 in Quakespasm-Spiked console to decouple the framerate. More info at 3.1 here 
@dumptruck 
Off hand, that is probably is a bad idea.

You'll get a lot of frame rate variation.

And if you get really high fps, you might overheat your graphics card.

Quakespasm, Quakespasm Spiked and FTE love to overheat with no map running ... (not that DarkPlaces doesn't love this also).

Kicking out tons of frames per second rendering the console over and over again.

Also the above engines if I recall, love to kick out 700 frames per second when the application is hidden or in the background.

In contrast, Mark V throttles down when no map is running or not the active application. No point in rendering an idle console 700 times per second or rendering hundreds of frames per second when the app isn't even active.

/My thoughts 
 
Also the above engines if I recall, love to kick out 700 frames per second when the application is hidden or in the background.

Interesting, that reminds me of when i got my latest computer and began to install old games (from around 1990) and the computer began to overheat, as it happened with several others. Curiously it didn´t happen when they weren´t on fulscreen. 
Host_maxfps 
I set mine to 144 to match my monitor. 
 
@A_COCONUT
If you really want to let it rip, set sys_throttle 0 too, otherwise it'll still idle a little (and thus struggle to go above 800fps iirc).

@Baker
cl_idlefps defaults to 30 in FTE - the equivalent of your selling point for your own engine. if you cleared that cvar then you're getting exactly what you asked for.
DP has cl_maxidlefps. Same behaviour. 
 
Spike, I looked at the code it looks like your intentions are right.

That being said, when FTE is not active app for me, it uses 50% cpu. This laptop is dual-core that is that is the most it could use (100% of one core).

Here is FTE in idle (50% cpu): screenshot

Here is Mark V in idle (9% cpu): screenshot

And right now, my video fan is finally spinning down some after FTE had it screaming.

FTE going idle causes my video fan to go crazy.

FTE operates fine when it is the active application. 
#343 
Windows 9x interface will always be the best.

I'm particularly fond of the Windows Me interface, too bad the underlying OS was crippled. 
 
Also the above engines if I recall, love to kick out 700 frames per second when the application is hidden or in the background.

In contrast, Mark V throttles down when no map is running or not the active application. No point in rendering an idle console 700 times per second or rendering hundreds of frames per second when the app isn't even active.


Oh shit, so that's what that is.

A fix for QS/QSS would be great. I have a laptop, and it will cook itself if I'm not really careful. 
 
My original interest in throttling down came from ORL.

Long ago, he ran a server and was kind of insistent it needed a feature from Ben Jardrup's Quake named sv_sleep or host_sleep or something so that the server used very little cpu. I was shocked by the cpu usage reduction.

(Quakeworld has always had this in the server side to make it use low cpu).

In ProQuake, in one release I enabled it by default as it seemed to be fine in single player and pretty ok in multiplayer.

Multiplayer complaints came rolling in hard and heavy and en mass, especially those using very high fps for smooth lightning gun aim.

So I disabled it. Later I made it only apply when no map was running or if the application was in the background.

GLQuake does have a lesser form of this, so does FitzQuake. But it never made its way over to FitzQuake SDL or later to Quakespasm.

[For other fun, in windowed mode in Quakespasm ... minimize the window ----> BOOM! Also the mouse moves when the window doesn't have focus unlike FitzQuake or GLQuake ... and Quakespasm Spiked ... do "Single Player"->"New Game". Watch while nothing happens.

No one seems to report these things to the engine developers ... a bit curious.] 
 
@Baker
cl_yieldcpu 1

@Kinn/FifthElephant/Cocerello
tbh, just use vsync.
with host_maxfps 0 or so, so that you don't confuse any prediction your driver might be doing, and thus get lower latency from it.
with vsync it might report 100% of a cpu core, but your drivers will be using some fancy low-power instruction to wake up as soon as the gpu pokes it instead of depending upon the operating system's (shoddy) timings (same reason I'm too paranoid to default fte's cl_yieldcpu cvar to 1).

any modern game will have some vsync option in its menus, though old opengl programs might leave it to your drivers to force the setting
which might also be useful for any games that don't allow you to use the swap-tear extension (which can help when drivers guess timings badly if nothing else). 
 
Spike --- no difference. Now this is FTE 5020 from April 2018 +/-.

cl_cpuyield 1 -- screenshot 
@spike - Re-review 
If I set cl_idlefps to 30 and cl_yieldcpu, the cpu usage when FTE isn't the active app is quite good.

screenshot

But cl_idlefps defaults 0 according to the screenshot. Which was the source of my pain and frustration. 
#285 
When I think about this feature, most lighting edits are very localized

Most if my lights are surface lights. Very few of them are very localized. Sunlight and then surface lights coming from light fixtures, liquids and some special textures like teleport destination pads. Maybe the editor should compile the portion in the viewport first and then the rest in background. 
@adib 
I've had instances where the surface lights didn't line up with the texture. This has only happened on nonorthogonal constructions. Was wondering if you have encountered this and how often to you play with the -surfacelight_subdivide parm? 
@dumptruck_ds 
I don't know a way to see the generated lights to check for misalignments. I just trust it works. And I never played with surfacelight_subdivide, tbh. I just tweak the light entity. Need to follow one of your tutorials to see those :P 
 
I still want definable fog volumes via brush (func_fog) or something

and decals 
Thanks 
Thanks for the great info guys. I love the smoother feeling of higher frame rates but hate how many plats and trains hurt the player when HOST_MAXFPS is above 72 in most engines.

@dumptruck_ds
Love the mapping tutorials. Keep it up.

@Shamblernaut
I would love to have decals and multiple fogs. It would make maps with multiple distinct atmospheres easier to make. 
@354 
decals can be faked well enough with fence textures in my experience. Multiple fogs = multiple settings for fog depending on where you are in the map? If so, AD has it.

My 2018 dream at the moment is actually making a complete map... 
Thoughts And Rumblings 
We have a lot of this stuff if you are willing to use engines like FTE, DP and to some extent QSS.

For example, decals are very much a thing in those engines.

If these are just posts requesting QuakeSpasm to introduce more and more graphical whizbangery, then it needs to be specified really. 
 
Yeah, that's quite true. Also, isn't the point of QS to be a faithful port that runs the game without any bells and whistles? You can argue that things like decoupling framerate and physics still fits within this mission objective, but I don't think that QS should be adding things like (proper) decals... 
 
isn't the point of QS to be a faithful port that runs the game without any bells and whistles

Yes, well...kinda. I suppose there's a sort of vague, entirely subjective "yeah that still feels quakey" filter for classifying something as "fits the QS philosophy" as opposed to "unnecessary eye-candy shite".

For example, no-one here will say fog or coloured lighting shouldn't be in QuakeSpasm.

Tough call really! 
 
Forgive me if I'm forgetting my 'Quake Engine History 101' lessons, but aren't most of the features that QS has that aren't 'standard quake' inherited from FitzQuake? It wouldn't make much sense to try and remove those, but the argument I feel can be made that treating that as the feature cutoff point is a sensible idea.

At least, having such a point is a good idea if you want to be seen as the 'core' engine that provides the basic expected functionality for modern quake. It could be declared today of course, or for QS 1.0... 
 
It's a really tough one to call and ultimately we should be grateful that QS is curated by people who have sensible opinions on what is "quakey" and what is "not quakey ahhhh my fucking eyes".

I do not agree in having a "not in fitzquake therefore we shouldn't do it", cut-off because there's loads of really good potential future things that would benefit quake and still be quakey.

For example, I would looove at some point to see proper static meshes with lightmaps that integrate with the rest of the world lightmaps (to avoid nasty obj2map abuse).

But it's all down to the QS coders and as I said we're lucky that these chaps tend to be on the same page as us. 
 
no one here will say fog or coloured lighting shouldn't be in QuakeSpasm.

Fog shouldn't be in QuakeSpasm. It's not featured in any of the official versions of Quake (Quake, GLQuake, QW, GLQW, Saturn Quake, Quake 64, and the obscure official ports to dead hardware accelerators). Coloured lighting, however, is present on both Saturn Quake and Quake 64. The Saturn port doesn't use the Quake engine but still is an official port of the game.

That said, community-made maps uses non-Quake features such as fog and skyboxes in too many maps for these features to be ignored. I don't remember a single AD map not using fog. So, they shouldn't be, but they need to be. 
:popcorn: 
 
 
Fitzquake isn't just an engine for playing id maps. It is also for playing custom maps. Those features were added so you can play most custom maps as mappers intended. When mappers added fog, colored light, external textures, entity alpha, extended entity limits to their maps, I wanted to be able to experience those maps correctly. I think fence textures and bsp2 support (which QS added) are in line with this philosophy. They don't make existing maps look wrong, they only allow new maps to look/work the way the mapper wants. 
Power To The Mapper 
Go map! 
This Here 
They don't make existing maps look wrong, they only allow new maps to look/work the way the mapper wants.

This is why I am more interested in QSS than FTE or DP. From a mapper's POV anyway. 
 
Fog is perhaps the single greatest feature ever added to these source ports. No better way to instantly create a beautiful atmosphere.

https://i.imgur.com/cwakFVt.jpg 
 
Oh absolutely.

BTW - it's possible to make FTE look really, really like Quake - more like Quake than QuakeSpasm currently does actually, because you can enable a lovely 8-bit colormap lighting mode, and mdl lighting that's almost identical to WinQuake (the Fitz/QS mdl lighting is still too bright).

But "out of the box" it has a load of silly stuff turned on (as does DP), so I understand why people are instinctively turned off by it. 
@kill 
The destruction of my config.cfg file is what REALLY turns me off about FTE. 
 
@Kinn
depends which preset the user picks when they first run it.

Note that you can force cvars to some specific value in FTE using worldspawn keys, eg: _cvar_r_shadow_realtime_world 0 to cripple any attempt by the user to use rtlights on your map.
Whether it works properly with cvars that need a vid_reload is a different matter, but disabling world lights is fine, and probably needed if your map has lots of lights that use the delay field.

@dumptruck_ds
Destruction?!?
FTE does NOT write a config.cfg - it writes an fte.cfg instead. And it usually writes it to your home dir somewhere too (although you can disable that part with -nohome if you really want). 
 
Note that you can force cvars to some specific value in FTE using worldspawn keys, eg: _cvar_r_shadow_realtime_world 0 to cripple any attempt by the user to use rtlights on your map.

Ooh, that's pretty good to know.... >:} 
@Spike 
Sorry if I am getting confused but I recall my configs and settings being borked the last time I tried FTE and then went back to another engine. I was a while ago. For recent testing I have an isolated FTE install.

So does FTE keep all my video settings and key bindings untouched if I switch between engines? 
Fte Configs 
that's the idea yes - so long as you use the cfg_save command (or quit via the menu and pick 'yes' to save, or set cfg_save_auto 1). 
@spike 
Thanks for that tip, I'll definitely need it for my maps.

I really should spend more time with FTE. It was by far the easiest solution when trying to set up LAN coop on short notice when I was at a friend's house - other engines had socket errors - and I enjoyed my time with it, as brief as it was. 
1 post not shown on this page because it was spam
First | Previous | Next | Last
Post A Reply:
Name:
Title:
Body:
message
question
exclamation
idea
flame
noflame
error
skull
beer
moon
pent
rocket
sheep
pacman
pig
cheese
worldcraft
gauntlet
crate
pitfall
pimp
smile
cool
sad
frown
oi
yay
tongue
evil
wink
neutral
q1
q2
q3
ut
hl
cs
doom
dkt
serious
cube
Website copyright © 2002-2018 John Fitzgibbons. All posts are copyright their respective authors.