Learning OpenGL

So today and yesterday to a lesser extent, I've been reading the "Red Book" on OpenGL. It's seems long overdue since I'm working on an OpenGL based game engine. I just didn't realize until now how necessary it would be. This way I'll be able to start making commits on the OpenGL side of things. To think that before this summer I thought OpenGL WAS a game engine...derp.

I hope to get some code done today as well, although I haven't made much headway on implementing scenes as a dictionary. So it will be unrelated to that. It's a little bit over my head to be honest, so it's definitely taking some time to figure out what's what with Mapping Protocol and such, and how it actually would be used in the context necessary to actually get this all to work.

Scenes and Dictionary

So today I'm working on changing a scene to work as sequences of bodies. As right now there is no way to know which bodies belong to which scene based upon only have the scene as information. Creating an external storage only makes the code using it really messy. I tried this originally before I realized how silly it was to do it that way, when it could be changed in the API to work better. So I asked Arc about it.

Originally Arc said it was intended to implement this as a sequence of bodies, but after we talked he came to conclusion that it would be better implemented as a dictionary of bodies. This way bodies can be created outside of a scene, be removed from a scene and essentially exist outside of a scene. (In a void scene which contains all bodies not contained in a scene.) Also with the dictionary it helps reference the various different bodies of different names.

So what I'll be doing is looking into Python3's Mapping Protocol, and figure out how to make this all work.

Atomic Cleanup

Yesterday (and the day before that as well) I fixed some bugs with HBox and VBox. Today I'm helping Arc with the atomic cleanup of position/color in various files to fit the newly updated Atoms.

Interactive Console!

I found a good way to implement the interactive embedded console for the scene designer! (After a bit of sifting through search results about implementing an embedded python console in C++.)

Now onto to figuring out Pickle. Which is basically serving in place of the future .soy format, as that hasn't been implemented yet in PySoy. As I'm sure most of people reading this know, you wouldn't want to use pickle in the long run due to it being insecure.

More Joints

Finished up the rest of the joints today, with exception of the two properties Bounce and Stops. (Which is in all of the new ones.) These methods require enum parameters to be added to the ode vapi file, except I haven't figured out what the enums actually are yet. Going to look into this tonight.

New Dev Environment / Tiling WM

So I spent the last few days setting up my desktop to be more efficient for coding. I'm now using Ubuntu with XMonad inside of Gnome. Using Ubuntu in a VM on my Mac in order to have to compile code for PySoy gets old pretty quickly. I'm working on the tiling window manager  for the scene designer right now, thanks to amaurymedieros for implementing resizing on HBox/VBox on the libsoy side it should actually be possible now to start working on. :)

Internal Tiling Window Manager

I haven't been updating quite often enough to this blog, but I feel that as my project moves along and picks up momentum, so will the amount of blog posts. I went to a professor's summer BBQ today, so I ended up starting a bit later than usual. This should of been posted yesterday, but I apparently created the post without actually publishing it the first time. :)

For the sake using the maximum amount of screen space possible, the PySoy Scene Designer will be using a tiling method to manage the windows. For an example of this simple see something like dwm or awesome (tiling window mangers tend not to use capital letters in their names for some reason...), which are two tiling window managers which are used under X. It will be a relatively simple one to start off with, but if it seems necessary I'll add more stuff to it later after other parts of the program have been implemented.

So what I've been working on is the tiling window manager to be used within the program. HBoxes and VBoxes are already implemented in libsoy, so it's just a matter of adding the python c extensions to pysoy. (Which I'm going to work on tomorrow, when I get a chance to clarify. 

The tiling window manager used here really comes down to following three things:

1. The ability to switch the contents of HBoxes with the contents of HBoxes.
2. The ability to switch the contents of the VBoxes with the contents of VBoxes.
3. The ability to full screen any windows.

To help manage this there needs to be a 'active' window at all times. Switches will happen relative to the current window, switching the current window to being the in the primary HBox should be as simple as a key combination press, switching out whatever was in the primary HBox into the secondary HBox, at the top VBox there. And another key combination should allow you to switch back instantly. 

This could be extended to work like cmd-tab does on OS-X (and I think Gnome), if you press cmd-tab once it will go to the last window you used, however if you continue to press tab continuously before unpressing the cmd key it cycles through all of them. The visual functionality of this could be implemented as 'highlighting' the edges of the currently selected window.