Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

OpenRift

Members
  • Content count

    10
  • Joined

  • Last visited

About OpenRift

  • Rank
    Warming Up

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. No, both NetQuake AND QuakeWorld.
  2. WinQuake does support 320x200 and 640x400 on some setups. But here's the thing. It doesn't correct the image to 4:3 on modern systems. However, it DOES correct it on Windows 9x versions. But there is no way to do it on modern Windows 10 hardware to my knowledge.
  3. There's already a map pack called Coffee Quake with a focus on vanilla style maps. Nice try though ;)
  4. *nudge-nudge* kek ....unless?
  5. Look at the Quake logo in the 200p screenshot. It it's more proportionally accurate to the actual logo. Also, same with the id software logo.
  6. I did post this on quakeone.com, but I wanted to put it here too so that word gets around a bit more.
  7. Now, I know what you're thinking. "There's plenty of software renderer source ports out there, try Mark V Winquake!" "Quakespasm's pretty vanilla." Here's the thing. As awesome as software ports like Mark V Winquake and Chadquake are, they still don't have the 100% vanilla experience. From a preservation perspective, the full DOS Quake experience is very far from accessible. Running it in DOSBox always yields performance issues (running too slow/fast). Running in an emulator like PCem or x86Box is a pain to set up and also has significant drawbacks. But what sets DOS Quake apart from something like Mark V Winquake or Chadquake? The most important things to look at are the resolutions available in DOS Quake. The main resolutions to look at here are 320x200 and 640x400. If you do the math, that should calculate to a 8:5 (16:10) aspect ratio, right? Well, if you know anything about old DOS games, you'll know that CRTs back then had the talent of being able to display non-square pixels. Given that most MS-DOS games ran at 320x200, this meant that this 8:5 ratio is squished into a 4:3 screen. This would mean that the pixels have a 1x1.2 width to height ratio. But why is this important? Let's have a look at a side-by-side comparison of DOS Quake at 200p (left) and then at 240p (right). Don't see it yet? How about now? That's it. Every 2D Texture, from the menus, to the console, to the hud, to even the crosshair are stretched when displayed at 240p because it then renders all these textures with square pixels instead of non-square pixels. To put things into context, most DOS game developers, including Id Software, designed their 2D texures with non-square pixels in mind. Most people are used to the stretched look from 240p, 480p, etc. because no source port that I could find has ever made the effort to replicate these non-square pixels in the menus. This essentially means that most people cannot viably experience true vanilla Quake without having to jump through a bunch of hoops to get it working in some sort of VM or suffering with DOSBox's terrible performance handling. But enough talk about resolutions, what about QuakeWorld? There are very, very few QuakeWorld source ports to choose from, which is kind of a shame in my opinion. FTEQW does come admirably close to a semi-vanilla experience, but can be incredibly bloated at times. Sure, there is the qwcl.exe that comes with your copy of Quake, but it's So what could be done about this? Think about Doom source ports. The ones like Chocolate Doom or Crispy Doom. They render the game in 320x200 (or up to 640x400 in Crispy Doom), squeezed to 4:3, and then scaled up to your monitor's native resolution. I propose creating a sort of "Chocolate Quake", that would consist of the following. All resolutions from the DOS version are supported With support for non-square pixel resolutions, in a manner akin to Chocolate/Crispy Doom .MP3/.OGG support for the soundtrack NetQuake protocol 15 support A QuakeWorld variant Extended compatibility for modern QuakeWorld (like from ezQuake/nQuake) mods, protocols, etc. So what's my point? My point is to start a dialogue, create interest in making the original experience from 1996 and '97 more accessible. If anyone here knows how to work with Quake's source code and is interested in this idea, contact me on discord at OpenRift#8470. If I knew how to code, I'd do this myself, but the most I know how to do is edit .cfg files. I can't really tech myself either, since I'm knee-deep in college as of writing. Thank you.
  8. I'm a bit of a purist when it comes to games like Doom, so I like to use source ports faithful to the original version of the game (Crispy Doom, Chocolate Doom, etc.). I recently got Sigil with the buckethead soundtrack, and it seems that in order to run it on Crispy Doom, I have to use the compatibility WADs (SIGL_COMPAT, SIGIL_SHREDS_COMPAT). Am I missing out on anything by using those instead of the regular wads?
  9. I've started playing on Chocolate Doom, as I wanted the definitive experience of the game, and I noticed that upon death, I lose all the weapons that I've gained thus far. Is that an original feature or is that a gamerule set by chocolate Doom? I've played through the whole game on GZDoom and never experienced that. Or maybe I'm just stupid and forgot or something.
×