News | Forum | People | FAQ | Links | Search | Register | Log in
SW Quake Question
Hi guys. Hope everyone had a good new year's day. Now, I need your help not only as mappers, but mostly as a Quake player community.

I am rewriting my engine from scratch, and this time I want to have a software version, so people without hardware accelerators still could have an option besides the vanilla Quake. But the fact is: while I reckon the software render can looks surprisingly well in the context of the original Quake atmosphere, the default 320 x 200 resolution just plain sucks. Big time. Which brings my question to people who stills playing software Quake: I want to drop support to the lower VGA resolutions (anything below 512 x 384, actually). Not only because they suck, but because I plan to have some additional artwork (menus, HUD elements, etc) that simply won't fit in lower resolutions. So I would like to hear from the community what you guys think about this move.
Anyone here stills needs to run in such lower resolutions, or see a good reason to keep it ?
First | Previous | Next | Last
Tochrisquake 
afaik tochrisquake added some useful things to software quake that are lacking in winquake, namely transparent water and animation blending.

Would be nice to have some higher defaults for sv_maxspeeds and maxsurfs and higher limits for big maps, lots of enemies etc. like aguirre's engine has, along with some of the niceties of fitzquake, such as the improved console and mouselook state saving.

and 1920x1200 (and other widescreen resolutions) would be nice too. Also, make sure you support half sizes on all widescreen resolutions, so there is a 960x600 for those with a nice monitor but crap pc :) 
Tron 
The project goal is to have a common set of features in both OpenGL and software versions. Some of these common features are:

- animation and movement interpolation for alias models
- transparent texture support
- support to Quake 2 models and maps

Most of this are already existing features in engines like Maqaku, FTE and others that I will port/adapt to my original code base. Besides that, I have a couple of unique features (mostly non-graphical, but useful for modding in general) ready to be added. And I need some feedback from the community about this minimal resolution question in software Quake. 
Sorry, CZG 
I can only test it at 1280 x 1024. But I will put your request on the wish list... :) 
Hey Frag.machine 
one thing that would be useful for mappers and the aesthetics of Quake would be proper Quake 3 style rotation and related to this, properly lit bmodels.

Also, Irrlicht has a new SW project that attempts to keep compatabilaty with its hardware driven renderers. It may be worth a peak for ideas (with low detail maps its redraw rates are not unreasonable as well). 
 
can u guys please leave q1,q2 and q3 suported seperated? they are diferent games.... dont mix then in same engine...

huds and stuff is ok but maps? errr 
Thanks For The Tips 
@HeadThump: I'll check it out, thanks. Do you have any links ?

@Trinca: I see no harm supporting more artwork formats, as long the engine does not rely on this to load required assets. The idea here is to open more choices to modders (let's face it, good Quake 1 models are some orders of degrees harder to find than Quake 2 or Quake 3 counterparts). An engine supporting Quake 2 models in both software and OpenGL versions would be a useful option IMHO. 
Yeap 
http://irrlicht.sourceforge.net/

open source and under the zlib license; 
Heh 
if anything, huds should diaf. bring on the q3bsp! 
I Created A Poll 
at http://forums.inside3d.com/viewtopic.php?p=5649#5649

I'm afraid your registration is required in order to vote, but I'd really appreciate any feedbacks from you guys on the topic. 
320x200 
as it would be a shame to have a modern sw engine with no chance to run on vintage pcs.

And make sure Kinn's miniature maps run on it. ;) 
Yup 
Kinn's Marcher Fortress is a real battle test (no pun intended) to any engine, this map revealed a hidden bug in my old engine texture loading code. I recommend to any engine programmer to test his work with this map. 
Would It 
be hard to keep 320x200? If not in any other way, with commandline option? What about 320x240? 
Ah I See 
you answered that already in that forum, renewing fonts and all that...

I think many QW people play still in soft 320x200, something about the shaft being better or something, I don't know, I haven't followed that scene since a year. 
Here Comes Another Question... 
.. but still related to engine development.

On this thread at QuakeSrc.org (http://tinyurl.com/36tlwl) there's a discussion about adding support to a new kind of texture animation in Quake.

As we all know, in vanilla Quake one can make animated textures renaming them like this:

+0texture
+1texture
+2texture
...

We are proposing to create a similar naming convention (maybe using a different character instead the "+" so we don't break things) allowing for more frames, and maybe other features, like variable intervals and/or randomized frames. We would like to know what you mappers really need, and what would be the best way to implement it (from the end-user point, in this case, the mappers). The idea is to add a feature that will effectively be used, so any feedback from you guys is more than welcome. 
Warping 
Being able to apply a water warping type effect would allow for nice teleporters. I think everyone has tried the trick before of taking a screenshot to use for a teleporter, but it doesn't seem to like odd resolution textures being used. 
Frag.machine: 
i'm a little confused, mh seems to be suggesting that the new animation frames are created as tga or similar files, and that the .bsp and .wad would only contain the texture that serves as the placeholder with a base name -- "waterfall" in the .bsp would be replaced in the engine with a loop of "waterfall_anim_00.tga", "waterfall_anim_01.tga", "waterfall_anim_02.tga" etc.

Is that the suggestion, or are you now talking about new textures and naming conventions in the .wad and .bsp themselves?

I think the first idea makes more sense (though the exact naming pattern doesn't have to be as mh suggested.) 
Metlslime 
That was the initial idea. Later we agreed that using a more simple convention like "+00texture", "+01texture", etc (simply adding one more digit and thus allowing more frames and using a more familiar naming convention) would be a better way. The use of TGA/PNG/JPEG files is obviously a detail, applied to engines which support it (not being a mandatory condition, of course). What we are discussing there is just the naming convention and details like "what would be the best animation frequency ?", "should we use + or other symbol ?" or "would random animation cycles be a good idea, too ?". 
Warping Is A Good Idea, Too 
Because one could simulate liquid brushes, for example. 
Frag.machine: 
That method does not sound backwards-compatible. For example if you had a 37-frame animation that went from +00 to +37, in an older engine, instead of 37 frames you'd see 4 frames:

+00texture, +10texture, +20texture, +30texture

And it would loop every 0.4 seconds. Instead, I'd suggest using a new symbol so that old engines would simply display a static image, rather than a hyper-fast-animated one.

Hmm, but I guess you're trying to solve two issues:

1) Animations are limited to 10Hz framerate
2) Animations are limited to a 1sec loop length

You could solve problem 1 in a backwards-compatible way by simply saying that the +00, +10, +20, etc. frames would always occur 0.1 seconds apart, and if there are in between numbers, like +05 or +01, this will add more frames, making the animation smoother. Regular quake would just play the animation at 10Hz, dropping the appropriate frames, so it looks approximately correct.

However, that probably forces you to make the implementation logic very complicated to find the next frame and decide when to play it. I suppose you could specify that the only valid framerates are 10Hz, 20Hz, 50Hz, and 100Hz.

Still, the second issue of length of loop is not solved. I don't see a way to solve this in a backwards-compatible way, unless you use a new symbol and accept that regular quake will not animate that texture at all. 
Frags 
On another SW topic, I recall Nicolos Capens developed a DirectX 9 type shader system for SW rendering called Soft-Wire. He had several examples and posts on flip-code and other places like this article

http://www.devmaster.net/articles/linear-optimization/

Also there was a lot of software he made available here:
http://sw-shader.sourceforge.net/
but it now leads to a commercial site that I guess he started up to give Abrash some competition. Unfortunately, I couldn't find the shader code and editor he use to have up on sourceforge. It may be buried somewhere on the new site, but I don't typicaly do join ups. 
Light Bulb Went Off In My Head 
and my notion turned out to be correct.

You can find the soft-wire code here:

https://gna.org/projects/softwire/ 
HeadThump 
Thanks for the links. I am collecting as many material as possible.

metlslime: that's why we are considering alternatives so we could leave the "+" animations as is. Besides, vanilla Quake would not treat + 00texture and +01texture as belonging to the same animation cycle. 
 
Besides, vanilla Quake would not treat + 00texture and +01texture as belonging to the same animation cycle.

Yeah, that's what i said. 
Note To Self: 
"Don't reply forum messages when you're asleep" :D 
If You Guys Don't Mind... 
I'd like to forward your suggestions (with the due credit to each one, of course) to the QuakeSrc.org thread. I believe there's no restrictions for doing this, but if someone prefers to stay out of the discussion, just say me. 
First | Previous | Next | Last
Post A Reply:
Name:
Title:
Body:
message
question
exclamation
idea
flame
noflame
error
skull
beer
moon
pent
rocket
sheep
pacman
pig
cheese
worldcraft
gauntlet
crate
pitfall
pimp
smile
cool
sad
frown
oi
yay
tongue
evil
wink
neutral
q1
q2
q3
ut
hl
cs
doom
dkt
serious
cube
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.