Since a few weeks I am working on a GL Implementation for the Vampire, utilizing the Maggie Chip (so with 3D Hardware Support). It is not a full OpenGL but more like a sort of MiniGL (not related to MiniGL Source-Code which relies on Warp3D but similar in approach, where MiniGL runs on top of Warp3D, gl4vamp runs on top of maggie.library).

Yesterday I had the first time a GL Demo running natively on Maggie (just a very simple demo ported over from one of the maggie.library Demos).

A code excerpt so you can see how this looks:

glBegin(GL_POLYGON); 
glColor4f(r,g,b,a);
for(int i = 0; i < 6; ++i)
{
  for(int j = 0; j < 6; ++j)
  {
  int vIndx = i * 4 + polyOffset[j];
     
                glVertex3f(CubeVertices[vIndx].pos.x,
                            CubeVertices[vIndx].pos.y,
                            CubeVertices[vIndx].pos.z);
     
                glTexCoord2f(CubeVertices[vIndx].tex[0].u,
                              CubeVertices[vIndx].tex[0].v);   
  }
  glNormal3f(CubeVertices[i * 4].normal.x,
                    CubeVertices[i * 4].normal.y,
                    CubeVertices[i * 4].normal.z); 
}
glEnd();

(Well, just standard OpenGL Stuff, and you clearly see this example copied from the maggie.library Cube example ;-) )

There is still LOTS to do, and I cannot tell a release date yet, nor what GL Features will make it to be in there. My personal hope is that it will be eventually good enough to run something like a Quake 2 Engine game for example.

Apollo Computers have been extremely helpful, made hardware (a Vampire) available to me, and Morten, the author of maggie.library helped me a lot as well. Gunnar also was helpful with everything.

Thanks to you guys!

Current Status of Implementation:

I have the stuff for the transformations set up as well as the texturemapping, vertex, normal and color handling and a lot of other odds and ends. I got a glu library with system specific stuff (supporting both banging the hardware for opening a display, and using intuition windows as alternative).

There is lots of GL-y stuff which is implemented in software right now (and completely untested) like Blending, TexEnv, Fogging etc., but probably a lot of work here still needs to be done.

The Library is currently a linkerlib but probably the end product will be a Shared Library.

Best regards,
Steffen Haeuser
tirionareonwe@gmail.com 
P.S.: If you wonder why a PowerPC-guy does GL for vampire - I like both systems. My Amiga x1000 is my number one but a programmer can have two "Amigas".

Robo Kupka wrote:

Cool stuff.   Is there a maggie.library package (lib, includes, docs) available for download ?

I had got it directly from Apollo, but as far as I understood Gunnar the package is available somewhere. It is still in development though, some stuff the Maggie Chip can do is not available in the lib yet. And the GL implementation will also cause some feature requests (both for Maggie and the lib) which I guess will cause major new versions. Already got a new Beta yesterday, which included support for more GL-like texture formats.

Very nice to read that especially from a programmer with you track records. What is the cost of going through maggie.library instead of banging directly the hardware?

"Banging the hardware" here means basically how the Framebuffer will be accessed, either by directly going over 0xdff1ec or using an IntuitionWindow and writing with WritePixelArray then.

With the time 3D Calculations take the difference will be - not noticable.

Going totally lowlevel without maggie.library has no advantage and would make the whole thing a lot harder. Actually one option might be to integrate the GL at one point directly into maggie.library (but that's for others to decide, my code's on offer for that at least - but before that the GL has to be mature, it is currently not even an Alpha Version yet).

>One word - COOL!
>  Have fun with 080,SAGA,AMMX and Maggie (and AOS3/AROS too) !
>  Back to 68k ;)

Thanks. Well I hope to be able to do parallel releases of stuff I implement for PPC and 68k in the future. As most of my projects involve GL in some form the GL port was a natural first project.

The biggest thing right now is that Maggie uses a different orientation of axis to OpenGL. The current example I have running is sort of fake-OpenGL. It uses OpenGL functions with maggie-like orientation. The transformations all need to be changed so that the code works with OpenGL-orientation (so that to port GL programs you do not have to adapt the whole code to a different orientation). Once this works the next step will be to test with OpenGL examples step by step the already implemented (without testing) features.

Steffen

Is there any link to some SDK or documentation for the libraries so I can take a look while I don't save money to buy my vampire v4+ standalone?

The computer is ok, the problems are the tax here in Brazil that can increase the cost to more than twice the price of the computer + shipping.

Best Regards,

Wow, twice the price sounds evil.

With "the libraries" you mean OpenGL ? Or the Maggie Lowlevel 3D Library ? Or Amiga Libraries in general ? If Amiga Libraries - you can assume if your software runs on OS 3.x it should run on Vampire.

There are though some things where the Vampire offers "special" things which are Vampire specific (Gunnar probably can answer this better than me, but from my perspective these includes:

- Joystick Support (for a Gamepad with many buttons)
- Music Replay (DMA-based)
- Directly accessing Video Mem, but in a way compatible with Amiga HW Hacking (P96 can alternatively also be installed though, so P96 using software or CGX using software also works)
- They have a SIMD solution (think AltiVec or SSE, the Vampire's SIMD thingy is called AMMX)
- They have a continuation of the 68k line of CPUs, the 68080 which also offers some more features (either using ASM or some compilers also offer 080 optimization).
- 3D is done either by directly accessing the Maggie chip or through maggie.library, hopefully in the future using GL with the lib I am working on also

It will be some time till it really is a OpenGL library though. My current implementation still is using axis "as done on Maggie" which means any GL app ported to it would need to have adapted (this cannot stay like that!)

If anyone here who is experienced in 3D programming wants to have a look at the problem feel free to contact me at tirionareonwe AT gmail.com. I am trying to get it done myselves though (basically setting up a transformation matrix to transform between Maggie Space and OpenGL Space). I think eventually I will get it done, but if someone wants to have a look - I am flexible about sharing that source code actually ;-) My GL implementation is using an OpenSource licence (not GPL, I used a licence compatible with both commercial and OpenSource projects).

MagicSN

Hi,

Yes, the tax here are killer.

Maggie Lowlevel 3D Library.

And you can use axis for reference point in the normalized device coordinates without problem. Watt will impact is how you build your matrices. I think the padronization in this case for global platforms is not a good idea by the difference of performance of architectures.  For example, one RTX 2060 can handle with a very (In this moments I would know speak english best hehehehe) more data, 
the approach may be different than on a chip that you need to extract the maximum from it to have an output compatible with what is expected in our days.

I hope you get what I want to say.

Best regards,

Is Maggie.library documented somewhere ?

I tried some months ago to do some code to port WaZp3D to Maggie using the maggie registers description (ie draw a triangle with maggie) but I couldnt succeeded as there was no documentation about how to setup zbuffer/screen/textures/mipmaps

Sadly Vampires dont have an Hardware Reference Manual :-/

About gl4vamp: you should use existing MiniGL/StormMesa/TinyGL sources as a basis  = no need to reinvent the wheeel ;-)

Hello Gunnar,

The SPRHDAT description in your site have a 404 error.
CLICK HERE 
Ok, that may be just a SPRHDAT, H, but just to you know about the problem.

I would like to talk just a suggestion,

Good documentation can help your platform, ok that there are registers explanations, but many users feel more comfortable with manuals with examples and other high-level things. Remembering that much of the success of the Amiga in the 90's was AMOS.
Some programmers will like bare metal, but others will prefer the chewed up stuff.

It is a platform to disseminate, the more programs, the easier it is. Just look at windows, which despite being rubbish, remains to this day due to the number of programs, some very bad, but they exist. Even the Commodore 64 spread so much because of BASIC.

I hope it has a great success, and I even imagine that because it is FPGA you might be a little afraid of someone getting a reverse engineering, but a higher level documentation, I think it would not be the path that would give this risk.

Remembering that this is not a criticism, but just a point of view that aims to help.

Best regards,

There a lot demos sources included for effects like for example:

Its a lot of information incuded,
I think you will agree that the provides source examples go far beyond that was provides as code examples for Amiga in the old days in the Amiga hardware reference manuals.
 

You are right!

In the site I gone direct to the documentation button, and for this I was thinking that has no documentation, looking the other areas now, have a lot of information.

EXTERNAL LINK  -------------------------

Documentation

Amiga_Sprites.pdf  <---- :)

--------------------------

Looking now the other buttons, have much more to see.

Sorry about it. My mistake.

Best regards,

I do not have Vampire to test, but I make the reverse, I get one src on Aminet EXTERNAL LINK and port it to Linux X86_64, with minimal alteration and it work fine, 100% no problem. Glut for menu, all working...

screenshot on this link EXTERNAL LINK 
The version for Amiga Work 100%, I do not know were is the problem to the people can build 3d programs.

Best Regards,

The Amiga platform really could use new and updated 3D / Animation software. If we want to revive the Amiga, we need new / updated software in ALL categories.

And i´d be willing to pay for it !

Your external link is just an example of a 3d program.

This does not help.

You do not want to do adaptions the same way everytime you port a program.

OpenGL (or a subset of it) is absolutely required.

I probably could have several of my projects running on Vampire and 68k if a subset of OpenGL existed already.

And if you have a project which requires
- texturemapping
- alphablending
- blending (with several different blending modes)
- z buffering

and a view other things

you really do not want to have to adapt it x times for x platforms.

There is no reason to not use OpenGL.

The alternative would be to do a Warp3D.library clone running on Maggie. Even if it does not support the full functionality this could help.

Personally I tried to go the "let's implement a subset of OpenGL on top of maggie.library" route, but both routes would be possible.

Best regards,
MagicSN

I wanted to write this post long ago. Now I am doing it. Note this is not meant as an attack on anyone. And I am pretty sure Vampire version of Heretic 2 will still work out (but cannot guarantee it).

And if that comes sort of unexpected - why do you think I am here, the guy who likes PPC and did contract work for Hyperion Entertainment ? It is because of Heretic 2 (and possible future titles for Sin), running on Vampire V4 ;-)

First of all - I have not given up on this (GL for Vampire).

It already runs a small OpenGL-Demo correctly (the same drawing cube which was one of the early demos for Maggie). But getting a complex game like Heretic 2 running on it is hard and requires more work.

If anyone - with 3D coding knowledge - wants to help, feel free to contact me (myselves I am now taking current version and try how far it can run Heretic 2 even with massive graphics bugs). gl4vamp is OpenSource.

I am though not convinced if this is the right way, a new GL implementation - or if a Warp3D or Wazp3D Driver would be the better way (actually it WOULD be the better way, just not sure if the option exists right now). MiniGL is tried and tested (as is TinyGL) it would be better to use those. But they require Warp3D, not maggie.library.

In an ideal world without company politics and philosophy Warp3D driver for maggie and just using MiniGL V1 68k would be the right way. Would have made it easier for me A LOT.

Actually H2 is just a trial. I could do a Maggie-supporting version of Freespace if this works out. And potentially Shogo (have to admit I don't have much clue of the Shogo source code, I was the original author of Amiga Version of Freespace though...).

The moment I popped up on this forum - this was all about Heretic 2 68k which I want to bring to the Vampire. And Sin (OS4 version was shown at Amiga Nord, 68k version does not work yeet, but I *am* working on the 68k version).

I already have it (H2, not Sin) running playable on PiStorm (well an Alpha-Version not ready for release - very unlike the OS 4 Remaster which I hope will be on sale for xmas), it was shown at Amiga Nord 2023, I would like to get it running on Vampire too. Vampire was actually the first 68k system I was thinking of as target for Heretic 2. Despite it running on PiStorm first (I am terribly impressed by both systems, if for different reasons).

Current "drawbacks":

- Features missing in Maggie-Chip (but I had a talk with Gunnar, and he seems to be willing to implement these features, if there is a chance H2 will run, I am currently working on a prototype which will look crap/unreleasable because missing features but hopefully will show Vampire is fast enough for H2 with help of Maggie. But I hope if this prototype is a success Gunnar will add the missing features.
- My GL Implementation. Let's be serious. it let's far to be considered. My job.
- Lots of code in the H2 renderer to be reimplemented to get around limitations of Maggie which are let's put it as "not required for Gunnar to fix" (I can fix them at software side, but this requires implementation time on my side)

My preference would still Warp3D Drivers for Maggie. This would make all H2, Sin, Freespace, Shogo (and yes I know there is no 68k version but there could be, I would be willing to do one) MUCH easier.

But I will try if there is an alternative with my "gl4vamp".

If someone wonders on these mystic "missing features":

- glBlendFunc(GL_ONE, GL_ONE)
- glBlendFunc(GL_ZERO, GL_SRC_COLOR)
- TexEnv for GL_REPLACE and GL_MODUlATE (currently Maggie always does GL_MODULATE I am told)
- glDepthRange

(There was a fourth issue which Gunnar already implemented though did not release yet)

Note other games (Freespace, Sin) might have a few other requirements (Interpolative blending for Freespace, H2 in normal code has this too, but I can fix this by using additive blending,it will look slightly worse but IMHO only VERY slightly)

And do not get me wrong - for my opinion the Amiga x5000 is still the best Amiga which ever existed, and after that the x1000 which I own myselves. But I find the Vampire also very impressive and I would like that all the work I did for gl4vamp and H2 68k reaching SOMETHING on Vampire.

MagicSN
tirionareonwe@gmail.com

Hi Steffen,
 
please allow me to add a very small correction to your post.
 
All that you want to do today already possible -
but you want it more convenient to use - which I fully understand.

Technically you can do all what you ask for with Maggie already today. I think Morten explained this before already.  And doing this is actually not hard.
 
What you can do is run any complex effect on 2 buffers  and then run a merge combine on them - and this will gives you exactly the result you want.

And the Amiga 3D demo that won the Demo competition on the A38 party - used this technique and created using Maggie exactly such effect that you asked for.

Of course on Maggie you can also do some stuff more efficient than Heretic code did it. Instead doing light over a slower memory access - Maggie does support the option to mathematically compute Light and Shadow - which is more efficient and faster.
 
And Maggie supports also features like higher resolution texture and with a lot more colors (e.g. truecolor) while Heretic today only uses 256 colors and lower resolution.
 
So there is some unused potential to improve picture quality and to increase performance.

But using any of this will of course add some effort to Heretic, like replacing the textures with higher quality ones, or needed to touch the code to benefit of the from the more efficient computed light.
 
 
And I fully understand that you seek for a simple way to get the game run and not want to invest a lot time in profiling and improving the engine or in recoding the engine to benefit from more efficient features.
 
I understand this - and yes we can add support for such options to make your live easier - so that you not need to touch any old code.

In the old days when a "port" was done. E.g. from a game from C64 to  Amiga. It was normal to rewrite parts of the core and also to redraw some GFXm and redo music to improve the game to get the most out of the system. I always see value in doing this.
But I understand fully that today many people want to save time and look for the benefit to make a port with less amount of effort. And this also makes sense.

I think it makes good sense to offer both, good ways to do stuff make more efficient that before (example computed light) but also simple to use ways to do stuff as before without needing to touch any code.  Both makes sense and helps people to make good Amiga games.

I hope your reply to this post does not mean you "revert" on our agreement, which we had on Discord and phone. Does this agreement still stand ? Your reply makes me wonder on this. I do not want to reach the situation to have managed a prototype after a lot of work, and then find out the missing features will not get added to Maggie after all.

And nothing on this is "simple" or "less amount of effort". "Simple" and "less amount of effort" would be to say "Get a Warp3D Driver implemented or forget about a Vampire version". Have I said that ? No. I am trying to find other solutions. The whole gl4vamp thing is a try to find an alternative, despite massive work it requires.

Yes, I still recommend doing a Warp3D Driver - it would not only be for the good of my game port, others would profit it too. But I am trying to find a different solution, after nothing seems to be happening regarding a potential Warp3D Driver.

Crossposting some information:

"
glBlendFunc and lighting functionality serve different purposes in OpenGL.

glBlendFunc is used for controlling the blending of colors during rendering. It determines how the color of a new fragment (pixel) is combined with the color already in the framebuffer. This is commonly used for achieving transparency effects, such as blending a semi-transparent object with the background.

On the other hand, lighting functionality in OpenGL is related to the simulation of lighting effects, such as ambient, diffuse, and specular lighting. Lighting calculations are used to determine the final color of a pixel based on the interaction between light sources, material properties, and the view direction.

In summary, glBlendFunc is used for blending colors, while lighting functionality is used for simulating the interaction of light with surfaces in a 3D scene. They are not interchangeable or directly related, as they serve different aspects of the rendering pipeline.
"

And it is not only for Heretic 2, this is basically used in a whole bunch of games all in the same way. It makes no sense to have to reinvent the wheel every time. Especially as this stuff is supported widely - even a S3 Virge can do Blending.

I am already adding LOTS of effort to make this possible. The "normal way" would be to say "okay, do a Warp3D Driver, then Vampire can be supported". It is not what I did, I actually started on implementing a whole GL Implementation on top of maggie.library.

I still think it would easier (than what we do right now) that you would try to get a Warp3D Driver based on your existing maggie.library code. Often it is just a different API for very similar functions.

Then we could directly use the tried and tested MiniGL (or TinyGL).

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.

We appreciate that you highlighted this drawback - and as discussed its our goal to make Maggie as easy to use as possible - and we look forward to add a simpler way here to make using these features easier to use - which will help people to port games with less effort.

Maybe a simple example is the instruction EXT.W and EXT.L
EXT.W does extend 8bit to 16bit
and EXT.L does extend 16bit to 32bit.

To extend an 8bit value to 32bit - 68000 coders always used the two instructions after each other.
first EXT.W, then EXT.L

So doing this was absolutely possible on the 68000 CPU.
But Motorola acknowledge that having one instruction doing this directly is easier, faster and makes coding simpler.
So Motorola added EXTB.L. which does 8bit to 32bit

I think this is similar to the texture discussion.
You can today "stack" texture operations and use 2 runs to create an effect you want - but easier will be adding a mode in which the same effect gets created in just 1 run.