[v1.2.4 - Nov 2nd] ACS.NET - Useful ACS functions!

[Nash]

For my first question, I am making a custom inventory toolkit to be released under GPLv2 and I was wondering if I could distribute ACS.NET along with my sources... do you think it would be a better idea instead to not distribute ACS.NET and instead tell users to download it separately? I thought it would be convenient to distribute it because it would make recompiling easy for users.

For the actual feature - thanks! Although IMO it should be named ParseFixed, because some alternative ACC compilers (like GDCC) have an actual, separate "float" type (it's different from fixed)... I know ACS.NET was made for stock ACC but heh, y'know, future-proofing and all. :D

Thanks again so much! ACS.NET has been ULTRA useful in a lot of the stuff I'm making!

[Vincent(PDP)]

For my first question, I am making a custom inventory toolkit to be released under GPLv2 and I was wondering if I could distribute ACS.NET along with my sources... do you think it would be a better idea instead to not distribute ACS.NET and instead tell users to download it separately? I thought it would be convenient to distribute it because it would make recompiling easy for users.

Well I think you should release ACS.NET's source with your project. Because either way, you have to include it's license somewhere (even if you only release the compiled library). Just because your project is released under GPL doesn't mean that you cannot include ACS.NET in it. As long as ACS.NET's license is put where users can easily find it (such as in a lump below the actual library) you can do whatever you want with it as long as you follow the license terms. And it doesn't say anywhere in the terms that you cannot include it in a project where the project has another license. Because however you distribute it, the license for my library will always apply.

---

In the programmer world you meet a lot of different licenses for third-party libraries/applications. And those who are supposed to be used as a part of another project (which ACS.NET is) sometimes states in their license that a copy of their license must be included with your own project/application. So no matter what license you have, you'd still have to include the third-party's license and it will always apply. You can have a project that has your license, and for example thee third-party libraries where each has it's own license. Your license apply to your work, and their license apply to anything regarding the third-party libraries.
So whatever you do, their license MUST (if not stated otherwise) stay intact, but you can still do whatever they permit you to do.

---

Here's one example of it, a guy uses a third-party DLL, and he asks wether he need to include it's license: http://programmers.stackexchange.com/qu ... d-as-a-dll#

[Nash]

That was very useful, thanks. :) Yeah, I do make it a habit to make a "licenses" folder in all of my projects and chuck all license text files in there if I ever use any third party stuff. :D

[Vincent(PDP)]

Okay... Another, somewhat critical, update.
When I first created ParseInt, I forgot to make it able to parse negative numbers...

v1.2.4:
* Fixed so that ParseInt and ParseFloat supports parsing of negative numbers.
* Included Math_Abs with the library (required for ParseFloat to work).

[Nash]

More issues to report...

1) I suggest you rearrange the functions in a way such that no function will ever call an undeclared function. I am using an alternative compiler (gdcc-acc) and it throws a fit if it finds a call to a function that is actually defined AFTER the call. I could solve it with forward declarations placed on top of the ACSNET source file but it would be great if you addressed the problem so that I can work with a pristine copy of the file with no local changes. :D

2) StringFind() - the last argument is the wrong type (should be int); acc doesn't complain but gdcc-acc is a little more strict...

3) gdcc-acc is case-sensitive, I suggest you follow C semantics/standards for the reserved keywords like int, str, return, function, #define, if, etc etc etc... instead of #Define Str If etc

Thanks!

[Vincent(PDP)]

1) I suggest you rearrange the functions in a way such that no function will ever call an undeclared function. I am using an alternative compiler (gdcc-acc) and it throws a fit if it finds a call to a function that is actually defined AFTER the call. I could solve it with forward declarations placed on top of the ACSNET source file but it would be great if you addressed the problem so that I can work with a pristine copy of the file with no local changes. :D

After reading through your post it sounds like GDCC-ACC is (I don't mean to be rude to the creator, but...) a pain in the ass compiler.
There's no logic in not being able to compile functions which are declared after a call. Most (if not all) programming languages manage this anyway since the function/method actually IS defined.
I particularly don't like reordering code after it's written since I know where to find it.

2) StringFind() - the last argument is the wrong type (should be int); acc doesn't complain but gdcc-acc is a little more strict...

Is it? Whoops. *Looks*
Well, yes it is. Never noticed that. Will fix.

3) gdcc-acc is case-sensitive, I suggest you follow C semantics/standards for the reserved keywords like int, str, return, function, #define, if, etc etc etc... instead of #Define Str If etc

Argh, an even worse thing with the compiler. The original ZDoom syntax IS: "Int, Str, Return, Function, #Define, ..."
And also ACS is supposed to be case-insensitive!
Right now GDCC-ACC makes no sense to me at all. :/

Anyway, I'll do some fixes and get back to you when I'm done.
Thanks for the headsups!

[Nash]

Hey thanks for considering! I know it sounds like a pain in the butt right now but gdcc-acc is the only alternative compiler that promises almost full compatibility with regular ACS (so, unlike gdcc-cc or whatever, you don't have to rewrite your entire code to be like C and make it not even look like ACS anymore), save for some semantics stuff and some strictness... but it has some important additions like structs and enums which I really need!

The author did have some technical explanations regarding functions and forward declarations but I don't fully understand it... perhaps I could get him to explain it to you!

[DavidPH]

1) I suggest you rearrange the functions in a way such that no function will ever call an undeclared function. I am using an alternative compiler (gdcc-acc) and it throws a fit if it finds a call to a function that is actually defined AFTER the call. I could solve it with forward declarations placed on top of the ACSNET source file but it would be great if you addressed the problem so that I can work with a pristine copy of the file with no local changes. :D

After reading through your post it sounds like GDCC-ACC is (I don't mean to be rude to the creator, but...) a pain in the ass compiler.
There's no logic in not being able to compile functions which are declared after a call. Most (if not all) programming languages manage this anyway since the function/method actually IS defined.
I particularly don't like reordering code after it's written since I know where to find it.

To clarify, you cannot call a function before it is declared. acc gets around this by implicitly declaring the function when used as having all int parameters. Doing something similar in GDCC is planned, but not necessarily in the immediate future, and would be accompanied by a warning due to the dangers of implicit function declarations.

With respect to compatibility with acc, the only fix is to reorder the functions to avoid forward-references. However, gdcc-acc itself offers forward declarations of functions.

And also, I would note that a number languages do not allow forward-references of functions.

3) gdcc-acc is case-sensitive, I suggest you follow C semantics/standards for the reserved keywords like int, str, return, function, #define, if, etc etc etc... instead of #Define Str If etc

Argh, an even worse thing with the compiler. The original ZDoom syntax IS: "Int, Str, Return, Function, #Define, ..."
And also ACS is supposed to be case-insensitive!
Right now GDCC-ACC makes no sense to me at all. :/

gdcc-acc is case insensitive, as that is a property of the ACS language as defined by acc and one of the primary goals of gdcc-acc is compatibility with acc. Even for some of the more "esoteric" corners of the language, to the greatest extent possible without making GDCC itself into a spaghetti dinner and without compromising my ability to add extensions to ACS.

That said, there are several pragmas available to enable "advanced" features like block scoping for locals, the fixed type, and C-style object-like macros. And other extensions, such as structs, the float type, and function-like macros are enabled by default as they do not interfere with acc compatibility.

[kodi]

Thanks for making this. The ParseInt function in particular has been invaluable in my project, and I expect to replace and/or utilize more of these eventually.

If I may be so bold as to suggest something for future versions, I would really enjoy:
A) a function that separates a string into lines with \n sequences at the last available space that would make the line longer than (argument) characters while also taking any \n seqences already in the string into account, and
B) a function that returns or logs the X and Y pixel coordinates of an actor(TID) on the players screen accurately regardless of angle/pitch/roll.

[Vincent(PDP)]

I am more or less back from my time of (partial) inactivity.
I'm sorry, Nash, for not updating ACS.NET yet. I've had busy month with not much time to work on these kinds of things.
Though, I will finally update this soon.

If I may be so bold as to suggest something for future versions, I would really enjoy

Of course. I appreciate feature suggestions. :)

A) a function that separates a string into lines with \n sequences at the last available space that would make the line longer than (argument) characters while also taking any \n seqences already in the string into account

I will add this in the next version, but I saw you got it at the ZDoom Forum. (:

B) a function that returns or logs the X and Y pixel coordinates of an actor(TID) on the players screen accurately regardless of angle/pitch/roll.

I'm not exactly sure what you want to achieve... Overall something like this is a hard task to perform. I will try, but it will probably not make it to the next version.


Thanks a lot for being as patient as possible everyone.

[kodi]

Of course. I appreciate feature suggestions. :)

Great! I have another then: Functions that returns the *real* current vertical and horizontal FOV. Like Quake, the FOV cvar in zdoom related engines is the horizontal fov of the 4:3 area of the screen only, so in 16:9 the actual horizontal fov is something like 106.xyz degrees rather than 90° if memory serves me right. Vertical fov is always 60° I believe, but I'm not sure. Then there's the force aspect ratio cvar to account for, as well as the FOV CVAR being set to anything other than the standard 90.

Edit:Found a quake fov calculator here. This is the javascript source for it if it's any help:
[spoiler]

Code: Select all

function recalc() {
		var desiredfov = deg2rad(document.getElementById("setfov").value);
		var ratioDividend = document.getElementById("ratioDividend").value;
		var ratioDivisor = document.getElementById("ratioDivisor").value;
		var aspectRatio = ratioDividend/ratioDivisor;
		var ratioRatio = aspectRatio/(4/3);
		document.getElementById("result").value = 2*rad2deg(Math.atan(Math.tan		(desiredfov/2)*ratioRatio));
	}

[/spoiler]

I will add this in the next version, but I saw you got it at the ZDoom Forum. (:

Yeah, I was going to edit this post and link you to it but you found it yourself
Glad it'll be included and available to everyone, considering how useful it is.

I'm not exactly sure what you want to achieve... Overall something like this is a hard task to perform. I will try, but it will probably not make it to the next version.

The purpose would be the ability to accurately print hudmessages on top of monsters for things like health bars or other info hovering above them, or in the case of my project comparing the coordinates to an ACS mouse cursor so actors can be interacted with by clicking on them. I have such a system in place, but I'm terrible at math so the projection is hard coded for 1920*1080 and isn't even quite right at that.

I think Nash's Bumi has some tracing functions in the lens flare script you could look through. It's all Greek to a non-programmer like me.