Ownership surfaces

[Rhino123]

We programmers are by nature very shy and don't dare to say anything to someones face directly, so we revert to chatting and posting messages ;^)


no all kidding aside, Jape is working at home and Jacco is indeed sitting a few metres away from me.

By setting the discussion online, other people can add their 2 cents where possible.

Although we are omnipotent, we do sometimes ask the others for input

[Phantom]

Ehm, no, well, actually, Reinier and I are in the same office. Jaap is 'working' from his home at the moment. That's because he can't afford an apartment at a decent distance from the office with his salary, hehe.

[s9801758]

[Johan]

All ideas are crap..

You´re loosing the OO thinking here.. Why should the end user have to struggle with smart pointers and surface memory allocations just to draw a sprite?

I believe a referencing / subclassing system like the one used in 3dsmax would be most efficient, and I will be implementing a similar one in gapidraw (sprites are so easy to do, but still everyone feels that sprite support is important for a library).

(1) Let each sprite be a surface. Draw to the sprite and you draw the surface. Delete the sprite and you delete the surface. Use subclassing to inherit from a surface to the sprite.
(2) 15 similar bullets? Create a new sprite and pass an option to let it reference to the first one. The referencing could be done using simple multiple-to-multiple references (change base -> all references change, change reference->all other changes). Draw a change to one of the bullets and all other bullets will change instantly. Going the 3dsmax way, one could also add an option that it you can override some properties of the base object, and the ones not overridden will still be used as they are in the base (change base -> all references change, change reference->no other change).
(3) What happens if I delete the "base sprite".. Won't that crash the application? Not if you use an internal referencing system (delete base -> notifies all childs, delete child -> notifies base).

[Edited - changed some errors in (2)]

/Johan

[s9801758]

"You´re loosing the OO thinking here."

Maybe so, but OO is highly overrated anyway. It may be the trendy-paradigm of the 90s and the first couple of years in the twentyfirst century, but people will find out that different paradigms work for different problems. OO is not the end of all means. If meta-programming, generic-programming, functional-programming, imperative-programming, object oriented-programming, generative programming or any other yet-to-be-discovered or ancient paradigm fits my problem better, you can be fairly certain I'll be using it instead.

"Why in the earth should the end user have to struggle with smart pointers and surface memory allocations just to draw a sprite?"

I agree. In fact, why in the earth should the end user have to worry about anything? Instead, let's provide a FrameGame::DoFunky3DQuakeClone() to the user. He'll call that and his game is done. Simple eh :).

Kidding aside, we want to provide flexibility yet ease of use to the client. These are two contradicting wishes, and we have to maintain a balance. Whether we/you/anybody thinks smartpointers belong on the other side of the balance is one of the reasons of this discussion.

We can't ignore that smartpointers provide a easy and effective solution to many ownership-difficulties. But they come at a cost, and in reallife situations the client will end up with smartpointers too. So in that regard, you are correct.

However, I'm at a complete loss on your proposed solution.

How do you implement such a subclassing technique? You can't inherit a bullet from a sprite such that all 15 bullets will share the surface.

Could you elaborate, maybe with a simple code sample?

Thanks,

Jape

[Johan]

Hi,

I wrote the first post while eating breakfast and watching tv.. I changed my proposed solution..

[s9801758]

Uhmm....

how exactly does your solution not rely on smartpointers? I agree, your referencecount (or -link) and the pointer itself are stored in different locations, but the fact remains that you are keeping track of the amount of reference to a particular resource.

Smartpointers just provide a different syntax for your proposal, but maintain the same semantics.

With one big difference however. Your solution has an explicit owner. So we have 15 bullets, of which one is the boss. What if that bullets collides with a wall first and then explodes. It has no reason to exist anymore, but its children will. What to do?

Create 16 bullets? One eternall living one, and 15 referencing bullets? That's how we have it now. You create an eternal surface and let the sprites reference it.

Cheers,

Jape

p.s. where eternall means: "as long as possible future sprites may want to use it"

[Johan]

Um. Yeah. I think I actually ended up with the same solution as the one you already have. 16 bullets.

I should get back to my documentation project now I guess..

[D]

hmm...I implemented something like what you guys are discussing for the game I'm working on.

The way I have it is that I give a unique ID for each sprite. I had it so that the filename contains a number used as an ID (I know it's kinda hacked...) then I just check if that ID exist, if so then just add a reference. I could've used the filename as an ID but that would take too much space.

I'm thinking that the for the smart pointer, just let the client manually add references. Short and simple.

So is this going to be added to 0.99?

[Phantom]

All proposed solutions are quite simple, so we should be able to add this tomorrow once we all agree (or once I decice;) ). So yes, this should be in 0.99.

There will be more of course. But it looks like the libraries are stabilizing. Most of the time is going to the GPRS stuff. That is such a disaster to code for. We have a round trip delay of 1.6sec minimum, we have a 'permanent connection' that needs to be set up using a shabby API with lousy documentation, we have to protect the stuff so we don't get hacked in the first week, we want slow comms in threads and so on and so on. All stuff that you guys won't be using, but it has to be done and it has to be done well.

Why am I whining about this here? Sorry.