Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Feature wishlist

Author
Message
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 19th Jan 2011 19:57 Edited at: 21st Jan 2011 12:29
The current threads seem to be about pretty specific things so I'm making this general topic, feel free to add your own ideas or tell me that mine are stupid.

Note: All suggestions with a # before them are features I don't think are essential for the first release and can be later added without breakng backward compatibility
Note: Although my examples all use the same case, this would work fine without case-sensitivity so I don't mind either way

1 - Naming conventions

1a - All functions whose names contain some American/British English variants should be replicated so a variant for each exists
1b - Functions no longer contain the $ symbol when returning strings, i.e. Str$()


2 - General language syntax

2a - All function calls should require brackets
#2b - Add support for references
2c - Array creation and access uses square brackets []


3 - Language features

3a - No 'gosub' call
3b - There should be way more data types
3b-1 - 'Function' should be a data type
3b-2 - 'Array' should be a data type
3b-3 - 'Dictionary' should be a data type
3b-4 - 'Image/Sprite/Sound/etc' should be a data types
3b-5 - 'Float2/Float3/Float4/Float4x4/Float3x3/etc' should be data types
3b-5a - The above vector types should have basic operators defined, such as multiply
3b-6 - Allow all the above types to be declared in a UDT
#3c - Allow retrieval of function objects via not using brackets to call it
3d - Variables in UDTs should be allowed to have default values
#3e - Allow functions to be declared inside functions with access to outside variables, aka lambdas
#3f - Some type of namespace support, maybe allow the user to import a library
3g - Support for common comment characters/blocks, i.e. // /* */ rem ` remstart remend
3h - Arrays should have 1 based indices
3i - Better scopes; each control structure is a deeper scope level
3j - Variables can be created via assignment, i.e. 'myString = "Apples"' or 'for i = 1 to 10'
3k - Basic types such as String/Integer should have constructors that can take other types as arguments to perform conversion
3l - Print should accept all data types, including UDT types

4 - Library features

4a - All functions that create a resource(like an image) should return the associated resource data type rather than require an index
#4b - The string library should contain functions to deal with UTF-8 input
#4c - The file functions should treat the passed paths as UTF-8


Justifications

1a - I hate writing color
1b - This is a static language, so binding the type to the function name is pointless and forces the user to learn more syntax rules

2a - Consistency is a good thing
2b - I cringe every time I see DBPro code with something like: myArray(indexTo).something = myArray(indexFrom).something, except that line is done about 50 times for each type, and it can't be sped up. This feature can easily be added at a later date without breaking existing code
2c - Using round brackets for everything doesn't make much sense, 'var = myArray( 5 )' looks identical to a function call, so differentiating them will increase readability

3a - It's pointless and makes the language more complex for no reason
3b-1 - This allows for elegant callbacks and keeps everything consistent
3b-2 - Why not? Dim makes no sense in DBPro, it's so drastically different in terms of syntax from everything else when it shouldn't be
3b-3 - This would map between strings and some other data type, similar to arrays, which map between integers and some other data type
3b-4 - I don't see the point of the resource index system, passing an integer which is actually a resource index isn't descriptive in the slightest, and it forces you to name your variables with what type they are
3b-5 - Why wasn't this the case in DBPro? Vectors are so fundamental to game programming and their use in DBPro is gimped to say the least. I used the Float(height)[x(width)] syntax because it makes it more clear as to what type is being mapped, and allows for DoubleFloat4x4/Integer4 maybe?
3b-5a - Definiting the basic operators for these vector types makes code very legible, more complex operations such as DotProduct/CrossProduct/Decompose/etc should of course use functions
3b-6 - Makes a lot of sense! And it also automatically allows for arrays within UDTs, because arrays would be a standard data type! As well as functions within UDTs
3c - This ties into 3b-1 and 3b-6 and makes sense, however this isn't amazingly important, and adding this at a later date won't break anything
3d - This should be obvious, e.g: Type MyType health as Integer = 100 EndType
3e - This powerful feature can be added at a later date without breaking existing code
3f - If we have some type of library support(which we should because NO ONE shared libraries in DBPro, as there was no support for it, and TCPs are a naming convention mess) then maybe the 'import' statement could specify the namespace it gets shoved into?
3g - These are the same as DBPro, except for the C-style block comment, I personally like // because you can stack loads in a row to separate sections of code, the ` grave accent doesn't look as nice!
3h - The 'for i = 1 to count' is quite a nice way of interating through a loop and can be done with a 1 based array, 0 based indices makes sense from a low-level perspective, but isn't this supposed to be a high level language to begin with?
3i - DBPro's 3 levels of scope isn't good enough, any control structure should be able to access any variables declared in any of its parent scopes and nothing else, so no more declaring globals in functions, globals must be outside of functions, so no need for global
3j - DBPro allows you to do stupid things like 'print i + z' which makes no sense, allowing creation via assignment or full declaration makes the most sense and is very clean
3k - This removes the need for functions such as Str$(), Val(), which are very confusing for beginners. Simply having 'age = Integer( "1234" )' is amazingly clear and stays consistent with DBPro's style
3l - This would simplify code a lot, I often have to write 10 lines of code to just print the contents of a UDT

4a - What's the point of the whole index system? Is it just so that the spinning cube example can be a few characters smaller because you don't have to create a variable for the cube object? The index system causes so many problems and is one reason why no one ever shared DBPro libraries, because they were always incompatible. I could rant all day about this.
4b - And by deal with, I just mean a feature to count the amount of glyphs in a string, and various other UTF-8-aware variants of certain functions
4c - This takes little effort to implement and solves a lot of issues with localization


Differences between DBPro and this

These would be the major differences between DBPro and this script, assuming you didn't use all the optional features suggested above

Images in DBPro

Images with the AppGameKit concept



Type casting in DBPro

Type casting with the AppGameKit concept



UDTs in DBPro

UDTs with the AppGameKit concept



Arrays in DBPro

Arrays with the AppGameKit concept



Variables in DBPro

animal as string
animal = someFunctionThatReturnsAString() // Works on 2 lines...
Variables with the AppGameKit concept


Functions in DBPro

Functions with the AppGameKit concept



Examples

Note: These examples mainly show the optional features that would be possible as a result of the above suggestions, and none break compatibility with simpler code

String casting

DBPro version:



Vector types 1 - (In DBPro this would be about 7000 lines)

DBPro version 1:

DBPro version 2(This is the official DBPro way to do vectors):


Vector types 2


UDT 1


Function type 1


Function type 2


Function type 3 - (This is pretty advanced and isn't required early on)


Array type 1


Array type 2


Array type 3


Array type 4



Resource type: Image


So as you can see, should you stick to your die-hard DBPro ways, your code shouldn't require much modification, and at least with the arrays, I feel it both makes more sense than the DBPro implementation, but it's also clearner if you looking at it from a DBPro-style syntax point of view

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 19th Jan 2011 20:06
+1

Also, some sort of error handling would be nice. Ideally support for exceptions. (That way errors are still shown as usual unless you specifically choose to catch a particular error)

[b]
Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 19th Jan 2011 20:30 Edited at: 19th Jan 2011 20:56
If gosub is removed then the problem of not being able to declare UDT's in functions needs addressing to ensure it isn't re-introduced.

I agree very much with the US/UK English thing. It is intensely annoying having to intentional misspell words.

Just gone through all your example DCs. Some excellent suggestions and I would love to see most of them implemented but since the idea of AppGameKit was "If you know DBP, then you already know AGK", it seems that many of your ideas would stray too far from that ideal.

Perhaps that ideal needs changing?



thenerd
15
Years of Service
User Offline
Joined: 9th Mar 2009
Location: Boston, USA
Posted: 19th Jan 2011 20:40
I have one small suggestion, I'd like to know what other people think.
Instead of:
x=x+1
have something like this:
x+=1
that could be also used for subtraction: -=

dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 19th Jan 2011 21:16 Edited at: 19th Jan 2011 21:49
Quote: "If gosub is removed then the problem of not being able to declare UDT's in functions needs addressing to ensure it isn't re-introduced."


Ah, well... let's just pretend my suggestions assume the big parsing issues have all been resolved .


Quote: "Just gone through all your example DCs. Some excellent suggestions and I would love to see most of them implemented but since the idea of AppGameKit was "If you know DBP, then you already know AGK", it seems that many of your ideas would stray too far from that ideal.

Perhaps that ideal needs changing?"


Indeed, I tried to keep my ideas as close to DBPro syntax as I could while retaining the power from languages like lua and HLSL. Or at least, allow them to be mostly backward compatible, for example the UDT, variable and function declarations can be identical.

The most drastic language change I suggested would probably be to make all the resource and array types essentially classes, however, in my Image example I do PasteImage, which takes an Image object as the first parameter, I'm pretty sure a user of DBPro could understand exactly what's going on there without even knowing the Image object isn't an integer, because the syntax is virtually the same, except the object(or ID) is returned, rather than passed.

So to solve this, perhaps every resource and container(Array etc) related method could have a function counterpart, or more accurately, the functions for these objects could have a method counterpart that calls these. That way, the general DBPro structure would be almost identical.

I just added a new section to the bottom of the OP to show these differences.

Quote: "I have one small suggestion, I'd like to know what other people think.
Instead of:
x=x+1
have something like this:
x+=1
that could be also used for subtraction: -="


I considered adding this to the list, but I wasn't sure if the ratio of complexity:benefit was as high as some of these other features. I must have rewritten this post a few times now but I can't actually think up a decent reason why it shouldn't be added, because it can be implemented using the = and + operators, thus if operator overloading was ever added to the language then it wouldn't require any code changes. Plus, it's not like += is a difficult concept to teach to beginners, and it makes some code much neater than the a = a + b alternative.

Fatal Berserker
13
Years of Service
User Offline
Joined: 2nd Jul 2010
Location:
Posted: 19th Jan 2011 23:54
Quote: "Instead of:
x=x+1
have something like this:
x+=1"

or even:
x++;
=p

thenerd
15
Years of Service
User Offline
Joined: 9th Mar 2009
Location: Boston, USA
Posted: 20th Jan 2011 00:03 Edited at: 20th Jan 2011 00:04
Quote: "or even:
x++;
=p"

what exactly would that command do?

Link102
19
Years of Service
User Offline
Joined: 1st Dec 2004
Location: On your head, weeeeee!
Posted: 20th Jan 2011 00:24 Edited at: 20th Jan 2011 00:29
I agree with everything above this post (at time of posting), but I'm afraid this is simply not going to happen. The developers probably have enough on their minds already at the moment.

"what exactly would that command do?"
It assigns p to x+1 and gives an error for the ;

Sixty Squares
17
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Somewhere in the world
Posted: 20th Jan 2011 00:26
Quote: "Quote: "or even:
x++;
=p"
what exactly would that command do?"


I think =p was just a smiley face .


Guns, cinematics, stealth, items and more!
thenerd
15
Years of Service
User Offline
Joined: 9th Mar 2009
Location: Boston, USA
Posted: 20th Jan 2011 00:33
Quote: "I agree with everything above this post (at time of posting), but I'm afraid this is simply not going to happen. The developers probably have enough on their minds already at the moment."


Actually, one of the reasons they started this forum was to take suggestions from the community on what the specifics of the syntax would be. A suggestion like mine would probably take, say, 10 minutes to code? simply have the operator += add the second number to the first variable, and then reassign it to that variable.

The_Quay
14
Years of Service
User Offline
Joined: 10th May 2009
Location: Scotland, UK
Posted: 20th Jan 2011 01:20
Quote: "or even:
x++;"

Actionscript ftw!

but yeah x++ would be easier than x=x+1, as that would just cause an infinate loop of +1 constantly being added to x woulnd't it?



- The Quay

thenerd
15
Years of Service
User Offline
Joined: 9th Mar 2009
Location: Boston, USA
Posted: 20th Jan 2011 01:25
Quote: "but yeah x++ would be easier than x=x+1, as that would just cause an infinate loop of +1 constantly being added to x woulnd't it?"

Oh... I had no idea ++ was a command to add by one...
It wouldn't be in an infinite loop, it would just add the second value to the first one time.
For the += command, it could be used to add any value, not just one. for example, x+=y would add y to x.

LeeBamber
TGC Lead Developer
24
Years of Service
User Offline
Joined: 21st Jan 2000
Location: England
Posted: 20th Jan 2011 04:26
Hi Guys,

Just been following the thread and I could not shake out of my mind that all these cool features you are looking for already exist in the AppGameKit Tier 2 C++ option. You'll get everything you've listed plus the extra speed of direct compilation too!

My concern is that if you change the DBP style script too much, it won't resemble BASIC anymore and become a sort of 'easy to use C++' Maybe it's an over-reaction, but when I see a request for advanced data types, referencing, C style command declarations and OO I wonder why it would not be more gratifying to switch to C++ and call the AppGameKit API directly (Tier 2)?

One of my aims with Tier 1 (the DBP style script) was to keep the unique 'ease of use' qualities that BASIC provides. There is a freedom to using a variable without the need to declare it, identifying and creating a string variable using the $ symbol without jumping to the top of your program to type 'as string' and similar scenarios that save these little bits of time.

I suppose what I am curious about is whether we want to turn BASIC into something more like C++, or whether the idea of a Tier 1 (script) and Tier 2 (C++) approach allows the BASIC script to remain 'simplified' and the C++ code to be as sophisticated as you need it to be.

The great thing about the AppGameKit forum is that you have an opportunity to say, 'Lee, dude, you're the only one that thinks this. Move on mate!'. This is the time when we change the future

I drink tea, and in my spare time I write software.
SoftMotion3D
AGK Developer
18
Years of Service
User Offline
Joined: 24th Aug 2005
Location: Calgary,Alberta
Posted: 20th Jan 2011 05:47
I like using gosub...lol

haha ill get burned for saying that!

I assume a function call would be better and faster i guess.... but old basic fellas like me grew up with the old trs-80 in the 80's and i cant seem to shake off using the gosub / goto commands...lol

ok im ready to get burned now....

Development & Editting
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 20th Jan 2011 07:19
OK I've updated the thread to include some new ideas that increase compatibility with DBPro, and the examples now go from being DBPro like to more complex as you go down.

Quote: "My concern is that if you change the DBP style script too much, it won't resemble BASIC anymore and become a sort of 'easy to use C++'"


Good point, I made a few changes to my examples to showcase just how backwards compatible the system is. The major thing I changed was how arrays are handled, I think it's a massive mistake copying the ancient Dim system just for the sake of remaining true to DBPro. Arrays in DBPro are so vastly different in terms of syntax to anything else that I think retaining them is detrimental to the idea of keeping the language simple. I believe suggested syntax of 'identifier as Array of SomeType' is more in line with the rest of DBPro's syntax than Dim.


Quote: "Maybe it's an over-reaction, but when I see a request for advanced data types"


I don't think any of the data types suggested are advanced in terms of usage. Almost all code I see written in DBPro handles vectors as three distinct variables that get passed around everywhere, even basic operations like adding velocity to a position is really messy. If vectors were implemented like HLSL into the core language, then it would make the code highly readable as the user doesn't even need to know what's happening most of the time as shown in some of my examples.


Quote: "C style command declarations"


Where? I thought I stayed pretty close to DBPro's specs, if anything it's similar to lua in that functions would be first class. Of course you'd still maintain the 'Function identifier( args ) EndFunction ret' syntax, but allowing the optional 'identifier as Function' increases the consistency between other types.


Quote: "and OO I wonder why it would not be more gratifying to switch to C++ and call the AppGameKit API directly (Tier 2)?"


My OO suggestions are merely simple extensions to the existing UDT system, I updated the examples to show there would always be function variants of the methods for each type should you want them. I didn't suggest RAII or any form of inheritance because they do stray beyond what DBPro was about. As for C++, it's not really geared toward making games quickly, if AppGameKit is great from the start then there may not be a need to use the C++ API.


Quote: "One of my aims with Tier 1 (the DBP style script) was to keep the unique 'ease of use' qualities that BASIC provides. There is a freedom to using a variable without the need to declare it, identifying and creating a string variable using the $ symbol without jumping to the top of your program to type 'as string' and similar scenarios that save these little bits of time."


I didn't suggest these be removed, but I didn't exactly make that clear so I've updated it, including in all my examples. I think DBPro's existing 'print a + b' ability(without any prior declaration) is a huge mistake, and # and $ are also mistakes that make the language more complex for beginners. But I fully agree with the ability to automatically deduct types from assignment, else 'for i = 1 to 10' wouldn't be possible.

Take a look at my 'Images with the AppGameKit concept' example, it does away with the index based resource system and hides that the Image is in fact an object, the user can even pretend it's an integer, I think the resulting code is more elegant and is easier to grasp.


Quote: "I suppose what I am curious about is whether we want to turn BASIC into something more like C++, or whether the idea of a Tier 1 (script) and Tier 2 (C++) approach allows the BASIC script to remain 'simplified' and the C++ code to be as sophisticated as you need it to be."


C++'s goal in life is to be the highest level language that still maps as closely to asm as it can get away with, DBPro aims to be a highly readable language aimed at quickly developing games. So turning AppGameKit into C++ would be a mistake, given what you say about tier 2. But that doesn't mean you can't naturally extend existing features that are almost really useful, and depreciate old features that no longer make sense.

Fatal Berserker
13
Years of Service
User Offline
Joined: 2nd Jul 2010
Location:
Posted: 20th Jan 2011 10:25
X++ is the same as X+=1
and its in most C languages.
X-- is the same as X-=1;

baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 20th Jan 2011 10:53
Quote: "I like using gosub...lol

haha ill get burned for saying that!"

Me too. I use it for my setup routine so I can set my UDT's up in their own little sub-routine and then use functions (mostly) for everything else...

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 20th Jan 2011 12:20 Edited at: 20th Jan 2011 12:21
Lee, I think the main problem with just using Tier 2 is that we then have to buy licenses, and recompile our code to support all the different platforms, whereas with Tier 1 we can instantly run it anywhere with no extra hassle.

Also, some of these features (like exceptions) would not change the syntax of the language at all for people not using the features. Lets say you want to load an image using AGK. IMO, there should at least be a way to detect when an error has happened rather than just showing an error and then ending.

Vectors and matrices are already implemented in DBPro but are accessible by an index rather than usable directly. Surely it would actually be simpler from the user's point of view to treat them like just another datatype?

Finally, some way to have arrays in UDTs is just necessary. You can work-around using a few single dimensional arrays, but you lose both speed and readability by doing it that way, and you don't force any more complexity on the user because they can still use whatever method they want.

[b]
thenerd
15
Years of Service
User Offline
Joined: 9th Mar 2009
Location: Boston, USA
Posted: 20th Jan 2011 13:16
Quote: "X++ is the same as X+=1
and its in most C languages.
X-- is the same as X-=1;
"

Ah, yes. I don't usually code in any C languages...

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 20th Jan 2011 17:40
Some good suggestions there.

But what's the point of the array data type (or the DIM command for that matter)? Isn't the following far simpler - especially if implemented with first index 1 as in your suggestion? A zero for the first dimension could be used to indicate an empty array.

knxrb
FPSC Tool Maker
15
Years of Service
User Offline
Joined: 10th Oct 2008
Location: United Kingdom
Posted: 20th Jan 2011 19:34 Edited at: 20th Jan 2011 19:36
I think it would be beneficial to add 'Redim' and 'Redim Preserve' commands to it (unless you've got arrays the same as they are in DBPro already):

Redim would let us dim an array again removing all data in the array:

After executing the above you would end up with an array called 'myArray' with 21 available spaces, all blank.

And Redim Preserve would dim the array again, keeping all data currently in the array intact:

After executing the above code you would end up with an array called 'myArray' with 21 available spaces and all data intact, meaning myArray(0) stays as "Hello".

knxrb
kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 20th Jan 2011 20:08 Edited at: 20th Jan 2011 20:08
You can just call Dim again and it will change the size of an array and preserve all the data.

Example:



Will print "Hello" to the screen.

knxrb
FPSC Tool Maker
15
Years of Service
User Offline
Joined: 10th Oct 2008
Location: United Kingdom
Posted: 20th Jan 2011 20:18
Yeah, I know you can do that in DBPro but I want to make sure the devs know that it's wanted in AppGameKit just incase they changed the way it worked or removed it for any particular reason.

knxrb
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 21st Jan 2011 05:11
Quote: "But what's the point of the array data type (or the DIM command for that matter)? Isn't the following far simpler - especially if implemented with first index 1 as in your suggestion? A zero for the first dimension could be used to indicate an empty array."


Good point, I didn't think about multi dimensions!

However, I'm not sure if your syntax would be friendly for passing arrays to functions, assuming the passed array size isn't known, the declaration would have to look something like: 'function a( passedArray[,] )' for 2 dimensions right? If it instead used separate brackets for each dimension then the declaration would look like: 'function a( passedArray[][] )', which I think is clearer? Anyway I'll change my array idea in a bit, as this is better and increases consistency.


Quote: "I think it would be beneficial to add 'Redim' and 'Redim Preserve' commands to it (unless you've got arrays the same as they are in DBPro already):"


Can you explain why you think the 'Dim' construct should even remain in the language? Besides it being a carry over from BASIC I think it's incredibly inconsistent with the syntax for the rest of the engine. Not to mention Dim/Redim and whatever are very bad names, having ResizeArray and such would be nicer.

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 21st Jan 2011 13:21
I prefer the simpler "function a( passedArray[,] )" to "function a( passedArray[][] )" but don't feel strongly about it.
Nomad Soul
Moderator
17
Years of Service
User Offline
Joined: 9th Jan 2007
Location: United Kingdom
Posted: 22nd Jan 2011 03:19
Will AppGameKit have shader support?

Zotoaster
19
Years of Service
User Offline
Joined: 20th Dec 2004
Location: Scotland
Posted: 22nd Jan 2011 06:33
If references are supported, then it would be nice to have inheritance in UDTs, even if there is no OOP.

Even as a procedural language, it would be able to have some support for virtual functions, using function overloading (which should also be a feature). This will greatly decrease development time for many things.

Consider this example. If I wanted to create two different entity types, as things are, I would have to do this:



As you can see, without references, I need an array, and without inheritance, I need two functions to do essentially the same thing.

However, with references + inheritance, I can do this:



Now here, I only need to write one function, which takes an Entity reference, and is able to directly change it's value. Since references are just pointers, and references of all types are the same size, any reference type can be passed in, and since, in this example, Objects and Lights are Entities, they can be accepted as parameters, since they are known to have the 'x', 'y', and 'z' fields.

"everyone forgets a semi-colon sometimes." - Phaelax
Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 22nd Jan 2011 11:31
I'd like simple inheritance too, but it would only make sense if TGC added support for passing parameters by reference.

[b]
HowDo
21
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 24th Jan 2011 20:00
could AppGameKit have two way library calling system were if you find the dll of which ever device you are writing for, you could than call device dll and send or receive the data.

meaning if a device has an add on that would be useful to use in the making of the app, then you just call the device dll.

Dark Physics makes any hot drink go cold.
Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 24th Jan 2011 20:40
Quote: "using function overloading (which should also be a feature)"

Agreed

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 24th Jan 2011 21:45
@HowDo
I'm fairly sure windows is the only system which uses .dlls, although there are equivalents for some of the other platforms.

[b]
HowDo
21
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 25th Jan 2011 16:46
Quote: "@HowDo
I'm fairly sure windows is the only system which uses .dlls, although there are equivalents for some of the other platforms."


As I don't know what they used in other system I used dll as a way of expressing what I was thinking.

Dark Physics makes any hot drink go cold.
Lost Dragon
13
Years of Service
User Offline
Joined: 22nd Aug 2010
Location:
Posted: 27th Jan 2011 04:51
I wish that the IDE hint/help system would bold parameters as I clicked on them.

Say I have paste sprite s, xp,yp

When I click on "paste sprite" in the IDE it gives me the syntax for that command in the lower left corner. That's nice, but I'd like for each parameter to be in bold as I clicked on it. So if I clicked on S, the hint would have the word SPRITE NUMBER in bold. That way I know I'm on the sprite number. If I clicked on xp it'd have X POS in bold. If my commas are screwed up, I now know right away.

It's simple and nicer than it probably sounds - especially nice for your own home-brewed function that has 5 or 6 parameters.

It'd also be nice if this functionality made it over to DBP...
Jeff Miller
19
Years of Service
User Offline
Joined: 22nd Mar 2005
Location: New Jersey, USA
Posted: 27th Jan 2011 21:30
You could achieve the "1 base index" result, which does have advantages in some situations, and still maintain the flavor of Basic by including the Option Base command that appears in other forms of Basic. If someone wishes to have the first index as 1, they use Option Base 1 before declaring their arrays.

Similarly, for those who wish to be forced to declare all variables, you could add the Option Explicit command. Those who do not wish to be forced can merely not use the command.
Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 27th Jan 2011 21:59
I'd prefer it if there weren't too many compiler options, as it will cause problems when attampting to share code. Option explicit is one of the few I think are worth-while.

[b]
Jeff Miller
19
Years of Service
User Offline
Joined: 22nd Mar 2005
Location: New Jersey, USA
Posted: 28th Jan 2011 03:43
TWO options are not "TOO many compiler options" TO cause problems. (I've been lying in wait to use all three homonyms in one short sentence). Both are well-established in prior species of Basic. I think I've been using them (other than in DBPro) for about 20 years or so.
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 28th Jan 2011 04:20
There have been other suggestions for compiler settings too, like case sensitivity. I'm personally against all compiler settings that alter the way code has to be written, because as Diggsey says, it will hamper the ability to easily share code; People would have to specify a list of compiler settings to go with every snippet.

Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 28th Jan 2011 10:03
I have to agree that compiler settings for such things would be annoying when sharing code, unless the options could be set from the source itself (a compile directive).

Quote: "(I've been lying in wait to use all three homonyms in one short sentence)."


Homophones.
Jeff Miller
19
Years of Service
User Offline
Joined: 22nd Mar 2005
Location: New Jersey, USA
Posted: 28th Jan 2011 12:58
Then is it possible to make "Option Explicit" a default IDE setting that does not affect compilation in any way? The user could switch it on/off. It would have no effect other than to cause the user's IDE to highlight an undeclared variable in something like obnoxious brown. The IDE's are making my code look like a rainbow already.
Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 28th Jan 2011 13:11
Just make directives localized to the source file.

BiggAdd
Retired Moderator
19
Years of Service
User Offline
Joined: 6th Aug 2004
Location: != null
Posted: 30th Jan 2011 15:03 Edited at: 30th Jan 2011 15:04
Don't forget to add the ability to return a UDT from a function, which is my major niggle with DBPro. That and default UDT values and UDT scope, but they are already in the list.



Gunner
20
Years of Service
User Offline
Joined: 9th Apr 2004
Location:
Posted: 1st Feb 2011 20:32
Comments on coding AppGameKit in c++.
I think going from Basic like syntax to full c++ is too much of a jump for most.

My preference would be GDK basic script with survey additions implemented (no spaces,[]...etc)
Or
Adopt a standard language that's between the two, Actionscript or javascript.. Both quite easy to use and you're learning industry standards as you code games.

Anything but c++
Lost Dragon
13
Years of Service
User Offline
Joined: 22nd Aug 2010
Location:
Posted: 7th Feb 2011 05:49
I'd like to see improved compiler error messages and detection. More than once I've seen "syntax error" with no line number. Or worse, I accidentally declare the same constant twice and end up with some generic nonsense error.

I know this can be improved upon because Purebasic handles it a lot better.
Neuro Fuzzy
16
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 14th Mar 2011 07:11
I just really really really want operator overloading.

LeeBamber
TGC Lead Developer
24
Years of Service
User Offline
Joined: 21st Jan 2000
Location: England
Posted: 18th Mar 2011 05:37
I think we will have to take things a few steps at a time, as there is clearly a lot of wishes on this list As to the issues of using Tier 2, there would be no additional costs or troubles. You can download the Visual Studio Express Edition for free, install AppGameKit Tier 2 and start coding in C++ right away. No licenses or costs to worry about for platforms such as Windows, Samsung, MeeGo, Browser, e.t.c. For others you would need a Mac for iOS and MacOS development.

I take the point about augmenting the AppGameKit compiler to provide more industry favourite features in the Tier 1 script, as the advantage is that your finished app is instantly publishable to all devices hassle free. I think if there is a majority verdict that the feature is much needed, then it's worth adding, but we'll have to do this step by step. Making a laundry list of features does not make it so From this entire thread, can everyone agree on what is the most important ONE feature that absolutely needs to make it into the first release of AppGameKit? Perhaps returning UDT data types from functions?

I drink tea, and in my spare time I write software.
DMXtra
21
Years of Service
User Offline
Joined: 28th Aug 2002
Location: United States
Posted: 18th Mar 2011 11:12
Returning UDT data types from functions is the feature I would like to see added from this thread.

Dark Basic Pro - The Bedroom Coder's Language of choice for the 21st Century.

Login to post a reply

Server time is: 2024-04-20 17:06:37
Your offset time is: 2024-04-20 17:06:37