Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Running Games and Apps.

GL for Vampire/Maggie ("gl4vamp")page  1 2 

Gunnar von Boehn
(Apollo Team Member)
Posts 6220
22 Nov 2023 16:19


Steffen Häuser wrote:

As it is, adapting the renderer manually to Maggie missing features will have to be done again for Sin, and if I would want to do a Maggie-enabled adaption of Freespace or Shogo it would have to be done again.

 
 
 
Yes correct looking at each Game, and deciding what the optimal way to implement what it needs - is what people used to call "porting".
 
I fully understand that today more people like to get a game run with less efforts - and not like to invest time into understanding the bottlenecks and demands of each game. But to get it compiled ASAP. I see that this is something many people want.
 
I fully understand your point of easy of use.
And I fully agree with you that it makes a lot sense to make life as easy as possible for users.

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.



Steffen Häuser

Posts 40
22 Nov 2023 16:52


There is no language problem. A philosophy problem maybe (that we definitely have).

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.




Gunnar von Boehn
(Apollo Team Member)
Posts 6220
22 Nov 2023 17:28


Steffen Häuser wrote:

Again I need to know if our agreement still stands.

 
Yes I said this 100 times now.
 
And I very clearly said that I thank you for giving examples where we can make coding simpler for the users.
 
Yes I tried to "correct" a little your wording.. That is all.
I hope you understand this.
 
 


Thellier Alain

Posts 141
24 Nov 2023 09:11


I think that as maggie only have the classic glBlendFunc (alpha,1-alpha) then the only way to emulate say glBlendFunc(GL_ONE, GL_ONE) that is used with RGB texture is to convert the RGB tex to a new one RGBA that will include the correct blending factor in his A and eventually will scale also the R G B values
  This will not do the same effect 100% but can give something similar


Steffen Häuser

Posts 40
25 Nov 2023 20:31


thellier alain wrote:

  I think that as maggie only have the classic glBlendFunc (alpha,1-alpha) then the only way to emulate say glBlendFunc(GL_ONE, GL_ONE) that is used with RGB texture is to convert the RGB tex to a new one RGBA that will include the correct blending factor in his A and eventually will scale also the R G B values
    This will not do the same effect 100% but can give something similar
 

 
  So Maggie supports alpha,1-alpha blend function ? I assume you refer to GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA here ? This is an interesting information and I definitely will "play around" with this. Up to now I assumed it doesn't support any blendfunc.

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 ?
 


Thellier Alain

Posts 141
25 Nov 2023 21:19


I allways thought that Maggie was doing GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA but perhaps I am wrong (I didnt tested this yet)

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


Steffen Häuser

Posts 40
26 Nov 2023 10:43


I suspect a software emulation would be acceptable in the case of H2, the GL_ONE,GL_ONE effects seem not to be a big area of effect (at least not in the first level). Where they are big area (water effects) the Alpha Blending could be used and it does not look too bad.

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.


Gunnar von Boehn
(Apollo Team Member)
Posts 6220
27 Nov 2023 09:47


Steffen Häuser wrote:

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.


Steffen Häuser

Posts 40
05 Dec 2023 09:57


Has to be seen how good the first version runs. Any sort of Software-Emulation of Blending modes would have to go into the Wazp3d/Warp3D Driver (Driver author thinks would be not fast enough) as Blending will work together with other GL features (basically rendering pipeline), so no, cannot be done in the application.
 
  It is not just about doing for example GL_ONE,GL_ONE Blending, but GL_ONE,GL_ONE Blending in combination with TexEnv in combination with other features you already do. Either the driver needs to provide this or the GL.

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.

posts 29page  1 2