Today’s update is probably not what you expect since I didn’t quite finish working on the AScope type already. This time, I couldn’t resist the urge to get to the graphics aspect of the engine. Let’s get started!
So during the past week, I’ve actually gotten around working on the AScope type and actually did finish working on it, except I haven’t implemented how it’s passed to AExpression instances yet. Most importantly, I’ve started working on getting Perspective Projection as an option for rendering in addition to Orthographic Projection which the A-Engine has been restricted to until now. To explain the difference in brief, Perspective Projection does a better job in simulating how our eyes see things. It allows objects to stretch and shear to give you a sense of depth of the objects in your field of sight.
It becomes obvious that allowing Perspective Projection and implementing an effective camera for it is already most of the work needed for allowing 3D models in. This will mark the transition of the A-Engine from a 2D only Engine to one which allows doing games in both, 2D and 3D graphics.
Now in order to allow for using models, there were few things to consider. First, I have to adopt the more universal coordinate system where the y-axis is upright instead of the inverted one 2D games, and the A-Engine itself, used; what this means is that giving a hitbox y_impact=10 will launch the target it hits upwards now instead of downwards. To my naivety, it turned out I had made the z-axis inverted too. Also in the older rendering code of the A-Engine, the z-position of objects was included with the y-position when objects were placed on the screen. Resolving some of these issues, and trying out Perspective Projection yields:
*The character Template sprites are from the game Little Fighter 2
As you can see, it’s much easier to locate objects more accurately even though no ground nor shadows are rendered. In a similar manner, Perspective Projection will actually be more intuitive to work with. There are few things to note in the above screenshots:
- Left is right and right is left. Near is far and far is near. i.e moving is reversed for each left, right and up, down; as a result of the inverted axes hodgepodge (I love this word, by the way). Will of course be fixed, but the y-axis will be upright now as I’ve mentioned earlier.
- The very low FPS reading in the title of the window. Don’t worry. This has nothing to do with the projection mode itself, as no matter what you use, it shouldn’t affect performance at all. This just has to do with heavy debugging stuff I had when I did the screenshot.
- The black background. If you’re one of those whom have been following me from the forum, then you probably already know that I have went about reworking the stage files to allow for things like different tiles interchanging their positions or trees coming up in different locations every time you play the stage. Fortunately actually, I hadn’t finished working on that, and now there will be a need to change few things in correspondence to the planned 3D support. More details will be shed on this later.
There is one thing which I haven’t talked about before, even though it has been there for a while, and that’s about me upgrading the A-Engine’s graphical API from OpenGL 1.X (known as Legacy OpenGL) to Modern OpenGL (3.0+). To make it brief, in addition to many performance issues, legacy OpenGL didn’t allow manipulation of vertices and fragments (pixels but not really) after the graphics are sent to the GPU, but it was the responsibility of the OpenGL specification to render them as you specify in their enum switches. With modern OpenGL, it becomes the responsibility of the programmer to write programs or routines for the GPU to use, giving them control over the whole process until the LEDs or whatever are lit on their display screen. These routines/programs are called shaders, and in OpenGL, you write these using GLSL. Shaders in game development have been very useful for custom lighting algorithms, more flexible shadow mapping, and most importantly, post processing effects. Basically, you will be able to do some of the stuff you can do with Photoshop, on the graphics of your objects, at run time. Here is an example of a 3D model which lighting’s been processed with 2 different shaders:
The main point being, the A-Engine will support these shaders, and you’ll be able to apply any to whatever model/sprite you like individually. In addition, for those who wish, they will be able to write their own GLSL shaders and use them for their A-Engine creations.
One last thing that is worth mentioning is that I’ve been investigating the android development environment to see the odds games developed with the A-Engine will be able to make it on the Android OS. For those who don’t know, the A-Engine is being written in C++, and uses of SDL2 for inputs and sounds and OpenGL for graphics. Developing for android in C++ is available via Android NDK, SDL2 supports android with sounds and touch events, but OpenGL is only available on phones as OpenGL ES, a downgraded, outdated and a branch of OpenGL. While a lot of developers have praised OpenGL ES 3+ for being up to date, its not yet wildly available as OpenGL ES 2 is, so I am not counting that. In order to test it for myself, a couple of days ago, I’ve tried out OpenGL ES2.0 to render some stuff, and it turned out to be very similar to its non-ES counterpart, save for the fact that it doesn’t support later GLSL versions. With this, A-Engine on android is definitely something to look for in the future!
And here is where I will stop typing. Sorry for the giant post today, but I will be trying to write less and more concisely in the next updates.
If you have any questions or comments, feel free to drop them below, and I will do my very best to reply.
I will see you in the next update, and have a nice weekend!
Contact at: firstname.lastname@example.org