Sorry your browser is not supported!

Agreed, but I've deliberately avoided tinkering with too many low-level detail at this point - I was comparing methods, not opportunities for optimisation (although that last alternate piece of code kind of strained that rule).

Another alternative is to use some sort of small-object allocator, as each of these handles are only 4 bytes in size (not tested, but it looks right).

I'll think about the testing structure itself ... but I'll do that tomorrow.

i would only like this idea if it was:
hero.LoadObject("mupkidz.x");
and we had other commands like that (hero.PositionX())

cos otherwise this would just be annoying, if u want names than just do:
const int hero = 4;

LoadObject(hero,"mupkidz.x");

That doesn't make sense. How can you do hero.LoadObject when hero is not set to anything yet?



Which only works for the most basic programs possible. The whole point of having handles is that you don't have to search for a free ID each time you make an object. Also these are not names, they are variables.



Why? Having to remember which object numbers you've used is annoying. What could be simpler than this:


It's just the same as using an integer:


An object is just treated like any other type this way.

Object hero = new Object();....
hero.LoadObject();
hero.Position();
hero.Move()
hero.Delete()

Object[] heroes = new Object[100];

foreach(object _hero in heroes)
{
Object _hero = new Object();
_hero.LoadObject();
_hero.Position();
_hero.Move()
_hero.Delete()


}

Programming like this allows for powerful intellisense. And i did mean to say names and not variables....

I like what Fatal Berserker has proposed. That looks like a timesaver and will result in very clean and easy to follow code.

But I think it should look like this:


Doing something similar using types would require a whole lot more code. This would do wonders for new programmers, it just makes sense.



Oh, and having done a pretty big project in DBP once, I do not like all the extra work of dealing with object numbers etc.

So is hero a integer relating to an object number, is it a type, is it an internal structure, is it a pointer?

I don't think it can work like that, because we might not have a say in what is performed when creating a new sprite. For example, I mentioned early on that I'd like to see a standard entity type, so sprites, sounds, pointsprites etc could all share common position and movement vectors. I have this in my OpenGLES engine for iOS, and it is pretty handy - when creating a new sprite, I can decide what variables are set to what, during creation, after creation, whatever I need. But if we can't add to NewSprite(), then it'll be the same amount of work as it is with DBPro. Rather than assigning 100 sprites with 1 call, which I've no idea how it could work - It would have to know the number of indices, and how to get back to the array name. We can't really work like this without proper class support - then AddSprite() could be a function in your own sprite class. It's doubtful that AppGameKit will allow this IMO, and the minute you need something extra, all that DBPro style workload comes flooding back.

I think your 'hero' sprite would have to be a read-only, but deletable object ID, so you can create it and assign it a free object ID, then load it's image, set it's position, whatever you need. But hero would only be a reference, if you needed hero to be a type, with position, mode, velocities etc, then you'd need a component in that type to hold the object ID.

So it kinda digs up my old point on page 1 - there is little chance of AppGameKit supporting classes, so is there anything that could be done to help move away from For...Nexting every little thing. Things like, along with having position data, add in X and Y velocity and weight as well, the things that Box2D will need anyway, but could ultimately save us a lot of coding and time. So then I could have 'Hero.XS' return or set the X velocity - no need for function calls to return this data, it should be directly accessible, and it should replace/redundify (is that a word) whole chunks of our own handling code.

internal structure/internal class

and i dont think it would need to be readonly

Okay, let's say they would use

image = LoadImage("mupkid.jpg")

But when i want to load muuch mupkid.jpgs, then what, i gotta use arrays?

Like



Don't ask for what i need 200 mupkid images, it might be also done with load object.

What would you prefer instead? The whole point of an identifier is to identify a single object (even if that object is, ironically, a group of objects, but let's not complicate matters).

I don't see the point of hiding the implementation of something which should be as simple plugging an integer into whatever optimal data structure your code requires.

PureGDK, for example, has taken the PureBasic approach (this is for all PureGDK supported languages, C++ included!)

Normally you would create a cube like this:



You are required to specify the number twice if you want to store it in something. Or maybe you put it in a variable first. Bravo. However, your code now requires human intervention to handle your IDs.

Ok, so how about using some kind of iterative counter? But now you have to keep track of the allocating and freeing. Maybe you like this kind of control. But what if you want something a little more automated?



GDK_Any is a constant of value -1. If specified then the engine will take care of finding an appropriate ID for you. And if you pass a variable or constant integer yourself, that number will be returned to you for very easy assignment on allocation.

An added bonus is that this type of implementation is not hidden. It is described within the plugin used to build the headers for the target language. So if you prefer to use your own implementation, reference counting perhaps, or some custom "handle" or wrapper object, you're more than welcome to override the function's behavior.

For example, by applying an override template parameter and reimplementing the ID allocation and return type, you can perform something like this:



My solution in PureGDK was to provide what I felt was an optimal solution while still allowing the functionality to be overridden.

If reading this thread has shown me anything it's that everyone has their own opinion about which implementation would be most appropriate. Hiding the implementation hurts innovation.

If you really want some kind special kind of handling then instead of requesting a sweeping change in the engine, why not just implement it yourself?



I suggest keeping it an integer. We all know what a number is, how to compare it, how to increment it. If you want it to be something else then wrap it up into your favorite data type.



IanM, I do realize that you're just comparing methods but if you really want to do something fancy for DBP, please at least keep the engine exported as C function calls (please don't pass or return any objects) so those of us who prefer a more open implementation don't have to jump through hoops to get a simple object identifier.

Handles, I love handles. I don't love love handles though.

Hi Guys,

Can't believe I just read all this!! Phew, what a debate, and some great work thrashing out an optimum solution for resource handle management (my apologies for the GCSE description of this)!

Although using strong types to lock down different kinds of resources help the coder avoid mistakes and open up some nice optimisation opportunities (always welcome in a VM), Mistrel's post was quite close to my own thought process in that it robs the end user from overriding those handles with simpler forms of code, such as:

For N=1 To 10
LoadImage ( N, "anim"+N+".png" )
Next N
For AnimFrame=1 To 10
SetSpriteImage ( 1, AnimFrame )
Sync()
Next AnimFrame

By keeping the handles 'weak/dumb/integer/variable' containers as it where, you can use the new myimage=LoadImage("file") or the simpler LoadImage(1,"file") form. With handles, the latter form would not possible, and if it could be coaxed, it would stray away from the DBP model that attempts to create a very simplified starting point from which to grasp the concept of resources. As as example, here is the same program using strongly typed resource handles only:

Dim MyImages[10] As Images
For N=1 To 10
MyImages[N]=LoadImage ( "anim"+N+".png" )
Next N
For AnimFrame=1 To 10
SetSpriteImage ( 1, MyImages[AnimFrame] )
Sync()
Next AnimFrame

It's only a few extra lines but as you can see there is no way bash out the code without pre-declaring the array, and the code for specifying the sprite image gets bigger. More significantly we now have a lot more going on under the hood, with the VM now dealing with writing and reading to an array of handles, which in ASM terms means a few more cycles per instruction compiling raw and significantly more ASM if you wanted to check the array subscript against the size of the array (if it exists).

It's only a few little extras, but I'm having a hard time trading the relative ease, speed and interchangeable nature of using integers with the benefit of additional compiler warnings should the coder try to place a sound resource in a sprite command.

Put simply (so Lee can understand it), what other benefits are there to strong typed resource handles apart from improved resource handling for the coder? (apart from any gains we might make through passing a relevant handle directly to the command thereby skipping the ID look-up on each command call).

Agreed, but without handles you have the issues that DBPro has - possible links to resources that don't exist (object -> texture), and inefficient updates when updating resources (texture -> sprite).

It would be nice to have handles to those resources, as pretty much any code I write allocates resource id's and stores them in arrays anyway (so having id's adds a level), but it's not then end of the world if it's not available at the user-level.

If you check the pieces of code I posted, you'll see that I always took care to make sure the handles at 4 bytes in size, so there wouldn't be too much difference between holding an integer or a pointer.