Click Here
home features news forums classifieds faqs links search
6071 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
9 crawler(s) on-line.
 125 guest(s) on-line.
 1 member(s) on-line.


 OlafS25

You are an anonymous user.
Register Now!
 OlafS25:  1 min ago
 NutsAboutAmiga:  5 mins ago
 Gunnar:  9 mins ago
 MickJT:  24 mins ago
 A1200:  47 mins ago
 outlawal2:  1 hr 22 mins ago
 AndreasM:  1 hr 24 mins ago
 sibbi:  1 hr 33 mins ago
 saimo:  1 hr 48 mins ago
 DiscreetFX:  1 hr 48 mins ago

/  Forum Index
   /  Amiga Development
      /  [Open Source] AmiDARK Engine Bug report fixing
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 Next Page )
PosterThread
phoenixkonsole 
Re: [Open Source] AmiDARK Engine Bug report fixing
Posted on 17-Jan-2015 18:41:59
#21 ]
Super Member
Joined: 8-Nov-2009
Posts: 1770
From: Unknown

@wawa
This attention can also happen between those both or directly while fixing.
This Thread was about bug fixes and ended in "anyalyzing definitions"

about open source...
yes AROS is open source but i can add or replace things with proprietary elements so I am fine.
All contributions I made are based on closed source efforts. Even the HDAUDIO driver was released after it was paid already. And those donations I made to p2p are earned with proprietary things.

In my world the bounty would have failed... i purchased the code. I paid for reviewing and fixing. Problems solved. No drama.

_________________
AROS Broadway - AEROS - Aminux - AmiCloud - indieGO! Appstore - AmiWallet - VAN lossless video codec - AMC Amiga media Center -KrypUnite - LibertyNet - MinX - amigaNX

 Status: Offline
Profile     Report this post  
AmiDARK 
Re: [Open Source] AmiDARK Engine Bug report fixing
Posted on 17-Jan-2015 19:12:10
#22 ]
Regular Member
Joined: 28-Mar-2007
Posts: 469
From: South France

@Daytona675x :
If you'd read carefully my message, as you currently don't. You mays have seen 3 points :

1. My 1st message it is clearly mentionned that the "rules" I have mentioned are available "until the bounty to be validated/unvalidated by Power2People.org" by the statement : "in the wait for the bounty to be validated/unvalidated by Power2People.org, depending on the feedback concerning the review requested by them in another thread..." ... So there Never was Fraud. It's you that misunterpreted my words.
I was just deliberately do this to see if you read things carefully or only point to what interest you and how negative you are against me, from the beginning of the review. Power2People.org did not yet pay me for the release of the source code, so that mean I remain the legal owner of the source and decide what I want from it.
When Power2People.org will pay the bounty (if they pay), the MPL Licence will be fully effective... It's not me the faulty there .. It's you and your way of always attacking me from the beginning of the Review.
No there is NOTHING ILLEGAL.
It is surprising that a professionnal like you don't take care of how a contract run ...

2. I have already started to fix bugs you have mentioned in the 2nd message it is shown, to show my desire to make the engine progress and being fixed but, you are "not god" so, it's not because you decide something that I will do it ... More especially on the fact that the Engine is always MY own ....As Power2People did not yet pay for the release. I do my best to keep the project in the good direction.

3. With all these, you should understand that trying to "impose things" by force, that is what you clearly said by "Hammer'in my head" in the other thread. is NEVER the good solution .. Aggressive behaviour will only attract aggressive behaviour (more especially on the fact that I am "Electro Hyper Sensible" and that aggressivity and stress I receive cause more havoc than other person like you... Imagine that stress/aggressivity is multiplied by 10 when I receive it, I can't control that correctly .. You should really learn the basic on "discuss with respect to others peoples" and What Electro Hyper Sensitivity is... As I have already mentioned it in the other thread.

Last edited by AmiDARK on 17-Jan-2015 at 07:26 PM.
Last edited by AmiDARK on 17-Jan-2015 at 07:18 PM.
Last edited by AmiDARK on 17-Jan-2015 at 07:16 PM.
Last edited by AmiDARK on 17-Jan-2015 at 07:16 PM.

 Status: Offline
Profile     Report this post  
Hans 
Re: [Open Source] AmiDARK Engine Bug report fixing
Posted on 17-Jan-2015 20:48:24
#23 ]
Elite Member
Joined: 27-Dec-2003
Posts: 5066
From: New Zealand

@Daytona675x

Please stop making over the top allegations (like "fraud") and antagonising AmiDARK. You're not achieving anything useful.

Hans

_________________
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.

 Status: Offline
Profile     Report this post  
Daytona675x 
Re: [Open Source] AmiDARK Engine Bug report fixing
Posted on 18-Jan-2015 1:54:13
#24 ]
Regular Member
Joined: 5-Jan-2011
Posts: 491
From: Germany

@Hans
Quote:
You're not achieving anything useful.

Wrong.
Actually this time it really had an useful effect:
Namely that AmiDark edited his initial post once again and added this little phrase, that changes everything he said before:

Quote:
3. When Power2People.org will have validated the bounty, the paiement of the bounty will makes the MPL become really effective and then rules will not be the same ... They will be fully the MPL Licence rules

Of course his initial statement

Quote:
With the fact that I AM and I REMAIN the LEAD DEVELOPER of this project as it was decided with the community before starting the BOUNTY and is a non debatable/disputable requirement

is still weird and off, but since the newly added rule (3) effectively cancels out everything else, this is okay now.

The only sad part of his change of policy is that he now tells you and others that I did not read his initial post correctly first... Which of course is a lie, since he edited it afterwards Best of all: here he actually admits his genious move (since it may be that he edits that away too, I'll better quote it ):

Quote:
the 3rd rule was added after, just to show Daytona he didn't read carefully my messages ...

Ehm, sorry, but what's that? Phew, I feel pretty embarrassed for him. Not that I'm surprised though.

Quote:
Please stop making over the top allegations (like "fraud")

Considering his post before he edited it again and considering his reaction on my very valid (and really polite, even considering your and AmiDark's high standards ) question regarding this post at that time, no, sorry. "Fraud" etc. were just the correct words. And since he finally added that little (3) I quoted above it probably wasn't a bad idea to chose the correct wording to make him correct his course after all.

And just to make it clear: yes, the word "lie" I just used above is a very valid description of what he did right now too. It's not "over the top" neither.

So, please. Please stop posting such partisan-postings like the one above (not your first one btw.). Thank you!

@wawa
Quote:
i think thanks to daytona it actually got all attention it could, and thanks to controversy around it actually even more than that. if none had reviewed the code (and apparently except him and bszili none did) the bounty would be quietly closed, paid and forgotten

I guess that's true I wish I could stop reviewing it, after all most likely nobody will use it anyway, most likely it's a stillborn. But then I think about all those poor guys who donated and got that bug-orgy in return (most without even knowing). And so I continue even if that means to waste additional time argueing with its creator. Yes, such is the life of a code-Inquisitor, definitely one of the hardest lifes

@AmiDARK
I have to repeat it: you're priceless Now EHS is brought up to excuse your behaviour and to acuse me of not considering this and not having put on my velvet gloves. It's lovely! Wonder what comes next? Your hard childhood maybe? Man...

Oh, and just in case you want to acuse me that I put your precious thread off track (and regarding the respect you don't become tired to mention):
You could have simply answered something like "No, I forgot to mention (3), etc.". Of course you did not. Instead you started this mess, once again.
And unless you re-edit your posts again: it's there, for everyone to see ( @Hans: well, for everyone with eyes to see ).

Btw.: because of people like AmiDark who modify their posts later on to appear in a more positive light the guys from the os4welt forum modified their forum system to forbid post-editing after 5 minutes. Not a bad idea.

Anyway, let's contribute something:

Core (partially)

Apparently some things got fixed here already. At least I remember I had seen more issues here before. That's good (thanks to BSZili, I suppose).
Nevertheless quite some stuff remains, and quite a lot of this is "degree 3" (an AmiDark-synonym for "oh my god" ).

AdvFctList, AdvFctPriority (just a note, hint for improvement)
deCore.c
[33]er arrays? Looks like a quick and dirty patch for some former [32]er arrays that got accessed in a wrong way. Looking at that 33 I asume the real number of entries should have been 32 and it was 32 before somebody noticed that we got array-bounds-errors again. Enlarging the arrays by 1 would be a quick patch for such issues. Smells like that.
If I'm right (can't tell since for some reason the original AmiDark file cannot be accessed from the git-server) and this is a patch for a former array-bounds-bug then it is of course better than nothing. It works.
I'm wrong then I wonder where this weird number 33 comes from.
In any case: just consider the following to be a well-meant hint you should strongly consider.
As always it would have been better to
- add a const MAX_ADV_FCT=32
- look for all uses of AdvFctList / AdvFctPriority and really fix the wrong parts
- and replace all those 33/32 numbers around by MAX_ADV_FCT equivalents.
Really, things like this one tend to bite you in your ass sooner or later, believe me. Especially if you stick to those hard-coded numbers.

ListFunctionToRender (deg. 1, just wrong)
Core_AdvancedRender.c, line 50:
You should use %p if you want to correctly printf a void-pointer. Anything else, like the (int)-cast here, is just wrong.
Since this is a diagnosis function with pretty limited use anyway and since it won't crash anything or so I consider this a degree 1 bug only.

DESqr (deg. 3, most likely opposite behaviour)
deMaths_Functions.c, line 233-236
This function doesn't compute the square but the square-root of Value. So it actually does the opposite of what I asume it is supposed to do because of the function's name.
But I can only guess since this command it not mentioned in the docs. And its comment inside the source is the same as the comment of DESqrt.
No idea. Therefore I have to asume the worst case, namely that it should compute the square but doesn't.

DEWrapValue (deg. 1, documentation mismatch)
The documentation says "Return (uint32) represent the value wrapped in the range of 0 to 360.".
This is wrong. The return value is a float (which also is what it should be).

DEWrapValueEx (deg. 1, redundant)
deMaths_Functions.c, lines 123-126
This function simply is a wrapper for DEWrapValue. It can be deleted, just bloat, has no additional value.

deMaths_Functions.c in general (deg. 1,2)
Most functions should be inline.
There are upper-case function name versions again. As being said in previous reviews such things do more harm than help. Recomendation: remove those.

DEGetDate (deg. 3, critical, root of undefined behaviour)
Core_Functions.c, lines 125-135
The documentation says that this function should return the "date as a formatted string".
But for some reason this function's code was almost completely disabled, probably because it was not working correctly (did not check the now commented code).
The problem is that the code was commented out in such a way that now an uninitialized (= random) char-pointer is returned. Therefore this function now is the root of undefined behaviour.

DEGetTime (deg. 3, critical, root of undefined behaviour)
Core_Functions.c, lines 139-154
The documentation says that this function should return the "time as a formatted string".
But for some reason this function's code was almost completely disabled, probably because it was not working correctly (did not check the now commented code).
The problem is that the code was commented out in such a way that now an uninitialized (= random) char-pointer is returned. Therefore this function now is the root of undefined behaviour.

DEFillMemory (deg. 1-2)
Core_Functions.c, lines 182, 192
Why reinvent the wheel? There are already (most likely much faster) functions available for that task. Use those. Your code certainly won't be better.
For example make that function an inline wrapper for a simple memset call.

DESuspendForKey (deg. 1-2)
Core_Functions.c, lines 264, 267
The DarkBasic docs (at least those I got) tell me that SuspendForKey is simply an alias for WaitKey. It should make no semantical difference which one I use.
Since AmiDARK wants to mimic DarkBasic as much as possible I'd not expect DESuspendForKey to behave pretty different due to a WaitTOF delay. This behaviour is not documented neither.

DESuspendForMouse (deg. 3, critical, not working (and if it would then it would behave unexpected))
Core_Functions.c, lines 305, 308
Pretty much the same as above.
But in addition it simply does not work at all, the reason is the same as for DEWaitForMouse, explained below:

DEWaitMouse (deg. 3, critical, not working)
Core_Functions.c, lines 277, 283
The actual wait-functionality would happen between lines 283-290.
But those lines will never ever be entered, because the initial condition in line 283 is always false because MouseChanges will always be 0 at that point.
Therefore this function has just one effect: it issues a call to ReadJoyPort and returns immediately no matter what the joy-port's state is.

DECl (deg. 3, wrong functionality and possible undefined behaviour)
Core_Functions.c, line 320, 324
In contrast to what it shall do this function doesn't return the exe's parameters, but the exe-path itself (argv's first entry is (usually) the executable's path; besides that an argc-check for > 0 wouldn't hurt in case argv has some other meaning than the traditional shell parameters).
And then there's a possible potential crash situation: if *argv points to a string >256 characters the strcpy in line 324 will write beyond the allocated memory.

DEInputS (deg. 1, redundant)
Core_Functions.c, line 349-353
This function is just a useless redundant wrapper to DEInput. Remove it, makes no sense, just bloat.

InputInteger (deg. 3, memory leak)
Core_Functions.c, line 521
The string returned from InputSomething is not freed and the pointer is lost when InputInteger is left.
Since InputInteger is currently used by DEInputI, DEInputI suffers from this issue as well.

InputFloat (deg. 3, memory leak)
Core_Functions.c, line 544
The string returned from InputSomething is not freed and the pointer is lost when InputFloat is left.
Since InputFloat is currently used by DEInputF, DEInputF suffers from this issue as well.

DEDrawToFront (deg. 1, just wrong code)
DEDrawToBack (dito)
DESpritesFirst (dito)
DESpritesLast (dito)
You should use %p if you want to correctly printf a void-pointer. Anything else, like the (int)-cast here, is just wrong.
Since this is just a diagnosis printf and since it won't crash anything or so I consider this a degree 1 bug only.

DESyncON / DESyncOn (deg. 1, useless capital letters variants
DESyncOFF / DESyncOff
Core_Render.c, lines 67-88
The usual things. The usual recomendation: get rid of those.

_________________
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

 Status: Offline
Profile     Report this post  
Birbo 
Re: [Open Source] AmiDARK Engine Bug report fixing
Posted on 18-Jan-2015 10:33:19
#25 ]
Cult Member
Joined: 5-Apr-2007
Posts: 594
From: Zurich, Switzerland

@Daytona675x

Your writing style is priceless too.

I still don't understand your goal.

Why do you use that kind of writing style (with words like bloat, fraud, and so on)?

Reading your posts is like reading a personal attack against AmiDark

Even the technical review part sounds like an attack.


I believe that your goal is just to show what a great goldencoder you are and how bad AmiDark is.

I don't read anything of objective in your words.

Please go on like this. It has become a funny daily reading to me.

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

 Status: Offline
Profile     Report this post  
kiero 
Re: [Open Source] AmiDARK Engine Bug report fixing
Posted on 18-Jan-2015 11:20:51
#26 ]
Member
Joined: 15-Apr-2004
Posts: 84
From: Unknown

@Birbo

Oh i hope he goes on like this. The funny part is just on the side of people trying to diricule it based on their intention of backing this bounty (charity).

#Daytona

+1 :)

 Status: Offline
Profile     Report this post  
Boot_WB 
Re: [Open Source] AmiDARK Engine Bug report fixing
Posted on 18-Jan-2015 11:37:03
#27 ]
Super Member
Joined: 14-Feb-2006
Posts: 1134
From: Kingston upon Hull, UK

@Daytona675x

Thanks for the detailed review, if only more such critiques were available online it could help any coder improve their work. Thanks for having the assertiveness to honestly appraise the code, and spending the time to give such detailed and constructive feedback.

@Amidark

Can't be pleasant for you to have this going on in a public forum, but it's a lot more useful feedback than 'it crashes' and should help you immensely in finding difficult to trace bugs/instability. Considering the amount of work put in so far, fixing some critical bugs before collecting the bounty should make everyone happy...ish.

You'd be in a lot worse position without daytonas feedback, especially given that the included demo currently doesn't run... 'it crashes' seems to be your only other clue.

Seems like it's most of the way there to what was described, with hopefully just some stuff to fix to bring it up to the stated stability (compiles, demos run).

_________________
Troll - n., A disenfranchised former potential customer who remains interested enough to stay informed and express critical opinions.
opp., the vast majority who voted silently with their feet.

 Status: Offline
Profile     Report this post  
t0lkien 
Re: [Open Source] AmiDARK Engine Bug report fixing
Posted on 18-Jan-2015 11:45:00
#28 ]
Regular Member
Joined: 25-Sep-2004
Posts: 185
From: SPAIN

I feel sad that two great persons can develop to our loved machine in plain 2015 but we are seeing a stupid war of nosense words.
We are a tiny crazy group that like a machine. Let´s work together.
Perhaps both of you have reason...I don´t mind. I like when I see a new prod from Daytona. I like when a person spend a lot of hours in a semidead machine like AmiDark.
Is AmiDarkEngine incomplete or buggy? For sure. I knew it when I donated but I prefer that and work on it like Bszili does.
AmigaOS is also buggy and incomplete and with slow development. We all know it but accepted it.
I love this machine but I feel sad.

Let´s be a great community please.

 Status: Offline
Profile     Report this post  
AmiDARK 
Re: [Open Source] AmiDARK Engine Bug report fixing
Posted on 18-Jan-2015 11:52:49
#29 ]
Regular Member
Joined: 28-Mar-2007
Posts: 469
From: South France

@Boot_WB
Quote:
Can't be pleasant for you to have this going on in a public forum, but it's a lot more useful feedback than 'it crashes' and should help you immensely in finding difficult to trace bugs/instability. Considering the amount of work put in so far, fixing some critical bugs before collecting the bounty should make everyone happy...ish

Yes, the informations he provide are really interesting and will help improve the engine but it is more a "bug report" "out of the bounty scope" than a objective "review of an unfinished software". I only regret his way of speaking from the beginning of the other thread that is patronizing... But I'll wait he'll finish the entire bug report to tell more ... some things I have found and that may understand his "behaviour".

Quote:
You'd be in a lot worse position without daytonas feedback, especially given that the included demo currently doesn't run... 'it crashes' seems to be your only other clue.

you're wrong.
I've sent (in private) an archive containing :
1. the LibAmiDARK.a compiled under my AmiDevCPP with My SDK 53.20 and the additional libs
2. The BoingBall.exe demonstration compiled with the LibAmiDARK.a provided in the archive.

Zzd10h send me these results :
1. The BoingBall.exe provided demonstration Work!
2. The boingball demonstration compiled by him with his SDK version and additional lib, and using the LibAmiDARK.a provided crash.

So, the problem is outside the library itself. We must exchange informations on files that are different in his SDK from mine.
So we know where to investigate and found the problem in order to fix it.

Regards,

Last edited by AmiDARK on 18-Jan-2015 at 11:58 AM.
Last edited by AmiDARK on 18-Jan-2015 at 11:58 AM.

 Status: Offline
Profile     Report this post  
zzd10h 
Re: [Open Source] AmiDARK Engine Bug report fixing
Posted on 18-Jan-2015 12:20:52
#30 ]
Amiga Developer Team
Joined: 21-May-2012
Posts: 1077
From: France

@AmiDARK

"Zzd10h send me these results :"
And I even posted the results

http://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=39807&forum=15&start=0&viewmode=flat&order=0#749899


"We must exchange informations on files that are different in his SDK from mine.
So we know where to investigate and found the problem in order to fix it."

Right, but it will be nice if another people than me take time to test the binary/compilation process.

I have many others things to do, too.

Last edited by zzd10h on 18-Jan-2015 at 12:25 PM.

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

 Status: Offline
Profile     Report this post  
Birbo 
Re: [Open Source] AmiDARK Engine Bug report fixing
Posted on 18-Jan-2015 13:10:24
#31 ]
Cult Member
Joined: 5-Apr-2007
Posts: 594
From: Zurich, Switzerland

@t0lkien

Thanks. Good words.

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

 Status: Offline
Profile     Report this post  
Boot_WB 
Re: [Open Source] AmiDARK Engine Bug report fixing
Posted on 18-Jan-2015 14:16:20
#32 ]
Super Member
Joined: 14-Feb-2006
Posts: 1134
From: Kingston upon Hull, UK

@AmiDARK

Quote:

AmiDARK wrote:
@Boot_WB

Quote:
You'd be in a lot worse position without daytonas feedback, especially given that the included demo currently doesn't run... 'it crashes' seems to be your only other clue.

you're wrong.
I've sent (in private) an archive containing :
1. the LibAmiDARK.a compiled under my AmiDevCPP with My SDK 53.20 and the additional libs
2. The BoingBall.exe demonstration compiled with the LibAmiDARK.a provided in the archive.

Zzd10h send me these results :
1. The BoingBall.exe provided demonstration Work!
2. The boingball demonstration compiled by him with his SDK version and additional lib, and using the LibAmiDARK.a provided crash.

So, the problem is outside the library itself. We must exchange informations on files that are different in his SDK from mine.
So we know where to investigate and found the problem in order to fix it.

Regards,


With respect, you have found a condition under which the crash occurs, not the cause.

From what you have stated so far, the suggestion that the new sdk files are the cause of the fault appears to be premature, compiling using them could very well be triggering a crash caused by a code error that simply isn't triggered when compiled using the older files.

Anyhow, best of luck in finding the root cause, at least you have some detailed suggestion as to where to look (along with a lot of suggested improvements for future development).

_________________
Troll - n., A disenfranchised former potential customer who remains interested enough to stay informed and express critical opinions.
opp., the vast majority who voted silently with their feet.

 Status: Offline
Profile     Report this post  
Hans 
Re: [Open Source] AmiDARK Engine Bug report fixing
Posted on 18-Jan-2015 20:00:26
#33 ]
Elite Member
Joined: 27-Dec-2003
Posts: 5066
From: New Zealand

@Daytona675x

Quote:

Daytona675x wrote:
@Hans
Quote:
You're not achieving anything useful.

Wrong.
Actually this time it really had an useful effect:
...

No, you're not achieving anything useful. I've read through your claims, but I still see no postive results; just a heap of arguing, nit-picking, and animosity.

Quote:

...

So, please. Please stop posting such partisan-postings like the one above (not your first one btw.). Thank you!

Nice try, but trying to turn this back on me won't work. I'm not on anyone's side here. I've encouraged AmiDARK to listen to your technical feedback multiple times already. Likewise, I've suggested that you should tone things down, because your aggressive, accusing and condescending tone is a problem (multiple times). Seriously, making things so personal isn't helping anyone (including yourself).

It's up to you whether you heed anyone else's advice/suggestions/requests, or if you will dismiss them as "partisan" and continue as you have. I really hope that you will at least try to tone things down, though.

Hans

Last edited by Hans on 18-Jan-2015 at 08:00 PM.

_________________
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.

 Status: Offline
Profile     Report this post  
wawa 
Re: [Open Source] AmiDARK Engine Bug report fixing
Posted on 18-Jan-2015 20:01:40
#34 ]
Elite Member
Joined: 21-Jan-2008
Posts: 6259
From: Unknown

@AmiDARK

Quote:
1. the LibAmiDARK.a compiled under my AmiDevCPP with My SDK 53.20 and the additional libs


amidevcpp is very custom and pretty outdated environment that has numerous quirks, produces orthodox makefiles, depends on its project files and imho its been apropriate for quick and dirty sdl ports but is not suitable as base for more complex project that need to be maintainable and portable without such a "hard coded" dependency. in my noob eyes such a project should be compilable with few available gnu tools, rather than with some ide, even if it was a maintained and up to date one.

Quote:
Yes, the informations he provide are really interesting and will help improve the engine but it is more a "bug report" "out of the bounty scope" than a objective "review of an unfinished software". I only regret his way of speaking from the beginning of the other thread that is patronizing... But I'll wait he'll finish the entire bug report to tell more ... some things I have found and that may understand his "behaviour".


well, right.. he sounds patronizing alright. but you sound as well as pretty self confident in your contradicting claims, he was calling you on. and as i am probably allowed to remind you have demanded a bit more money for this source initially, so its only right if it is now being checked for quality of what has been delivered in contrary to what have previously been usually the case. and i think your personal and financial situation and such shouldnt be a subject here, except if you had outright called for charity.

Last edited by wawa on 18-Jan-2015 at 08:09 PM.

 Status: Offline
Profile     Report this post  
BSzili 
Re: [Open Source] AmiDARK Engine Bug report fixing
Posted on 18-Jan-2015 20:25:33
#35 ]
Regular Member
Joined: 16-Nov-2013
Posts: 447
From: Unknown

@wawa

I've added new makefiles, which can be used for cross compilation, and native compilation alike.

_________________
This is just like television, only you can see much further.

 Status: Offline
Profile     Report this post  
wawa 
Re: [Open Source] AmiDARK Engine Bug report fixing
Posted on 18-Jan-2015 20:30:21
#36 ]
Elite Member
Joined: 21-Jan-2008
Posts: 6259
From: Unknown

@BSzili

thx, good to hear.

 Status: Offline
Profile     Report this post  
Daytona675x 
Re: [Open Source] AmiDARK Engine Bug report fixing
Posted on 19-Jan-2015 19:01:18
#37 ]
Regular Member
Joined: 5-Jan-2011
Posts: 491
From: Germany

@Birbo
Quote:
Why do you use that kind of writing style (with words like bloat, fraud, and so on)?

I explained why the word "fraud" was absolutely appropriate in that context.
I use words like bloat etc. because they are the correct vocabulary for the respective situation. For you, who apparently doesn't know better, such words may sound patronizing or whatever while in fact they are not.

Quote:
Reading your posts is like reading a personal attack against AmiDark

Maybe the parts where I react to AmiDark's attacks towards me may sound a bit too clear for your taste since they partially adapt AmiDark's tone. Have to say it once again: cause and effect.

Quote:
Even the technical review part sounds like an attack.

That's just your imagination, presumably because you have no idea about the common vocabulary used when talking about code.
Actually all those reviews are in very neutral language. However I don't sugarcoat things. And for your information: sugarcoating or making somebody feel comfortable is not the point of a review. In fact I'm rather nice in the reviews.

Quote:
I believe that your goal is just to show what a great goldencoder you are and how bad AmiDark is.

I don't have to show that and it's not my intention. At least the latter can be seen by anybody who looks at the code anyway. And of course the one who finds the bugs will always appear superior than the one who made them / ignores them / denies them, that's the nature of the beast. Other than that: AmiDark himself and his coding skills are of no interest to me.
I have other interests / goals here, and those I already explained. Actually I already repeated them for you once.

Quote:
I don't read anything of objective in your words.

Weird, I cannot help you then, the reviews are highly objective, also according to the feedback of people with coding knowledge. But:

Quote:
Please go on like this. It has become a funny daily reading to me.

That's nice to hear, and I certainly will go on like this! Apparently you are not the real target audience, therefore words like "bloat" and other things probably make you laugh unintentionally, but as long as you're happy and the target audience gets it - who cares, glad if it makes you happy

@kiero
@Boot_WB
Quote:
Thanks for having the assertiveness to honestly appraise the code, and spending the time to give such detailed and constructive feedback.

Thanks!

Quote:
With respect, you have found a condition under which the crash occurs, not the cause. ... could very well be triggering a crash caused by a code error that simply isn't triggered when compiled using the older files

Exactly. That's something he doesn't seem to understand.
It's similar to what I tried to explain to him multiple times before:
if it compiles does not mean that the result is stable. And only because it runs (most of the time) on machine x doesn't necessarily mean that it's stable.
In contrast some of the bugs found prove that it cannot be stable. So a good strategy would be to fix those issues first.
Therefore, let's repeat it once again:

@AmiDARK
Quote:
1. The BoingBall.exe provided demonstration Work!

By luck. I just checked, some of the critical bugs I found that make any AmiDark-executable unstable / crash depending on the machine's RAM state, still exist.
Again: as long as those are not fixed you cannot possibly create a working executable with the current lib. No need to look for another culprit like the SDK as long as there are obvious flaws in the code that explain such crashs.

Quote:
I only regret his way of speaking from the beginning of the other thread that is patronizing... But I'll wait he'll finish the entire bug report to tell more ... some things I have found and that may understand his "behaviour".

Strong words for a person one can only feel embarrassed for. So after all I guess the best reaction to you and your talk is: "tell it to the hand"

@Hans
Quote:
but I still see no postive results

Hm, then I really can't help you, it shouldn't be too hard to see. But somehow I already anticipated that especially you wouldn't spot it:
Quote:
it's there, for everyone to see ( @Hans: well, for everyone with eyes to see


Quote:
I'm not on anyone's side here.

Great! Then I wonder why you keep concentrating on me, when the other one just admitted that he was lying to discredit me etc. and when the other's tone is worse (or at least not a tad better) than mine. Weird way to show your neutrality. Here, that's an example how a real neutral comment taking both sides into account looks like (bottom part in case you have problems seeing that too ).
But well, enough small-talk, back to the topic. I guess you and your pretty unimportant and biased personal opinion on AmiDark's and mine personal issues, tone, whatever already got more of my attention than deserved.

Better let at least me be productive and constructive instead once more

Text

In general the text functions (and many other code areas) have a 256 character string size limit. However, the AmiDark Engine claims to aim for Dark Basic Professional compatibility, at least it says so on the bounty's page ("that is compatible with the DarkGDK product from TheGameCreators (and later, with Dark Basic Professional").

But, as far as the DBP docs I found tell me and in contrast to what AmiDark told us here, DarkBasic Professional has no such limitation! Strings can be any size, 0 terminated, just like normal C strings.

The current 256er-limitation, besides being a problem itself, is also the root for lots of problems because it is not consistently enforced / kept in mind when processing text. Actually it is not even documented.

In general: since DBP doesn't have that limit it should be removed here so that AmiDark's specs match.
Suggestion: to avoid more bugs and improve performance it would be smart to introduce a string-struct that hold pointer, length and buffer-size of a string.
That may sound like a lot of work but a) it's not that much as it sounds and b) it's worth it and c) the whole thing would become more DarkBasicPro-ish with a "real" string-type.

Anyway, since many functions have some sort of 256-limit under the hood, although they shouldn't, some will behave unexpected if fed with larger strings. If a function has such issues I'll therefore consider this to be a severe degree 3 bug due to unexpected behaviour.

TXT_Constructor (deg. 2-3, uninitialized global variables)
Text_Constructors.c, lines 31-39
MyText.RGBColor and MyText.fMode are not initialized (fMode is set in the necessary DESetTextFont call though, therefore not too critical).

TXT_Destructor (deg. 2, (uncritical) memory leak)
Text_Constructors.c, lines 43-47
MyText.FontName is not deleted. Should probably happen here.

DEAsc (deg. 1-2, efficiency, constness)
Text_Functions.c, lines 122-133
dwSrcStr should be const, the whole functions should be inline and could be turned into a well-readable 1-liner.

DELeft (deg. 3, 256-problem, efficiency, constness)
Text_Functions.c, lines 137-152
The resulting string will be at max. 255 chars long even if more is requested. This is critical unexpected behaviour.

DELen (deg. 1-2, efficiency, constness)
Text_Functions.c, lines 156-162
text should be const, the whole functions should be inline and could be turned into a well-readable 1-liner.

DELower (deg. 3, 256-problem, crash, efficiency, constness)
Text_Functions.c, lines 166-179
text should be const.
strcpy in line 172 will create undefined behaviour if text's length is > 256.
However this line 172 could just be removed, since the loop in lines 173-175 can be modified to do that if text[] would be used as parameter to tolower.
However the function will still behave undefined / crash if text's length is > 256, since sLen is not adjusted to account for the 256-limit.

DEMidEx (deg. 3, 256-problem, crash, efficiency, constness)
Text_Functions.c, lines 183-194
Efficiency, line 187: better cache strlen's result before.
The function does not validate the parameter "depart" for being too large. As a consequence texta may point into nirvana after line 188. And "size" may become negative in line 187.
This in turn may lead to undefined behaviour / crash in line 189, because strncpy's num parameter is of type size_t (an unsigned int type). This means that a negative "size" will be interpreted as a pretty large number by strncpy. And since texta already points into pretty randomly filled RAM it may write and write and write far far out of bounds where no man has gone before (just a little joke to make Birbo happy ).

DELeft / DEMidEx (example for inconsistency)
Text_Functions.c, lines 137-152
Text_Functions.c, lines 183-194
DELeft: a NULL-pointer will be returned if the text-parameter is NULL.
DEMidEx: a pointer to an empty string will be returned if the text-parameter is NULL.
Functions that have a similar behaviour in terms of "they are all pretty atomic string manipulation functions" should behave consistently.
So in this case here it would be best if DEMidEx would behave like DELeft if the text-parameter is NULL.

DEMid (deg. 3, crash, efficiency)
Text_Functions.c, lines 198-201
Should probably return what the docs say: a single character instead of a full 256-char*.
In its current form this function relies on DEMidEx, and therefore it also suffers from the same crash problems.

DERight (deg. 3, 256-problem, root for crash, efficiency, constness)
Text_Functions.c, lines 205-219
strlen only needs to be computed once.
Very dangerous: this function either returns a newly created char* or the same pointer it was fed with (line 211). How shall the caller know if he shall delete it or not later on? He can only know if he does additional sanity checks / manual bookkeeping. This is a potential root for later crashs (in the style of delete-twice).
Undefined behaviour / crash in line 214/215 if num is > 256 and texte's length is > 256.

DEUpper (deg. 3, 256-problem, crash, efficiency, constness)
Text_Functions.c, lines 223-236
strcpy in line 229 will result in undefined behaviour if text's length is > 256.
However this line 229 could just be removed, since the loop in lines 230-232 can be modified to do that if text[] would be used as parameter to toupper.
However the function will still behave undefined / crash if text's length is > 256, since sLen is not adjusted to account for the 256-limit.

DESpace (deg. 2, 256-problem, dangerous)
Text_Functions.c, lines 240-249
Limited to 255 spaces (although even with the 256-limitation one more would be okay).
Dangerous: the string is not explicitely terminated with a 0. Since LCreateString currently creates memory filled with zeros this is not a problem now. But if somebody thinks that this zero-initialization of the whole buffer can be optimized away (and yes, it actually should be optimized away), then this function will create strings that are not 0-terminated. I strongly suggest to add an explicit 0-termination here to avoid potential future side-effects. Other functions don't rely on LCreateString's current behaviour neither.

DEVal (deg. 3, totally broken, wrong parameter type)
Text_Functions.c, lines 253-263
This function doesn't do what it is supposed to do. It should just do an atoi.
But instead it returns the ASCII code of the string's first character in an extremely inefficient way.
Besides that the ZeChar parameter should be of type "const char *".

DEFlip (deg. 3, 256-problem, crash, constness, highly inefficient)
Text_Functions.c, lines 268-284
In line 279 we got undefined behaviour / crash if Intext's length is > 256.
This function is really very inefficient, it should be implemented without strncpy / strncat, this can be done best with pure pointer-arithmetic / array accesses (or maybe just use the C function strrev, I'd have to check whether all Amiga-flavours' std-libs support that though, can't tell for sure right now).
As a side-note: this function is not thread-safe needlessly. Only because of that static temporary array sortie[256] in line 270. And that array makes no sense, because only its first and second characters are used. It neither makes sense to make it 256 bytes lager nor to make it static.
Actually this temporary buffer itself makes no sense at all.

EDIT: post too long, continues below.

Last edited by Daytona675x on 19-Jan-2015 at 07:03 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

 Status: Offline
Profile     Report this post  
Daytona675x 
Re: [Open Source] AmiDARK Engine Bug report fixing
Posted on 19-Jan-2015 19:04:12
#38 ]
Regular Member
Joined: 5-Jan-2011
Posts: 491
From: Germany

Part II (sorry, the post wasn't too long as I suspected, it was the < < below that made the post being terminated early)

DEBin (deg. 3, just wrong, efficiency)
Text_Functions.c, lines 288-304
The for-loop at line 294 starts with 32, therefore the mask in line 295 will be 1 < < 32, but for the algorithm to do what it is supposed to do it should be 1 < < 31.

DEHex (deg. 1, documentation off)
Text_Functions.c, lines 308-313
The documentation states that "an eight character string equivalent to the hexadecimal representation of the number" will be returned. This is not true. The string's size is not enforced, it varies depending on the input value.

DEValF (deg. 1 constness, efficiency)
Text_Functions.c, lines 317-323
MyStr should be const, function should be turned into an inline 1-liner.

DEChr (deg. 1, dangerous, efficiency)
Text_Functions.c, lines 338-343
Efficiency: this functions is supposed to return 1 single character. But it creates a 256-bytes-string for that task internally.
Dangerous: the string is not explicitely terminated with a 0. Since LCreateString currently creates memory filled with zeros this is not a problem now. But if somebody thinks that this zero-initialization of the whole buffer can be optimized away (and yes, it actually should be optimized away), then this function will create strings that are not 0-terminated. I strongly suggest to add an explicit 0-termination here to avoid potential future side-effects. Other functions don't rely on LCreateString's current behaviour neither.

DEAppend (deg. 3, 512-limit, crash)
Text_Functions.c, lines 382-394
Undefined behaviour / crash if the summed length of destination and source is > 512.

DETextStyle (style)
Text_Functions.c, lines 438-443
The operation designed for such things is OR. And defines / consts for italic and bold would be best (also helps lib-users to write clean code).

DECompareCase (deg. 3, crash, constness)
Text_Functions.c, lines 516-522
tInputA and tInputB should be const.
tInputA and tInputB are not checked for being NULL pointers. But the strcmp in line 517 will crash / behave undefined if fed with NULL pointers.
The behaviour per se would be okay, if it was documented. Since it is not and since the rest of the string functions here check for NULL pointer parameters, this can be considered a critical deg. 3 bug.

DEReverse (deg. 3, not functional, wrong return type etc.)
Text_Functions.c, lines 526-530
This function should do the same like DEFlip (see above) but right now it simply does nothing, although the docs say different.

DEFindSubString (deg. 3, crash, constness)
Text_Functions.c, lines 533-539
tSource and tString should be const.
tSource and tString are not checked for being NULL pointers. But the strstr in line 536 will crash / behave undefined if fed with NULL pointers.
The code in line 537 looks rather elegant but it is dangerous. If tOrigin is NULL and tSource holds a sufficiently "large" adress, this may result in a positive int at the end. And then the function returns a positive value even if it should not. Better do an explicit NULL check on strstr's result.

DEFindFirstChar (deg. 3, crash, constness)
Text_Functions.c, lines 543-550
tSource and tChar should be const.
tSource and tChar are not checked for being NULL pointers. But the pointer derefence in line 546 as well as the strchr call in line 547 crash if there are NULL pointers.
The code in line 548 is dangerous. Reason: see above in DEFindSubString's description.

DEFindLastChar (deg. 3, crash, constness)
Text_Functions.c, lines 554-561
tSource and tChar should be const.
tSource and tChar are not checked for being NULL pointers. But the pointer derefence in line 557 as well as the strrchr call in line 558 crash if there are NULL pointers.
The code in line 559 is dangerous. Reason: see above in DEFindSubString's description.

Last edited by Daytona675x on 19-Jan-2015 at 07:05 PM.
Last edited by Daytona675x on 19-Jan-2015 at 07:04 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

 Status: Offline
Profile     Report this post  
OlafS25 
Re: [Open Source] AmiDARK Engine Bug report fixing
Posted on 19-Jan-2015 23:11:15
#39 ]
Elite Member
Joined: 12-May-2010
Posts: 6321
From: Unknown

@Daytona675x

if that is a review in good mood I will hopefully never see you in bad mood

and BTW I will hopefully better not reviewed by you

You are taking it much too seriously, as phoenixconsole already said, almost deadly serious

It is a home-project done by someone just starting to learn C and the bounty was vy non-programmers supporting someone for charity and to support someone programming something for Amiga (what is rare today). I do not know if you understand that but if you invest a lot of spare time and heart in a project and somebody puts it in the mud that hurts a lot even if it is true. Simply leave out your judgements and if you really want to help just give advices. Most people here are not stupid some even programmers (even if not as genious as you ) but all can read and draw their own conclusions. That would be more positive and sympathic. But perhaps you are not interested in that.

BTW I dislike C for some reasons, some of the errors are not even possible on other languages

 Status: Online!
Profile     Report this post  
AmiDARK 
Re: [Open Source] AmiDARK Engine Bug report fixing
Posted on 19-Jan-2015 23:27:37
#40 ]
Regular Member
Joined: 28-Mar-2007
Posts: 469
From: South France

@OlafS25
Don't react to him .... He have "high standing" concerning coding ... As we can see in the company he is .. 1 bug per 1000 line (instead of standard 2 bugs per line) ...
So, as resulting, I have understood he HATE the whole existence of the bounty we're talking about and it's only "unconscious" objective was to kill myself from wanting to continue project ... Saying I'm a so so so noob coder that the project should never have existed ... It's what I feel from his speeches and the way he try to reverse things.

I give up on fighting against someone like him that think he is "god" and that can act in a forum like he want ... I'm really nauseated on the way he act.
I really complain his wife, his child and animals ... if he is with them like he is there... But I doubt that he is like this with them ... As like I said he hate the fact that an unfinished project is sold....

I prefer stop loosing energy and health as it makes me litterally out ... I'm tired of all these ... And you know what ... I'm sure he will answer: "(it's your fault not mine" ... And he is right. I may have ignored himself from the beginning instead of trying to be honest and expose myself ...

So, let him tell what he want .... My soul is far further than these baseness of the ego ... You know what Daytona675x ? Say what you want ! I will not more defend myself ... You definitively do not deserve it! I have already offered too much time and energy to you... Make and say what you want ... I have nothing more to do...

Good night for those that can spend one good... My health and the one of my child will definitively prevend me from having one good...
To all whom that can act with love.

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 Next Page )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle