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 / Spaces in command names

Author
Message
Mike Johnson
TGC Developer
21
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 21st Jan 2011 10:54
Rather than keep everything in one big thread I will make a few threads so we can keep on topic for one issue.

In the previous thread I mentioned about removing spaces in command names. It looked like there was plenty of support for this so commands go from:

Load Image "your image.png", 1

to

LoadImage "your image.png", 1
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 21st Jan 2011 11:40
If you do take out the spaces, make sure that it isn't case sensitive so people can choose whether they put capitals on individual words. - I personally hate having to have my finger hovering over shift while I'm coding and like to just freely spam text that does stuff but I can also see the advantage in coding like that.

baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 21st Jan 2011 12:10
I agree, keep it none case sensetive and take out the spaces.

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 12:47
On topic: definitely no spaces.
Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 21st Jan 2011 12:56
No Spaces

Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 21st Jan 2011 12:58
Since it'll make parsing easier, no spaces.
bitJericho
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location: United States
Posted: 21st Jan 2011 14:41
I don't care either way.

[center]
Join the TGC Group!
http://tehcodez.groups.live.com
Help people
13
Years of Service
User Offline
Joined: 4th Oct 2010
Location: Tombsville
Posted: 21st Jan 2011 15:00
No spaces ... and thanks for the information...

thenerd
15
Years of Service
User Offline
Joined: 9th Mar 2009
Location: Boston, USA
Posted: 21st Jan 2011 15:37
No spaces.

swissolo
14
Years of Service
User Offline
Joined: 9th Jan 2010
Location:
Posted: 21st Jan 2011 15:53
No spaces

Although I doubt anyone will agree with me, I like using _ as space, so it's separted, but still one whole word.
load_image()

swis
Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 21st Jan 2011 16:14
No spaces

@swissolo
The only bad thing about that is that it's slow to type _ compared to other letters.

[b]
swissolo
14
Years of Service
User Offline
Joined: 9th Jan 2010
Location:
Posted: 21st Jan 2011 22:33
Yep, completely aware of that, I got really used to using it in my variables, but I don't expect it to become a norm. Speed to type is the same reason I didn't like having sync with brackets... sync() instead of sync. I see everyone's reasoning, but I don't quite understand why it's so important... Doesn't really matter.

swis
LeeBamber
TGC Lead Developer
24
Years of Service
User Offline
Joined: 21st Jan 2000
Location: England
Posted: 21st Jan 2011 22:43
Looks like the 'no spaces' camp have it Imagine all those saved key presses and 'every so slightly' shorter commands!

I drink tea, and in my spare time I write software.
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 23:22
Thread lock? Or am I jumping the gun.
Brk_oth
18
Years of Service
User Offline
Joined: 8th Aug 2005
Location: Australia
Posted: 22nd Jan 2011 05:47
no spaces and im glad that basically everyone else thinks the same.

No signature found...
DMXtra
21
Years of Service
User Offline
Joined: 28th Aug 2002
Location: United States
Posted: 22nd Jan 2011 08:10
No spaces
No object numbers

AGK should manage Object numbers, I shouldn't have to do that as it's 2011 and nobody should manage object numbers except AGK.



This in my opinion is just better to read and to code.
No image numbers for anyone to manage and remember.

No spaces in commands, easier to manage, easier to read, case insensitive (why should the computer worry how I type things, it should know what I mean--again this is 2011).

Spaces are confusing to humans and to the IDE and it's more to type for no reason and it looks sloppy.

Dark Basic Pro - The Bedroom Coder's Language of choice for the 21st Century.
Fatal Berserker
13
Years of Service
User Offline
Joined: 2nd Jul 2010
Location:
Posted: 22nd Jan 2011 20:53
Quote: "No image numbers for anyone to manage and remember."

You can already store that in a const variable.
But how do you propose we loop through every object from X to Y?
Storing them all in an array seems abit wasteful of time and resources.

The Slayer
Forum Vice President
14
Years of Service
User Offline
Joined: 9th Nov 2009
Playing: (Hide and) Seek and Destroy on my guitar!
Posted: 22nd Jan 2011 21:39
Having no image (or object, sound, etc...) numbers, would really cause issues, IMO.
How would you find the right image back if you'd had 500 images, all declared like this:



or even like this:



???



SLAYER RULES! YEAH, MAN!!
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 22nd Jan 2011 21:44
Store the values in an array perhaps?
The Slayer
Forum Vice President
14
Years of Service
User Offline
Joined: 9th Nov 2009
Playing: (Hide and) Seek and Destroy on my guitar!
Posted: 22nd Jan 2011 22:09
Quote: "Store the values in an array perhaps? "

I'd rather have it the old way. Arrays and me don't go well together.

SLAYER RULES! YEAH, MAN!!
Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 22nd Jan 2011 22:49 Edited at: 22nd Jan 2011 22:50
Quote: "Arrays and me don't go well together."


That's a rather defeatest attitude

Under DBPro syntax it would look like this.
With object numbers:


Without object numbers:


One extra line in one scenario, but you completely remove the whole issue of either remembering which numbers have been used, or finding a free one (which wastes time).

(And for those about to "cleverly" point out that I didn't use index zero in the array, I left it to refer to an invalid/non-existant image)

[b]
DMXtra
21
Years of Service
User Offline
Joined: 28th Aug 2002
Location: United States
Posted: 22nd Jan 2011 22:50 Edited at: 22nd Jan 2011 22:52
This is what arrays are for. You can loop through them.

Remembering object numbers is very outdated and I don't know many languages that do that, except the dark basic kind. It is silly and not really needed. Arrays can do this nicely if you need to do a loop.

Edit, yep... This exactly... see how clean this is?

dim images(100) as Image

for i = 1 to 100
images(i) = load image("image_" + str$(i))
next i

paste image images(5), 0, 0

Dark Basic Pro - The Bedroom Coder's Language of choice for the 21st Century.
bitJericho
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location: United States
Posted: 22nd Jan 2011 23:28 Edited at: 22nd Jan 2011 23:30
I usually code like this



Of course, on hand-held devices where there's very limited ram, or on projects where you fear you could use up all the ram, I'd probably choose a different coding style.

Enumerations come to mind as being particularly helpful.



[center]
Join the TGC Group!
http://tehcodez.groups.live.com
The Slayer
Forum Vice President
14
Years of Service
User Offline
Joined: 9th Nov 2009
Playing: (Hide and) Seek and Destroy on my guitar!
Posted: 22nd Jan 2011 23:59
Quote: "Without object numbers:


"


My 'issue' is not with the loading part of images (or other media). I understand how to do it. But, my point is that no matter what, you still have to number everything that you load or manipulate.
And, suppose you dim 100 images, and later on in your program, you delete 10 of them, how do you find the right image back? If you remove 10 images out of an array of 100, the others have different numbers, right? Or, am I wrong?
When you number your images in DBPro (no arrays), it is easier to keep track of the image number.

Cheers

SLAYER RULES! YEAH, MAN!!
Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 23rd Jan 2011 00:55 Edited at: 23rd Jan 2011 00:58
Quote: "But, my point is that no matter what, you still have to number everything that you load or manipulate."


That's the whole point, you DON'T have to number everything!

Say I have a load of enemies stored in an array. Each has their own image to display. The UDT might look like this:


I can then do this to create an enemy:


Then to draw an enemy:


To call that function


No need for any image numbers. If I was to do that in DBPro currently, I'd have to first search through the images to find a free one, and then use that. You might say that the indices in the array are equivalent to ID numbers, but that's not true. It's perfectly safe to remove an enemy from the middle of the array without messing up all the others, as they don't depend on having a specific index in the array. Hence, new enemies can just be added at the end of the array, no need to search for a free slot.

At no point in anyone's code are ID numbers such as those in DBPro necessary. They were just invented by TGC to (supposedly) keep things simpler.

[b]
The Slayer
Forum Vice President
14
Years of Service
User Offline
Joined: 9th Nov 2009
Playing: (Hide and) Seek and Destroy on my guitar!
Posted: 23rd Jan 2011 01:21
Quote: "That's the whole point, you DON'T have to number everything!"

I think you've misunderstood my point. Whether you number an image (or anything else) with just a number, or do it thru an array, each image you create or load or manipulate gets their internal number assigned, right? How else can the interpreter know what image you refer to?
So, my point being, if you have an array of 100 images, and you delete 10 of them (i.e. numbers 7,20,31,50,57,64,70,71,80,85), what happens to the rest of the internal numbers assigned to the remaining images? Do they obtain their same internal number?

SLAYER RULES! YEAH, MAN!!
Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 23rd Jan 2011 01:28 Edited at: 23rd Jan 2011 01:32
No, there are no internal numbers They don't exist. They are simply an invention!

In the underlying C++ API these things are all identified using pointers (OK, so a pointer is still like a number, but it's not chosen by the programmer). These are addresses in memory where information about the resource is stored. When an image is created internally, DBPro has a big lookup table of all the image IDs against the pointers to the images, so that when you specify say 3 as an image ID, it will lookup 3 in the table, and see that it refers to an image at (say) memory address 0x15267350.

Doing it this new way, TGC can still hide the pointers and stuff from the user, but they don't have to maintain a load of lookup tables, and the user doesn't have to worry about finding free IDs.

[b]
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 23rd Jan 2011 01:40
That's half the story. The other half is the effect on your DBPro housekeeping. If, for example, you



then you need to note that myImageArray(5) no longer points to a valid image. A simple way to indicate that is to also do



immediately after deleting the image.

You can also use another array to point to the currently free array slots in case you want to load or create another image. Same goes for objects.

It's all very straightforward and what I'd do if I needed to handle large numbers of objects or images dynamically.
bitJericho
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location: United States
Posted: 23rd Jan 2011 11:22 Edited at: 23rd Jan 2011 11:25
Quote: "what happens to the rest of the internal numbers assigned to the remaining images? Do they obtain their same internal number? "


Well, in my example there's still image numbers. I like having the ability to use image numbers too, I'd like both ways.

Anyway, the routine for obtaining a free image number can be done any way the developers like.

DBPro does not have a built in method of finding an unused image (or object, sound, etc) number, but matrix1utils does have functions to do this. You can also manually write functions to do it in DBPro. Before matrix1utils, what I would do is have a global that would keep track of the last used image number. Whenever I'd request a freem image, with a function called "find_free_image()", I would increment that number, check to make sure that number wasn't being used. If it was being used, I'd increment it by one and check it again. Once I find a free image number, I'd return that number. If it hit the maximum value an image number can have, it would return back to 1 and check it to see if it's free.

With this method, it's very fast as long as it doesn't run into a block of used images. If you use up all available slots, it would cause an infinate loop and crash unless you check for that too. Matrix1utils uses random numbers last I heard. It's a very fast lookup too unless you have *a lot* of images being used.

[center]
Join the TGC Group!
http://tehcodez.groups.live.com
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 23rd Jan 2011 13:11
We've kind of gone off-topic with this thread really.

I understand where Diggsey is coming from: my networking plug-in uses the exact same technique of returning object memory addresses to be used as handles for other commands. It works, and it's simple, but as you have to also implement a method of validating the handles you are passed, it's actually no faster than using ID's.

However, I switched to using ID's again for everything else in my plug-ins, because it fit better with the DBPro way of doing things.

Personally, I have no problem with using either method.

Anyway, if TGC continue to use numbers for ID's, I'd be happy to donate my low-memory/fast 'FreeList' class to them if they want it (and even I'll document how it works so that it can be ported from C++). I might even be able to find my DBPro prototype of it somewhere, which uses a dynamic array implementation (or write it again otherwise).

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 23rd Jan 2011 13:17 Edited at: 23rd Jan 2011 13:18
You're just missing one small point If TGC implement them as a special type rather than an integer, there is no need to validate them. The user has no way to make them invalid.



And as an added bonus, it makes it impossible to pass an image to a bitmap command or something. The error will be caught at compile time rather than run-time.

[b]
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 23rd Jan 2011 13:33
Actually I was thinking about suggesting some kind of 'resource' type, and I think that would work pretty well. Under the hood it could be a sort of dynamically allocated reference which is assigned none/null when the resource is destroyed (which naturally means that the resource has to track all references to it).
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 23rd Jan 2011 13:40 Edited at: 23rd Jan 2011 13:42
@Ben,
You beat me to posting, so the this kinda follows what you've just said.

@Diggsey,
Ah, so you'd implement a handle type for each and every resource type and only allow assignment for those types and maybe for a special 'null' value?

In that case I disagree - there's still a need to validate handles. The following code is simple, but breaks without validation as it shows it's too easy to have an invalid handle:

Or are you proposing reference-counted resources and dropping the DELETE commands for them, so that if any handle still references that resource, the resource is kept in memory?

Also, how would third-parties provide handle-types for their own plug-ins that provide resources.

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 23rd Jan 2011 13:43 Edited at: 23rd Jan 2011 13:48
It would be like Benjamin said. When you delete a resource, all handles pointing to that resource are set to null/nil/nothing.

As for third party commands. It sounds to me like Tier 1 won't support third party commands as such? However, if it does, all resources could either use a common resource type, or the compiler could automatically pick up any extra resource types from plugins a bit like the DBPro compiler checks for dependencies.

At compile time they'd all get converted to the exact same thing anyway. The difference is only useful for ensuring that they are the right type at compile time.

[b]
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 23rd Jan 2011 14:34 Edited at: 23rd Jan 2011 14:35
Implications of what you suggest:
- each resource has to track handles that point to it to be able to clear them when the resource is deleted.
- when a handle goes out of scope, it has to remove itself from the resource's handle list.
- when a handle gets reassigned, it's equivalent to removing itself from it's old resources handle list, and adding itself to it's new resources handle list.
- you now need a new command to check if the handle points to a resource or not.

Depending on how the handle list is defined, that's a lot of list maintenance.

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 23rd Jan 2011 14:39 Edited at: 23rd Jan 2011 14:40
All of those things are already done for strings anyway, except that they are allocated and deallocated instead of added and removed from lists

[b]
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 23rd Jan 2011 14:50
No they're not. Strings are not shared resources.
- When a string goes out of scope, it frees the memory it points to. No scanning of resource lists required.
- When a string is assigned to another, the old string is freed and new memory is allocated for a copy of the source string. No scanning or inserting into resource lists required.
- No special 'delete' command is required, you just assign an empty string.
- No special 'exists' command is required, you simply test against an empty string.

Strings are completely different from the resource handling in my previous post.

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 23rd Jan 2011 15:00 Edited at: 23rd Jan 2011 15:01
What you do is different yes, but the triggers for those things are not. IE. it's already possible to detect when a variable goes out of scope. It's already possible to detect when a variable is reassigned. There's no need for another command to check for existance, just test it for equality against a null value.

As for speed implications:
- There's unlikely to be more assignments than commands used on a resource.
- Looking through a list of references, which probably only has one or two items in is quicker than looking up an ID in a table containing EVERY resource of that type.
- You just need a std::set<void**> per resource, which is not much overhead, and std::set automatically minimises the number of reallocations you need to do.

[b]
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 23rd Jan 2011 17:36 Edited at: 23rd Jan 2011 17:47
... or you could just reference count and not store those references you have to clear at all. That's my point.

Then you can use the exact same reference-counted implementation to track sprites that use images, so that the image doesn't disappear until all user references and all engine references are dropped.

Your method means that you have sprites without images.

Sorry to say that none of your arguments so far have convinced me that your suggestion is simpler, faster or easier.

[EDIT]Stuff it, I'll code the alternatives and see what I come up with.

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 23rd Jan 2011 17:53
TBH, I don't really mind which way it is done. Reference counting is perfectly fine if you think TGC will agree to that. The only problem is that certain things have a definite life-time, such as 3D objects, which could make it confusing for a beginner. I thought it was preferable to have a slightly more complicated implementation if it kept the language simpler and closer to DBPro.

[b]
bitJericho
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location: United States
Posted: 23rd Jan 2011 18:22
I don't mind either way. Holding pointers to resources in a variable or getting an id to stick in a variable, makes no difference to me.

[center]
Join the TGC Group!
http://tehcodez.groups.live.com
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 24th Jan 2011 00:27
Ok, I've coded 3 implementations, compared them, and thought through the implications of each, and right now I'm going to go with either the existing ID system, or dumb handles (the only difference is in who allocates the 'ID', you or the system).

For intelligent handles, there are the two methods of Diggsey/Ben, and mine.

I found no benefit to using the Diggsey/Ben method over using standard ID's - existence-checks are replaced by 'is the handle valid' checks, there's a constant overhead for adding/removing handles from internal resource lists (they get copied and destroyed whenever you pass one into a function), and there's a memory overhead on a per-handle basis, and then you still need to manually delete the resource when you are done.

Although there were benefits to the scoped handle method I suggested, there was one great big problem with it - global variables, by definition, never go out of scope, so if a handle is stored in a variable at that scope, the resource is never deleted automatically, and can only be deleted by assigning a 'null' handle to the variable, and then you need to provide a function to check if the handle is valid. At this point, you're in a worse position than other methods, because sometimes you leave it to the system, and sometimes you don't and a beginner will make mistakes with that. In addition, it's kind-of counter-intuitive in a beginners language to use variables and not commands for controlling resource lifetimes.

Basically, all the new suggestions are pants, and we should stick with ID's.

Code is available for all three via email on request (it's quick-n-dirty code just to check things out, so don't expect too much).

dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 24th Jan 2011 01:23
I'm still not sure I see the problem with Diggsey's idea of deleting a resource automatically null-ing all references to it. In non-fictional code, you'll only hold a single reference to an object which would normally be in a UDT of some kind, or in a global variable called 'skysphere' or something.

The only difference I can see from using integers and an actual resource type using the above method is that this would be less prone to errors. In DBPro, you can delete a resource and all references to that ID would still remain, not to mention checking for its existence isn't a decent way to determine if it's been deleted or not, because a new resources with that ID could have since been allocated.

That's a bit of a minor issue, because as mentioned above, you'd only typically have a single reference to each resource, but it also means functions cannot discriminate the input resource type. Meaning it would be perfectly possible to pass a bitmap ID to a function expecting an image, and if an image exists with this ID then the function has no way of knowing if you made a mistake.

As a result of the above, you'd almost force Hungarian notation on either the arguments or function name. So I don't really see the advantage of using IDs, and introducing a garbage collector is a whole different story, as DBPro pretty much acts exactly like native C++ in terms of memory allocation.

DMXtra
21
Years of Service
User Offline
Joined: 28th Aug 2002
Location: United States
Posted: 24th Jan 2011 12:58
I vote for the system to keep track of IDs. Who wants to set out variables and arrays to do all of this. Just let the system manage this and we are good.

Dark Basic Pro - The Bedroom Coder's Language of choice for the 21st Century.
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 24th Jan 2011 14:17
@dark coder,

Taking Diggsey's/Ben's suggested handle mechanism:

Yes, you yourself would likely hold a single handle to a resource, but then you pass it to a function that you have written or even a TGC-provided command: now the handle has to be copied and now you have two handles (or more if that passes it to another function). Now you are into multiple handles per resource, and that has a cost in handling the addition and removal of those handles to the resource's internal list of handles as those handles are created and deleted.

In the code that I have thrown together, I can make it cheaper to add and remove from the resource's lists, but only at the cost of tripling the memory usage for a handle to 12 bytes each, thus making it more expensive to pass those handles around in the first place.

The only answer that I have is that dealing with handles in this way is more expensive than ID's, and has no clear benefit over them that I can see.

That's separate from an unintelligent handle, which has a type distinct from the languages other types (so an image handle can only be assigned to another image handle). That would be a cost-neutral method of using handles over ID's.

dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 24th Jan 2011 15:09 Edited at: 24th Jan 2011 15:10
Quote: "Yes, you yourself would likely hold a single handle to a resource, but then you pass it to a function that you have written or even a TGC-provided command: now the handle has to be copied and now you have two handles (or more if that passes it to another function). Now you are into multiple handles per resource, and that has a cost in handling the addition and removal of those handles to the resource's internal list of handles as those handles are created and deleted."


I thought we were talking about AppGameKit itself here, why would the C++ back end need to be integrated with this handle system? A call to PasteImage() for example would only require a read-only image, as there's no way you could delete it during this call. The only exception I can think of is assigning resources to other resources, such as the Sprite() command or TextureObject(), but such things could trivially be done using a simple resource counter combined with the AppGameKit handle list.

Sure, passing a resource to an AppGameKit function would require another handle list entry, but realistically this isn't going to be done during runtime, and I think you're making the overhead seem more significant than it is.


Quote: "That's separate from an unintelligent handle, which has a type distinct from the languages other types (so an image handle can only be assigned to another image handle). That would be a cost-neutral method of using handles over ID's."


This should at least be in there as a given.


I think your reference counting suggestion would make the syntax a bit too different from DBPro, as the resource deletion commands would no longer be required. But there's an alternative to this that would combine both suggestions:

Inside the internal Image class there would be a boolean that specifies if the image exists and there would be a reference count(these could be mapped to just use 1 byte), so any operation like PasteImage or ImageExist or maybe just 'if myImage then' would first check if it existed. Calling DeleteImage would free the image data and set the boolean to false(thus all image commands on this resource could be set to raise an error). Then once all handles are reassigned or nulled, the ref count would reach 0 and the class itself would be freed.

Zotoaster
19
Years of Service
User Offline
Joined: 20th Dec 2004
Location: Scotland
Posted: 26th Jan 2011 15:04
Quote: "Yes, you yourself would likely hold a single handle to a resource, but then you pass it to a function that you have written or even a TGC-provided command: now the handle has to be copied and now you have two handles (or more if that passes it to another function). Now you are into multiple handles per resource, and that has a cost in handling the addition and removal of those handles to the resource's internal list of handles as those handles are created and deleted."


Are we talking about reference counting here? Because if we're not, I don't see why each resource would need to know what's referencing it. Even if we are talking reference counting, the resource doesn't need to maintain a list of handles to it - only how many references it has. One byte is quite enough for this. Also, I had assumed that by passing a handle to a function, you'd be passing a reference rather than doing a deep copy. I must have missed something obviously.

Either way, I vote for handles. Not just any handles, but pointers to the resource. Yeah this can be dangerous if you give the user too much control over them, but they don't need that much control if they don't plan on doing any fancy pointer arithmetic or anything. Reference counting would also be nice, but that raises two problems: circular references, and the fact that users aren't really that sure when their resources will be freed. Manual reference counting is a good solution, but not exactly intuitive to novices.

"everyone forgets a semi-colon sometimes." - Phaelax
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 26th Jan 2011 20:23
Diggsey and I were discussing types of handles - I was advocating reference-counted handles (which I later back off of due to the issues you raise), and he was advocating handles that when a delete was carried out against one, all handles pointing to the same resource were also cleared automatically.

See the download in your thread, particularly the readme, which contains a rough performance comparison of all 'intelligent' handle methods discussed.

(BTW, if reference counted handles could be made to work, it'd be hands-down the winner).

Digital Awakening
AGK Developer
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Sweden
Posted: 1st Feb 2011 19:44
Oh do you go off-topic fast or what!

Here's another vote for removing spaces. Case insensitivity gets another vote here as well.

And can we please not have object/sprite/sound ID numbers? When you code anything bigger they need extra code to work with.

[center]
Gunner
20
Years of Service
User Offline
Joined: 9th Apr 2004
Location:
Posted: 1st Feb 2011 20:03
My vote:

Please nooooo spaces

Also, Commands(x,y,z)
Case insensitive

Blocking can be {} or if endIf..etc as long as there's no spaces between words.

I also prefer dot punctuation when accessing members as opposed to /.
Sprite.x not sprite/x

Just covering all bases since TGC is re-evaluating syntax

Login to post a reply

Server time is: 2024-04-19 14:33:19
Your offset time is: 2024-04-19 14:33:19