News | Forum | People | FAQ | Links | Search | Register | Log in
Mark VI
Continuing discussion from Mark V thread, (http://www.celephais.net/board/view_thread.php?id=61375&start=2427) regarding clone on github: https://github.com/victorbstan/mark_vi

Perhaps to clarify for newcomers: I like the Mark V engine and wanted to contribute some bug-fixes/updates as I am able to, as well as invite further contribution from anyone interested in helping the engine development and testing by using GitHub as collaboration and distribution platform.

I've updated the build/dev tools to use the latest Visual Studio 2019 Community edition (free).

My ambition regarding this engine is modest, as I think it's a pretty good package overall. However I do want to focus on making it even more versatile and customizable for modders to have complete control over the look of the engine and use it as a platform for making new games.

Performance wise, some issues have been inherited as they are, from the original Mark V engine.

The most noticeable ones have been:
* Fire input registration/lack of
* Sprite performance issues in mods with many sprites
* Transparent water / texture performance issues
* Limited compatibility with very large maps

These issues are likely not the only ones, or even the highest priority, but they have been noted, and I want to keep discussion and development open to addressing them.

Some of these points will be easier/harder for me to address personally, so I will seek input from the community.
 
seriously, if markv-2 please just port things over to qss-spiked. or back port to quakespasm
its like overlapping the same codebase with same features?? 
 
spike is having a heart attack right now

quoting:

"""
QSS exists because of my frustraction with common quake engines totally ignoring mod development, and with mapper-focused engines ignoring multipler and multiplayer engines ignoring maps.
QSS is my attempt to fix that. Being based upon QuakeSpasm it retains the benefits thereof (and singleplayer is still the primary focus). And with my numerous networking fixes it ca actually be used through firewalls or over ipv6, and without flickering when there are too many entites - it should be noted that this makes it better for extreme singleplayer maps too.
Meanwhile it also supports numerous QuakeC extensions, even including Simple CSQC, so mods are no longer limited to hacks. It supports an effects system too, so you can finally create weapons that are actually different - assuming enough players also upgrade.

A secondary aspect of QSS is to provide a 2nd or 3rd implementation of various extensions. Imho, when it comes to extension, 1 implementation is a mess, 2 implementations is an argument, and only 3+ implementations is a standard. More implementations help solidify standards.
QSS is not intended to change the aesthetics from that of QS (beyond more file formats supported). People who want more graphical effects are probably already using an engine that supports them, and implementing them in QSS is likely to drive users away instead.
QSS does change the networking (I consider this a bugfix due to how dire parts of vanilla quake were), but not in any way that should change the normal behaviour of the game's physics nor be visible to existing mods.
""" 
Do It! 
 
@R00k 
I can't port things to other engines, since what features get integrated into those engines is up to the leader/contributors of that engine. As to what I can port into this engine, the goals of the project are stated on the GitHub page. 
I Love QSS R00k 
But Mark V actually has quite a few unique features QSS doesn't have. Quaddicted integration is just one nifty one.

This is kind of like suggesting why make your own mod if AD has all the features you want already? 
 
thats my point. Qs has a better renderer than MarkV and Qss has better mod support; so port the things you like from markv into qss.
or back port the best of qss into markV 
 
i mean baker will be back.. he always takes a break.
I am seriously forking qss and porting some quality-of-life things i am used to in Qrack over to it. i think, for my self, ripping code from qss and porting it to my engine just perpetuates the division of quake clients. Porting into one 'netQuake' code base (even as forks) help the "single-player" engine of choice. 
 
and ultimately the bumberstick says "just use FTE" but... we are talking about ftizquake variants :D 
 
*bumpersticker 
 
Making an updated fork of the Mark V engine (let's call it MarQ W or something) would be good for people who want a software renderer with up-to-date Quake compatibility. IIRC someone told me it doesn't support alphamasked textures properly. 
Raising Limits 
So with Arcane Dimensions out, is there any chance anybody will take a look at the source code and raise the limits to make sure all new maps are working?

Last time I checked in January, Quakespasm had limits like this: Dynamic lightmaps allocation, BLOCK_WIDTH/HEIGHT 256, MAXALIASTRIS 4096, MAX_STATIC_ENTITIES 4096, MAX_STACK_DEPTH 64, cmd buffer size 256K, MAX_EFRAGS/MAX_MAP_LEAFS limits removed.

I dunno if Spiked went even higher in his port modification, but that's the absolute minimum of what should be done. 
 
Baker still uses glBegin/glEnd code in MarkV so it will run AD like shite unless the renderer is rewritten. 
You must be logged in to post in this thread.
Website copyright © 2002-2020 John Fitzgibbons. All posts are copyright their respective authors.