ENIGMA Development Environment

I am thinking of revamping our particle system to support this popular extension from the GMC.

http://gmc.yoyogames.com/index.php?showtopic=422338

Except, it won't be used via dll, I basically mean to extend our particle functions to include the ones it has basically rewriting it but having the same function names.

What do you guys think? I figure well I wanted 3D particles, and this was already a well established and popular API for Game Maker, so why not make our functions the same?

Edit: Heh, he even mentions LGM in the topic...

**NOTE, Change the room in the GMK to see the right demo (Default is now the Spore Like Galaxy)
400k. (Because of sprites) GM7... You can convert it to gm6 with LGM. GM6er's Notes

Yah just a heads up everybody, Studio removed the draw_set_color function, well, the way it used to be anyway. I recently readded it the Game Maker 8.1 way with Direct3D where you can call it to change the color of a model or the alpha, but listen here is the funny thing. YoYoGames decided to store current color for every vertice, making their code redundant one would assume, and making it run slower and also making it less flexible to use, eg. drawing transparent models, when they simply could have replaced the blend operation in the FFP with HLSL. But never the less ENIGMA will continue the old expected draw_set_color behavior because it is rather useful to draw transparent models and the likes.

void draw_set_color(int col)
{
enigma::currentcolor[0] = __GETR(col);
enigma::currentcolor[1] = __GETG(col);
enigma::currentcolor[2] = __GETB(col);
    D3DCOLOR D3DColor = D3DCOLOR_RGBA(__GETR(col), __GETG(col), __GETB(col), 155);
d3ddev->SetRenderState(D3DRS_BLENDOP, D3DBLENDOP_ADD);
    d3ddev->SetRenderState(D3DRS_SRCBLEND, D3DBLEND_BLENDFACTOR);
    d3ddev->SetRenderState(D3DRS_DESTBLEND, D3DBLEND_INVSRCALPHA);
    d3ddev->SetRenderState(D3DRS_BLENDFACTOR, D3DColor);
d3ddev->SetRenderState(D3DRS_TEXTUREFACTOR, D3DCOLOR_RGBA(155, 155, 155, 155));
}

Also, this means that stupid cubes demo of their's won't work right out of the box. And listen how dumb this is, here is why...
       draw_set_color(c_red);
       d3d_set_lighting(true);
       d3d_light_define_direction(0, 0.5,0,1, c_white);
       d3d_light_enable(0,true);
       
       d3d_transform_set_rotation_z( d3d.x );
       d3d_transform_add_rotation_y( d3d.x/2 );

       if( global.cube>=0 ) d3d_model_draw(global.cube, 0,0,0, -1);
       
       d3d_set_lighting(false);
       d3d_model_draw(global.wirecube,  0,0,0,  -1 );

They put draw_set_color(c_red); directly before drawing the cubes. Which doesn't even change anything in Studio since set color was stored in the model but yet it does work in ENIGMA. Which makes me wonder why the fuck that code is even their in there demo, if they were just testing it or testing if it was removed or what. But at any rate, ENIGMA will keep the easy to use expected behavior and sprite batching will render on the state change since it is simply a blend op.

Because of inheritance I was able to get the following Studio tutorial working, with a slight modification to two for statements because none of them know how to program.

That is right I have implemented full object inheritance and polymorphism to the compiler, even the event_inherited() function and the corresponding drag and drop tile. There is a setting now added to Build->Settings where you can completely disable inheritance if you, for instance, like cheeseboy, you only want inheritance for collisions and nothing else.

You can also see settings there for my angular unit and scalar types, the options don't do anything quite yet they are implemented in the engine the setting is just hidden away I have to do something else first before I make the options work.

Compatibility should improve a lot now. You must update LateralGM and the plugin if you update from git or vice versa because a modification was made to allow the YAML settings layout to parse checkboxes. At any rate, enjoy!

I just want to prod everyones thoughts on merging OpenGL 1.1 and OpenGL 3 together into one graphics system. This can be done simply by implementing compatibility mode settings such as software vertex processing that can easily be toggled by simply switching off to vertex arrays which I can do rather easily and would eliminate having duplicate code but make our graphics system backwards compatible.


When the FFP is rewritten to GLSL/HLSL I can simply add another option to set the shader model compatibility level. What does everyone think about this?

Also, I am thinking of changing a few things around and making this ENIGMA settings a little more complete such as better layouts because right now the frames eyaml file makes it look like shit, and also adding maybe like tab support or something, because really there will be other graphics, collision, and audio settings and I think these 3 systems should each get their own tab.

I have made a further attempt at eliminating casting. Most of the API's we use internally use radians, not degrees, so I decided to implement a macro to the universal system scalars that can be easily changed and used to switch entire systems between degrees and radians. Please use these functions, as I have added them to Box2D extensions already, anywhere in the engine that a function takes degrees or any sort of degree/radian conversion occurs.

The angular unity macros can be found in this file.
https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Universal_System/scalar.h

I don't know if many of you have seen this or not but it is basically a free and open source remake of the original Age of Empires, except with modern HD graphics and very big largely detailed maps. I have already had a chance to play it while it was early in development and it was already really stable and fun then, but the game is now nearing completion and I have once again picked it up for another play through.



I definitely recommend you guys head over to their site and try it out, they did an absolutely brilliant fucking job with it.
http://play0ad.com/

Platforms: Windows, Linux, Mac

Monkey is a next-generation games programming language that allows you to create apps on multiple platforms with the greatest of ease.

Monkey works by translating Monkey code to one of a different number of languages at compile time - including C++, C#, Java, Javascript and Actionscript.

Monkey games can then be run on potentially hundreds of different devices - including mobile phones, tablets, desktop computers and even videogame consoles.

Monkey saves you time and allows you to target your apps at multiple markets and app stores at once, potentially mutiplying sales several times over.

Exports to:
Features: Monkey, Monk IDE, Mojo for Android + iOS (iPhone, iPad, iPod Touch) + Windows Phone 8 + Windows 8 + GLFW (Windows, Mac, Linux) + XNA (Xbox 360, Windows Phone 7) + Flash + HTML5, documentation, samples

Price: 100$

Recently tried it myself, it is very nice, their IDE is in Qt as well. I would use it over Studio as well, has classes real object orientation, etc. 3d all that shit.

Game Maker returns floating point precision for dot product functions, ENIGGER returns double precision. Don't know what Josh thinks about this since last time we talked about it he said all the internal C functions use double precision, so idk.