Anyone get arcane dimesnions to run on qbism super8? I tried running but it crashes on start up. 

mark_V_Winquake just crashes for me. Used the link that was included. Sad. Was looking forward to the palleted texture rendering. hehe 

If you post your config.cfg, your command line, start up Mark V with "c:\quake\mark_v_winquake.exe -condebug start" and post the contents of "c:\quake\id1\start.log" tell me about your machine specs (version of Windows, anything unusual) ...

I'd be willing to quickly check for anything unusual.

I haven't had anyone say that Mark V WinQuake and 30-40 people have given it a test drive, but obviously it isn't working for you. 

does qbism super8 have a console command similar to qbism super8 cl_beams_quakepositionhack? for darkplaces? I am trying to adjust the position of the lightening gun beam in QC but no matter what I do, it is always in the center when using qbism super8. I was wondering if it is the result of qbism also having a console variable similar to qbism super8 cl_beams_quakepositionhack? in dark places that I need to disable in order to get it to work.

I've looked for one. but no luck so far. 

That behavior was implemented by me before qbism forked the code, so he may have not changed it. When I implemented it I didn't add any cvar to restore the original behavior.

Hmm� Yep, no changes were made:
https://github.com/qbism/super8/blob/master/cl_tent.c 

@mankrip: So no matter what, there is no way around it unless something is changed in the engine itself? No way around using quakec code? 

:/ Yep, no way around, other than using a different kind of beam. 

Well not quite... You can spawn a new entity to be the source of the beam at the spot you want. 

@ 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. 

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. 

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. 

 

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. 

Sure, I did say it was messy. But it's qc only as opposed to needing engine changes. 

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. 

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? 

Cvar name is cl_beams_quakepositionhack 

What are the cvars that can be tweaked to make DarkPlaces look like software Quake? 

type in this -

gl_texturemode gl_nearest 

r_useanotherengine 1 

Doesn't make any engine look like software Quake. Software Quake had mipmaps but gl_texturemode gl_nearest will disable mipmapping. 

software quake didn't have mipmapping. This will remove all texture filtering and make it look oldschool.

Are you trolling? 

Of course software Quake had mipmapping. That was one of the cool features. 

Oh, I see, you're confusing mipmapping with filtering ... no, it didn't have texture filtering. But it DID have mipping. 

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.