Today it think there is a little mix-up of the meaning of the word "porting", today many people say "porting" when they in fact only do "a compile".

And I understand fully the advantage of doing a simple "make" and have a so called "port" over doing a full scale analyses of the game and looking for the optimal way to implement it.

If you look at "Robin Hood" for example - it goes the full traditional meaning of porting. The Robin port does a full scale analyses of the game code, including profiling, and the port chooses implementations for each part that are optimal for the hardware. Including changing software sprites to hardware sprites, or changing "memcopy scrolling" to real hardware scrolling, or changing multi threading to interrupt based routines.

I assumed after we had this discussed again and again I can assume this discussion is done for.

And it is not some extra coding steps but reimplementing the engine in a completely different way.

And you know - I have here several games basing on the same engine, this would mean doing the same again and again.

While if you did it as it is on every other platform and at least implemented the MINIMUM set of features (I did not ask for more, I actually tried to replace things wereever possible to make the number of features still needed as small as possible) this would simplify things a lot. And I have no doubt your hardware could do it at still acceptable speed.

And software which does not need blending - it just won't use it.

Again I need to know if our agreement still stands.

And sorry, I won't continue the blending vs. lighting discussion again.

I currently assumed if any is supported it is GL_ONE,GL_ONE and GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA might have to be replaced using GL_ONE,GL_ONE. I will evaluate if the opposite is possible then.
 
I still hope a future "version" will include the missing blend modes. My assumption was that they will still get added (I never said I need them NOW, just before the release of Heretic 2).
 
I repeated certain wordings to avoid people claiming this would be "political" or "just to be negative". I already have been getting contacted by people (not affiliated with Apollo Computer) who told to ME that it should be easy to run H2 on Vampire, something I as the author did not even know yet. I wanted to avoid to the blame getting shifted to me.
 
  If you need further examples feel free to ask, can also be done in private. I am also sure Morten would know some examples, asides from myselves.
 
  @Alain Thellier: Could the "similar effect" be integrated into a theoretical Wazp3D Driver (I assume as you write here you would be the best person to ask about this, after all you are the author of Wazp3D) so the author of the application using it does not need to care for it ?
 

Yes it need to create a new RGBA texture and feed it this way

UBYTE* RGB;
UBYTE* RGBA;
UWORD a;

for each pixel
RGBA[0]=RGB[0]/2; //r
RGBA[1]=RGB[1]/2; //g
RGBA[2]=RGB[2]/2; //b
a=( RGB[0] + RGB[1] + RGB[2] )/3;
RGBA[3]=a; //a
RGB+=3;
RGBA+=4;

This will not be mathematically the same but will give a good enough transparent tex for fire,explosion,etc...

But perhaps the better solution will be to let Wazp3D draw those rare problematic textures with his own soft renderer that supports all the blend functions

It might be problematic on the lightmapping (which uses either alpha,1minusalpha - which is unproblematic if it is supported - or zero,srccolor).

note additional to the blending I also need "no blending" (gl_one,gl_zero) at places and of course blending needs to be combined with gl_modulate and gl_replace texenv.

I wonder if we have a misunderstanding here.
Your post give me the impression you think this is not possible today?

Maybe I can help with information.
Let me explain what is possible today already.

Today Maggie3D does support 24bit DXT1 and 24bit DXT1a textures.
And can save back to 16bit(RGB) or ARGB 32bit result.

AMMX is the 64bit SIMD instructionset expansion supported by 68080.
AMMX has very fast and optimal instruction for Alpha Blending and many other operations.

What you could do with Maggie3D today is you "process/scale/zoom/texture/map" one texture - and store this result in a 32bti ARGB buffer. And as 2nd step you call a simple AMMX routine.
And with the AMMX routine you can do ANYTHNG you can think of for mixing this buffer with the screen or for mixing several buffers.

So using this technique you can do all you want.
This needs 1 more AMMX copy call so its of course a little slower than if Maggie3D would do it in the first run.

But as AMMX is really very fast and can do a alpha multiplied merges of 2 source with 2 screen pixel in 1 instruction. Using AMMX is not a KO criteria.

And we might add more speed to this in the future and also enable Maggie to offer more blend option by itself.

But I think we wait for the proof of concept here first.
 
  Hardware should support it. Even lowly S3 Virge supports that. I think proof-of-concept should be possible without those features though.
 
  First version will look crappy due to these missing features, but hopefully give us an idea about how fast it can possibly run. MiniGL 68k renderer is done, waiting for Wazp3D Driver now.
 
  Generally if you want to do AMMX optimization the perfect place for it (asides from missing feature issues) would be MiniGL. While MiniGL is optimized for usage in Games I suspect AMMX might be useful there. If you want you can get the MiniGL Source Code from me, it is actually OpenSource.
 
  I had a quick look and while I do not know AMMX I think there are several places which would profit of a SIMD architecture (which I think is what AMMX is - right ?).
 
  Stuff like this I was thinking about:
 
  "
      do
      {
    float x = v->bx;
    float y = v->by;
    float z = v->bz;
 
    v->bx = a11*x + a12*y + a13*z + a14;
    v->by = a21*x + a22*y + a23*z + a24;
    v->bz = a31*x + a32*y + a33*z + a34;
    v->bw = a41*x + a42*y + a43*z + a44;
 
      v++;
      } while (--i);
  "
 
  Doing something there would not only profit Heretic 2, but assuming the Wazp3D Driver works out it would help ANY application or game using MiniGL on Vampire.
 
  Note the MiniGL for 68k is statically linked, different to the OS4 version. Some parts of the MiniGL Code is a bit a "#ifdef desert" (at the time they released this into OpenSource I think they were working on some unfinished features). I suspect the code in draw.c and matrix.c could profit of AMMX optimizations.