Pages: 1 2 »
  Print  
Author Topic: I got to thinking.  (Read 4380 times)
Offline (Male) qc.zackf
Posted on: August 09, 2009, 01:08:47 AM

Member
Location: Winter Haven, FL - USA
Joined: Aug 2009
Posts: 41

View Profile Email
    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...
Offline (Male) Josh @ Dreamland
Reply #1 Posted on: August 09, 2009, 10:01:48 AM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
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
Offline (Male) RetroX
Reply #2 Posted on: August 09, 2009, 10:06:53 AM

Master of all things Linux
Contributor
Location: US
Joined: Apr 2008
Posts: 1055
MSN Messenger - classixretrox@gmail.com
View Profile Email
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)
Quote from: Fede-lasse
Why do all the pro-Microsoft people have troll avatars? :(
Offline (Male) qc.zackf
Reply #3 Posted on: August 09, 2009, 01:48:43 PM

Member
Location: Winter Haven, FL - USA
Joined: Aug 2009
Posts: 41

View Profile Email
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?

Code: [Select]
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...
Offline (Male) Josh @ Dreamland
Reply #4 Posted on: August 09, 2009, 04:45:58 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
How about
Code: [Select]
list<var> list1;Or, implicitly, as it may be possible to do:
Code: [Select]
list list1;
Then
Code: [Select]
list1.push_back("something");
list1.push_back(1);

Maybe list::add can be added... I'd much rather not, obviously. But yeah.

Code: [Select]
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
Offline (Male) qc.zackf
Reply #5 Posted on: August 09, 2009, 08:10:39 PM

Member
Location: Winter Haven, FL - USA
Joined: Aug 2009
Posts: 41

View Profile Email
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...
Offline (Male) Josh @ Dreamland
Reply #6 Posted on: August 09, 2009, 09:26:23 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
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
Offline (Male) qc.zackf
Reply #7 Posted on: August 09, 2009, 09:54:50 PM

Member
Location: Winter Haven, FL - USA
Joined: Aug 2009
Posts: 41

View Profile Email
Can map<key,type> be accessed through EDL?
Logged
Only ask questions you know the answer to...
Offline (Male) Josh @ Dreamland
Reply #8 Posted on: August 09, 2009, 10:18:16 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
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
Offline (Male) RetroX
Reply #9 Posted on: August 09, 2009, 10:28:27 PM

Master of all things Linux
Contributor
Location: US
Joined: Apr 2008
Posts: 1055
MSN Messenger - classixretrox@gmail.com
View Profile Email
Each object should operate like a class.  I'd rather not have to mess with the with statements and just do something like: obj_this.function().  It also would be nice if we could declare class functions within objects.
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)
Quote from: Fede-lasse
Why do all the pro-Microsoft people have troll avatars? :(
Offline (Male) qc.zackf
Reply #10 Posted on: August 09, 2009, 10:47:37 PM

Member
Location: Winter Haven, FL - USA
Joined: Aug 2009
Posts: 41

View Profile Email
Hell yes it would.
Logged
Only ask questions you know the answer to...
Offline (Male) Josh @ Dreamland
Reply #11 Posted on: August 10, 2009, 08:50:32 AM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
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
Offline (Male) Rusky
Reply #12 Posted on: August 10, 2009, 10:56:20 AM

Resident Troll
Joined: Feb 2008
Posts: 955
MSN Messenger - rpjohnst@gmail.com
View Profile WWW Email
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
Offline (Male) qc.zackf
Reply #13 Posted on: August 10, 2009, 01:33:52 PM

Member
Location: Winter Haven, FL - USA
Joined: Aug 2009
Posts: 41

View Profile Email
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...
Offline (Male) Rusky
Reply #14 Posted on: August 11, 2009, 12:50:25 PM

Resident Troll
Joined: Feb 2008
Posts: 955
MSN Messenger - rpjohnst@gmail.com
View Profile WWW Email
I didn't say anything about how EDL is now, I'm not sure how it works at the moment.
All I was saying was that's how it should be. Unless EDL can pass types around, including non-GM-object classes. Which would also be cool.
Logged
Pages: 1 2 »
  Print