News | Forum | People | FAQ | Links | Search | Register | Log in
Mark VI
Continuing discussion from Mark V thread, ( regarding clone on github:

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.
First | Previous | Next | Last
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


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! 
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. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2023 John Fitzgibbons. All posts are copyright their respective authors.