qc.zackf
|
|
Posted on: August 09, 2009, 01:08:47 am |
|
|
Location: Winter Haven, FL - USA Joined: Aug 2009
Posts: 41
|
Ok, just saw the child forum below and read most of the post. No offense to anyone here, but damn, you guys put that guy in the ground. His 'program' and I use that word carefully didn't seem all that bad from what I read, just another GM alike, which has been making me wonder and think 'real' hard. I'm honestly sick of gm but from what I understand ENIGMA is going to be 'similar' (used carefully) to gm. So why not completely rear off that path. I was looking in the Development section of the site and noticed that the 3D implementation is planned(no matter how far away) to be 'just like' gm and that bothers me. Why not incorporate a front-end interface for 3D? I know LGM is not ENIGMA developers responsibility, but you do use it as an IDE and I don't feel that it needs to change, you can always modify it easily. Here is some recommended changes to create this front-end 3D interface: - Make a 'Mesh' resource object and a small editor/viewer in LGM to go with it.
-
Instead of 'Backgrounds'; call them 'Textures'. - For 2D objects create a 'Node' object. Which will be NO different than the gm 'Object'. For 3D objects create an 'Entity' object. This will be just like a 2D 'Node' but with 3D components.
- Now a 'Room' should similar to it is now except designed for the 3D placement of 'Entities'. A WYISWYG 3D editor. For all 2D 'Nodes' create a resource called 'Overlay' with an editor (no different than the room editor now). which can be used to place 'Nodes'. Every 'Room' can have an 'Overlay' associated with it. If the game does not use 3D; then just use 'Overlay' objects and use an empty 'Room' and control the game progress by changing the 'Room's Overlay'.
- Create a resource called 'Material' which will be applied to 3D objects, along with an internal editor/viewer.
- Create a tool called 'Interior Editor', which will create a mesh and a material associated with an octree mesh.
- Create a tool called 'Terrain Editor', which will create a mesh and a material associated with a terrain.
- Create a resource child-of 'Room' called 'Camera' in which 'Material's can be added to in order to create special effects. This will be 'Room' oriented; not a global object.
- So here will be the tree-node setup example for a visual:
[-] Sprites [-] Textures [-] Meshes [-] Materials [-] Paths [-] Time-lines [-] Scripts [-] Nodes [-] Entities [-] Overlays [-] Room [-] Camera Allright, this isn't meant to harm the progress of ENIGMA but it would be nice to see this program grow into powerful software that can be used to easily create next-generation games. As far as console support goes, ENIGMA does use C++ so not impossible; just legal issues to deal with. These are only recommendations to think about while ENIGMA is still early in development.
|
|
« Last Edit: August 09, 2009, 01:55:07 pm by qc.zackf »
|
Logged
|
Only ask questions you know the answer to...
|
|
|
Josh @ Dreamland
|
|
Reply #1 Posted on: August 09, 2009, 10:01:48 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
ENIGMA will always support GM functions for the same reason that Microsoft still has a thousand deprecated functions from Win95. It's just so old things you've made will still work.
Most of the GM functions are so vague that they will fit into any system we decide to build, especially for 3D. The most advanced thing his 3D functions can do is work with his own model format. It's almost pitiful.
I've wanted a mesh/material resource for some time now. The background resource, however, I'd like to stay named backgrounds and just have it apparent that they contain a texture. The more advanced users will be the ones using 3D, and they will understand that sprites and backgrounds can be treated as textures. Novice users, however, won't understand that textures can be used as a background image.
Or perhaps they will, but I always think it's best to start something at its simplest and then show how additional functionality is possible.
As for a mesh resource, I'd really like that. LGM doesn't have so much as a sprite editor at the moment, so I'm not going to speak for all the things I'd like to see in the IDE. However, making a 3DS importer shouldn't be difficult.
Right now, I'm focusing on making a fully functional parser. I believe this will carry us the rest of the way.
If you look at the GMC, you'll see a bubbling vat of ignorance. But amid that ignorance lies some true talent in specific individuals who dedicate their time to making GM-Compatible DLLs. Imagine if this group of people was able to develop (in their own language, for many of them) right in the game's file.
A new resource we have already added will allow users to add functions to ENIGMA that are as fast and functional as the official ones. And, should they develop a working system, it may go on to be an official part of ENIGMA. That's very idealistic, of course, but if nothing else, I know of several people who are at least decent at C++ who would be willing to help develop GM functions for ENIGMA.
What I'm getting at is that, with a little luck, people will come along to extend this thing far past where GM is, and hopefully past where I could have done myself.
And if I can get these new parsers working, users will have the C++ language at their fingertips, right along with GML.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
RetroX
|
|
Reply #2 Posted on: August 09, 2009, 10:06:53 am |
|
|
Master of all things Linux
Location: US Joined: Apr 2008
Posts: 1055
|
The only problem with mesh is that you would have to support skeleton animations. You would just have to.
I say that the d3d functions should be there (which won't even be d3d since it's using OpenGL and not Direct3D, but called that for compatibility), but the real 3D functions should be called gl3d_whatever, and also add some other functions that are prefixed gl2d_whatever for some advanced 2D drawing functions. I say that we should do something similar to what you said, and while we're keeping the "depreciated" Game Maker functions, we should definitely use something else all together if we want real GL drawing functions that aren't limited to Mark's specifications.
For the way I see this, we should have two modes for making games - GM and ENIGMA, one keeping to GM's tree with only GM's functions, and one for ENIGMA with everything.
As for node/entity... really, I think we should just keep all objects as the same resource. Just add a little checkbox for 2D/3D.
For overlays... I think it should be surfaces. These surfaces could be then used as textures on 3D mesh (and HUDs, etc.), or just in 2D rooms. It would be a slight bit more work to draw the surface on the room, but it would be better. One thing GM does not have is surfaces that work in 3D mode.
|
|
« Last Edit: August 09, 2009, 10:12:11 am by RetroX »
|
Logged
|
My Box: Phenom II 3.4GHz X4 | ASUS ATI RadeonHD 5770, 1GB GDDR5 RAM | 1x4GB DDR3 SRAM | Arch Linux, x86_64 (Cube) / Windows 7 x64 (Blob)Why do all the pro-Microsoft people have troll avatars?
|
|
|
qc.zackf
|
|
Reply #3 Posted on: August 09, 2009, 01:48:43 pm |
|
|
Location: Winter Haven, FL - USA Joined: Aug 2009
Posts: 41
|
I like 'Surface' better than 'Overlay' but having a 2D/3D check box for each object will not be as efficient. Have an object optimized for 2D use and one optimized for 3D use. GML is not a bad scripting language, just I can't stand how it uses global functions. There's no structure to how the functions are called and in really big games I've had experience where I was confused about what index belongs to what variable. Why not have more structure?
var list = ds_list_create() //instead of: ds_list_add(list,etc,etc); //implement: list.add(etc) Just easier to read to me, but that is my opinion. You guys are saying to keep all GM functions, but why reinvent the wheel; why not make it better.
|
|
|
Logged
|
Only ask questions you know the answer to...
|
|
|
Josh @ Dreamland
|
|
Reply #4 Posted on: August 09, 2009, 04:45:58 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
How about
list<var> list1; Or, implicitly, as it may be possible to do:
list list1; Then
list1.push_back("something"); list1.push_back(1);
Maybe list::add can be added... I'd much rather not, obviously. But yeah.
map a; a["key"] = "value"; a["another key"] = 10; a[-100.5] = "weee";
map<int> b; b[-10] = "wee"; b[-10] = 4;
map<int,int> c; c[1000]=3;
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
qc.zackf
|
|
Reply #5 Posted on: August 09, 2009, 08:10:39 pm |
|
|
Location: Winter Haven, FL - USA Joined: Aug 2009
Posts: 41
|
I wouldn't use add() either; just giving an example.
I like the idea of list<var>; is 'var' the type of variables contained within the list? I think templates would be nice , as they are easy to use and are more flexible.
|
|
« Last Edit: August 09, 2009, 08:13:43 pm by qc.zackf »
|
Logged
|
Only ask questions you know the answer to...
|
|
|
Josh @ Dreamland
|
|
Reply #6 Posted on: August 09, 2009, 09:26:23 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Yes, the parameter in the <> to list is the type to contain. Can often help with speed, though when dealing with linked lists, not sure how much. (No benchmark to date).
With map, it's map<keytype, valuetype>. I'll write some of this in the help file.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
qc.zackf
|
|
Reply #7 Posted on: August 09, 2009, 09:54:50 pm |
|
|
Location: Winter Haven, FL - USA Joined: Aug 2009
Posts: 41
|
Can map<key,type> be accessed through EDL?
|
|
|
Logged
|
Only ask questions you know the answer to...
|
|
|
Josh @ Dreamland
|
|
Reply #8 Posted on: August 09, 2009, 10:18:16 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Anything C++ can do, R4 should be able to understand. Right in with the rest of your EDL.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
qc.zackf
|
|
Reply #10 Posted on: August 09, 2009, 10:47:37 pm |
|
|
Location: Winter Haven, FL - USA Joined: Aug 2009
Posts: 41
|
Hell yes it would.
|
|
|
Logged
|
Only ask questions you know the answer to...
|
|
|
Josh @ Dreamland
|
|
Reply #11 Posted on: August 10, 2009, 08:50:32 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
It'd be hell getting with() to be able to call member functions. It was a big enough pain deciding what to do with instance_destroy().
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
Rusky
|
|
Reply #12 Posted on: August 10, 2009, 10:56:20 am |
|
|
Joined: Feb 2008
Posts: 954
|
d3d_* should just be aliases for the built-in gl* calls, and then gl_* can be EDL's higher-level 3D stuff. Since Enigma is an LGM plugin, adding resources shouldn't be too hard- a mesh resource would be nice for 3D as well.
One problem with objects-as-classes though, is that in GM, objects are referenced by their index, which effectively means you can pass classes around and say instance_create(x, y, <some variable that holds an object index). That would be a pity to lose, so I think objects should be kept as their own type of thing.
Also, saying some_obj.function() is evil, because that syntax makes it look like some_obj is an instance, not a class (grar, GM's stupid terminology is getting in the way...). some_obj.variable is confusing enough once you put it in the context of something that understands C++.
|
|
|
Logged
|
|
|
|
qc.zackf
|
|
Reply #13 Posted on: August 10, 2009, 01:33:52 pm |
|
|
Location: Winter Haven, FL - USA Joined: Aug 2009
Posts: 41
|
I see. In order make each object its own class you would have to rewrite EDL. Sounds painful.
|
|
|
Logged
|
Only ask questions you know the answer to...
|
|
|
|
|