Scroll object creation

duenez

Hello everybody,

Here I go again with my philosophical questions...

I am giving Scroll a go because I realized I basically was doing that functionality pretty much anyway.

So I find myself with this problem: It seems to me that the only supported way of creating ScrollObjects and have them properly initialized is via the main application class (i.e. the one that has the Init, Execute, Update, etc). This is a bit inconvenient because many times I am inside of an object, say the player, and I want to spawn bullets directly from there.

I know I can simply make the main application be a singleton and call the CreateObject from the outside, but this solution seems rather ugly. Is there a good reason to not have CreateObject be a static method, or have another way to create ScrollObjects that is more elegant? Am I missing something?

I can get around this problem, but I wondered what people would think.

Thanks a bunch!

duenez

Oh, and since we are in this topic: I realize that the One C++ object per One Orx object is a nice mapping, but again, if I want to have bullets have exactly the same behavior but with two different types of graphics for enemy and player bullets, it makes sense to have two Orx objects attached to one C++ object.

Is the only way around this to create boiler-plate classes that extend my bullet to have a 1-1 mapping?

Cheers,

iarwain

duenez wrote:

Hello everybody,

Here I go again with my philosophical questions...

Hi duenez, I like your questions and I hope you don't mind my answers!

So I find myself with this problem: It seems to me that the only supported way of creating ScrollObjects and have them properly initialized is via the main application class (i.e. the one that has the Init, Execute, Update, etc). This is a bit inconvenient because many times I am inside of an object, say the player, and I want to spawn bullets directly from there.

I know I can simply make the main application be a singleton and call the CreateObject from the outside, but this solution seems rather ugly. Is there a good reason to not have CreateObject be a static method, or have another way to create ScrollObjects that is more elegant? Am I missing something?

Only a small detail: your main application is already a singleton, that's the nature of Scroll (and that's also how ScrollEd can be embedded in your own game).
You simply need to call CreateObject on that instance, something like:

MyObject *poObject = MyGame::GetInstance().CreateObject<MyObject>("ObjectSection");

As long as we already have a singleton, mixing static and non-static methods would get a bit messy.

iarwain

duenez wrote:

Oh, and since we are in this topic: I realize that the One C++ object per One Orx object is a nice mapping, but again, if I want to have bullets have exactly the same behavior but with two different types of graphics for enemy and player bullets, it makes sense to have two Orx objects attached to one C++ object.

There isn't actually a 1-to-1 mapping between ScrollObjects and orxOBJECTs. An orxOBJECT maps to a single ScrollObject, but it's not reciprocal. You can have many orxOBJECTs representing your bullets mapped to a single ScrollObject class.

Is the only way around this to create boiler-plate classes that extend my bullet to have a 1-1 mapping?

There are two options to do the mapping, the old one and the new one since binding hierarchy support has been added to Scroll, earlier this year.

Let's look at the old one first (assuming your C++ class is called MyBullet):

In config:

[PlayerBullet]
# ...

[EnemyBullet]
# ...

In code:

void MyGame::BindObjects()
{
  ScrollBindObject<MyBullet>("PlayerBullet");
  ScrollBindObject<MyBullet>("EnemyBullet");

  // Or you can even define a list in config and loop through it
}

The new one, now:

In config:

[Bullet]
# Sets common properties to both types of bullets
# This section can be completely empty but needs to be defined

[PlayerBullet@Bullet]
# Sets specifics to PlayerBullet here

[EnemyBullet@Bullet]
# Sets specifics to EnemyBullet here

In code:

void MyGame::BindObjects()
{
  ScrollBindObject<MyBullet>("Bullet");
}

Any orxOBJECT whose config section inherits from [Bullet] will now be bound to the C++ class MyBullet, unless explicitly redefined with a ScrollBindObject<>() call.

Does it make sense?

Cheers!

duenez

Thanks!

I saw Scroll was already a singleton after posting, but I still wanted to see what you said. I am using the GetInstance() to create object from all over my code

As for the mapping, I like the way it is done and the way you describe it. Cool!

duenez

Looks like I celebrated a bit too early... This is a bit unrelated to the main topic, so feel free to move it to a more appropriate thread, if you want.

I seem to be missing something because my Scroll derived class doesn't call the Update function after Execute, nor after StartGame. Which is the magic call to have Orx start calling the Update function?

Cheers,

iarwain

Mmh, beside calling StartGame(), there isn't any other requirements for having your Update() method called (unless you call StopGame(), of course).
If you have some code to show me, I could be of better help I think.

duenez

Here is my main application implementation... Please let me know if you would like any other part.

http://pastebin.com/6dFMxaMn

Thanks a bunch

iarwain

Your Update function doesn't have the correct prototype, so it's not overriding the virtual defined in Scroll.h.

You'd think a sensible compiler would warn you about that!

PS: You're using a pointer instead of a reference for the parameter.

duenez

Ah, I knew it had to be something st00pid like that. Thanks again!

iarwain

My pleasure. Let me know if you have any other questions!

PS: I saw you were using rand(), there's a few orxMath_GetRandom*() functions with different types if you ever need them.