Amiga.org
Amiga News and Community Announcements => Amiga News and Community Announcements => Topic started by: AmiDARK on May 28, 2014, 06:47:16 PM
-
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/ (http://www.power2people.org/projects/amidark/)
-
I guess classic Amigas are too slow for this engine?
-
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,
-
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?
-
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
-
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
-
@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.
-
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.
-
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.
-
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
-
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.
-
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
-
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
-
..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
-
looks cool to me...
-
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.
ok, i stand corrected here. then if someone backports the os4 improvements it might be easier to keep amidark compiling against it.
-
Wawrzon :
When I code the AmiDARK Engine, I don't use the MiniGL documentation.
I only use official OpenGL 2.1 documentation available here : http://www.opengl.org/sdk/docs/man2/
I use directly gl......, glu...... & glut....... functions.
That mean that if Storm Mesa is 100% compatible with the official OpenGL 2.1 specifications, the AmiDARK Engine should be compatible with Storm Mesa without any changes concerning the 3D part.
I've checked with the StormMesa developer files available at aminet : http://aminet.net/package/util/libs/StormMesa_Dev
and StormMesa available at aminet : http://aminet.net/package/util/libs/StormMesa_LibsPPC
There is written in the amigaguide file : The GL 1.2 API is supported
We should check which commands/functions that exist under OpenGL2.1 API are not available under OpenGL 1.2 API...
Does someone have the informations concerning OpenGL 1.2 API ?
-
Since AmiDark already supports AmigaOS4 and MorphOS I wouldn't worry about the OpenGL 2.x support. Both MiniGL and TinyGL are OpenGL 1.x implementations.
-
@BSZili & Others :
To show that the AmiDARK Engine can be ported to AROS, I tried to make the changes in the current build of the AmiDARK Engine to make it compatible with AROS i386 (because the SDK Pack available for AmiDevCPP own both FreeType & FTGL).
All the objects (Basic3D, Camera, Core/Render, Images compiles correctly for the AROS i386 version.
I have already fixed the main "OS" functions (in the dedicaced files for OS compatibility using some sort of Wrapping method).
I have some more changes to do to other files to make it fully compiles under AROS i386.
(I must found PTReplay library for AROS i386 or I'll put the ProTracker support "away" for these tests)
After this, I'll release a compiled technical demo of the AmiDARK Engine compiled for AROS i386 and I hope people will try it (and I hope it will work on AROS i386).
I know it was one of the objectived of the bounty to help port AmiDARK Engine to AROS but, due to the answer of some peoples on various forums, I think that making an exemple should help reassure people on this project.
Regards,
AmiDARK
-
Thanks for your effort, I hope it will help to spark some interest in the AROS camp to the bounty.
-
A lil more than 1 month to go for the bounty date for this games engine.
http://www.power2people.org/projects/amidark/
-
Doesn't look like it will reach it's goal. But I'll chip in a little if others too say they will in this thread.
-
I donated early on, but since the AW.net thread sprung to life too Ill link the discussion
there if some of you only reads a.org and not aw.net;
http://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=39012&forum=15&start=80&viewmode=flat&order=0
http://www.power2people.org/projects/amidark/
I guess its worth noting Hans's comments about the merits of this engine, and how simple it would make game creation, demo making etc. Im sure developers could find all kinds of use for the engine as they familiarise themselves with it.
Link to the mainpage of Amidark;
http://www.amidark-engine.com/
Link to a codesnippet to illustrate the power of its design;
http://www.amidark-engine.com/spip.php?article10
If you read Hans's comment, what requires 1000+ lines during normal developent, can be done with 2-3 lines in Amidark.
-
Doesn't look like it will reach it's goal. But I'll chip in a little if others too say they will in this thread.
Donation made. Your turn?
-
My turn :)
-
I guess its worth noting Hans's comments about the merits of this engine, and how simple it would make game creation, demo making etc. Im sure developers could find all kinds of use for the engine as they familiarise themselves with it.
Link to the mainpage of Amidark;
http://www.amidark-engine.com/
Link to a codesnippet to illustrate the power of its design;
http://www.amidark-engine.com/spip.php?article10
If you read Hans's comment, what requires 1000+ lines during normal developent, can be done with 2-3 lines in Amidark.
One point that I don't think I got across properly, is that a game engine like AmiDARK would give those who would like to create a game but are lacking in coding skills a chance to create their game. It lowers the barriers to entry.
Hans
-
One point that I don't think I got across properly, is that a game engine like AmiDARK would give those who would like to create a game but are lacking in coding skills a chance to create their game. It lowers the barriers to entry.
Hans
Don't be kidding. Those who are lacking the coding skills won't become a game designer or just a software engineer no matter if they chose Basic, Amos, Logo or any other simplified and easy to learn language.
The dreaded attempts to create something usefull with Amos or SEUCK or any other low end game engine (adventure construction set) are history now.
AmiDark is proprietary, uncompareable and incompatible to all other. How to port C code to or back if you need cross-platform developement?
My opinion about this totally overpriced engine is, it is not worth a single dime. I really wonder what pledgers had in mind when donating. Are they expecting any game developed with it ? Released before end of century?
-
Don't be kidding. Those who are lacking the coding skills won't become a game designer or just a software engineer no matter if they chose Basic, Amos, Logo or any other simplified and easy to learn language.
Utter total BS. Nobody is born with coding skills. There was a time when I was lacking in coding skills too, but I've become very good at it.
I started using BASIC on the C64, but quickly wanted something better (performance sucked). Back then, I could write simple programs and would have liked to create games. However, I lacked the ability to do the bare essentials like load and display images, move sprites, play sound effects and music, etc. A "low end game engine," As you put it, would have been exactly what I needed to get started. It would have helped me a lot.
I remember a friend had AMOS, and with a few lines of code we could create stuff way more impressive than anything that I'd ever done before. That was awesome! It lowered the barrier to entry for creating games/demos. No, we never released anything, but it certainly helped me to learn how to write software. It was also fun.
What something like AmiDARK, Hollywood and AMOS provides is an easy way to get impressive results quickly. That helps get people started, and also helps boost the motivation needed to keep on working, learning, and improving. No, not everyone will go on to become a game designer, but it will provide those who are genuinely interested with a good starting point. Plus, creating stuff is fun, even if the end result isn't always release grade.
The dreaded attempts to create something usefull with Amos or SEUCK or any other low end game engine (adventure construction set) are history now.
Of course the first attempts that anyone makes at a new task are going to "suck." However, with practise people get better. The goal for a rookie is to learn and enjoy the process of getting better. You have no idea how many of the people who made "dreaded attempts with low end game engines" now work in the gaming industry.
Of course, if you tell people how much you hate their "dreaded attempts," then they're much less likely to try again and make something better. Way to go, Grinch!
AmiDark is proprietary, uncompareable and incompatible to all other. How to port C code to or back if you need cross-platform developement?
The bounty is to open-source it. It closely mirrors the DarkGDK API. You would have known this if you had bothered to look into it before spouting your opinion.
Hans
-
Don't be kidding. Those who are lacking the coding skills won't become a game designer or just a software engineer no matter if they chose Basic, Amos, Logo or any other simplified and easy to learn language.
The dreaded attempts to create something usefull with Amos or SEUCK or any other low end game engine (adventure construction set) are history now.
AmiDark is proprietary, uncompareable and incompatible to all other. How to port C code to or back if you need cross-platform developement?
My opinion about this totally overpriced engine is, it is not worth a single dime. I really wonder what pledgers had in mind when donating. Are they expecting any game developed with it ? Released before end of century?
Since AmigaDark engine is developed since 2009 (September is the first blog entry, It has maybe been developed earlier...)
Based on that data, the cost per day is 1.09 Euros. Too expensive you're right.
Kamelito
-
Since AmigaDark engine is developed since 2009 (September is the first blog entry, It has maybe been developed earlier...)
Based on that data, the cost per day is 1.09 Euros. Too expensive you're right.
Kamelito
The inventors of the fantastic steam powered toothbrush started their project in 1912. Price is 40580.- €. That is just 1,09 per day.
What a bargain. Think of all the electric power you save. :hammer:
Face reality. Gaming is more then watching still images.
Today it's 3d accellerated graphics, postion based audio, multiplayer and/or makes use of steering wheels, force-feedback controllers and the whole shebang.
Now, there are classic and ng amigas. What type of hardware do those machines support to make gaming a thrilling experience or fun?
Furthermore: it's my opinion about the price. Posting was about the lack of capable coders. Talented coders don't tend to drop from the sky.
Experienced coders might be able to set up their own collection of macros and wrapper functions.
And last point is, it doesn't make coding as easy as pie just because you save some lines of source code. You need lots of experience to master any high level language for any kind of project that is as time consuming as game developement.
Me thinks, your little math was just to fire up the heat for the next flame war, that would distract everyones attention. There is no gaming platform that demands such a "game engine". There is no project in the pipe using such a game engine. That would be a good reason to keep this alive, a game that is worth naming it a game and that is build upon AmiDark and highly anticipated.
Name one, and i am convinced.
-
Don't be kidding. Those who are lacking the coding skills won't become a game designer or just a software engineer no matter if they chose Basic, Amos, Logo or any other simplified and easy to learn language.[.quote]
Utter total BS. Nobody is born with coding skills. There was a time when I was lacking in coding skills too, but I've become very good at it.
I started using BASIC on the C64, but quickly wanted something better (performance sucked). Back then, I could write simple programs and would have liked to create games. However, I lacked the ability to do the bare essentials like load and display images, move sprites, play sound effects and music, etc. A "low end game engine," As you put it, would have been exactly what I needed to get started. It would have helped me a lot.
I remember a friend had AMOS, and with a few lines of code we could create stuff way more impressive than anything that I'd ever done before. That was awesome! It lowered the barrier to entry for creating games/demos. No, we never released anything, but it certainly helped me to learn how to write software. It was also fun.
What something like AmiDARK, Hollywood and AMOS provides is an easy way to get impressive results quickly. That helps get people started, and also helps boost the motivation needed to keep on working, learning, and improving. No, not everyone will go on to become a game designer, but it will provide those who are genuinely interested with a good starting point. Plus, creating stuff is fun, even if the end result isn't always release grade.
Of course the first attempts that anyone makes at a new task are going to "suck." However, with practise people get better. The goal for a rookie is to learn and enjoy the process of getting better. You have no idea how many of the people who made "dreaded attempts with low end game engines" now work in the gaming industry.
Of course, if you tell people how much you hate their "dreaded attempts," then they're much less likely to try again and make something better. Way to go, Grinch!
The bounty is to open-source it. It closely mirrors the DarkGDK API. You would have known this if you had bothered to look into it before spouting your opinion.
Hans
+1
-
@Calimeiro
Haha, your post is so ridiculous as to be hilarious.
Going by your "logic" no language/engine is ever worthwhile, because when theyre first created there's no good projects that exist, and people need to learn to use them.
Do you not see the chicken/egg scenario?
Even when you've had details pointed out to you you've chosen to ignore them so you can continue your nonsense rant. Did you miss the gdk reference? You asked for an example, but ignored that detail. You also question cross platform development, even though the answers to that are within the bounty.
Near as I can tell you've simply decided upon an opinion based on absolutely nothing other than the misinformation you've concocted in your head and run with it.
-
Everybody, please help reach the goals of this bounty.
http://www.power2people.org/projects/amidark/
-
@calmeiro
Sure 3D...not really in the mobile market. Even Apple saw that 60% of most apps are games and many 2D games that's why they developed Sprite Kit to make it easy to develop 2D games but I'm sure they're wrong...
As for Calimeiro the cartoon I remember it because it was always complaining ie the character, good choice for your nick.
kamelito
-
I have donated a lot of money over the years to p2p through their general fund. I'm prepared to ask them to divert a good amount of that money to this bounty if the goal looks reachable.
So open up your pockets please. If everyone donates a little over the next week I'm pretty sure I can put the decisive weight of the scale :)
-
Making a one time only bump here. If we get a little more money in there I should be able to make it pass the 1500€ line. When we reach 1200€ I think.
-
Face reality. Gaming is more then watching still images.
Yeah, it's about the game play.
-
Increased my donation ^^
-
AmiDark Engine
Donations: €1205
Raised 80% of €1500 goal.
Going reasonably fast now ^^
Been some updates to the bounty page;
http://www.power2people.org/projects/amidark/
-
I see Amidark have updated the page a bit more.
Donations: €1440
Raised 96% of €1500 goal.
-
I think that the words from the great Hans have helped to this bounty. Thanks. I think It is a necessary tool.
-
I kept my promise and transferred 230€ from the general fund. 250€ in total :) The rest is up to you guys ;)
-
:) Indeed.
If everyone updates their donation with just a few euros it will easily pass the minimum.
Still, I feel very confident the bounty will be met before the end date.
Some detailed info about development status of the engine;
http://www.amidark-engine.com/spip.php?article38
-
In other news, still at 45 Euro to go ^^
-
I just donated 25.00 euros.
if it was possible to port it to classic systems that would be cool.
-
I just donated the other 20, so that should be it once Power2people updates
-
Raised 100% of €1500 goal.
Good stuff :)
-
Yes. Yay us. It looks like a cool engine.
-
Thank you all for your support.
Effectively, I also think that hans words helped a lot ! :p
Now, the source code must be reviewed to see if it meet the bounty requirements.
Regards,
AmiDARK
-
All donors have been contacted regarding the cancellation of the fundraising effort.
If you are a donor but have not received an email regarding your donation, please check your spam folder. Thank you.
Despite the cancellation, we would still like to thank everyone who contributed financially to support the project. Furthermore, we would like to thank all developers who spent any time inspecting or improving the source code during the public review process.