What are you planning on doing with your software renderer to improve it over Winquake? 

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 :) 

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. 

I can only test it at 1280 x 1024. But I will put your request on the wish list... :) 

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 

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

http://irrlicht.sourceforge.net/

open source and under the zlib license; 

if anything, huds should diaf. bring on the q3bsp! 

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. 

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. ;) 

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. 

be hard to keep 320x200? If not in any other way, with commandline option? What about 320x240? 

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. 

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

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. 

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

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 ?". 

Because one could simulate liquid brushes, for example. 

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. 

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. 

and my notion turned out to be correct.

You can find the soft-wire code here:

https://gna.org/projects/softwire/ 

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.