Project forums > Q-Gears
How about OGRE3D?
Cyberman:
--- Quote from: sfx1999 on 2006-05-21 16:50:44 ---What do you mean that it would be hard? You can use glOrtho for the field, and then use your standard drawing for the models.
Or, push a new projection matrix on the stack and then pop it when you want the models.
--- End quote ---
I mean it's not plug and play. More importantly with just GL (if you read carefully) it's easy. With an engine, it's not so easy.
Now the thing is that you have 2d layers and a walk mesh. Somewhere in the field file information is what describes the placement of the 2d layers relative to the walkmesh and when what gets drawn.
In summary you have a number of layers, PC and NPC model information to analyze before anything gets drawn. The ordering of the drawing changes depending on where the PC/NPC is on the walkmesh, and the positioning of the 2d layers. This is not easy especially in a large scene with a bunch of NPC's. If it were one could just throw it together in a few minutes :D
Cyb
Akari:
--- Quote from: Cyberman on 2006-05-21 19:00:03 ---
--- Quote from: sfx1999 on 2006-05-21 16:50:44 ---What do you mean that it would be hard? You can use glOrtho for the field, and then use your standard drawing for the models.
Or, push a new projection matrix on the stack and then pop it when you want the models.
--- End quote ---
I mean it's not plug and play. More importantly with just GL (if you read carefully) it's easy. With an engine, it's not so easy.
--- End quote ---
It's easy. People use engines not to make things harder, but otherwise to make it easier. We need a lot of things that we need to write by ourself aside of GL. Frame limit is one of things thet needs to be created. Console for runtime script debugging, All shading and camera work.
The most hardest are all video cards support. We need a lot of hacks to make them all works correctly and fast, there are a lot of bugs. Engine solve all this problems.
In addition Ogre can use DirectX render which is faster under windows.
--- Quote ---Now the thing is that you have 2d layers and a walk mesh. Somewhere in the field file information is what describes the placement of the 2d layers relative to the walkmesh and when what gets drawn.
In summary you have a number of layers, PC and NPC model information to analyze before anything gets drawn. The ordering of the drawing changes depending on where the PC/NPC is on the walkmesh, and the positioning of the 2d layers. This is not easy especially in a large scene with a bunch of NPC's. If it were one could just throw it together in a few minutes :D
--- End quote ---
2d enviroment is not a problem =)
Read the manual to Ogre =) More importantly that 2d and 3d already works correctly and tested by many users. If we use our own render it will be a lot of bugs. There are to small amount of developers to work on all this things. We need to concentrate on the game itself, not on the one of the hardest things - 3d engine.
It's not problem with ether engine or my abstraction from open gl (the model is loaded into inner format and then we works whith it as one). On lower level they do the same things.
halkun:
I think we are going into a tangent.
The 3d part of the engine is not that hard, the rendering is actually a painters algo with 2d layer overwrites. This seems a little overkill for what we need. When we get to the battle system, there might be a call for something a little more complex, but most of the stuff off the bat is kernel file support and 2d rendering.
Keep all the modules seperate. There is no need to put 3d code into the menu system, which should be the fist module up and running. The field system reads 3d entities for display from the dat file. These are all-in-one models (though you have to piece them togeather) with modular, sharable animation sequences. There is no need for another engine overhead.
3d battles are more long term, and even then, we have a debug battle to parse and play with, (battle 999)
In the end, we should be able to make each compoent of the engine stand on it's own, with very very little interaction between modules execpt for a place for the call to start and a place for the call to end.
In the debug room, when you call battle 999, the battle module is called and the whole field module is deleted. The only thing that the battle module reads is the savemap, (The menu module is also deleted) and the battle number that was used as an argument. Everything else is kernel hooks. When the kernel is finished, The display, animation, and window routines should already be in place in the kernel. We don't need another engine to manage this for is.
Leviathan can load models without a huge engine behind it.
Ifalna and render animations without any huge engine support
Zangan can display battle locations (By the way, the battle backgrounds are the same format as all the other polygon enities in the game)
I think this will lead to overengeering, and overengeering leads to fear, and fear leads to suuuufffferrriiiinnnggg!
sfx1999:
I think it would save a lot of time, and make enhancements so much easier. It really seems like a good idea to me.
Anyway, why do you want to do it the exact same way the FF7 engine did it? The reason they did it was for saving memory. With current PCs that is not a problem.
Cyberman:
sfx1999:
Ummm enhancements weren't a goal originally, and likely still aren't in other words enhance after it works.
The fact is.. enhancements are WAY down the road, these are features and aren't needed for the project to meet it's goal.
It's going to take a bit of time to get objects for reading both types of content. (PS1 and PC)
I'm in a six of this half dozen of the other view on this.
However I do believe it's too early really to implement anything for an engine.
For now we can discuse what will work
There are plenty of ways to implement 3d etc. I'm really not in a big hurry to use anything in particular myself. We've got plenty of time to think about it.
First goal is to have something working for debugging the script engine, kernel, and loading things in.
We aren't there yet so it's OK to think about it but... I see no point in discusing what enhancements are to be made when we have nothing to work with.
Akari:
You make some good arguements it's something to think about. I was looking at the Q3 engine. If you've played RTCW it seems that engine is quite capable of handling menu's etc. Maybe you can look into it?
halkun:
hehehe.. well yes I was kind of saying "interface" to get off the engine thinking and into how to we get what we have to work with something else :)
I'm not sure if an engine will make everything easy, since I've not used one before (grin). However I would like to point out that dismissing something because it's overkill is not a prudent way of looking at the problem. First we aren't there yet, Second it might be good to decide just how do we want this part of q-gears to work. I'm wondering if we build an interface with the ability to use more than just our own custom engine we might be better off (it's more generic at the very least and thus portable). Just in the same way we are handling 3 types of content (PS1 CD, PS1 ISO Image, PC data) the GUI can be handled.
I suggest we look at 'engines' in general find which ones we can use for the project (IE legally) and which ones make our job of handling the modular construction easiest without it becoming overly dependant on engine features. Lets do some research while we implement things that have to be implemented now. When the time comes "to engine or not to engine?" we can decide after thinking about it some more.
Just my thinking.
Cyb
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version