angelhill.net/code

Today I thought I needed a lesson in OpenGL. It begun because I had trouble finding good enough info about the isometric perspective, so I thought… “Hey wouldn’t it be nice to have a coordinate system you could spin around in 3D and find out what isometric is all about eh?”

Then my quest for a tutorial on OpenGL begun, and quickly ended here.

Lo and behold, a short while later I was pumping out triangles and cubes and… a coordinate system which I could freely spin around.
Now I have a much better understanding of the system, and can also test out various cool things directly in the 3D engine, like placement of objects and stuff.

Eventually I am surely making a game using OpenGL, the power seems limitless. So now I even took out my physics book along with my maths book, both have joined the pile of opened books all over the place.

Anyway, so far I’ve been mostly streamlining my code, and no new major developments have can be reported today (aside from the 3d engine stuff). I am learning about overloading operators (which is some seriously KICK ASS SHIT!), and basically just doing a lot of refactoring so I can once again start to add new stuff.

Although I really wanna do that thing I wanted, with the clicking on a point and moving the character towards it. I might do it now if I have the brain-power.

Here are some pics of the 3D stuff (first outside the cube, then inside, note the coordinate system) and my desk.

Now that we include the world z position in our display calculations, its time to also implement it in the sprite sort order.
The method basically uses a separate array, into which we stuff pointers to every object that is in the main object array, but in a different order. This array is then used to display the objects, rather then original container array. (the reason for the second array is that we need to keep the object numbers intact, of course, this brings us back to the problem of deleted objects… I am leaning towards a hashtable!)

Currently the order is based on screen_y + world_z coordinates. This is a bit strange, but it seems to work. At least for objects of the same size. I will have to run tests with more tiles.

Working with an isometric engine presents several interesting challenges.

Since you are faking a 3D world, your coordinates are no longer what they appear to be.
Basically you have your world coordinates and your screen coordinates. I am guessing this is my first foray into the confusion of 3D programming
The key to victory is to make sure that everything that you do, you do in isometric coordinates and do the conversion to screen coordinates just before the graphic is to be displayed on screen. At this point my code is getting a bit confusing and messed up, and its time to create some order out of chaos. I shall think about a thorough restructuring tomorrow.

First of all, I now see that I will need a new class or file containing certain methods that will be used often, like the function to transform world coordinates into screen coordinates and back.

I think for performance reasons it might be wise to store screen coordinates in the object class, but they should only be used for the blitting coodirnates, and the conversion should take place in as few places as possible (preferably only if world coordinates are changed, or if camera is moved!).

Otherwise I will go mad. It’s already starting.

However so far it’s not going too bad, tomorrow I have a mission. I must figure out how to point and move a character towards a point that was clicked on the map. This is a maths exercise and I will do it in order to try and get my head around the whole isometric perspective issue. I think I need to read a book too.

So far I am pleased with my progress. I have learned a few new things today. And took out my old maths book…hehehe

Should tiles be game objects?

I mean we will have plenty of tiles, and duplicating them seems like an easy way out, however, when we for example will do map editing or tile rearranging, every tile must be its own object otherwise we will be unable to control it separately from the others.

However, perhaps we can separate the truth from the lies, and simply have one class that draws the map using fake objects, and if a times comes when you need to edit it, those fake objects can be turned into the real thing and give you full access. Pierhaps.

I think I will split the sprite class into a parent and child. We shall have a BasicSprite which will be a one frame image without any rotation or animation, and one that is AdvancedSprite which will have animations and rotations. With polymorphism we can easily add either advanced or basic sprites into the sprites vector for every object, and this way we avoid having to do a bunch of calculations for the unanimated sprites such as tiles.

It just hit me. Events should be objects too?

This thought just popped up in my head as I was thinking about connecting sound objects to graphics objects. And then I thought, why not connect them to event objects too.

Now I have to elaborate on that idea…
Each event that is created in-game can be an object… That can be connected to a graphic object, and have a sound connected to it as well.

I guess that we can connect a group of event object to various game objects. For example, if you have a soldier, perhaps we can give him events like Attack, Die, Walk, Talk.
Each event can be accompanied by more data, and possibly can be extended with python.

Event objects can be used for invisible game events too, and if you assign a sound to it, when an event is triggered, a sound is played. And how can this be? For he is the Event Haderach!

Anyway, this seems like a good idea on paper, but I need to think on it some more. Right now my head is getting tired so I need to go to sleep probably, but I can already feel the possibilities. (and smell the complexity! heh)

I will probably take a break from engine coding tomorrow (i tried today but failed, maybe tomorrow I will have better luck).

However, here is a list of things I did and should focus on tomorrow or day after:

- Finished basic what-you-clicked-on functionality, it does not however check for transparacy yet. Got the basic idea from this article but did it a bit differently. The basic idea is the same however, simply add objects as they are being drawn into a C++ list container (in reverse order, push_front) and then go through it after all sprites are blitted.

- Check if the pixel you clicked on in the current object is transparent or not, if it is, continue checking… this is not yet done, but will be a fun challenge.

- Work more with tiles. I have done basic ISOmetric tile blitting, now the next step is to adapt movement to the isometric perspective (NE is not 45 degrees in isometric terms), and find some tiles on the net to play around with.
The movement aspect has basicly been fixed with some calculations, I will post them later when I actually understand how they work.

- Work on perfecting image metadata structure. I think my image metadata structure is a little stinky and needs to be redone. I’ll deal with it as the time comes, but now I also need to start working on a map storage structure, collision detection and object to object awareness…

- As I was playing around with the game just now, I realised that while my tiles are printed correctly in regards to who’s on top of who, but the objects are not. At first I was thinking that a static sort order was the way, but now as I was playing around, I realised that I would have to dynamicly change the sort order based on the objects position in the game world. So if unit A is lower then B, A should be printed last.
This has been solved, I created a separate array into which objects are sorted based on their position in the game world, however this will probably require more work since its quite basic at this point.

I think that’s all I can think of right now. Far off notes include networking and sound, but I’ll leave that for later…. Saying only that Sounds will probably be their own objects that extend the standard object class, and can be somehow connected to graphical objects when needed.

I just tested some stuff.
I was thinking that if we store the current state of the python object, we could check if there is a state change before actually calling the c++ method to perform the change, since I guess calling methods between c++ and python is a bit time-consuming.
I did run into a snag with my current set up. What if a state change occurs in C++, at the moment, these changes are not sent back to the python object, so if you change the player animation to attack in C++, python will still think that the player is walking and the player will not be able to walk until python tells him to do something else first.

This is a bit of a problem but it all comes back to the greater scheme of things, like how much control will C++ have over the objects, or will python take over everything.
Obviously from a performance POV, we might want to implement most functions in C++, but on the other hand, that would kinda defeat the purpose.

I did run tests on the above scenario, and the python script that called a C++ method every time for 100000 times, ran for about 900ms, while the one that only called the C++ function once, and the other times used an if statement to confirm that the same action would not be done again, ran for about 800ms. So maybe it’s not a big deal.

One thing is clear tho, all the craving functions would probably be better off in C++. However I will run some tests to determine how big the difference is.

Solved the object deletion bug for now by first of all using an array.
Second of all, by moving the last element into the newly empty spot.

- There is still the problem of display order and who gets to be on top.
- The python object no longer carries the correct reference!
The right object id must be returned to the python object
OR
- Use maps?
OR
- Assign a 0 to the slot of the deleted object, and just place any
newly created objects into it

- Next mission is the ISOmetric aspect…or simply the assigning of
some sort of perspective or something. We’ll have to decide more
exactly how to deal with it.
In order to make a tilebased engine look good, ISO is probably best.
However since I have no idea how to do it, I should study the ISO
engine that I already have.
- Implement tiles and draw them.

Problem with current system:
When you delete an object from the vector, it probably becomes so that
the index numbers are suddenly shifted, right?
So if we have a monster who is 3, and 2 dies, then 3 becomes 2, and
monster 3 is left without object… we’ll need to test it.

Perhaps I need to rethink it more fundamentally, or use hashtables.

[SOLVED] Also right now the whole thing bugs out if you delete something
from the vector, obviously this is due to the fact that when you empty
one piece of a vector, it is still there when the program tries to
display it or delete it when you quit. Need better solution.

[SOLVED] Also in Python, right now we remove the reference to the monster
object to kill it, IE assign a 0 to its host variable. This is great,
but not safe. The best way is probably to delete it first, then assign
a 0, making sure that its really gone.