Please contact me if so, I would be delighted to help as beta-tester ,code reviewer and most important moral support. I have a good knowledge about ASM, C/C++ and 3D Programming.

Thanks,

Bastian

bz__variamedia_de

The biggest issue here is the code of the reimplementation uses OpenGL.

I am personally trying to get OpenGL (a subset) to the vampire
but it is hard work. If someone wants Wipeout - and
possibly other titles - on vampire it would ne best to join my project.

I could use another 3d programmer for the project,
best one who like me has a Vampire hardware (mine
is sponsored by Apollo Computers, thanks to whom
thanks is deserved, incredibly helpful people!)

Another possible approach would be writing Warp3D
Drivers based on either maggie.library or directly the
Maggie hardware (any volunteers? ;))

If you feel you know the tech enough to discuss it
feel free to contact me at tirionareonwe@gmail.com  (And yes i am the Steffen Haeuser who did several
game ports for Hyperion Entertainment).

At least one future project of mine would get a
version for the Apollo Vampire 68080 system
additionally to AmigaOS 4 if either a partial OpenGL
implementation (which i try to make reality myselves,
a first demo is running) or Warp3D drivers existed.
We are not talking of Wazp3D here, i require Maggie
support here for my project and I suspect it might
be similar for a wipeout port.

And yeah, Apollo supported me on all this, especially
Gunnar and Morten. Sorry that i could not yet
provide something to show for Amiga38.

If no other coder is available i just continue on this
as a one-man-show (besides other projects, most
on AmigaOS 4). I still espect at one point getting it far enough
for my project to run my project on Vampire. Still another
3d coder could help a lot!

Best regards,
Steffen Haeuser aka „MagicSN“

The platform and renderer abstraction is well done.
Basically only 5 draw function are required.

If SDL2 and OpenGL driver would exists this port can done quite quickly.

So two ways to port it:
1) Using SDL / OpenGL (both libs would need to be developed, very time consuming).
2) Only implement the minimal required features of renderer and platform abstraction layer.

1. is what you propose, advantage other ports would benefit from it as well. However, it is a long shot.

2. faster to implement, game specific optimisation can be implemented.

Would be interesting to know how far your OpenGL driver is already on V4 ?
Concerning SDL2, in my understanding some parts of it already exists.

Why?

Because we have an Amiga here, and the Amiga hardware allowed to do much better games on Amiga than on PC, Apple and Atari - it its time.
The reason for this was that the Amiga had "advanced" hardware compared to them.

SDL is a one size fits all approach - which does the same on any system and never uses any of the advantages of the Amiga hardware.

In my experience to make a good Amiga port - you want to really write the game to use as much of the Amiga DMA system and Amiga HW features as possible.

1) You need joypad and mouse input.
These you can of course write from scratch in just a few lines.

2) You need to open a chunky screen, and this again can be done in few instructions.

For AUDIO is assume you want to go directly to the 16bit AMIGA DMA hardware of Arne audio chip - which DMA powered and super fast.

So why would we want to link a 1000 KB SDL monster into our game?
If we can do the stuff we want to with very little code ourselve?

I actually never understood why someone would want to use SDL to access OpenGL in
a game. Why not use OpenGL directly?

For a 2D game it depends. Depending on the nature of the
game as you showed with the ongoing Robin Hood game
SDL might be a severe performance penalty compared to
clever usage of sprites etc. in other titles even 2D it
might make no difference.

But again - for 3D there is no alternative to OpenGL.
Especially not if you work on games using standard engines.
If you have several games on the same engine you do not
want to do the same adaptations for the same engine
several times again especially if it means no advantage.

Also the Amiga standard for 3D is Warp3D and MiniGL.
To do it the Amiga way would be writing a Warp3D driver,
no matter if 68k or PPC.

In 3D having a hardware is not all. You also need an API.

Open a screen with hacking the HW? That’s unbelievable “ugly”.
Yes it can be done and it is not so hard work, but since the 90s
I am using a combination of intuition and cyber graphics there which
has the beauty that the same code runs on any Amiga system,
any cpu platform.

As to input devices which you mentioned in your other port
i usually use AmigaInput (developed by myselves ;)). Of course
for the Vampire i directly access the chipset as no AmigaInput
there but it is again a bit ugly (AmigaInput for OS4, hardware
Hack for Vampire, lowlevel.library for other 68k). Of course
you could use SDL for a catch-them-all but using SDL just
for input devices (and audio i guess) only? That’s
also a bit ugly i guess and i never did that.

Again - the issue i addressed is not about SDL.
It is about OpenGL to which there is (asides maybe
for completely self-developed games) no alternative.
And even for those an established 3d standard is the
advantage, no matter if OpenGL or Warp3D (personally
I prefer GL as W3D is just a lowlevel 3D library without
matrix/transformation handling etc).

And of course it is especially silly to use MiniGL through
Wazp3D but not have Warp3D to do it through the already
available physical 3d hardware. That’s just silly.

For the vampire there are basically three options:

A) implementation of Warp3D
B) an “own” gl on top of maggie.library as i currently try
C) convince wazp3d author to add maggie support (i do not know him, no idea if feasable)

Best regards,
Steffen

Currently it is far enough to do a drawing
Cube in OpenGL code. If i do some of the
Matrix manipulation code directly in gl it
flickers (if i do the same directly manipulating internal
structures - bresking the gl - it does not
Flicker, probably my matrix code, stuff
like glRotate etc has a bug somewhere).

I am unsure if there are further bugs in
the matrix code, likely.

A lot of gl things (blending, alphablending etc)
Are currently not supported by Maggie. I
currently implemented them in software but
this is all untested and might comtain bugs
(And/or be unbearable slow for some features).

Gunnar told me though it should be no problem
to add some of the missing features to Maggie,
He has been very helpful ;)))

My code is publicly available under an opensource
licence you could have a look (i still have
to push the last changes to the git, note the
code needs some recent changes by Morten
to the maggie.library includes where i am not
sure if they are public yet).

Actually it would be great if someone else
had a look still.

And yes OpenGL is some work even a limited
Version (i am not talking of full GL, but something
enough for certain games).

Note the wipeout stuff would still need a bit adaption,
It is on top of OpenGLES (available on OS4 but it needs
Shader hardware) - but i think the changes would be small.
For example for OS4 the code differences i have for the
MiniGL and GLES renderers for H2 and Q2 are minimal to
each other it is mainly to which library is linked and init
and exit code different (open screen and stuff).

For other games (think q2 etc) it might simplify a lot.
And it is doable. Hyperion did MiniGL in 2000 to port H2
and Shogo ;)

Still i think the “perfect” approach would be a Warp3D Driver
and use MiniGL (would still be Hyperion MiniGL, not
MiniGL V2 but that is enough ;))

Best regards,
Steffen

I am interested to take a look into it. Where do I find the repo ?

I will update the repo with the latest code somewhen
later today (the version on there at the moment is not really
functional).

Can i reach you also by email?

Thanks, anyways!

Best regards,
Steffen

"I'll do" as in "I recommend/I'd do" or as in "I will do the implementation" ? ;-)

If the second one - that would be really great ;-)

Best regards,
Steffen

Hello
I am Wazp3D author
I have a Vampire stand alone +
I made some tests on the Vampire to port Cow3D with a cpu renderer but it was slow, too sloooow to be usable
For the last two years I didnt coded anything (unemployed, depression,etc...) anyway I think that using Maggie as renderer for WaZp3D will not be too difficult

I didnt do it myself as my Vampire is no more updated (dont have a core with maggie)

Wazp3D use a simplified driver called soft3d.library
This driver was firstly developped to give accesse to native cpu software rendering calls inside WinUAE (so the name soft3d) but it has been adapted since to use various hardware renderered libraries (TinyGL, OpenGL, Mesa, Composition)

Sooo adapting soft3D.library to use Maggie is really the simpler way as this library got very few functions to recode

Sooo for resuming: if you have a working soft3d.library using Maggie then you will have directly a working WaZp3D/MiniGL/StormMesa with no additionnal coding

Also
if someone is in Paris and can help me to setup/update my Vampire for coding for Maggie
Will need some documentations or source code especially for setting up zbuffer, textures, screen buffer as the available maggie registers description give no hints about this part
idem for maggie.library functions

Also there is two compatibilities issues for Maggie vs GL

GL interpolate between two RGBA colors when drawing a pixels segment (multi colors lighting) but Maggie use only one RGBA color and interpolate only the light level

Maggie use only compressed textures but GL can setup normal textures (like an RGBA pixels rectangle) so we will need additionnal code (not from me) to do the normal to compressed conversion

Ah, sorry, i did not know your name.

I know your software Wazp3D of course, very
impressive software!!!

And i absolutely agree if you could write a driver
for Warp3D using Maggie that would of course solve
the problem. Thanks for your offer to help!

That would limit my task to porting my MiniGL renderer
of my game to 68k ;) and would give the same option to others.
And much better than doing a new gl implementation from
scratch!

About your problem to get your vampire up to date,
maybe Gunnar can help there?

I am btw reachable by email at tirionareonwe@gmail.com 
The texture conversion is handled (not all possible formats
but the 32 bit formats).

Blending modes and some other stuff will be an issue but i guess
this could be done “for now” in software?

Best regards and many thanks,
Steffen

Is there any way to contact you (by email or discord or something like that) ?

Thanks in advance.

Best regards,
Steffen Haeuser
tirionareonwe@gmail.com <- my email address, feel free to write me

hi, first one :-)

Thanks. I sent you an email.

Steffen
tirionareonwe@gmail.com