Project: Stone Goose OpenGL Engine
| Project Started: |
26th October, 2010 |
Last Update: |
26th November, 2010 |
| Project Owner: |
 ~Matt Esch~ |
Project Members: |
|
| Project Type: |
MMF2 Extension |
Project Progress: |
|
|
| Project Overview |
|
I have decided that it's a good idea to log this project for 2 reasons. First of all some sort of public documentation of the project will urge me to complete it. Secondly, this is a good way to make people aware of the OpenGL development that is currently underway.
For those of you who have not explored the possibility of 3D games in MMF2 (or TGF2), OpenGL is a very feasible option. In fact you have as much control over OpenGL as most programmers have. Perhaps I am behind with the times, but the last time I checked, MMF2 was looking to receive a set of extensions belonging to an implementation of the Irrlicht 3D game engine. From experience I felt that this engine was fairly limiting with respect to what I wanted to do. I managed to get a copy of a subset of these extensions to see what they are capable of. The major issue I had with it was that it doesn't support primitive models by default. I can't make 3D models myself, so I tend to build scenes using textured primitives. Another issue I walked into was that I was not given the opportunity to work with the Irrlicht extension during the alpha or beta phases for various reasons, so I have turned my attention to creating a *free* solution to implementing 3D games using click products.
We have to respect that the current major click products are designed to make 2D games. While it's possible to make full 3D games using MMF2, I dont see how this could ever be targeted towards the average click user. The engine I am working on is primarily oriented towards 2.5D games. These are essentially 2D games that are visualised as 3D games. Mario kart (some versions of it at least) is a good example of this sort of style.
The engine I am working on at the moment is the first phase of a 2 part implementation of a 3D engine using MMF2. This engine encapusaltes all of the necessary OpenGL routines that are needed to draw all the things we want to draw. This is built on top of Min's work, which you can find on Clickteam's forums. Most click users will find themselves lost in a cloud of OpenGL calls. The Stone Goose OpenGL engine is a semi-generic engine that allows people who know what they are doing to implement 3D engines in MMF2.
Once I have completed this extension, I will turn my attention to actually writing an engine that an average person can use. The result will be fairly unconventional because it will require MMF code. The idea is that I will write a base code set, and people will work from this. You should use MMF's clone level functionality to duplicate my work and then build up the objects that you want to appear in your level. In order to make this easy I will write numerous "placeholder" objects. These objects are almost like active objects, except they don't have animations, only a single image, but most importantly they are used to store the values of the object they represent. The image is used for the sake of collisions. The objects themeselves will have properties that relate to the object: a cube has 6 faces, each with a colour and a texture. The cube also has a width, depth and height. All of these properties will be available to define on the object, but the MMF code that I write will take these properties and draw them for you using the Stone Goose OpenGL engine. What is important is that users will not be required to have skills beyond what they currently have. You will still be able to create sprites and use these in your 3D games and you will simply dump objects in a top-down or side view, and these will be rendered in a relative position, so the playfield still has its use.
Hopefully this project is of interest to this community. If you think this is a good idea feel free to leave a comment or rate this project. I hope to have something to demonstrate in the near future, phase 1 is nearing completion. Perhaps once this is done the Android SDK will be ready for my OpenGL ES plans...
|
 |
Project Forums |
Topics |
Posts |
Last Post |
|
Public Forum
Public forum for open project discussion |
2 |
11 |
So... what's poss...
By: Disthron
On: 18th Nov 10, 01:24:59
|
|
 Private Forum
Private forum for project members only |
0 |
0 |
No Access
|
Not enough time
|
Posted 26th Nov 10, by ~Matt Esch~
|
2 Comments
|
I finally managed to get some work done today. I am finding it very difficult to find time whilst completing my final year of BSc Computer Science with Mathematics. I love the course but it sure does take up a lot of my time.
I keep losing bits of paper with todos on, so I am just making a quick log of what needs to be done on the base object...
1) Optimize skybox drawing
2) Implement the viewport changing function (already written, just need to call the function)
3) Go through the expressions list and make sure everything is there and in order.
4) Add an angle calculating function to the calculator list.
5) ... write some documentation -_-
I guess I will have to start thinking about beta testing this object. This base object requires a considerable amount of understanding to use. Fortunately I don't expect the general populous to have to deal with it, leave that to me 
|
|
Sprite scaling consistency
|
Posted 29th Oct 10, by ~Matt Esch~
|
7 Comments
|
The Stone Goose OpenGL engine has the ability to calculate sprite scales. Lets see if I can explain the difficulty here...
OpenGL measures everything in "texels". When you specify sizes in OpenGL, you are working with texels. When you have finished telling OpenGL what to draw, the scene is rendered and you can see the image you have produced.
Sometimes, we want to know how big our polygons are going to be in pixels on our screens. If I draw a square that's 32 x 32 texels in size at a distance z from the camera, how big is that going to appear in pixels?
Well really we don't care what size it is going to be, rather, we want to know how we can draw a square that appears to be 32 x 32 pixels on our screen at distance z.
What we need to compute is the texel to pixel ratio. How many texels are there to the pixel? Stone Goose OpenGL engine can do this calculation for you. Of course this depends on how far things are away from the camera ( z distance ), since things get smaller due to perspective as they move away from the camera, so you have to specify the z distance and you get a ratio for that distance.
I have attached a screenshot of this in action. Thanks go to Hayo for the lovely graphics.
You can see that the main player looks like a 2D image. I decided that my main player sprite was going to be 50 texels away from the camera, and then calculated the sprite scale at z = 50. I calculate this number, and then draw all my sprites at actual pixel size * sprite scale, and then all of the sprites are scaled relatively.
I am thinking of making this scaling automatic, it would probably make it easier for people who don't understand it very well, but it might cause issues for people using lighting.
Another point to mention is that the HUD graphic you can see is actually a 2D sprite. This is not drawn in 3D but actually drawn as a 2D image on top.
That's all for now 
|
|
|
 View Project Archive
|
Is this worth a look? Let others know!  Favourite
|
Advertisement
