FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The Physics/Scene graph system...
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic     Forum Index -> ArcLib
View previous topic :: View next topic  
Author Message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Sat Mar 31, 2007 8:09 am    Post subject: The Physics/Scene graph system... Reply with quote

Recently, I've been able to look at this system to get a closer view on how it works. Either I need to understand a little bit more, or this system needs a little bit more polish, with these key phrases in mind.


Consistent.
Code stays 'consistent', following the same types of rules of other code in its similar area.

Clear. Code is as clear and simple as possible. It should be dead obvious exactly what is happening in the code from looking at it.

Coherent. Consistent, understandable, clear.


First, it took me a while to figure out the inheritance tree.

------------------------------------------------------------------------------
Group <-- Group Base <-- Parent Node <-- Single Child Node <-- Node

World <-- Group

Sprite (it took me a while to know there was /another/ sprite class now) <-- Composite Group <-- Group

Composite <-- Parent Node
------------------------------------------------------------------------------

Physics System

Add to system

As of now:
World w;
w.addChild(Node);

Remove from system

As of now:
World w;
world.removeChild(Node);

Query System

As of now, there seems like no way to get

- total number of objects within a system
- total number of objects of a specific type within a system (asteroids, ships, etc.)

---------------------------------
Issues with the new 'sprite'
---------------------------------

- Seperation of Frame vs. LinearAnimation,
- Frame should be equal to an Animation with one frame

- Animation all in one file
- lose flexibility...
1) All frames need to be the same size now
2) Similar animations can not share the same frame, new data needs
to be created instead.
3) Problematic for possibly procedurally generated animations

- Animation and frame being seperate
... the sprite interface should work similarly to the original sprite interface, except maybe remove option to play sound at beginning of animation

------------------------------------------------
What needs to be done
------------------------------------------------

- Sprite system needs to be more like the old one

- Querying system for physics system

- If possible, make the whole system more 'clear.' Not quite sure how to approach this yet.
Back to top
View user's profile Send private message AIM Address
ChristianK



Joined: 26 Sep 2006
Posts: 159
Location: Berlin, Germany

PostPosted: Sun Apr 01, 2007 5:09 am    Post subject: Reply with quote

You are of course correct: the scenegraph system is far from done! In fact, my intention with porting asteroids to use it was to see if the concept works. So yes, it still does need a lot of polish and convenience methods. And a lot of documentation.

Its main goal is to tie graphics, physics, sound and possibly other parts of arc together, without knowing anything about the subsystems. It mustn't become too complex to use though.

I've just committed some cleanups to the inheritance tree. Here's my explanation:

Code:
Node (abstract parent interface and traversal)
<- MultiParentNode (may have multiple parents)
<- SingleParentNode (may only have a single parent node)
  <- CompositeNode (a single node that encapsulates multiple nodes, see below)
  <- GroupNode (node with children)
    <- CompositeGroupNode (a single node that encapsulates multiple nodes and may have children)


I'm not so sure if composite nodes should stay yet. They solve the following problem:
The user wants to add his sprite to the scenegraph:

Code:
Sprite s = new Sprite(...);
root.addChild(s);


What happens? Sprite itself has to consist of multiple nodes (translation, maybe multiple images, sounds, etc), so it will add additional nodes to the scenegraph. Now the tree becomes fragile, as the user could simply change or delete nodes that Sprite expects to reference later. Therefore I came up with composites which look like a single node to the user, but actually contain an arbitrary number.

An alternative would have been to make Sprite not a node at all, but rather a managing class. But Composites seemed to offer more benefits.

Quote:
Sprite (it took me a while to know there was /another/ sprite class now)


I left in the old one for comparison. If the node-based Sprite works well, we can get rid of the old one.

Quote:
Query System


Yes, there's no way to query the tree. Simply didn't write it yet. Since the Node classes have to be pretty generic, it'd probably be faster for a game to manage a list of the nodes it wants to keep track of on its own.

Quote:
Frame should be equal to an Animation with one frame


Why? I don't see a benefit. There could be multiple animation classes - LinearAnimation is just one of many possible, including one that doesn't keep its

Quote:
Animation all in one file


It is no problem to create a new animation class that doesn't. I went with the 'all in one file' method because I am used to it.

Apart from that, I'm not happy with the animations yet. Need to devise more test cases. Maybe have a good integration with the state machine to handle animation switches?


Last edited by ChristianK on Wed Apr 11, 2007 1:38 am; edited 1 time in total
Back to top
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Mon Apr 02, 2007 7:00 am    Post subject: Reply with quote

Quote:

Yes, there's no way to query the tree. Simply didn't write it yet. Since the Node classes have to be pretty generic, it'd probably be faster for a game to manage a list of the nodes it wants to keep track of on its own.


Maybe the Node class can carry an 'ID' uint, and ID can be set equal to a number that will ID the type of the node? like ID=SHIP, or ID=ROCK. Then you can use a query function like

int numberof = queryNum(SHIPS)


Quote:
state machine to handle animation switches?


How do you propose the state machine is implemented? I know what they are, but I'm not quite sure how you would want it implemented.
Back to top
View user's profile Send private message AIM Address
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Fri Apr 06, 2007 12:29 pm    Post subject: Reply with quote

Here's almost like a todo-list of things we need

Code:


Arc Window Resizing and And Virtual Coordinates
________________________________________________

1) Do not allow resizing window w/ mouse

2) Reload textures / font on window resize

3) Re-think virtual coordinates, maybe its best for things not to be drawn relative to their size? Or else just let user assign larger virtual coords.
_____________________________________________
Physics System Needs:

1) Global gravity variable
2) Global wind direction variable
 - Angle (degree) which wind is blowing at
 - Speed of the wind
 - function to smoothly change the angle of the wind
 - finction to smoothly change the speed of the wind
 
3) Is there ever a time where a game will need more
than one 'physics' world? I might turn 'world' into
an arc module.
_____________________________________________

_____________________________________________
Scene Graph Design : Hold Everythign Together
_____________________________________________

Note: Node will most likely replace 'Entity' Class

Each node needs to hold the type of class it is...

// might be wise to abstract away the type used for points and things, so we can change it to double or real in the future
alias arcfloat float; 

interface INode
{
  void draw();
  void process();
}

class Node : INode
{
  // used for spatial structure
  Point loc;
  arcfloat rot;
 
  // used for querying the scenegraph on the number of objects of each type
  ClassInfo classType;
}

-- SceneGraph Rules --

1) Each parent node needs to pass on its
 - location
 - rotation
 
2) When a parent rotates or moves, all children's rotations and movements need to be updated to that of the parents relative to their own location and rotation.
 
3) When the parent is destroyed, all children nodes need to be destroyed as well

4) Each node can hold one 'child node'

5) Use 'process' and 'draw' function for the nodes
 
-- Scenegraph Needs

1) addChild
2) removeChild
3) uint queryNumObjects(classinfo type) // query number of objects in children of certain type of class
 
 Types of Nodes:
 
 Sprite Node contains a group of nodes: Can hold all of the above nodes. If uses Physics Body node, use the physics system. If uses static collision node, use the static algorithms.
 If uses nothing, then Sprite will not collide with anything. Of course with nodes, it's all mix & match.
 
 // Sprite node holds a group of all these types of nodes
 - Sprite Node
 - Animation Node
 - Frame Node
 - Sound Node
 - Mouse Node - defines bounds which the object is 'clickable', same as Static Body Collision Node?
 - Physics Body Collision Node
 - Static Body Collision Node
 - Weapon Spawn Point or simply 'AnchorPoint' node
 
 // GUI nodes
 - Layout Node (holds group of widgets)
 - Widget Node
  - Textbox node
  - Button node
  - Label node
  - Image node
 
// Other nodes
- Particle Node : generates particles with whatever gravity & wind direction is set


// Possible sprite system to work like
class Ship : Sprite {}


Group root = new Root;
Ship sprite = new Sprite;

sprite.addChild(new Frame("still", "still.png"))
sprite.addChild(new Animation("run", "run.png"))
sprite.addChild(new Sound("explode", "explode.png"))
sprite.addChild(new PhysicsBody("main"))
sprite.addChild(new AnchorPoint("laser", x,y)); // anchor point relative to the sprite

sprite.setAnim("still" / "run");
sprite.playSound("explode");

root.add(sprite);

// will call process to sprite
root.process();

// will call draw to sprite
root.draw();

if (arc.input.keyHit(ARC_SPACE))
{
   root.add(new Laser(sprite.getAnchorPoint("laser"), sprite.getAngle));
}

if (sprite.collide("main",x,y)) // use physics body to test for mouse collision
{
}

if (sprite.onCollide("main"))
{
    // sprite collides with another object
    ClassInfo info = sprite.getCollisionInfo;
   
    if (info == ASTEROID)
    {
       root.removeChild(sprite);
    }
}


Back to top
View user's profile Send private message AIM Address
ChristianK



Joined: 26 Sep 2006
Posts: 159
Location: Berlin, Germany

PostPosted: Sat Apr 07, 2007 7:18 am    Post subject: Reply with quote

First off: I have been busy with other things since I've come back home, but hope to get back to work on Arc eventually.

Quote:
3) Re-think virtual coordinates, maybe its best for things not to be drawn relative to their size? Or else just let user assign larger virtual coords.


I agree that this needs some thought. Maybe keep the default coordinate system, but add functions to window to adjust it. Point of origin (downleft or upleft seem to be in use) and virtual size of window should be configurable.

Quote:
1) Global gravity variable
2) Global wind direction variable


For gravity I agree that it'd be used so often it warrants a special case. World actually has a gravity variable. For wind, I'm not so sure. Requirements would probably be different for every game using it, so I'd rather have the user implement it himself.

Quote:
3) Is there ever a time where a game will need more
than one 'physics' world? I might turn 'world' into
an arc module.


Having the root and physics world nodes as static nodes somewhere was my initial design, but I made them user-managed to allow easy switching. Exchanging the root node could be the easiest way to switch between two rooms/scenes in an rpg-like game, for instance. Having multiple, totally independent physics systems might also be useful in some cases. (even if it's just to seperate the cool physics effects on your title screen from the in-game physics - though I'm sure there are more legitimate reasons)

Maybe we can compromise by having a default root and physics world node? Though I figure the user'd still have to add the default physics node to the default world node somewhere manually?

Quote:
// might be wise to abstract away the type used for points and things, so we can change it to double or real in the future
alias arcfloat float;


Yes. I'm not satisfied with arcfloat, but fail to come up with a better name myself.

Quote:
interface INode


Wait, are you rewriting the scenegraph from scratch? I thought it'd be my job to clean it up and make it usable?

Also, there's a reason I didn't put draw, process etc. into a single interface: extensibility. What if the user figures he needs to foo the whole tree? He'd have to change INode itself for the new foo to propagate in the same way you're suggesting draw and process traverse down the tree.

Quote:
// used for querying the scenegraph on the number of objects of each type
ClassInfo classType;


I don't get what you're trying to do with this. What classinfo do you want to store and why?

Quote:
When a parent rotates or moves, all children's rotations and movements need to be updated to that of the parents relative to their own location and rotation.


So you want to keep all positions absolute? I've had good experiences with storing relative coordinates in the childnodes. It also works very well with OpenGL (see the Transform node).

Quote:
Each node can hold one 'child node'


Only a single one? That's a pretty heavy restriction. Why do you want to limit to one child?

Quote:
uint queryNumObjects(classinfo type) // query number of objects in children of certain type of class


We could go even further and allow

Code:

class Node
{
  int iterateObjectsOfType(T)(int delegate(inout T) dg);
}

foreach(Ship ship; &rootNode.iterateObjectsOfType!(Ship))
{
  //...
}


Quote:
Sprite Node

Can hold all of the above nodes. If uses Physics Body node, use the physics system. If uses static collision node, use the static algorithms.


Overriding addChild for Sprite is a smart idea! That way Sprite can be very easy-to-use since the user doesn't have to worry about the internals. I'm going to do that.

Quote:
All Nodes have a char[] name


I'm not sure this is a good idea. It simplifies simple examples, but has problems of its own. Names would have to be unique, or they would lose most of their usefulness. Or possibly follow a directory-like structure (root.getSubnode("Ship/Weapon/FlameEffect");).

In the end I'll always prefer to simply store references to the nodes in variables than to query for the node's name every time I need it. That's a personal preference though. Named nodes might make simple programs quite a bit easier.
Back to top
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Sun Apr 08, 2007 10:01 pm    Post subject: Reply with quote

Quote:

For gravity I agree that it'd be used so often it warrants a special case. World actually has a gravity variable. For wind, I'm not so sure. Requirements would probably be different for every game using it, so I'd rather have the user implement it himself.


True.

Quote:

Having the root and physics world nodes as static nodes somewhere was my initial design, but I made them user-managed to allow easy switching. Exchanging the root node could be the easiest way to switch between two rooms/scenes in an rpg-like game, for instance. Having multiple, totally independent physics systems might also be useful in some cases. (even if it's just to seperate the cool physics effects on your title screen from the in-game physics - though I'm sure there are more legitimate reasons)


Sounds good.

Quote:

Maybe we can compromise by having a default root and physics world node? Though I figure the user'd still have to add the default physics node to the default world node somewhere manually?


It may be best to either use 'arc module' w/ default node, or make the user manage everything their self.


Quote:

Yes. I'm not satisfied with arcfloat, but fail to come up with a better name myself.


arcfloat
afloat
precision
prec
decimal
arcprec
arcfl

Quote:

Wait, are you rewriting the scenegraph from scratch? I thought it'd be my job to clean it up and make it usable?


I'm not rewriting it from scratch, I'm just brainstorming here, that's all Razz Trying to avoid idea stagnation.

Quote:

I don't get what you're trying to do with this. What classinfo do you want to store and why?


How will node know what type of class it represents?


Quote:

So you want to keep all positions absolute? I've had good experiences with storing relative coordinates in the childnodes. It also works very well with OpenGL (see the Transform node).


I want relative coords too... for some reason I thought you would need to update the children, but I see that is unnecessary now.

Quote:

Only a single one? That's a pretty heavy restriction. Why do you want to limit to one child?


Since one node can represent a group of nodes, why not?

Quote:

We could go even further and allow

Code:

class Node
{
  int iterateObjectsOfType(T)(int delegate(inout T) dg);
}

foreach(Ship ship; &rootNode.iterateObjectsOfType!(Ship))
{
  //...
}



ok

Quote:

I'm not sure this is a good idea. It simplifies simple examples, but has problems of its own. Names would have to be unique, or they would lose most of their usefulness. Or possibly follow a directory-like structure (root.getSubnode("Ship/Weapon/FlameEffect")Wink.


hrm... have to think if this, I guess.
Back to top
View user's profile Send private message AIM Address
ChristianK



Joined: 26 Sep 2006
Posts: 159
Location: Berlin, Germany

PostPosted: Mon Apr 09, 2007 2:07 am    Post subject: Reply with quote

I've added several documentation comments and cleaned up the scenegraph code. Take a look. Smile

Quote:

Name of floating point alias.


After all, arcfloat seems to be the best choice to me. Going through the code and changing this everywhere would be something for our post-release list of things to do, right?

Quote:

I'm not rewriting it from scratch, I'm just brainstorming here, that's all Razz Trying to avoid idea stagnation.


Ah, okay. I'm sorry for sounding offended.

Quote:

(classinfo member variable)
How will node know what type of class it represents?


Represent? What do you mean? (example?)

I was thinking only of classes in the hierarchy started by Node, where we can always check if a Node is actually a more derived class by trying to cast to it.

Code:
int iterateOfType(T)(int delegate(inout T) dg)
{
  foreach(n; &iterateChildren)
  {
    T derived = cast(T) n;
    if(derived)
      dg(derived);
  }
}


Of course this would also iterate over all subclasses of T, which can be fixed by a if(T.classinfo is n.classinfo) - in case it isn't the desired behaviour.

Where you thinking of something else entirely?

Quote:
I want relative coords too... for some reason I thought you would need to update the children, but I see that is unnecessary now.


Well, we still need the ability to calculate the absolute coordinates from the relative ones for visibility tests or mouse picking. I haven't implemented it yet, but I think we can either use OpenGL or implement it ourselves.

Quote:
Quote:

Only a single child per node?


Since one node can represent a group of nodes, why not?


You mean by using a Composite? A generic Composite that may represent multiple children would in fact become quite similar to GroupNode. However, I don't see why we should add that restriction - what'd we gain?

I was thinking about simplifying the Node inheritance tree though: specifically, getting rid of MultiParentNode.

Currently, MultiParentNodes may not have children and are therefore used for final nodes like Frame or Text, with the intention that the very same node might be added to more than one parent to safe some memory. I'm not sure this warrants the added complexity though. What do you think?

Quote:
Names


For now, we could not make it an integral part of the scenegraph (so not every asteroid has to have a unique name), but provide some simple free functions to make named nodes possible. Like in this stub:

Code:
module arc.scenegraph.namednodes;

private Node[char[]] namedNodes;

Node registerNode(char[] name, Node node)
{ namedNodes[name] = node; return node; }

Node getNode(char[] name)
{ return namedNodes[name]; }


it would allow

Code:
GroupNode root = new GroupNode;
root.addChild(registerNode("Ship", new Sprite));
getNode("Ship").addChild(...);


Certainly not the ideal syntax, but probably useful for small projects. This also shows another issue with simple names - all you get back is a plain Node, not the Sprite you originally added to the tree.
Back to top
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Mon Apr 09, 2007 10:37 am    Post subject: Reply with quote

ChristianK wrote:
I've added several documentation comments and cleaned up the scenegraph code. Take a look. Smile


looks good so far

Quote:

After all, arcfloat seems to be the best choice to me. Going through the code and changing this everywhere would be something for our post-release list of things to do, right?


Not post release, but done right before the release after all major features are taken care of. Added to roadmap: http://www.dsource.org/projects/arclib/milestone/0.2

Quote:

Ah, okay. I'm sorry for sounding offended.


no problem : )

Quote:

Represent? What do you mean? (example?)


Since nodes are so generic, how will we know what type of class the node is being used for (is Node a Sprite, Animation, Ship, etc.?)

Quote:

Well, we still need the ability to calculate the absolute coordinates from the relative ones for visibility tests or mouse picking. I haven't implemented it yet, but I think we can either use OpenGL or implement it ourselves.


Probably self implementation, not sure how you would do it with OpenGL.

Quote:

You mean by using a Composite? A generic Composite that may represent multiple children would in fact become quite similar to GroupNode. However, I don't see why we should add that restriction - what'd we gain?


Regularity / simplicity?

Quote:

Currently, MultiParentNodes may not have children and are therefore used for final nodes like Frame or Text, with the intention that the very same node might be added to more than one parent to safe some memory. I'm not sure this warrants the added complexity though. What do you think?


Yes, seems sort of unnecessary.

Quote:

For now, we could not make it an integral part of the scenegraph (so not every asteroid has to have a unique name), but provide some simple free functions to make named nodes possible. Like in this stub:


I wouldn't implement this right away... it should probably be thought of more.

Another note: instead of completely 'trashing' the existing sprite design, why not take the old sprite class and have it inherit node like

Code:

class Sprite : Node
{
  addFrame(...)
  etc.
}


or make a scenegraph wrapper for the original sprite like you did for scenegraph.text and the Font class.

This way,
1) Using the scenegraph for sprite is optional (Scenegraph + physics should be optional, because in some projects [card game] scenegraph and physics will simply get in the way )
2) Using proven code that already works well

And whatever features you think might be added by the scenegraph system, could probably be implemented in the huge sprite class as well. What do you think?
Back to top
View user's profile Send private message AIM Address
ChristianK



Joined: 26 Sep 2006
Posts: 159
Location: Berlin, Germany

PostPosted: Wed Apr 11, 2007 1:50 am    Post subject: Reply with quote

Quote:
Since nodes are so generic, how will we know what type of class the node is being used for (is Node a Sprite, Animation, Ship, etc.?)


Either by using casts or classinfo?

Code:
Node n = new SomeDerivedNode;

if(n.classinfo is SomeDerivedNode.classinfo)
  // this works
if(cast(SomeDerivedNode) n !is null)
  // this works, but'd also catch nodes derived from SomeDerivedNode


Did you mean something else?

Quote:
Sprite class


It should be possible to make the old sprite class work in the scenegraph context with just some small changes - that's why I left the old sprite class intact.
Back to top
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Wed Apr 11, 2007 11:28 am    Post subject: Reply with quote

Now I'm thinking it would be nice if our own defined value would require less typing than 'float', arcfloat is a nice name but it seems to long and I'm afraid it will bloat the code a little bit.

I wonder if 'prec' (short for precision) would work just as well? Or maybe doub (like short double).

Code:

prec value;
arcfloat value;
doub value;


hrm...

I'm glad we're going to keep the old sprite class. Maybe the new 'sprite like thingy' should have a different name to avoid confusion.

Also, I think classinfo + cast should work.
Back to top
View user's profile Send private message AIM Address
ChristianK



Joined: 26 Sep 2006
Posts: 159
Location: Berlin, Germany

PostPosted: Mon Apr 23, 2007 2:53 am    Post subject: Reply with quote

clayasaurus wrote:

I wonder if 'prec' (short for precision) would work just as well? Or maybe doub (like short double).


Somehow I don't associate 'prec'ision with floating point variables. 'arcfloat' still seems best to me. 'doub' would be ok. 'arcfp' probably a bit obscure (though I like it, personally).

ChristianK wrote:
A predefined root node isn't good.


It looks like I will have to create a common root for the scenegraph after all: the new MouseNotifyNode needs to know where the root coordinate system resides and a predefined root node seems the most simple solution.

I had tried passing the root node to the Mouse node on creation, but then it has to check whether it is still a child of this node all the time.

So, I'm going to add this node, probably in a new arc.scenegraph.root module.

By the way, I think we can get rid of arc.camera in the new release. If you really need multiple cameras, you should probably be using the scenegraph which provides this kind of functionality in a simpler way (via transform nodes).

Also, arc.window does a lot of things which don't really have anything to do with the window, like initializing various derelict (including OpenAL) parts. Shouldn't we move that functionality to arc.sound?
Back to top
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Mon Apr 23, 2007 10:50 am    Post subject: Reply with quote

There are only 2 things in window which aren't window related, but they are both initialization related

initializeDerelict()

initFont()

I don't see much harm in putting these in window.open. I would like to keep derelict initialization - deinitialization in one place as well, and most of the derelict initialization is for window.

So, we can keep as is, or add

1) arc.font.open() method for initFont
2) put sound initialization in arc.sound.open() , will cause al function calls to crash if arc.sound.open is not initialized

And then we would have to split up the myMissingProcCallback function into two different functions as well.

I'm not sure if it is really /worth/ it or not. If we add arc.font.open, we might as well add

.open() and .close()

stubs to all the top level arc modules, and have people use them even if they don't do anything, because they might do something in the future.

If scenegraph can do the same thing as the camera, then it's alright to remove camera I guess.
Back to top
View user's profile Send private message AIM Address
ChristianK



Joined: 26 Sep 2006
Posts: 159
Location: Berlin, Germany

PostPosted: Mon Apr 23, 2007 11:40 am    Post subject: Reply with quote

arc.window:

I see, so we keep most of the stuff in there - but the sound initializations could be moved to to arc.sound?
Back to top
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Mon Apr 23, 2007 3:08 pm    Post subject: Reply with quote

The only sound initialization code in there is the derelict loading / unloading.

Is there any specific advantage of moving the derelict sound loading / unloading to arc.sound.open() ?

I don't really care either way, just moving the code will take a tiny bit of work.
Back to top
View user's profile Send private message AIM Address
ChristianK



Joined: 26 Sep 2006
Posts: 159
Location: Berlin, Germany

PostPosted: Tue Apr 24, 2007 1:23 am    Post subject: Reply with quote

Quote:
Is there any specific advantage of moving the derelict sound loading / unloading to arc.sound.open() ?


Yes, it fixes this bug:

arc.sound.open();
arc.window.open();

Also, you'll be able to use arc.sound without using arc.window. Seems odd, but someone could be using a 3d graphics library without a sound component and want arc to do the sound.

EDIT:
Actually, we can just get rid of the calls to open and close altogether (except for window, where it does make sense). I just moved the derelict init, the sound init and input init from the open() calls to static this() module constructors and it works. (not committed yet)

What do you think? One less thing for the user to worry about.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> ArcLib All times are GMT - 6 Hours
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group