BOUNTY for AmiDARK Engine source code release.

[AmiDARK]

A new bounty is setup concerning the AmiDARK Engine.
Here are the details concerning this bounty :

Description
This project aims to collect sufficient funds (at least 2000 Euro) to release the source code of the AmiDARK Engine (Current 2D build 0.9 with partial 3D support, AmigaOS4 & MorphOS) for free use under the MPL licence, the Mozilla Public Licence.
 

About The AmiDARK Engine

AmiDARK Engine is a Game Development Kit for Amiga computers and compatible systems. It is released as a .a library containing .o objects with all functions.
It currently runs on AmigaOS4 & MorphOS but, if the bounty is completed successfully, there are plans to try to make it become compatible with AROS & AmigaOS 3.x as well.
Initially, the AmiDARK Engine was developed to bring a game development kit to Amiga systems that is compatible with the DarkGDK product from TheGameCreators (and later, with Dark Basic Professional with an integrated development environment (IDE) to be set up after the completion of the GDK).
 

Current Development State

-Basic2D Command set, which covers various 2D operations like dots, lines, triangle, box, circle, elipses.
-Basic3D command set, which provides custom 3D model loading and display in a 3D environment
-Bitmap command set, which implements virtual (hidden) bitmaps to precalculate graphics
-Camera3D command set, which handles the camera movements in the 3D world.
-Core command set, which handles system commands
-FileIO Command set, which handles file reading/writing
-Image2D command set, which handles 2D image loading and displaying on screen.
-Input command set, which handles mouse and joystick handling
-Light3D command set, which provides mechanisms to control lighting in the 3D world.
-Matrix3D command set, which is used to create some sort of 3D terrains (not started)
-Memblock command set, which deals with memory block handling.
-Music command set, which handles the use of music in various file formats (currently .mod)
-Setup command set, which handles basic display controls
-Sound command set, which enables the loading and playback of sounds.
-Particles3D command set, which is used to create 3D particles (not started)
-Sprite2D command set, which is used to create sprites (developed to add compatibility with DarkGDK)
-System command set, which provides system and memory functions
-Text command set, which handles the output of on-screen text in an AmiDARK Engine application
-Vector3D command set, which contains various mathemativs functions.

The current build contains a total of 705 commands / functions out of 1137 that had originally been planned. The 2D engine itself (without 3D) contains 476 commands and functions out of 484 that had been originally planned.


Technical Information

-The engine was rebuilt and the main "render system" is now able to handle priorities for the various rendering methods (Basic2D, Image, Sprites, 3D, Plugins).
-An additional plugin can be added in a "slot" like AmosPRO did or as an "unlinked" plugin.
-An additional plugin can add its own render function to display what is needed (FX2D plugin shows how this works).
-The engine has been developed in a way to make porting between Amiga-compatible platforms easier. All system/ OS functions are wrapped in specific files. Support for a new OS will have to be added there.
-The engine contains a partial HTML documentation explaining how the commands / functions work (632 commands / functions done)
-The engine contains an easy-to-use method to allow specific plugins or commands to access to functions / commands from other functions set.


Project Requirements

-The source code of the AmiDARK Engine is developed under AmiDevCPP (PC) so everything has been set up to work directly without any changes under AmiDevCPP
-Compiling for AmigaOS4 will require the AmigaOS 4 Release 53.20 Software Development Kit from Hyperion Entertainment.
Compiling for MorphOS will require the latest MorphOS Software Development Kit from the MorphOS website.
-With relatively few changes, the AmiDARK Engine can be compiled directly under AmigaOS4 (via CodeBench and the AmigaOS4 Software Development Kit Release 53.20 from Hyperion Entertainment).
-With few changes, the AmiDARK Engine should also compile directly on a MorphOS system although this has never been tested due to a lack of access to a sufficiently fast MorphOS-compatible computer.
-Sub-libraries, such as ptplay.library, ptreplay.library, freetype, and FTGL, are out of the scopie of this bounty project as they are not my property and can be obtained easily on the internet for various Amiga and Amiga-like platforms.


Optional

-If this project is successfully funded (by raising a minimum of 2000 Euro), and as long as the resulting ports stay true to the original version of the AmiDARK Engine in terms of user experience and command sets, Frédéric Cordier plans to share all source code that he will develop himself for future versions of the AmiDARK Engine for free
-If the funding level reaches an amount of 2200 Euro, The author, Frédéric Cordier plans to acquire a MorphOS computer with a valid MorphOS licence to help maintain the compatibility and port of the AmiDARK Engine for MorphOS.
-If the funding level reaches an amount of 4600 Euro, the author, Frédéric Cordier plans to acquire an X1000 or a succeeding model with a valid AmigaOS4 licence to help optimize the software for use with A-Eon's hardware products.

You can contribute to this project directly here :
http://www.power2people.org/projects/amidark/

[wrath of khan]

I guess classic Amigas are too slow for this engine?

[AmiDARK]

Hello,

Technically you need 3D hardware because the engine handle 3D.
That mean you need "at least" a BlizzardPPC + Bvision (or other 3D video card) + Mesa (OpenGL) to be able to use the engine on classics if, it is ported to AmigaOS 3.x .

Regards,

[biggun]

Wow, this sounds interesting.
Looks like a lot of work went into this.

I would like to learn more about this engine.
Does the engine allow Softrendering of 3D textures?
Dos the engine provide mechanism of ZBuffer and Bi/Tri-Linear mipmapping?

[AmiDARK]

Hello,

The AmiDARK Engine uses OpenGL for 2D and 3D rendering.
It (then) also uses Z-Buffer and, you can choose the OpenGL filtering (linear/mipmap/nearest/etc.) methods to render 2D and 3D.

If you want to learn more about the AmiDARK Engine,
Feel free to jump at : http://www.amidark-engine.com

There are two videos on youtube showing the AmiDARK Engine : https://www.youtube.com/playlist?list=PL6Q17EL65z6HFt3HfZ_C_6Cb9bPGb7RDS

Kindest Regards,
AmiDARK

[biggun]

OK thanks for the answer.

Do I understand this right.
Right now it does not work on OS 3-classic?

Will it be much work to get it running on OS3

[wawrzon]

@gunnar

the question rather is what program would you run via this engine if it was available for amiga. when it comes to 3d on amiga there already is an opengl implementation called storm mesa all along the sources and examples available from aminet. there also is software that takes advantage of it.

so the potential alternative to assumably
amidarkengine>minigl>warp3d>hardware (unfinished, no software available ive heard of)

is

storm mesa>warp3d>hardware (tested, available for years, existing applications)

so i dont understand why not to use the later. in case there is custom hardware involved you will in any case need to write a warp3d driver, because minigl also depends on/calls w3d functions, while not being much if any faster than storm mesa, but rather slightly incompatible to opengl because of some changed (init) function names. now have luck with getting documentation on w3d to write a driver, except matthey and alain may maybe have some hints. personally i think the easiest would be to make a hardware accelerated backend for alain thelliers wazp3d.

[AmiDARK]

Biggun :
You're right.

As I did not find some library I use on 3.x, the AmiDARK Engine is currently "not" compatible with AmigaOS 3.x
What I think is best should be to remove FreeType & FTGL to use directly intuitions/graphics for text output in the AmiDARK Engine
But doing this will require to remove the GLUT extension and create display directly with Graphics library.
Removing GLUT will also require to rewrite Mouse/keyboard input because it currently uses the GLUT system.

Here is what I think, that must be done to makes it compatible with 3.x
Excepted if we find a GCC compatible with 3.x and not too old, and FreeType / FTGL for 3.x..

@Wawrzon :
1. The AmiDARK Engine is further easier than MESA and any other language available :
For example, to open a display, you only have to do this :
deSetDisplayMode( 640, 480, 32 );

If you want to load an image :
deLoadImage( ImageIndex, FileName$ );

Display an image on screen :
dePasteImage( ImageIndex, X, Y, FilterMode );

It's really "easy like basic languages" but ... directly with the power of C/C++ languages!

2. Concerning Hardware :
You're wrong concerning Warp3D driver.
if I remind correctly, StormMesa contain OpenGL Commands so I don't have to rewrite the engine for this, simply include the StormMesa includes instead of the MiniGL ones. The OpenGL commands/functions used in the AmiDARK Engine will be automatically be mapped by the compiler (when compiling the .o/.a files) to StormMesa/OpenGL.
When I write 3D/2D for the AmiDARK Engine, I directly uses OpenGL 2.0 specifications commands/functions.
It's automatically compatible with all 3D environments compatible OpenGL 2.0
For example, I have modified NOTHING to makes the AmiDARK Engine compatible to MorphOS excepted including the TinyGL (MorphOS) headers instead of the MiniGL ones (AmigaOS4).
Concerning 2D/3D it will be the same concerning AROS & Amiga OS 3.x
I will only have to include the correct headers, check that all the OpenGL commands/functions exists in that OpenGL implementation and it should be ok.
There will maybe be only minor changes to do but the functions names should globally be the same. If not There will be "os selection" pre-compiler stuffs to add for these functions... Not too long to do I think.

The only things that really need to be tweaked up, are the "OS" functions like the Graphics/Intuition/Dos, etc... Some commands/functions that exists under AmigaOS4 are not available on AmigaOS3 & AROS or, don't have the same arguments needs.
But all these functions are "wrapped" in specific files so, the port will only concern "Os Specific Files" ... not the engine itself . (for example on some Amiga OS, dos library requires APTR when on others it requires INT/LONG)...

I hope I have answered your questions in the way you wanted to know.

[wawrzon]

replacing freetype, ftgl and glut seems a lot of work. freetype is available on amiga, i dont remember if only as part of afa, but i remember having linked against it. i also might have compiled ftgl as a static a library, but im not sure anymore. what concerns glut it is a part of mesa even if it may be missing on minigl.

what concerns linking against mesa rather than minigl, yes it should be possible, just it woulnt be just linking against other header i guess. remember also os4 minigl has been extended by hans, while mesa was not and certainly amiga(68k) minigl contains only a subset of both.

i dont discuss that basic style coding may be easier for noobs (like me) though the sole availability of this option doesnt effectively make people program anything, like for instance amiblitz example teaches us. although it seems a good option i can count programs done in amiblitz on fingers of one hand.

now, while you would link amidark against storm mesa and wait for people to write software with it there are still numerous opengl opensource stuff that might have been ported over and simply linked directly against mesa headers, been there, done that. im just too dumb and the hardware s too limited to make it work really well.

and about the hardware driver im still right. i think i know what gunnar aims for, as he isnt interested in a regular offshell 3d hardware but rather something like fpga core, he would have to write warp3d driver for, since whether minigl, storm mesa or your frontend all of them depend on w3d to hit the hardware.

[Hans_]

what concerns linking against mesa rather than minigl, yes it should be possible, just it woulnt be just linking against other header i guess. remember also os4 minigl has been extended by hans, while mesa was not and certainly amiga(68k) minigl contains only a subset of both.

StormMESA should implement the full OpenGL 1.2 specification (or whatever the version was when it was created. The additions to MiniGL were for stuff that MiniGL missed.

i dont discuss that basic style coding may be easier for noobs (like me) though the sole availability of this option doesnt effectively make people program anything, like for instance amiblitz example teaches us. although it seems a good option i can count programs done in amiblitz on fingers of one hand.

AmiDARK's advantage is much more than BASIC style coding; it's a game engine. So, you don't have to deal with all of the low-level stuff like loading & rendering objects, etc. If you use OpenGL directly, then you would have to write all of that stuff yourself. That's a lot of work.

As to getting people to use it, the following would help: providing good tutorials, documentation, example code and a large library of free to use models, sounds, etc. There are no guarantees that many people will use it, but I think that it provides a good starting point for beginners. It makes it easy to create good looking & sounding results quickly, which can be fun and motivating.

now, while you would link amidark against storm mesa and wait for people to write software with it there are still numerous opengl opensource stuff that might have been ported over and simply linked directly against mesa headers, been there, done that. im just too dumb and the hardware s too limited to make it work really well.

MiniGL was originally created on the 68K, because StormMESA was on the slow side. From what I heard, it was significantly faster. If MiniGL 1.2 provides all needed features, then it might be better to use that over StormMESA.

Hans

[wawrzon]

MiniGL was originally created on the 68K, because StormMESA was on the slow side. From what I heard, it was significantly faster. If MiniGL 1.2 provides all needed features, then it might be better to use that over StormMESA.

yes, thats what ive been told all along. few years ago i modified the gl examples to be compil and run-able against minigl and mesa side by side. a simple measure, because minigl inits differently to the standard. blame it on my inability, but funny enough it occurred minigl wasnt much if any faster than mesa. btw, im happy to be proven wrong.

also the subset of features minigl provided in comparison with mesa didnt allow to compile anything i can think of. im pretty sure if sm3.1 was ogl1.2 spec then minigl was a rather narrow fraction of it. may be different if amidark can live without all that stuff so far, still im not sure if there is anyone left in the so called amiga scene, who would program 3d games or apps exclusively no matter what easy it was.

that said i addressed gunnar post about specific 68k solution rather than general discussion about the engine.

[Hans_]

yes, thats what ive been told all along. few years ago i modified the gl examples to be compil and run-able against minigl and mesa side by side. a simple measure, because minigl inits differently to the standard. blame it on my inability, but funny enough it occurred minigl wasnt much if any faster than mesa. btw, im happy to be proven wrong.

Well, performance differences will depend on what you're rendering (and how). You might not notice much difference with simple examples like the gears demo, but a game with a full immersive 3D environment... Even so, any performance boost would depend on how the game rendered its graphics.

EDIT: IIRC, using manual locking in MiniGL can boost performance. This means that Warp3D is manually locked and unlocked, so that you minimise the number of times that this happens. Locking/unlocking Warp3D is rather expensive.

also the subset of features minigl provided in comparison with mesa didnt allow to compile anything i can think of. im pretty sure if sm3.1 was ogl1.2 spec then minigl was a rather narrow fraction of it. may be different if amidark can live without all that stuff so far, still im not sure if there is anyone left in the so called amiga scene, who would program 3d games or apps exclusively no matter what easy it was.

AFAIK, MiniGL's subset of the OGL spec was whatever Hyperion's game ports (Quake II, Freespace, etc.) needed.

Hans

[wawrzon]

Well, performance differences will depend on what you're rendering (and how). You might not notice much difference with simple examples like the gears demo, but a game with a full immersive 3D environment... Even so, any performance boost would depend on how the game rendered its graphics.

EDIT: IIRC, using manual locking in MiniGL can boost performance. This means that Warp3D is manually locked and unlocked, so that you minimise the number of times that this happens. Locking/unlocking Warp3D is rather expensive.

right, that might be where the difference have been. once i have guessed the dynamic linking of sm3.1 might steal some performance yet, but likely it wasnt the case.

AFAIK, MiniGL's subset of the OGL spec was whatever Hyperion's game ports (Quake II, Freespace, etc.) needed.
Hans

right again. so it wasnt meant for general purpose. best would be both of both worlds, probably for os4 as well as for amiga.. we are left with what we have though.


..so far seems my points still stand. minigl may be faster (marginally or not, we must rely on word of its programmers that happened to be proven wrong in the past, perhaps except of you, hans;)) but its not open and therefore it isnt extendable if need be. i think it rules it out for amiga (68k). neither way gunnar would need his w3d driver

[Hans_]

..so far seems my points still stand. minigl may be faster (marginally or not, we must rely on word of its programmers that happened to be proven wrong in the past, perhaps except of you, hans;)) but its not open and therefore it isnt extendable if need be. i think it rules it out for amiga (68k). neither way gunnar would need his w3d driver

MiniGL is open. The source code is available for both the OS4 version and the old 68K one. If you want the 68K version's source-code, then just download minigl.lha from aminet.

Regardless, yes, 3D drivers are needed. In theory you could bypass Warp3D, and build your HW driver directly into a modified version of MiniGL (so long as you shared the code as per the license).

Hans

[haywirepc]

looks cool to me...