|
Posted by Baker on 2010/08/20 23:27:49 |
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/ |
|
|
Any Chance Of A Translation?
Not everyone on func_ is a programmer/wizard/jesus... what's all the excitement about?
#2411 posted by Baker on 2016/09/14 02:51:54
There's a readme in the download. Kinn has rummaged through it.
I didn't reveal hardly any of huge surprises.
#2412 posted by Spike on 2016/09/14 03:58:08
@FifthElephant, sorry, I suck at explaining, so I left it kinda raw.
basically, there's:
1) a load of boring uninteresting stuff that mods might use. eg, you can imperfectly run smc (check the readme for the issues I know of). smc itself isn't the aim, but the lack of any extensions in fitzquake-derivatives is why we can't have nice things like string concatenation or traceboxes in the mods that really should be using them instead of crappy hacks.
2) some networking fixes/tweaks that if nothing else should make coop significantly easier to get going, just open a udp port, set your server as public, and people should be able to find you.
3) particle system that can be used by mappers to emit custom particles from surfaces based upon their texture names, like rain, snow, sparks, etc. I should give a proper example of this.
You can also use particle configs made for either fte or dp, just so long as they didn't use jpg or png textures, but that wasn't the real aim here, mostly for rain/snow/sparks/emittance/smoke vents/etc.
4) some other stuff. ramble ramble. modders blah blah. *continues to make uninteresting noises*
there's not really meant to be anything fundamentally new here (if there was then I'd have added it to FTE first, thereby making it not new). Really its just a version of quakespasm that tries to NOT be crippleware for modders, as well as fixing some networking/connectivity issues.
it still has no csqc nor replacement texture support. :P
The thought of people doing non-quakey things with the particle system is a worry, but hopefully the community and that continued lack of replacement textures will keep those people grounded somewhat.
@baker,
#2) alpha testing with a reference value of 0.666 will probably kill skirts well enough, but with linear sampling you get weird curved shapes to it. when blending, premultiplied alpha is much better, especially with mipmapping. I was trying to tread lightly and I'm lazy so I just left it as a comment rather than making any actual changes there.
#3) few things use allowoverflow, and thus few things can actually have the overflowed flag set. really its just unreliables, and those only check the overflowed flag when there is actual data inside them. that change just makes things a bit cleaner in that case.
#4) really I just reduced the mtu size of reliables back down to 1450, from 32000. nq always fragmented reliables, but it used the same value for reliables and unreliables. unreliables are still unfragmented and I didn't change any limits there, so there's nothing 'new' here. reliables now fragment much more frequently, this will have increased latency and made (non-local) load times worse, but should keep packet sizes below ethernet thresholds, preventing 100% packet loss and the inability to connect properly.
the protocol itself is identical, the receiver is in no way harmed by this change, but its still above 1024 and thus will still be an issue for vanilla clients.
#5) I have a countof macro in fte.
#6) I stopped copying the extra mips (because only fte would dare trying to use those in a gl renderer), but it still copies+preserves mip0 because of paranoia (I couldn't be arsed to read through the entirety of gl_texmgr.c to make sure it was safe).
And yes, I can be quite harsh with my wording even when I don't follow it myself, sometimes its just easier to not bother fixing it - I'd say it was nice to know what you could be fixing, but frankly its more a reminder of how many things you cba to fix... Lets just say that the comment was for a rainy day.
#7) well... I'm glad someone got something out of it at least.
Awesome Stuff Spike
#2413 posted by sock on 2016/09/14 04:05:01
some stuff that I think people like Sock would want to use if they could
Wow this is just awesome, QS + DP/FTE particle effects! Spike you are coding genius! Really nice to see all my DP particles flying around! :D
So I manually load the effectinfo.txt file (with the QC you specify in the readme file) and AD starts to use the new effects. For some reason I am getting 'backup Past 0' constantly spammed to the console when I load a map. I tried out ad_test10 and I get the following visual issues. Not sure how to fix this, any clues?
@sock
#2414 posted by Spike on 2016/09/14 04:33:58
backup past 0 is a traceline/tracebox thing (I think I included a note about how the vanilla code was stupid, but didn't dare fixing it due to probable precission differences and resulting minor incompatibilities).
the particle system does quite a lot of traces against the world and brush entities, so I guess I ought to try to rewrite that, even it it ends up behind a cvar.
or maybe I should just make a specific version for the particle system, where precision doesn't matter so much.
the diagonal Os look like a REALLY big copy of the particle font... I have no idea what's going on there.
the lines in the middle are something else, and the bit on the left is utterly bizzare, I've no idea what they're from either.
Hurrah for making sure I retested everything!... or not!...
only things I can think of is a NAN (possibly from uninitialised memory, a degenerate triangle, or even qc (read: division by 0). note that this could also explain the 'backup past 0' spam).
also I suspect I broke weather effects by trying to get decals working, it might be related. shows how much I test things...
I'll be sure to test ad_test10 to see if I can reproduce it.
try setting r_particle_tracelimit to 0, that should stop it from spamming traces (which will also disable blood decals).
Sock, just so you know, I also snuck in a 'cl_recordingdemo' cvar which will contain the filename, use cvar_string to read it or something. :)
#2415 posted by Spike on 2016/09/14 05:02:22
the glitches appear to be from decals.
it doesn't seem to happen in debug builds, so its probably something that I left uninitialised somehow.
I don't get the 'backup past 0' spam.
Spike
#2416 posted by ericw on 2016/09/14 05:12:29
cheers, this looks crazy!
Speaking of coop, I tried to run ad_swampy.bsp in coop last week, with QS svn.
The unreliable message limit of DATAGRAM_MTU = 1400 for nonlocal clients ( here) was making it unplayable, was getting lots of "Packet overflow!" and most entities were not visible. Everything seemed OK once I uncapped that to MAX_DATAGRAM (32000).
Does it sound reasonable to remove that 1400 cap for nonlocal unreliables, maybe only use it if a cvar/cmdline flag is set?
I understand that large UDP packets are frowned upon and more likely to be delayed or dropped.. but not handling large maps/mods at all is worse. (I assume there is no way to break up the SV_SendClientDatagram message into multiple udp packets without changing the protocol?)
#2417 posted by ericw on 2016/09/14 05:13:22
re: "backup past 0" spam, it only happens with "developer 1"
@ericw
#2418 posted by Spike on 2016/09/14 06:09:17
reliables larger than the mtu = server keeps trying to resend, blocking delivery of all later reliables. this especially includes the serverinfo, making it fatal even on tiny maps.
datagrams larger than the mtu = game packet gets dropped. when whatever activity goes away (ie: gibs fade out, the other players stop spamming shotgun effects, etc) then the game recovers.
nack networking (namely, fte's replacement-deltas protocol extension) was one of the things that I was considering adding, and would fix the huge unreliables issue, by splitting up huge updates into multiple frames.
the client parts border somewhat on trivial (at least if you're familiar with 666 etc), but the server side can get messy with logs and flags and resends and figuring out what consitutes a nack.
in contrast ack protocols like qw just spam everything every packet until acked, and are actually quite expensive on ram on the server.
remember that there are two protocols here.
if you're unwilling to change the nq protocol, you might be more willing to change the 'netchan' (ie: net_dgrm.c) to split+reassemble.
there's a limit to fragmentation though. bursting more than 4 fragments will generally result in the extra ones getting fragmented, so if you were to fragment that way, I'd suggest to have each unreliable fragment be complete in itself, so that they can still be reassembled even if there are gaps.
large unreliables will break the vanilla client anyway. so yeah, its important to know what you're trying to talk to.
I guess I ought to try to do the nack deltas thing, huh.
and yeah, I forgot about developer 1. :/
#2419 posted by Baker on 2016/09/14 06:55:03
Just give it FTE's QW protocol support with map/model download so people can actually coop, throw in minimum CSQC so Sock's particles live on the client.
Why add another bandage to NQ's primitive protocol -- when you have insane skill levels which are fairly incomprehensible to even most of the rest of the engine coders?
(I mean, you spent how much time on this? A week? And there is other stuff in there too like IPv6 support no one has said anything about ... )
Then get a book deal.
"John Carmack Started Quake; Spike Finished It!"
/This update has a rather eye-popping feature set already. When I opened your download and looked I was like "WHAT?!?!?"
Feature Request: Flood Fill Exception
#2420 posted by Preach on 2016/09/14 08:33:51
I've got a small request relating to model rendering. Quakespasm has the same code from Fitzquake which flood-fills the "background" of a skin with black. This is to remove the bright blue background of some vanilla model skins, which can show on seams.
The flood filling locates the background by assuming it starts at coordinate (0,0). Imagine one of the simplest models possible, 2 triangles forming a rectangle, with a rectangular skinmap that fills the entire skin, and the entire skin flood-filled with white. This model's skin gets turned entirely black by the feature, because the skin is no-background, all-foreground.
There are workarounds, like making sure that the pixel at (0,0) is differently coloured to her neighbours. However, this still compromises the model somewhat, because that pixel is still visible on the model, and must be black in colour in these engines.
My proposed fix is modest: if a model has a UV coordinate of (0,0) for any vertex, then don't apply the flood fill code. None of the original models the code is trying to fix have this coordinate, so it still does its job there. Any model which has a UV there clearly doesn't want flood filling to occur, because the point you want to start filling from is part of the skin, not the background. It even allows for an "opt-out" hack where an isolated vertex is added to models at that coordinate to disable the flood-fill even if the model doesn't use that pixel.
Take 2.
#2421 posted by Spike on 2016/09/14 11:26:19
http://triptohell.info/moodles/junk/quakespasm-spike-r2.zip
decals seem fixed (sorry for not spotting it earlier). I've also replaced the particle traceline code with my optimised version to mute spam.
I added an example 'weather' particle config too, for people to experiment with.
@preach, doesn't sound too unreasonable, frankly that flood-fill stuff is just annoying. personally I'd probably just fill it only if it was that specific colour...
@baker, ipv6 is easy really, mostly just a copy+paste with the address families switched over, some different structs+field names, and a slightly different 'broadcast' mechanism where its the receiver that decides if its willing to receive broadcasts rather than the sender. simple stuff really. Besides, I'm not all that great a coder, I just know quake well.
regarding protocols, if you want FTE's full protocols, just use FTE. FTE's 'PEXT2_REPLACEMENTDELTAS' extension (catchy name that) should prevent the need for huge unreliables as well as providing a whole load of extra entity state that probably noone cares about. The client parts shouldn't be too bad, but the server parts would spawn lots of bugs, so if did port that stuff over, it would be as a separate patch.
That combined with voip.
I wouldn't know where to stop with 'minimal' csqc...
if you want qw protocols in an nq engine done the lame way, read https://sourceforge.net/p/fteqw/code/HEAD/tree/trunk/fteqtv/net_qtv.h
#2422 posted by Kinn on 2016/09/14 12:11:43
This is all super badass. A possible future feature that I've thought would be mega useful would be QuakeC functions to draw textures to the HUD.
Once you can control the drawing of the HUD from QC, this really opens up a ton of stuff for modders (custom inventory displays, map screens...you name it)
Take 2
#2423 posted by sock on 2016/09/14 12:13:34
All the Backup spam is gone, decals works fine for me, but they seem really bright (colour wise). DP always made decals really dark, not sure why but all the decals look like they are glowing full bright.
I get spam on the console about not caching particles, but I have loaded the "effectinfo.txt" file so all of the particles should be setup. I am sure DP was doing the particle cache when the effects file was loaded, unless the message means something else.
I have updaded my world.qc with the new engine detection conditions (FTE_SV_POINTPARTICLES and FTE_PART_NAMESPACE_EFFECTINFO) and everything seems to switch over perfectly.
For some reason "traileffectnum" is missing so I don't have custom particle trails on plasma projectiles. Is it possible to check for this being missing? So I can fall back to the QS particle trails system instead. I know there is "trailparticles" but that is useless for traveling projectiles because you have to keep drawing the trail start and end positions all the time in QC.
#2424 posted by dwere on 2016/09/14 12:28:57
bindlist.lst
I wish this feature was available 20 years ago. Setting half the bindings via configs in complex mods was so clumsy.
QS-Spike Particles
#2425 posted by sock on 2016/09/14 13:12:22
@Spike, I am getting some strange particle emitters under the world geo and I am not sure why.
The size of the decals seems wrong, DP vs QS-Spike blood decals feels like a paintball game.
The size of particles in general seems to be larger with DP vs QS-Spike being very different. I tweaked all the DP effects to be a certain size and now everything feels too large.
My Gawd
#2426 posted by mjb on 2016/09/14 13:19:28
particle system that can be used by mappers to emit custom particles from surfaces based upon their texture names, like rain, snow, sparks, etc. I should give a proper example of this.
Spike this is incredible stuff man, thank you for your efforts! I would love to see an example :O
QS-Spike Particle Scale
#2427 posted by sock on 2016/09/14 14:18:32
@Spike, the engine scaling of particles seems to be affecting everything. Here is an example of the floor circle effect to show the difference of the scaling between DP and QS-Spike engines.
Stuff
#2428 posted by Spike on 2016/09/14 18:31:52
@kinn, you mean csqc? :P
rmqe has some simple csqc support that could possibly be used for huds or menus, but I don't think anyone really tried it.
if you want ssqc, then fte has 'tei_showlmp2' which allows adding/removing various persistent stuff relative to various parts of the screen. even dp has an svc_showlmp feature that nehahra used, but its only relative to the top-left of the screen. either form is really annoying to use.
@dwere, fte has had that for a long time. :P
kinda needs various cvar settings too though.
@Bloughsburgh, there's a weather example in the r2 zip. put the cfg in the right dir, use some console command or add a worldspawn key, restart the map, check the results.
@sock, precaches:
dp implicitly uses the effectinfo file to define the effect numbers, with both the client and server parsing the files themselves. this means that the excrement hits the extraction device if they differ. It also sucks big-time if you have multiple different particlesets loaded at once, or in other words DP has no user choice.
I could have QS parse that file server-side and auto-generate precaches that way, but that would mean two things: 1) the protocol is unconditionally changed even if the mod doesn't use pointparticles (the built-in effect names would need to be pre-assigned). 2) there's a whole load of redundant precaches if the mod uses the "effectinfo." prefix thing.
@sock,
particle scales: clearly I don't use DP enough, I'll need to look in to that.
dlight scales: I assume rockets give off different dlight sizes in both engines too, without any extra particle system. at least I assume that's what the floor circle effect screenshot was meant to be showing.
looks like 4-fold scaling with decals, maybe 2-fold with particles.
@sock,
emitters: o.O near the origin, too, but also far too regular.
@sock,
traileffectnum: this is mentioned in my readme as not supported, because its actually part of the entity state rather than a simple addition via a new svc. if I add the replacement-deltas protocol extension then I'd be sure to include this then, but I want to ensure everything else works before I screw everything else over (assuming I ever do).
until then, you can make a particles/trails.cfg (loaded the same way you're loading effectinfo) that contains "r_trail progs/foobar.mdl effectinfo.tr_foobar" lines.
ideally you'd use r_effect (and using count instead of countextra and its framerate-dependancies) for static entity emitters like torches or items, but I can understand you wanting closer dp compat.
#2429 posted by Kinn on 2016/09/14 18:48:57
kinn, you mean csqc?
God knows. I haven't done any quake modding since 2005 so this may as well all be new to me :)
Snow Video Using QS-Spiked-R2
#2430 posted by Baker on 2016/09/14 22:15:04
Yeah... the snow is well done. tehspiderman1 ! :)
Thanks for Spike's stuff :)
Xmas Jam
Better happen
So...
#2433 posted by Qmaster on 2016/09/15 00:03:39
Is sv_protocol 999 supported now too?
#2434 posted by Spike on 2016/09/15 00:14:26
QS 0.92.0 added support for 999, not me.
|
|
You must be logged in to post in this thread.
|
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.
|
|