As usual:

A) Everyone is right in what they are saying in their own line of talking
B) No one makes any sense when discussing with others

A) True: the Amidark Engine is buggy and bears no architecture
B) True: Amidark is entitled to the bounty. He open-sourced the software and that's it.

The community willingly paid some money for something that has close to no value.
They knew it from the beginning: a 1-man project 6 years in the making, with no application.
In pure "Amiga NG" style: something that was pointless from the start, gets made even more pointless by all the community drama.

Hi! Bye!

@AmiDARK
Quote:

So, with all your arguments. It's maybe time to "contribute" with your true knowledge ? Do you have a better algorithm for elipse/circles drawing ? It will be really appreciated.

If you'd carefully read my reports on that bug (and others) you'd probably find out that I already provided more than enough detailed information so that even coders as good as you could fix it with ease.
If you'd care about your customers you could have fixed all those issues by now yourself easily
You can be pretty happy about what I already handed to you on a silver platter.
But I think at least some minimal work should be left to the engine's author, don't you agree? And after all you'd not learn anything if you'd just copy'n'paste something (like with INTERNAL_CalculateNormal, which you said you blindly copied from somewhere, not realizing that you also copied a bug; no, no, better do it yourself to learn something).

@lionstorm
Quote:

it crashed here with a guru. when launched from shell and RAM, a window opens and then a crash (ISI) that can not get over.

Well, no wonder. Just as I tell you all the time: the whole thing is unstable and it's a matter of luck (or random RAM content etc.) if it crashs or not.

@AmiDARK
Quote:

Which Amiga platform SAM ? X1000 ? Which video card ? I must check : 1. In my dev diary what I changed from this release and that may cause the crash...

Why look around when you were already told the concrete cause and location of some bugs that may cause such syndromes? Hint: fix those first!

@Birbo
Quote:

What is your problem?

What's yours? Mine is that I constantly have to repeat explaining why things are broken here, since AmiDark continues to say "wrong, it's all stable".
Sorry, but plain wrong statements like that one following (you'll find lots of that kind) really leave me no choice than to re-try to hammer it into his head again and again.
Quote:

The truth is that you are wrong and the samples showing you the facts.

Quote:

I am really happy about every bug wich will be reported. But it is hard to understand what your goal is.

That's great! I explained my goals before. Just a short summary for you:
- I do those continueing reports because I was asked to
- and because I like to help fixing things, tell people how they can improve their skills
- and because I don't like when people are mis-selling things
- regarding the "tone": as being said, cause and effect. If you had followed the discussion you probably had realized that AmiDark is no innocent lamb here My tone was adjusted to match his attitude.

Quote:

AmiDark I can really understand you if you lose your nerves with Daytona675x.

Oh, I can understand him too But it's not my goal to make him happy, my goal is to show what's wrong with what he's doing and to help him, or somebody else who really wants to play with that code, to fix it - and to make sure that his wrong claims regarding my reports stand corrected. Naturally somebody with an attitude like him doesn't like that.

_________________
AmigaOS 4.1 FE (sam460ex Radeon 9200 / RadeonHD), MorphOS 3.8 (PowerMac G4 733MHz Radeon 9000), AROS (x86), A1200 (060 80MHz Indivision MK2), A500, A600, CDTV
Wings Remastered Development Diary

@Daytona675x

Incase it got lost in all the posts;

http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=39807&forum=15

The new feedback thread created by AmiDark.

@Yasu on aros-exec

"I'm a major donor (Johannes Genberg) and also a friend of Daytona. I've read the thread at AmigaWorld"...
"As for the bounty, from what I can tell, it's fulfilled."

http://aros-exec.org/modules/newbb/viewtopic.php?post_id=92673#forumpost92673

6 / 0

_________________
http://apps.amistore.net/zTools

@Daytona675x

AmiDark has changed his tone, so would you be adult and do the same? It is annoying also for other when two people are picking eachother. No doubt that you have been helpfull.

So change your tone and go there - >

http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=39807&forum=15

Please

@Daytona675x
Quote:

leave me no choice than to re-try to hammer it into his head again and again.

From the beginning you consider me as a noob and now, I will make things more clear
Be sure I don't like what I'll do as I hate to put my "ego" in front but your words forces me to reacth that point I don't like... And apparently "Ego" is something that lead you on several points. I think that your true objective are not really clear ... When I ask for "precise" help (for example with an algorithm for the circle/elipse drawing .. You feint/fake your answer ... I really have the feeling that, your true objective is to prevent the bounty from being paid ... And in this case your comportment is dishonest because now that the source code have been publicly exposed, I have no way to makes the engine source code being "closed" back.

And be sure that It will be a loss of time for you ... You will hammer nothing in my mind.
To be honest and objective, what, you call "stability" is in reality "Perfection".

So, to clarigy these words, In the past I worked for a company called HIP Interactive Europe, a video game distributor and I was at the Quality Assurance team... You know what it is ? That mean that I saw and worked on DEBUG for many commercial games... I was often considered as a "too precise debugger"...
(I was beta tester, not coder)

But, it's not this first point that is important, it's the one I'll detail now.
I saw game development from early alpha, to final release ... And be sure that a game is NEVER STABLE before we reach what we often call "Release Candidate" versions.
Why ? Simply because :
1. Alpha versions are versions where we add the product features. At this point many features are missing, some are done but not always complete nor fully functional.
2. Beta versions are versions where we TEST all features and check for their stability. At this point, the product can always have bugs, problems that may makes it crash.
Release candidate versions are versions where we finish the product, polish it and makes the latest checks.
Concerning the AmiDARK Engine, we are still between Alpha/Beta that mean that many things always are unstable, not available.
On that point mainly, I have fullfilled the bounty.
If you don't agree with this .. Then I consider that you are maybe not "as professional as you said" because you "lack of discernment.

So now to close the debate, I will be happy to get your help to make the engine progress, but now, it will be in the thread especially dedicaced to debug.

And ... Just at a last note ... From now, I will no more answer to you on that threat as I consider that even if you give informations for debug, your true objective is egotistic and negative.

Regards,
AmiDARK

Last edited by AmiDARK on 15-Jan-2015 at 06:44 PM.
Last edited by AmiDARK on 15-Jan-2015 at 04:56 PM.

@AmiDARK
Quote:

When I ask for "precise" help (for example with an algorithm for the circle/elipse drawing .. You feint/fake your answer

The answer is right here, just as I said.
Apparently you simply aren't able to spot it.
And if you check that post you will probably (well, maybe not) notice that I actually provided pretty detailed descriptions of what I found. More than detailed enough to derive a solution within seconds. Seconds.

Quote:

I really have the feeling that, your true objective is to prevent the bounty from being paid

I hate to repeat myself but you really force me to with almost every sentence you say:
Actually I explicitely said that this is of course not for me to decide. If people want to pay for your "engine", sure, why not?! But I want to make sure they get an unbeautified look at it. That's what a review should be about btw.
To use your words:
I really have the feeling that your true objective is to sugarcoat the extremely bad quality and not existing stability of your engine.

Quote:

And be sure that It will be a loss of time for you ... You will hammer nothing in my mind.

Yeah, I already found out that you're quite resistant to learning / accepting your faults. However you are quite good at saying that you are always right and others wrong without backing up your statements with facts. You are also quite good at complaining at other person's tone while being not a whit better. If you were that good at coding then your engine would probably be as stable as you say

Quote:

And be sure that a game is NEVER STABLE before we reach what we often call "Release Candidate" versions.

Yes, that's why serious people don't sell it at this point and don't pretend it was stable code.

Quote:

In the past I worked for a company called HIP Interactive Europe, a video game distributor and I was at the Quality Assurance team... You know what it is ? That mean that I saw and worked on DEBUG for many commercial games... I was often considered as a "too precise debugger"...

Oh god, I hope for that company's reputation that this is a joke And you are really the same guy who can't draw a circle, doesn't know how to compute a triangle's normal and believes there is no such thing as 0 in floating point arithmetics? Unbelievable!

But well, if that is true, then all those guys who said I shouldn't be too strict when checking your code because they thought you were a hobbyist etc. were wrong!
In fact we should start to really take the measurements as if you were a pro

With such a background there can't be any excuse for selling something that buggy.

Last edited by Daytona675x on 15-Jan-2015 at 05:30 PM.

_________________
AmigaOS 4.1 FE (sam460ex Radeon 9200 / RadeonHD), MorphOS 3.8 (PowerMac G4 733MHz Radeon 9000), AROS (x86), A1200 (060 80MHz Indivision MK2), A500, A600, CDTV
Wings Remastered Development Diary

@Daytona675x

Not nice

_________________
Sometimes we give people a lot of credit just because they’re writing nice sentences even if it isn’t adding up to much.

@AmiDARK

Quote:

AmiDARK wrote: @Jupp3 I know all these, but due to the "way it work" under DarkBASIC Professional, I currently cannot use something else than "glReadPixels".

Don't worry, in this rare case it's not "only us", it's too slow everywhere


Quote:

I must be able to : 1. Save the tiles pasted 2. Add the sprites over the display. 3. Display everything on screen. 4. Restore the tiles previously saved.

A bit more complex then.

Would something like this work then?
-Draw everything that isn't a sprite to fbo.
-Whenever a sprite is added, moved or removed (or similar), redraw background from fbo, followed to each onscreen sprite at current position.

Of course the downside is, it requires newer gl (guess only aros has it for now). Not sure if it's only s, some more restricted gfx cards might not be able to do it (but hey, there is already fallback for that!)

@Jupp3
To what I tested, I never managed to makes buffers works in OpenGL (on AmigaOS4 because I only had AmigaOS4 configuration for dev, MorphOS Efika was too slow)... Some peoples telled me they don't work (if my memory is good).
If someone have informations showing the contrary, I will be happy to modify this as it will makes Sprites compatibility more useable :)

@AmiDARK

Could be nice to include in your package :

-libAmidark.a compiled library with installation script (like you made for 0.9 in january 2014)

-fixed the LionStorm sample start problem (or if somebody else could compile and test a fresh compiled sample)

Last edited by zzd10h on 15-Jan-2015 at 06:50 PM.

_________________
http://apps.amistore.net/zTools

Here's the next chapter of my egoistic but fair code-review
Sadly I found quite some critical issues again. As always I provided very detailed descriptions of the respective issues, so that the people in charge can easily fix them if they want to.

Camera

As always: only critical and extremely awkward things get mentioned. There's much more, especially regarding efficiency, but this is not of interest to me now.

struct CameraType (hard-coded numbers, wrong usage of language features, inconsistent types)
Camera_Variables.c, Lines 10-20:
Instead of making each of that struct's 20 attributes an array of 8 entries and then declaring one global object of that type it should have been vice-versa:
define the struct with 20 simple plain attributes and then create an array of 8 camera objects.
This is not just a matter of taste or style. It is also a matter of memory-layout and efficiency. The way it is done here the attributes of camera X are not close by in memory, instead everything is kind of "interleaved". That would be beneficial if accessing lets say all cameras x-positions one after the other would be a common usage pattern. Of course that's not the case, the common pattern is to use one or many attributes of one single camera. Your code won't run faster if you constantly trash the cache that way.
And of course: don't use an hard-coded 8 for the reasons already explained before.
Another issue are the attributes CameraType.BackR, .BackG and .BackB. Those are defined as floats (which is okay) but later on they are actually sometimes used to hold integer RGB components in the range from int 0 to 255. More on this later.

CAMERA_Constructor (critical, missing attribute initializations)
CAM_Constructors.c
CameraType.Aspect[8] is not initialized. For cameras 1-7 this doesn't really matter since the mandatory call to DEMakeCamera before use will take care of this. Nevertheless this should be fixed to eliminate a chance for possible side-effects in case the code gets modified.
Camera 0 however is special and enabled inside the "constructor", so it can be used without DEMakeCamera (actually calling DEMakeCamera won't have any effect on it) and therefore it carries a potentially unitialized variable around. If you forget to use DESetCameraAspect(Ex) for camera 0 then you will get undefined behaviour.
BasicCamera.IsAutoCam, .BGDRed, .BGDGreen and .BGDBlue are not initialized neither.

DEPointCamera (can crash)
CAM_Functions.c, lines 245-246:
As already mentioned at the very beginning of this thread the functions FindXAngle and FindYAngle are (still) unsafe. Both may produce a division by zero. In this case here this will happen if the position fed into the function matches the current camera's position. Actually FindYAngle (and therefore DEPOintCamera) will also crash if just X1==X2 and Z1==Z2, because then both arguments to atan2 will be 0 which results in a domain error, no matter if the Y positions are different.

DESetCameraRange (critical,type mismatch)
CAM_Functions.c, line 303:
the camera-struct's near/far attributes are floats as it should be. But this function wants integer-parameters.
This can be considered a pretty critical bug, since defining good near / far planes may well be a matter of fractions.

DEClearCameraView (unexpected behaviour, type mismatch)
DEClearCameraViewEx (unexpected behaviour, type mismatch)
DEClearCameraViewEx2 (unexpected behaviour, type mismatch)
CAM_Functions.c, lines 325-353
As mentioned at the beginning CameraType.BackR, .BackG and .BackB are floats but here they are used like they were ints holding RGB components in the range from int 0 to 255...

DEColorBackdrop (inconsistency)
CAM_Functions.c, lines 468-470
... whereas here .BackR, .BackG and .BackB are filled with float in the range of float 0..1.
Of course this is the correct variant since those values are later used inside calls to glClearColor, which wants floats in that range.
But if you use one of the 3 functions above you certainly won't get the color you requested.

DESetCameraRotationXYZ (code style, maintainabilty)
DESetCameraRotationZYX (code style, maintainabilty)
DESetCameraRotationXYZEx (code style, maintainabilty)
DESetCameraRotationZYXEx (code style, maintainabilty)
CAM_Functions.c, lines 362,368,642,651
A define / const / enum like "CAMERA_ROTATION_TYPE_XYZ=0" etc. would be better than 0 and 1.

DEMakeCamera (unexpected behaviour, missing initialization, (rare) crash)
BackR, BackG, BackB and RotMode are not set. All other values are set to reasonable default values.
But those will contain the values they had before if the respective camera-ID was in use before.
Furthermore deGetDisplayHeight() may return 0, leading to a division by zero in line 552 (pretty unlikely condition I guess, but nevertheless: this value not being 0 is not consitently enforced, so it may happen).

CurrentCamera usage (consistency)
CAM_Functions.c, for example line 362, 368:
Here CurrentCamera is used without further checks. Obviously the engine asumes that CurrentCamera is always valid. And if that's the case (and it really seems to be) this is just fine.
However, for example in lines 374, 397:
Here the engine doesn't seem to trust itself and checks CurrentCamera.

_________________
AmigaOS 4.1 FE (sam460ex Radeon 9200 / RadeonHD), MorphOS 3.8 (PowerMac G4 733MHz Radeon 9000), AROS (x86), A1200 (060 80MHz Indivision MK2), A500, A600, CDTV
Wings Remastered Development Diary

@Daytona675x
As usual, what is really a bug have been added to the bug report thread.
Here: http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=39807&forum=15&0

Just for your "understanding" of the engine :

CurrentCamera -> Not added : All user functions that does not requires camera numbers need the check to be sure that at least 1 camera was previously created.
Per default, the engine start with NO CAMERA.

DEPointCamera -> Not added as the issue is not in this function but in a dependancy

DESetCameraRotation???(Ex) -> Not added as internal data are not available to AmiDARK Engine user.

DEColorBackdrop -> Not added as there is no issue in this function as you pointed, issue is outside ... What is the interest to add functions where there are no issue ? Just to increase the number of reports ? The issue is outside this function so, no need to add this.

DESetCameraRange -> Not added as DBPro compatibility requires float.
I should then convert them to GLDouble as gluPerspective (I use in the render camera fuction, uses GLDouble). (from here : https://www.opengl.org/sdk/docs/man2/ )

Last edited by AmiDARK on 16-Jan-2015 at 12:20 AM.
Last edited by AmiDARK on 16-Jan-2015 at 12:20 AM.

@AmiDARK
Quote:

As usual, what is realy a bug have been added to the bug report thread.

As usually your lack of knowledge and / or your lack of accepting when you're wrong made you leave out bugs.

Quote:

CurrentCamera

You did not understand what I explained. Please let it be explained to you by a friend again. Besides that: did I mark it as critical? No. It is just an inconsitency.

Quote:

DESetCameraRotation???(Ex) -> Not added as internal data are not available to AmiDARK Engine user.

Same here. Did I say it was a bug?
However you seem to forget that you just asked for cash to make this "engine" open-source. And what does that mean? Right: other people will probably extend and enhance that thingy. And that again means that your "internal data" is available to AmiDARK engine coders. So yes, you should probably make their life easier, not harder.

Quote:

DEPointCamera -> Not added as the issue is not in this function but in a dependancy

Right. But that doesn't change the fact that the function DEPointCamera is the one your poor library user will see crashing
Besides that: did you already add those internal functions to your list?

Quote:

DEColorBackdrop -> Not added as there is no issue in this function as you pointed, issue is outside

Think and read before you write. As I clearly stated mentioning this function had been done to outline the inconsitency you managed to code here in that color-area... "Of course this is the correct variant". Is that so hard to understand?

Quote:

DESetCameraRange -> Not added as DBPro compatibility requires float. I should then convert them to GLDouble as gluPerspective (I use in the render camera fuction, uses GLDouble).

Maybe you should let that one be explained to you by somebody who understands what I'm saying.
The problem is that DESetCameraRange has INTEGER parameters. Therefore the user of your funny lib has no chance to set your internal floats to actual float values. If he wants to set the near plane to 1.5 for example, well, he can't. Do you get it now? This is a severe bug.

Once again I have to ask:
why do you try to defend the bugs you made? Just accept them, fix them, be grateful.

Last edited by Daytona675x on 16-Jan-2015 at 12:49 AM.

_________________
AmigaOS 4.1 FE (sam460ex Radeon 9200 / RadeonHD), MorphOS 3.8 (PowerMac G4 733MHz Radeon 9000), AROS (x86), A1200 (060 80MHz Indivision MK2), A500, A600, CDTV
Wings Remastered Development Diary

@ASiegel
Hi,
What will happen if the bounty is not accepted ?

To be more precise, where will be refunded the money of the backers if they don't want to fund others power2people bounties ?

Thank you for your reply.

@Daytona
Do you see all these flaws only by code reading or too by code compilation and execution ?
Never mind, by code reading or not, congratulations !

@AmiDark
I expected that you was faster to try to solve the crash of my compiled "AmiDark GDK sample" that LionStorm executed. 

The only concrete test that was asked to you was to compile/run, one of your sample. I was kind enough to compile one,  Lio was kind enough to try it... Crash ! 
You don't really bother of it. But it was, IMHO, the real point that you needed to bother, is your library works at least with your samples ? 
Because of my own tests, I know that it worked at beginning of 2014, but now with the bounty package ?

And no reply about the lack in your package like :
LibAmidark.a or no more installer (it existed  before,)

And don't say "sorry, i don't see your post", one time was enough, I saw that you read my previous post, you replied to Daytona but not to me. 

You asked for money, saying "don't worry, i will keep the leadership of this project" but you don't take few seconds to reply (except to your detractors) .

What killed me is about a very minor question, to remove the hard-coded codebench path in the .info , after many reminders, "yes, i will do that but, i only have a A1200, it will be hard"...
Sorry, i don't trust you anymore as a project leader... Something will be always missing.

5 / 1

PS : what is sad is that, only Daytona looked at your code, but, except me, I think that very few peoples took time to compile your code, (remember your previous betas), but you don't listen to the few guys that give you advices (Daytona or me).
I donated not for charity (even if I had few hopes) but now I am convinced that this project will never be completed. Sad...

Last edited by zzd10h on 16-Jan-2015 at 12:57 AM.

_________________
http://apps.amistore.net/zTools

@zzd10h :
Concerning the bounty, if not accepted, people should be refunded. And then, I have no way to makes the engine become "closed source" again as it was already downloaded by many peoples ... so they have the source code ...

I understand LionStorm have a crash. Anyone tested the sample on another Amiga OS4 computer ? Any more information on crash ? Are all the data files in the good/correct folder/drawers when he tested ? Can he test directly on HD and not from RAM if not yet done ?
Without having more information it's difficult to understand what happen and without having any AmigaOS4 computer to test .. I cannot really make tests.
The only thing I can do, is to prepare a libamidark.a with several check display to see which setup module crash or if it is in the main demonstration. So I must take the time to make the changes and makes a special file available for these tests.

In the FILES section, the AOS4 and MOS version should have the .a that was available on os4depot (0.9r1). In the CODE section, no binay should be available (as some members said to me here or on aros-exec.org ... don't remind)

And don't forget that ... I have a life ... A child ( 11 months old ) ..
And at this time, it remain a "free time" task (and it will always be) and until the bounty is completed, I will only give "a few time" per week to make the changes... Don't remind I have a baby at home, I must continue my traininf/formation to find a new job .. And I've already started to makes some changes, uploaded them and you can see the various changes I've done when you go in the code section at sourceforge ... when you explore files and folders/drawers.
that's really funny saying "I have not been paid" .. But I should work 8h/day to fix everything in 1 or 2 days ... Eh! There's something wrong there !

Concerning CBP project files, I didn't answer here ... But it was added in the bug report thread :
http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=39807&forum=15&0
Didn't you check that ?

If you regret your donation, contact Power2People and ask them for a refund.
And it's what I may advice to all those that did donate and that are not Happy.
I can understand your choice, but you have also to understand mine.

Now, my answers will only concentrate on adding the bug to the list, fix them on my "free time" ... And we'll see.. If I'm bored before the bounty is considered as "finished" by Power2People then I will maybe ask Power2People to cancel the bounty and will remove the files from sourceforge reclaiming the fact that as the bounty wasn't finished, it automatically cancel the contract. The MPL release should legally be removed too... and anyone that will have downloaded the source will have to remove/delete them from all their storage supports.

Regards,
AmiDARK

Last edited by AmiDARK on 16-Jan-2015 at 01:28 AM.
Last edited by AmiDARK on 16-Jan-2015 at 01:26 AM.
Last edited by AmiDARK on 16-Jan-2015 at 01:26 AM.

@AmiDARK

Oh, you replied, nice !

Don't revert the situation please, it's you, the seller. When I begin to sold my zTools on AmiStore, one guys said me to take care because I will have to be make the HelpDesk (I always did it, nothing has changed for me, but you) now you will have to do it too.
If publically, reply to all requester or reply to none.

But you don't seem ready :
1) to accept to introspect your code
2) to reply to your "customers" (except to avoid a public criticism like now)

That's all !

PS : me too, I have a little boy at home ;)

Edit : i forgot, regarding cbp, what amazing me was the "i only have a 1200' not the speed of resolution

Last edited by zzd10h on 16-Jan-2015 at 01:59 AM.
Last edited by zzd10h on 16-Jan-2015 at 01:40 AM.

_________________
http://apps.amistore.net/zTools

@AmiDARK

I would not retract the code, is not you in fault, is rather that other people need to lower a lot expectations in actual Amiga world: i praise your efforts to create the engine and to open it and while other more skilled codes might not like it right now that is what actual Amiga and like programming pool has to offer.

We need more people like you, so please other coders not be that harsh with review!

_________________
Scarabocchi Binari - Italian AROS Blog
Binary Doodles - English language AROS Blog

@zzd10h

Please give AmiDARK time to process everything. He's got a lot to process (both factually and emotionally).

Suggesting that the bounty be pulled out from under his feet because he didn't respond to you to your satisfaction is rather uncool.

@all
This thread is continuing to go downhill at an accelerated pace. Perhaps it's time for people to take a step back, and lighten up a bit.

Hans


P.S. Why is whether he deserves to receive the bounty money still even being discussed? He's delivered what he promised. Just release the funds to him already.

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans,

Your right, the man has a lot on his shoulders and trying to offload some. Give him a break so he can get back to code. Nobody else out there knows all parts of it as well as he does. Help in a world of slow Amiga progress is welcome, to hinder this is non productive.

If you don't think this fulfills your expectations retract your donation! Yes, I'm talking to you!

Chris