Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • entries
    4
  • comments
    16
  • views
    7,765

Timers, Cameras


Paul Thomas

1,059 views

Actors are now in place and working correctly. I actually made a small mistake yesterday and made meshes part of the actor. This incorrect because a mesh should extend an object and be it's own actor type (i.e. class EMesh : public EActor{};). This is fixed and therefore the actor creation has slightly changed, but the shortcut (EActor::Add("ActorName", "mesh.gmf")) still works as expected.

 

Timer

I need to start adding actors so there are multiple in-game types of entities. First, I need a timer, because I just love timers. Even if it was just a single timer I'd be happy. They are extremely useful.

 

ETimer::SetTimer(1.0f, TRUE, FUNCTION);

 

A better example:

// .. function to execute by the timer
void TickSpecial(void)
{
printf("Tick Special\n");
}

// .. looping timer
Timers.SetTimer(1.0f, TRUE, TickSpecial);
// ..
void EGame::Unload(void)
{
Timers.StopTimers();
}

 

There is still more I want to add to the timers but this is a good start. I'd also like to move them to threads to support multiple timer tasks.

 

Cameras

Cameras are interesting and always seems to be a topic around Werkspace. Cameras in this engine/framework are Actors and this should be interesting. Since cameras will extend actors I already have translation and rotation.

 

// .. automatically done but an example[/i] - 0 is the framework camera layer to fetch
Cameras.Add("Camera_1", 0);
Cameras.Rotate("Camera_1", vec4(0.0f, 1.0f, 0.0f));

 

Next was to just add helper functions that are provided by LE, such as zoom, project, unproject, etc:

// zoom with interp
Cameras.SetZoom("Camera_1", 1.0f, 1.0f);

// project
vector project = Cameras.Project(vec3(MouseX(), MouseY(), 1000.0f);

 

I shouldn't have a problem from here having any type of camera "mode" I would like to have. I will begin working on these once I get to detailed mechanics.

 

Cameras are now working, along with timers, and now it's time to take a break. I may keep pushing forward but shortly I have to return to my other projects until I have time to return.

 

 

 

Until next time, and thanks for reading.

2 Comments


Recommended Comments

I notice you are using C++. However with your timer you only take a normal C function which breaks the C++ idea. If you wish to have a flexible way to assign events you could take a look at the event code I posted in the store. http://www.leadwerks...le/367-c-event/

 

This allows you to bind class methods as callbacks instead of normal C functions which end up breaking OOP. So for example my timer class looks something like:

 

class Timer
{
// leaving out variables. this is just to get the idea
public:
Timer(float interval);
void Start();
void Stop();
void Update();
Event0 OnTick;
};

// usage
class Actor
{
private:
Timer* tmrTest;
void tmrTestTick() {}
public:
Actor()
{
// create a new timer
tmrTest = new Timer(2000);

// bind the callback of the timer to a method of this class to keep the OO idea
// notice how I can even bind to a private method and it still works! this is great so that the tmrTestTick() isn't exposed to the outside world because why would you want it exposed right?
tmrTest->OnTick.Bind(this, &Actor::tmrTestTick);
}
};

 

When creating a framework these events can really help decouple your classes so they can easily be exchanged/changed without breaking things. For example in your actor class you can define an Event for OnHurt, which the actor will fire when they take damage. Any class can register to receive this event during the creation of the game.

 

Let's say you want a HUD class to know when the player was hurt. You could tightly couple the HUD class and player class together by passing references of each or 1 or the other. You could poll the player class and pass it or it's data to the HUD class every cycle OR by registering to the players OnHurt event at startup, your HUD class could get member methods fired automatically from the player class when it raises it's OnHurt event. No coupling of the classes, and no polling, so the code becomes more flexible and more efficient.

 

Just an idea.

  • Upvote 1
Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...