News | Forum | People | FAQ | Links | Search | Register | Log in
Quakespasm Engine
This engine needs its own thread.

Feedback: I like the OS X version, but I have to start it from the terminal for it to work and can't just double-click it like a traditional OS X app. I'm sure you guys already know this, either way great engine.

http://quakespasm.sourceforge.net/
First | Previous | Next | Last
@Hipnotic Rogue 
I think QS's vsync implementation is broken, in that it doesn't disable the regular frame throttling code so sometimes you will get stutters. I would recommend avoiding vsync right now.

It sounds like you get hitching with vsync off as well, at 144Hz?

One hack you can try is "sys_throttle 0" - this will make QS use 100% CPU instead of sleeping (the default is 0.02).

If there's stuff we can do to make this better I am interested. I'm hoping to get a 144Hz monitor some time this spring as well. :-) 
@ericw 
I've set sys_throttle to 0 but there's no change that I can discern.

It's not hitching as such at 144 Hz with vsync off. The 'hitched' frame (for want of a better term) tears instead. It's regular as clockwork just as the hitched frame would be with vsync on.

Is there anything else I could try for you or any more info you need just now? 
 
sounds like you want SDL_GL_SetSwapInterval 2 instead of 1, or ideally -2 (to enable swap_tear when timings slip a little).
The interval in question is measured in terms of buffer swaps, so 2 means that it'll run at 72fps on a screen running at 144hz.

Regarding host_maxfps timings - quakespasm uses milliseconds for timing - and rounding down means it needs to wait a little longer before the next frame.
This alternative will give more accurate host_maxfps:
double Sys_DoubleTime (void)
{
return SDL_GetPerformanceCounter() / (long double)SDL_GetPerformanceFrequency();
}
But do note that it might misbehave on certain/old dual core machines that lack drivers to resync cpu timers.
And ideally you'd rebase the counter to 0 to reduce fpu precision problems, but they.

Regarding nvidia, (at least for me) vsync is broken in their opengl drivers when the program (otherwise) runs at about 1000fps. Crossing that boundary (relative to the previous frame) results in a noticeable stutter. Enabling something wasteful like bloom seems to help, thanks to it no longer drawing frames in 0ms...

tl;dr version: timers suck. 
 
host_maxfps has lots of subtle little interactions beyond just wonky physics and killer elevators.

Particle trails have been touched on before; here's another one that many people might not be aware of.

Record a demo of you running around in a map for a minute or so at host_maxfps 72.

Record another demo of you doing the same run-around in the same map at host_maxfps 1000.

Compare the file sizes.

Interesting, isn't it? 
Quakespasm On Steam? 
For free. Why not? 
 
There's probably some legal shenanigans about distributing shareware Quake as part of another piece of software. Do you really want to read 17 pages of people who installed a sourceport without a game to play and are all copypasting the same gfx.wad not found error? 
@spud 
I'm assuming there's a way to ensure Quake is installed before launching. Similar to DLC. I dunno. 
 
Can anyone explain why Quake monster models occasionally turn black? I'd guess it's a lighting bug in the Quake engine but if anyone could give more detail as to why. I remember seeing this especially with the Scrag model. 
#3248 
Quake models get their lighting from the ground directly below them. If they pass over a bit of ground in total darkness, they go black.

Scrags sometimes fly over pits with pitch black bottoms far below them, and they thus turn black. Which is ugly. 
Following From That 
I kinda wish Quake used a 3d "light grid" like Quake 3 does for model lighting. People would probably be more inclined to make mdl props if the lighting was more accurate. 
 
And if there wasnt a 256^3 unit limit on size per frame. 
 
Don't models also only poll light from a fixed distance down? If they're too high up in the air they won't be lit regardless of what's below, iirc. 
I Thought Flying Monsters Used Lightsource Data Same As Viewmodels 
 
 
I'm not sure if you're actually looking for a solution to it, maiden, and maybe this belongs more in Mapping Help, but there is a workaround for dark flying enemies.

At the very bottom of the area in question, use an ordinary texture, and light it adequately, for example with the texture light option in ericw's compile tools. A short distance above that put a brush entity, like a func_illusionary or func_wall, that has the visual you want, like the solid BLACK texture. Enemies will pick up the lighting info from the solid world geometry underneath the fake surface, but players will only see the brush entity. A func_wall will also have the effect of making the surface solid, so if a player dies their head camera won't fall through.

I used this trick in my Xmas Jam map, xmasjam_tens, and although I used a solid gray texture, the principle is the same. I did have to tweak the lights to prevent the lower edge of the world from being brightly lit, but with eric's light options I was able to set the surface light's '_surface_offset' key to a negative value (in my case -2048). The surface got enough light to make entities above it visible, but the lower edge of all my rockwork is no more prominently lit than the rest of it. I almost didn't expect it to work, but it seemed to, so I'm not going to look a gift horse in the mouth. If you want to take a look, my source .map file is included in the Jam release like everyone else's. The light entity I used for the surface light is sitting just atop the starting crate, at 296 248 -112.

There's also sock's ad_sepulcher. There's a cavern area with a bridge, which triggers a mini earthquake when you walk over it. Search for a bunch of entities with the targetname "cavebridge_setup", they're all in that space. Look down at the bottom of the pit and you'll see an approach similar to mine. First is a func_detail_illusionary to provide the visual impression of a bottomless pit, but underneath is just regular world geometry, with ordinary textures. There's a few lights with their 'mangle' key set to make them spot lights, pointing down, so they only illuminate the extreme floor and don't break the illusion of endless blackness.

I'm sure other mappers have examples of this too, it's an old trick, but those two are the only ones I can remember off the top of my head. 
@3252,3253 
 
Winquake traced up to 2048 below the mdl, QS traces 8192 units. The code is in R_LightPoint: https://github.com/id-Software/Quake/blob/master/WinQuake/r_light.c#L248

@Tens
First is a func_detail_illusionary to provide the visual impression of a bottomless pit, but underneath is just regular world geometry, with ordinary textures.
Weird, I don't know why this worked, because the raytrace in R_LightPoint should have hit the func_detail_illusionary and picked that up instead of the lighting below it. Regular func_illusionary is safe though.

Btw, with my tools, you can set _minlight and _minlight_exclude on world brushes with func_group or func_detail - this could be a handy way to make the hidden brushes have the desired light value, without having to bother setting up spotlights pointing down. 
 
Thanks for the feedback mates. I was just curious what causes the ugly-looking effect. Good to know it's not a bug at all.

@ItEndsWithTens
If I ever dab at mapping I'll be sure to employ your workaround... :) 
 
@eric
I'm just going by what's in the 1.70 source files. Though looking at the map again in QS 0.93.0, Scrags flying over the pit do look kind of dark, so maybe it doesn't actually work? Hard to tell, honestly. You'd have to ask sock for more info, maybe there's more to it than meets the (or at least my) eye.

I'll be sure to fiddle with that minlight exclude key, sounds intriguing!

@maiden
Glad I could help! More Quake mappers is always a good thing, you'll certainly be welcome if you decide to join in one day. 
Controller Movement Tweak 
I added a "joy_exponent_move" cvar for controlling the move stick's mapping curve. Previously it was hardcoded as linear.. which translated to feeling twitchy (as Hipnotic Rogue was mentioing in ##3198)

I went with a new default of 3 (matching the "look" stick).. now you have to press the stuck further to get full speed, but it's easier to move slowly. The "look" stick is unchanged.

Wonder if any controller users could give me a second opinion on this in the dev build?
http://quakespasm.ericwa.com/job/quakespasm-sdl2/240/artifact/quakespasm-r1556.zip 
Cool Beans! 
I'll give it a test run after work and get back to you. :) 
As Will I 
 
Huge Improvement! 
I've been messing around and setting the joy_exponent_move CVAR at lots of different values just to see the difference. I reckon you were on the money with setting it at "3" though. :)

Slow and small movements now feel much more manageable.

Good job. :) 
Thumbs Up From Me Too 
 
Awesome Thanks 
 
 
The scrag example is one of the reasons the lightgrid was invented for Quake 3. 
When Will The Quakespasm Page Be Up Again? 
 
 
Does QS support .scale? I wonder if it would be fun to make tarbabies merge when they touch each other, forming a bigger tarbaby with each merging, all the way up to becoming a huge shambler-sized tarbaby. 
Awesome Idea! 
That would be an horrible "the thing"-like experience! 
If Barnak Likes It, It Must Be Wrong 
 
@mankrip 
I'm fairly confident that if you tried to use DarkPlaces .scale on an Ogre...

If you doubled his size, his feet would be in the floor.

Also you know Quake hulls (collision) ...

Maybe for Quake 3 map format .scale would work, but any feature using the Q1 map format shouldn't be called ".scale" but rather ".broken_scale". 
 
Hmm, that would require a protocol change then. Or a modified model, or CSQC.

The protocol method would send the mins&maxs from the QC physics bounding box to the client, so the renderer can offset the position of the model correctly. It's the most general-purpose solution and would make .scale more intuitive to use. 
@mankrip 
scale is supported by the rmqe/999 protocol, as well as fte+dp's protocols of course.
QS supports 999, I don't recall if it supports the scale part but QSS definitely does.

.scale is just as 'broken' on q3bsp as q1bsp.
For it to work properly, you need to bias the mins_z value to compensate. Obviously this will look seriously broken in engines that don't support scaling...
On q1bsp you need to refrain from changing mins_x and mins_y though, which limits the range of sizes you can get away with (otherwise a large monster will walk through walls in one direction, but not its opposite, and values that differ from the hull's size will make it more extreme).
maxs_z can be changed freely, at least. the monster might ignore ceilings but that's not a problem if you just avoid placing upscaled monsters in places with low ceilings. 
 
I don't think .scale is a good idea for reasons outlined by Spike, with which I'm in full agreement.

It's important to remember that the RMQ engine was a tech demo. One of it's purposes was as a semi-experimental test-bed for new ideas, not all of which should be expected to work well. Another of it's purposes was to become obsolete as ideas that did get bedded-in and nailed-down were picked up by other engines. It's a natural consequence of those two purposes that sometimes the implementation might be a bit wonky, or might simplify to a special case, or whatever. The point is: RMQ engine's implementation of .scale might not be a great model to work from. 
Scales 
RMQe's behaviour is fine, and is consistent with DP_ENT_SCALE, so that's a good thing.

But yeah, the hull issues make automatic scaling unworkable, so scale without qc is generally a bad idea.

So imho RMQe's scale is fine, and more robust than hexen2's... 
@mk -- Actually No 
"Hmm, that would require a protocol change then. Or a modified model, or CSQC."

Nope. Neither.

1) Open up, say, QME and double the model size.
2) Change the .qc setting the box -- you might need to add a new monster. This would at least get the Ogre's feet touching the ground appropriately.

3) If you decided to make a monster too big for a Quake hull (Shambler size?) -- you better add some invisible func_walls to box the bastard in too hide the lack of proper collision.

You can do what you want to do today and it would work in any Quake engine including and be done in 30 minutes.

Just don't get forget the asterisks. ** Any proper map using a "too big" model like the QTest dragon (Once Upon Atrocity, for instance) needs to "no clip block him in" to his area and close the door behind the player so he can't be sticking his dragon wings through the walls.

The Kurok engine actually had a special brush type "monster_clip" for special clip brushes that instead of blocking the player would block only the monsters instead --- in the case of Kurok, it was a helicopter shooting missiles and the monster clip kept it in a defined box.

The Quake map "Source of Power" https://www.quakewiki.net/archives/underworld/quakerev030624.html ... had baby Shamblers in GLQuake -- and I can't remember the name but some map had a 2x sized fiend or Rogue gremlin or something like that. It was also a map that ran in WinQuake/GLQuake just fine.

The short version is that ".scale" is and always was ".completely_broken_scale" that sounded cool unless you knew how broke it was.

It doesn't solve any problems and creates false newbie-sauce visions of grandeur -- and you can manually create a double sized or half sized fiend that works in WinQuake/GLQuake.

/Someone should find the guy who came up with the idea for ".scale" and slap him with a wet fish. 
 
You can do what you want to do today and it would work in any Quake engine including and be done in 30 minutes.

My idea was to use .scale in an animated way, and with non-arbitrary sizes. There would be a maximum size, but the tarbaby would also have any size between the minimum and the maximum.

Using multiple models would kill the model interpolation and wouldn't provide non-arbitrary sizes.

The animated shadows in Fightoon were created using animated scaling. The higher in the air the player gets, the larger (and more transparent) the shadow gets. This would be absolutely impossible to create in a regular engine. 
 
And here's another example of animated scaling usage. This effect dynamically resizes the model to the intensity of its entity's lighting.

I just didn't try figuring out uses of .scale for solid objects before. But for purely visual effects, it's a clear improvement. 
 
Using multiple models would kill the model interpolation and wouldn't provide non-arbitrary sizes.

You could author a new animation of "growing" from size N to size N+1, in each model. Play in reverse to shrink. This means he can't do anything else while he grows/shrinks, though. 
 
Also, the vertex compression would still cause the transition from one model to another to be jittery.

Using multiple models would still be a hacky & inefficient method. But the bigger issue is that the physics would likely end up even more hacky.

A proper solution for the physics would probably be to use the Q2 BSP format, which uses raw brushes for collision. But this means that such gameplay ideas aren't suited for Q1 anyway. 
Malice Issues 
why does the minigun skin in malice get messed up in both quakespasm and glquake?

also the probe wont fly about in quakespasm either... 
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-2017 John Fitzgibbons. All posts are copyright their respective authors.