#415 posted by mankrip on 2015/12/30 20:33:03
:/ Yep, no way around, other than using a different kind of beam.
#416 posted by necros on 2015/12/30 23:55:37
Well not quite... You can spawn a new entity to be the source of the beam at the spot you want.
#417 posted by Legend on 2015/12/31 12:11:09
@ necros:
You mean create an entirely new entity that duplicates that of the lightening bolt but with a different name and just use that as what is called by the lightening gun when fired? and it should appear where I want it to and stay steady? I managed to change the location of where the lightening bolt originates from the gun, but as the player moves, the lightening beams seem to lag to catch up with where the player is standing.
#418 posted by necros on 2015/12/31 14:53:59
Yeah, it's going to be messy, but what you do us something like this...
Spawn the entity, set its owner to the player. give it a think method to set it's origin relative to the player and make the nextthink 1. This makes it run every frame so the helper resets it's position all the time.
Then you'll want to store a time value 0.1 seconds in the future and include an if condition to remove itself after that time.
#419 posted by Legend on 2015/12/31 17:45:09
could I just add the think method to the original lightening entity? btw, where/which qc file is the code for the lightening bolt entity stored? I'm having trouble finding it.
Weapons.qc
#420 posted by ijed on 2015/12/31 20:45:43
@necros
#421 posted by mh on 2015/12/31 20:57:59
That's basically what the original code in cl_tent.c already does - spawn an entity at the view model origin and update it's position each frame. What you're proposing just seems a more complex way of reproducing the same behaviour as is already there.
Part of the problem is that the view origin for the view entity is actually not the same as the view origin that's used for drawing. I haven't actually traced through this part of the engine code in sufficent detail to say more though.
#422 posted by necros on 2016/01/01 07:13:14
Sure, I did say it was messy. But it's qc only as opposed to needing engine changes.
#423 posted by Baker on 2016/01/02 20:54:22
qbism has released a super8 with the ability to toggle the beams behavior ...
https://qbism.com/download/file.php?id=30
Presumbly the cvar is cl_truelighting 0/1, the same as JoeQuake/ezQuake/Qrack/etc. where a setting of 0 is Quake normal behavior.
#424 posted by JneeraZ on 2016/01/02 20:58:46
I tried qbism and I really like the look of the engine but ... fullscreen seems broken? My Windows task bar never goes away which is annoying. Am I alone on that?
#425 posted by Baker on 2016/01/02 21:03:29
Cvar name is cl_beams_quakepositionhack
#426 posted by babgo on 2016/01/03 16:39:41
What are the cvars that can be tweaked to make DarkPlaces look like software Quake?
type in this -
gl_texturemode gl_nearest
Babgo
#428 posted by Kinn on 2016/01/03 17:43:46
r_useanotherengine 1
Gl_texturemode Gl_nearest
#429 posted by mh on 2016/01/03 19:33:23
Doesn't make any engine look like software Quake. Software Quake had mipmaps but gl_texturemode gl_nearest will disable mipmapping.
Mh
software quake didn't have mipmapping. This will remove all texture filtering and make it look oldschool.
Are you trolling?
#431 posted by JneeraZ on 2016/01/03 19:48:09
Of course software Quake had mipmapping. That was one of the cool features.
#432 posted by JneeraZ on 2016/01/03 19:49:04
Oh, I see, you're confusing mipmapping with filtering ... no, it didn't have texture filtering. But it DID have mipping.
Fifth
#433 posted by Baker on 2016/01/03 19:53:45
If you view a texture in TexMex, it will let you see the 4 mipmap textures it creates.
Any Quake texture wad has 4 levels of detail built into the texture.
WinQuake uses them. GLQuake did not use them and instead generates it's own mipmaps from the texture.
gl_nearest_mipmap_nearest
#435 posted by Baker on 2016/01/03 19:58:52
TexMex ---> open a wad --> select a texture and click View ->View Detailed.
The smaller images below the main image are the mipmap level textures.
Ok
I guess I was confusing filtering and mipmapping as the same thing.
Basically I was helping the dude get the pixelly goodness.
#437 posted by Baker on 2016/01/03 21:12:32
The workings of the software renderer aren't as well known to most as the GL engines.
Mostly because for maybe a decade, the WinQuake style engines were basically abandoned and forgotten.
Mankrip was probably the main person working on them (other than Spike) but MH did 2 big tutorials that really made them better (one was animation frame lerping).
#438 posted by babgo on 2016/01/03 23:31:37
You guys seem to over-emphasize smaller differences in rendering from GL to Software. I mean, what most people really want, and notice, are the pixeled textures. And that's it.
Babgo
#439 posted by Kinn on 2016/01/03 23:36:45
Without simulated 8-bit rendering (i.e. every pixel you see on screen is in the quake palette) I'd be reluctant to say it looks anything like software quake.
|