Read Me

-------------------------------------------------------------------
08. des. 2007 - Trefall
-------------------------------------------------------------------
Started implementing the MD2 loader. Partly based on yours, Ravine,
and partly on some others I've found on the net. To keep all OpenGL
code seperate from engine structure and texture handling seperate
from engine structure, I'll need to specially write the loader for
our engine. The loading should be implemented now, I just have to
link it with rendering and texturing and we're set to go. I'll deal
with that next time (probably on monday).

I played a little bit around in the engine today too, and found that
with only collision detection applied, we already have a 2D engine
up and running here. Could easily base a 2D game on what we have now,
which is kind of cool.

Anyway, if I get it the way I want, we'll have MD2 loading support
sometime monday ;)
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
07. des. 2007 - Trefall
-------------------------------------------------------------------
After fiddeling a bit with our manual texture loaders, I made the
decision to try and download the image library that Ogre3D uses,
which is FreeImage. After a bit of back and forth, here and there,
I finally got it working with alpha channel and transparency! Yey!

I wrote a TextureManager, to make loading/unloading of textures easier
to manage. It now works great between scenes, and even though we now
call glDeleteTextures() between each scene, which is quite slow, it's
only on load time, and we can always optimize later.

The main important thing is that textures work now, to an almost
perfect degree. Only problem is that... err... it loads the red channel
of a 32bit RGBA tga as blue channal and the blue channel as red channel.
I haven't sat down and tried to solve this yet, since I just got the
alpha to work properly, which I find kind'a cool ;)
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
05. des. 2007 - Trefall
-------------------------------------------------------------------
Gave IComponent an id variable that works great with IMaterial and
texture loading. Still some small loading bugs in there, but I'll
sort those out first thing tomorrow!

It's fun to see how it's getting graphical and good looking the second
we toss in a texture loader... can't imagine how it will be once mesh
loading and lighting is tossed in as well ;)
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
05. des. 2007 - Trefall
-------------------------------------------------------------------
Started implementing an IComponent interface and a bmp texture loader.
Hadde to let there be memory leaks in the BMPClass to make it run, so
that's something to figure out :P Other than that it works like a charm!
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
04. des. 2007 - Trefall
-------------------------------------------------------------------
Finally got them rotating matrixes right. Now you can rotate camera
using directional keys and pgup/pgdn.

Edit: We need a way to assign special keys and mouse buttons to functions
as well, not just char keys, like we have now. I'm sure this shouldn't
be too difficult. If we in KeyActions also define an instance of the 
Key  enum and MouseButton enum of InputManager.h, and make a check that
somehow identifies which one of the three types this KeyAction stores,
then that should be enough for us to start using it. I just don't have
any time implementing it now, so, later ;)
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
04. des. 2007 - Trefall
-------------------------------------------------------------------
Made an advance on the way we write scripts today. I found out about
global functions, and how global functions of same name overwrite
each other. Just look at the code, you'll see how it works! This
should simplify what you're working on as well I hope ;) Oh, I'm
all excited to the potential in these discoveries!

This forum thread should also help:
http://www.somedude.net/gamemonkey/forum/viewtopic.php?f=5&t=159&hilit=calling+function+in+script
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
02. des. 2007 - Trefall
-------------------------------------------------------------------
Worked some more on rotations. Still haven't figured out quaternions,
but got up/down rotationis working now. I applied the rotation to the
first moveable object in the scene instead of the camera (using 
directional keys), and it's appearant that I'm multiplying wrong indexes
in the matrix array when computing rotation along the y axis :P

I also created an Entity folder in the script directory. My plan is,
as you can see, to divide up the code more. A problem with GM though,
as far as I can tell, it doesn't have classes, doesn't support
includes, nor inheritance (like Squirrel do ;) )
So my guess is that we need to make entities global functions that
can then be used in the other script files. Doing this, we have to
load all the entity scripts at gamemanager initialization I think...
which won't really result in a cleaner approach, as I had hoped for.

We can dwell some more on this maybe.
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
30. nov. 2007 - Trefall
-------------------------------------------------------------------
Started on implementing CreateCube(), however, I need to upgrade the
render system a bit to make that work, which will take more time than
I have this evening. I'll go back and add that in next time ;)
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
27. nov. 2007 - Trefall
-------------------------------------------------------------------
Fixed some issues with the camera, it now works in forward, backward,
strafe right/left, but I still have to work some more on the rotations.
I want to implement quaternions for rotations, and I still haven't quite
figured out how to multiply that into the local matrix of the camera.
I'll get there though ;)

Also fixed a small bug in how I initialized the SceneManager which
got rid of some weird bugs in how the scene was rendered.

I installed a new matrix and vector library too, which is much bigger
and better than the one we previously had (more functionality and
operators).
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
26. nov. 2007 - Trefall
-------------------------------------------------------------------
Started implementation of Camera and SceneManagement/SceneGraph. Still
quite a lot of work needed done before it works 100%, but the camera
is, if nothing else, functional to a certain degree now. More thought
and work needed though. Maybe we could start to implement scripted
moveability for the camera though? That's a thought... *hint* *hint*
;)
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
17. nov. 2007 - Trefall
-------------------------------------------------------------------
Ah, looong time since we last updated the repository here, so I
decided to put school work aside and work a bit on the engine today.
I looked thoroughly through your code, and though the KeyManager
doesn't really need to be a class, I think it's appropriate to make
it a singleton class like all the other managers, to keep consistency
in the code. I rewrote the script classes a bit though, in 
inspiration to your approach, and added a Script namespace and deleted
class definitions for the c++ script files. This resulted in a much
cleaner code (just look at the beauty of ScriptBind.cpp now).

I know I should've been working on rendering today, but I couldn't
help fiddeling a bit with the assignKey script, and got it working
today with conPrint and createPlane in the level1 script. No problems
at all! ;) This was a great way to approach the problem, good problem
solving on your part man!

I added an update function to the inputmanager now, that looks through
all keys in the keymanager list every frame (this can be optimized later).
Doing this, we only check on keys that are assigned through script,
which is a great way to optimize things (we don't check input on all
keys on the keyboard, only those keys that are assigned). It worked
out real well so far, and resulted in a clean update function.

That's all for now, but we now have in the core functionality for
scripting I think. Next step will be to add functionality, like movement,
etc.
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
9. nov. 2007 - Trefall
-------------------------------------------------------------------
Sorry for not responding before, and for not working on the engine
right now. I've been way to busy, but on monday I see an opening.

I'm very excited about what you've done on the action scripts so far,
and I'm very excited to see it work in action once you get more time
for it ;)

Just wanted to update this readme to respond to it!
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
06. nov. 2007 - Ravine
-------------------------------------------------------------------
I did some work with the keys and assigning them, not nearly done
yet. What I have done is created a KeyManager file (not a class,
I didn't see the need, but you might think otherwise) and then
started a function to assign a key with a function. Once the key
is assigned to a function, when it is pressed that function that is
stored with the key will be sent to Game Monkey to be executed. I
know this will make the program very script oriented, but it seems
like a fairly simple way to work with this, and very flexible. As
for the entity the key affects, I have decided (but not done 
anything yet) that there will be a variable of the focus entity in
the Game Manager, and that will be changed through a GM function.
I don't know how efficient running everything through GM will be,
so please let me know of your thoughts.
-------------------------------------------------------------------
-------------------------------------------------------------------

-------------------------------------------------------------------
05. nov. 2007 - Trefall
-------------------------------------------------------------------
Worked on two things today. First I added a reload function to the
level and menu state, so that we can reload the script during
runtime. This way we can edit a level's script and just hit reload,
instead of restarting to program.

I also abstracted the ScriptBind function. I added an extra folder
called Script/ and thought that we'd add one class per gm function,
each class have a dedicated function that takes gmThread* as param.
This cleans up ScriptBind a great deal, which is what we've been
worried about. Having one script command handled in it's seperate
file might be a bit overkill, but it abstracts everything in a clean
way and makes it quite obvious how to add new script functionality
as well. ScriptBing will still need a gmFunction added to it, but now
we simply call the dedicated class for the function inside it. Ah,
why do I explain, you'll quickly see how it all works anyway :P

I've thought a bit after my long rant last time, and I don't think
it might be a too long step to chew in one bite. We should seperate
it more into chuncks and add a little bit of functionality at the
time imo. So instead of worrying about all that needs to be done,
let's just focus on each step along the way...

Hopefully, with the new abstract scripting functionality, it will be
less intimidating to add new functionality.

Next time I'll sit down with this, I'll start focusing on the
scenemanager and rendering. That should make things interesting quickly.
After that, I'll integrate terrain loading from texture, textures and
eventually meshloading.

In the mean time, if we could get some scripting support for specifying
how the keys work, that would be cool.
What if we have a simple txt cfg file, or an xml file, where we store
predefined actions and where we can assign keys to those actions?
Similar to any Control screen in a game:
<Action>
	<Type>MoveForward</Type>
	<Key>W</Key>
	<Key>K_UP</Key>
</Action>

and load this via script where we define what the Type MoveForward does?
If there is a way to make GameMonkey read from xml, that would work
really well, or if we have to go through C++ to parse the xml and then
send it to GameMonkey, that could work as well... I don't know, what
do you think?
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
02. nov. 2007 - Trefall
-------------------------------------------------------------------
Ok, got movement working now (Moveable : public Entity). You can
check it out by pressing w and s keys while running. This should
let you test out your Input/Action scripts as you implement them ;)

Fixed a bug in the Special Keyboard function of the InputManager as
well, so now input from special keys, like K_UP/K_DOWN works as well
and behaves just like the other keys does.

One thing about movement that we need to be able to define in script,
is which Entity the player controls. Maybe we need to add a name or id
to entities, so that in the script the programmer can just refer to
that name/id when he's assigning which object he's applying movement
or actions to.

If we do this flexible enough (which wouldn't really be hard to do),
we could allow the player to control multiple objects, not just one,
thus not forcing the engine to work for one specific type of game.

Simply in action scripts, one could type actionAssign(id, index, key);

I think movement is an action as well though, so maybe unifying all
actions to the same function in the script would be the best. Also,
doesn't GM support named indexing? Like instead of having the index
parameter be of type int, it can be of type string or char, and we'd
use that for finding which action the programmer want, instead of
having to refer to a table of ints.

actionAssign(name, function, key);

actionAssign("Player", "translateLocal(0.0f, 0.0f, -0.1f)", "K_UP"); //Move forward
actionAssign("Player", "translateLocal(0.0f, 0.8f, 0.0f)", "K_SPACE"); //Jump

if(currentState == a_levelState)
{
	actionAssign("GUI", "LoadState("PauseMenu")", "K_ESC");
}
else if(currentState == a_menuState)
{
	actionAssign("GUI", "Dialog("Exit")", "K_ESC");
}

I'm thinking something unified like this, though for now, let's not
think about menues or GUI at all, only entities in a levelstate...

Do you think calling the specific functions like this is a good way
to go? Or should we rather predefine functions in the C++ code, like

actionAssign("Player", "MoveForward()", "K_UP");
actionAssign("Player", "Jump()", K_SPACE");

What I think would be best, is to go for a somewhat middle road here.
I think that the Function parameter should be a script function
declaration, where we can do some more coding. Like for the jump
function in this example, where we probably want to join in with a 
physics system, like:

Jump() = function()
{
	startY = this.Position.y;
	y = startY + 0.1f;
	while(y != startY)
	{
		a = Physics.G;
		v = 10.0f;
		v = a * Core.DeltaTime;
		y += v;
	}
}

or simply

Jump() = function()
{
	this.MovePhysical(0.0f, 10.0f, 0.0f);
}

and then have a physics library handle everything on the c++ side.
All depends on how flexible we want to go.

Personally I'd like to see support for both approached is the end, 
but for now we could just as well do more c++ side stuff to ease up 
the amount of script writing that needs to take place in order to 
see results.

Ugh, this was quite the ramble, and to be honest, I haven't quite
made up my mind as to what would be the best approach, but I trust
you've put thought into this as well, and however you see a solution,
just go for it ;) Just don't go more complex at this point than an
evening's worth of coding imo.
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
31. oct. 2007 - Ravine
-------------------------------------------------------------------
I've been thinking about how to bind the keys to certain functions
with the script. The idea I have is to have each set of keys 
grouped: (W,A,S,D + Arrow Keys) - movement, 
(Ctrl, Space, Shift, Enter) - action keys, etc. You could change 
the groupings in the code, but each group would be assigned to
those functions. Then, inside the script, assgin each key to a 
section in the group; moveAssign(0,"W"); moveAssign(1,"A"); 
actionAssign(0,"Shift"); Then for different states, menues and such
we could have the function of actionKey[0] do one thing, but have 
a different function in the levels. Another idea to make it more 
flexible would be to include the ability to set the functions of
"actionKey[0]" in the script, but that might take a bit longer.

This might be a little confusing (I'm typing it during class ) 
just let me know if you need any clarification.
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
31. oct. 2007 - Trefall
-------------------------------------------------------------------
Generalized the EntityManager today, now it only contains one list
of vector<Entity*>. When we call GetRenderables() or GetMoveables()
we simply dynamic_cast from the Entity* list to Renderable* or 
Moveable* now. In order for this to work, I added a list of flags
for entity types which we check on in the EntityManager to find
which entities are of the type Renderable, Moveable, etc.

Still haven't got the movement to work, but I'll work some more on
it now, and hopefully I'll get it working before too long.
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
30. oct. 2007 - Trefall
-------------------------------------------------------------------
Started on moveable, though nothing works just yet... I'll add
more comments later...
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
26. oct. 2007 - Trefall
-------------------------------------------------------------------
Looks like we have a little problem in the entitymanager and loading
/ unloading resources. I tried to work out how to delete the plane of
level 1 and load a different plane for level 2, but the level 1 plane
remained. I'm pretty sure it's not an actual problem in the manager,
but rather in how I've set up the relationship in the openglrenderer
to the entity manager. I don't have time right now to look into it
any further, and probably won't until tomorrow at best, but I'll get
it working asap.

EDIT: Heh, solved :P
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
26. oct. 2007 - Ravine
-------------------------------------------------------------------
Not much done today, only added a function, to be used in 
GameMonkey, that creates a Plane at x,y,z. I think this is what you
wanted. :D Also, tested it and implemented it into the level 1 
script.
I'll try to get a bit more done tonight.
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
26. oct. 2007 - Trefall
-------------------------------------------------------------------
Got some more time to program today.

Created a FileManager, for handling file loading and checking if a
file exist.

I used this to create a loop in the StateManager, and I iterated
through levels until the filename didn't exist no more.

Also added the inputmanager to the levelstate to handle shifting
between two states. So now you can press 'c' to load Level 2 from
Level 1 and Level 1 from Level 2.

I might be back a little later today to do some more coding, we'll
see. Either way, I'm happy that I got this working today!!!
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
26. oct. 2007 - Trefall
-------------------------------------------------------------------
That's perfectly alright man. Looking forward to see what you can
come up with on the script side. Myself I've had a little bit of
problem to wrap my head around all of it just yet, but I'm getting
there. I can see how we need to bind the functions we want for the
scripting into the ScriptBind.cpp file.

I did a little bit of work on the code today. Basically I moved the
loading of the level script into the levelstate and added an instance
of the levelstate into the statemanager, where I defined the Level_1.gm
script as parameter. I also loaded the plane renderable in the
levelstate now, and added comments in levelstate and statemanager
that you might want to read up on.

So what I've done today, and what I did yesterday, have simply been
to abstract the functionality we currently have and slowly started
to move things into the right place. I'm starting to see the good
side of the structure we've chosen for this project, and I'm looking
forward to see where we can take this for the next step.

Next time you're on, it would be great if we could get in some more
functionality in the script. I was thinking that just a simple way to
decleare that we want an instance of the Plane object with parameters
in the script, so that we don't have to declare it in hardcoded fassion,
would be really cool. Later we can expand on this to include definition
of mesh file(s), texture(s), material properties, etc.

Anyway, as for the Visual3D.NET source code, I sent what I have to
Adam. I would send it to you myself, but I don't have my laptop working
now, and my stationary computer is not up and running either (I'm
working out of school). So I'm sorry that I can't help you with that.
I did look at the latest version of Visual3D.NET a couple of days back
though, and I can only warn you to say that it has changed quite a bit
since we worked on it last time, though there are still familiar tidbits
and structure left in.

Best of luck with it, and looking forward to see the next update!!!
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
25. oct. 2007 - Ravine
-------------------------------------------------------------------
Hey, sorry I haven't been working too much on this, I've had a 
bunch of doctor appointments this week. :-/ I'll try to get some 
work done tonight.
Also, do you think you can send me the latest source for the visual
3d demo? Hilm wants me to send him a build so he can make a demo
movie or something.
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
25. oct. 2007 - Trefall
-------------------------------------------------------------------
Too little time to do everything that's needed to be done!!! :P

I fixed the bug in the render system, so it renders the square again
now. I'll upgrade it next time I sit down to work on this.

I started to look into scripts today too, but didn't implement
anything new. I added a comment in the StateManager that you
might be interested in reading up on, and I added a Data folder
structure for the scripts. Check if you like it. Also, I thought
loading the engine config from script would be a cool thing to do.

Things like setting render system (though we are opengl only at this
point), screen width/height, etc, would be cool to do.

Have to run though, looking forward to the next update and till next
time I get time to sit down and work with this.
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
22. oct. 2007 - Trefall
-------------------------------------------------------------------
Didn't quite get time to finish the implementation of the Renderable
yet, but at least it's compiling. I'll get back to it first chance
my schedule opens up.

Great work on the scripting system btw ;) Very clean and direct!
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
18. oct. 2007 - Ravine
-------------------------------------------------------------------
I'm getting a weird error when trying to update,
Error: Failed to add directory 'D:\OtherProjects\KayaEngine\src\
Depends\include\GameMonkey': object of the same name already exists  
Im using TortoiseSVN, any suggestions?

Thanks :D

Nevermind, I fixed it :P
I just renamed the folder for backup then updated again, and it 
replaced the folder. It's all good now.

-------------------------------------------------------------------

Hey, I fixed the script loading by using std::strings (I think they 
are very unefficient by the way)and calling a script from a file or
raw code works now. You can take a look at how I did have it 
working, it's just commented out, and see if you can fix the 
problem. The problem is that it was allocating too much memory for 
the buffer and thus causing an error when calling the script in
_gmMac. I guess it's just a problem with my allocating skills or 
something :P Anyway, the code calling the scripts is in the
GameManager::Init(...) function. I wasn't sure where to put it,
so I just put it there to be called once.

Tell me what you think so far, and hopefully we can fix the old 
loading method! :D

The one modification in gmConfig_p.h is commenting out one line 
that was causing a error. It was just a variable that had been 
defined by a windows file already. I'm pretty sure it doesn't need 
to be defined there also, but take a look if you like.
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
18. oct. 2007 - Trefall
-------------------------------------------------------------------
Didn't get much time today. Just added a very little vector list
declaration to the entity rendering class, will start to build
thatone out tomorrow.

I didn't get time to look at your code either today, but I tried
compiling, and it works perfectly :D Good job man!!! It's so cool
to wake up in the morning and see progress on this project even
though I've been sleeping. Huge motivation boost... as if I didn't
have enough of motivation already!!! ;)
-------------------------------------------------------------------
-------------------------------------------------------------------


-------------------------------------------------------------------
17. oct. 2007 - Trefall
-------------------------------------------------------------------
Hey Ravine!

In this readme, just add any how-to's for new code that is added.

I just added an abstract rendering system now. Helps seperating API
specifics from engine logic and allows us to add in a plugin type
architecture at some point if we ever wanted to.

main.cpp holds the callbacks from glut, calling Render() each frame,
and Update() on idle. Render() calls GameManager's Render method,
which calls the RenderManager's RenderStart and RenderEnd methods, 
which finally calls the complementing RenderSystem specific methods.

The plan is that the RenderManager will hold a list of Renderable
object pointers, which points to entities inheriting from the
abstract Renderable class. The renderable class will hold the info
needed to render meshes. It will be implemented in such a way that
it stays RenderingAPI independent outside of the RenderSystem.

Alright, I'll have more tomorrow, and I'm looking forward to see
what you'll be doing on the scripting front ;)

EDIT: Oh, and I think someone forgot to add some dependecy files to
their svn commit ;)

-------------------------------------------------------------------
-------------------------------------------------------------------