This engine looks amazing and I can't wait to try it out when it's finished or in some beta phase. Taking MMF2 into the 3D (or 2.5D) world is a grand step forward I think, even if the graphics are maybe just on par with Minecraft. I would like to know a little more details about this though..
1. Are mouse look/FPS controls possible?
2. Are there height variations possible? Slopes?
3. Are Levels made of blocks like in Wolf3d?
4. Are light variations possible?
5. Is gravity possible? Jumping etc.
6. How is the performance? Does this run on average Joes machine?
And another thing, you said it is quite difficult to make anything happen with this engine, but Hayo said it is simple enough for "someone like him" to make a game with it. So, what does that mean? How do I generate a map? Do I draw like a 2D map with blocks on a layer and it will be computed into a semi 3d world?
Sorry for so many questions, but I'm quite excited about this
Anything OpenGL is possible, only limited by your own 2.5D coding and modeling skills. Fishhead 3D is made with blocks and no shading or other effects because I totally hate modern graphics. Models, filtering, shading and all that fancy stuff will be possible. Looking in all directions, slopes and all that is possible as long as you can code it on your 2D playfield.
The video of FH3D was made on a 5 year old laptop, so it runs pretty well.
Of course Matt can give you all the details, but he is hiding atm
I really have to restrain myself when people mention Minecraft. I will need to invest in some blunt instrument to attack people who mention it. This engine and Minecraft were developed synchronously and I object to even small hints that Hayo's graphics or this engine are in any way some replication of it. That aside...
1. FPS control is possible up to the point of FPS control in MMF2. You could potentially draw at a fraction of the framerate. The OpenGL extension itself seems to take care of the redrawing and handles vsync. If there is much interest in it then maybe I will look into some user friendly methods. You have complete control of the camera. This is OpenGL, it doesn't interfere with game logic at all, you have to do that yourself like you would in any 2D game. The whole point of this engine is to take 2D objects and 2D logic, things you are used to doing, and rendering them in 3D. Of course you have control of all 3 dimensions in code. You specify the camera angles if you want. You could have a mouse controlled camera movement by changing the rotation based on mouse movements and putting the mouse in the centre of the screen. I expect this will be a popular demand so expect to see an example of it at some point.
2. Yes height variations are possible. I am just not supporting it in terms of easy to use objects. You can specify the x y z and rotations of all of the objects, just don't expect the engine to help you with height testing and collision detection in more than 2 dimensions.
3. Levels are made from objects. Like actives and backdrops in an MMF2 game, you have active and backdrop objects. You want to use backdrops where possible because it's more efficient. Of course this then means you can't move the objects. There is no confinement to a grid, but there is nothing stopping you from doing that if you wanted.
4. OpenGL lighting is supported if that's what you mean. You have control of this with Min's advanced lighting object.
5. The logic of that is up to you. I know it's possible. I could code a completely 3D game in MMF2 using OpenGL, but it misses the point of this engine.
6. Performace is surprisingly good. There have been a few issues on some machines especially due to the terrible implementation of OpenGL on windows vista. I am always looking for optimisations though and I have made some significant improvements over time.
I am about to finish the "base object". This object gives me (and anyone interested) access to some OpenGL drawing routines. I imagine the reason why people aren't making games with the OpenGL extension is because they do not really understand how OpenGL works and it's too hard for them. There will be a whole bunch of objects (or just a single object with a selectable type) that has no code in it/them, they are just used for storing object data. I will then write some MMF code that looks at all of those objects in the level and uses the base object to draw them for you. This allows you to dump objects in the level editor where you want them to be, define the type of object, and you can move these around, test collisions etc like they are just actives, and you will see this rendered in 3D.
Oh, My, God. This looks awesome! I remember hearing about the Fishhead 3D project a while back but I don't recall hearing about an open source engine. This sounds like just the kind of thing I've been looking fore. I love the idea of taking the 2D overhead style programming and applying a 3D view to it. That's basically what Wolf3D and Doom did. I can't wait to get my hands on this thing.
Anyway, reading over your project profile there was really only had 1 point to talk about. Although given the lateness of my arrival here I'm now afraid that it's too late to do anything about it. Also, this is all just based on my own experience. So here goes.
"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."
Pleas make sprite handling easer. One of the biggest headaches I have had when it comes to any kind of 3D in MMF was how other extensions dealt with sprites. Like the Mode7 object, the 3D-Actives object or the other versions of the Open GL extensions. I honestly think that more people would use the Mode7 object if it's sprite handling was easer. I think the way the Ray-Casting extension handled it is probably the best way to go. When I first bought it I was bracing myself to have a hard slog trying to figure out the sprite system. But they made it so easy, all you do is "add an active object as a sprite", basically just 1 call. You can even "link Directions" so you can set up a doom/wolf3D style 3D sprite just using the animations inside the directions of the active object.
... Reading that back I'm not sure that explains it right. You know how in doom, all the monsters are 2D sprites but if you can walk around them they change there animations to make it look. The Ray Casting object did this buy itself!
Now I don't expect you to do it the exact same way, I'm not even sure it's possible to do given the nature of your engine, all I'm trying to day is that the easer you can make it, the better. I think there are some things that are so standard that they should be automatically implemented. One of the main reasons I brought up the Ray Casting extension was because it's a pay extension I don't think that many people know about it.
Anyway, this looks like some grate stuff.
"Oh, my god! A lightning monster just ripped out this poor woman's eyes, and your mocking her shrubbery!" - The Spoony One
I have thought about this. It would be nice just to use actives. I need to become a little bit more familiar with the SDK to work this out: I know theoretically what needs to be done, the pseudo-code if you like. I imagine you would insert a placeholder for collision detection and then select an active to link this object with. You could then just play through animations and such and it could all work just like that. It's a nice goal to aim for and I know it can be done, but I would really like to push this thing out as soon as I can and then make such improvements. The simple plan isn't exactly difficult at the moment but it could be better as it's a pretty manual process at the moment: you have to specify the number of animations, the number of directions and the animation speed, and then add some textures with the appropriate name, i.e.
remembering that directions are specified anticlockwise starting at 3 o clock -> and start with 1 (I find it rather tempting to start from 0).
Using actives would have a number of benefits such as:
1) you can use existing actives without having to put textures into the texture bank
2) you can specify a lot more information about your animations ( animation speed and looping )
3) you have a very nice editor without a jumble of textures.
I am sure this will come about, I just really think it's more important to get this done and released first.
I'm glad your thinking about these things, and I understand if you wont to get it out so people can start using it. Also people will be able to give you feed back and that may help to improve it. One thing that is hard to keep in mind, or at least I find it hard anyway, is that something that might seem simple to a programmer might be frightening to a layperson. I'm sure the people who made the Mode 7 object thought the sprite handling in that was fearly simple but hardly anyone used it.
---------[EDIT]---------
Oh, forgot to mention, in the Raycasting extension it would be optimal to use an separate active for collision, but it wasn't necessary. In my 3rd demo I just used the Wolf3D sprites because I couldn't figure out how to make the right sprite stay with the right collision detection object.
"Oh, my god! A lightning monster just ripped out this poor woman's eyes, and your mocking her shrubbery!" - The Spoony One
Advertisement
~Matt Esch~
