This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
61
General ENIGMA / Search Filter
« on: September 08, 2014, 06:27:20 pm »
Well this was just something I wanted to experiment with today, saw it in the new Studio and really liked the feature so I spent all day coding it and perfecting it to make sure there were no glitches. Functions pretty well and just about the same as Studio and is easily expandable for more capabilities such as regular expressions and case sensitivity. I optimized the searching/filtering as best I could as well so you should expect it to work pretty efficiently.
There are a couple of differences to note however. In the ENIGMA version if you have focus on the search filter and hit enter the selected resource is automatically opened in its editor, Studio does absolutely nothing so I just thought this was a nice little addition. I would appreciate it if everyone could test this new feature and give me some feedback or let me know of any errors encountered and whether or not you like the feature. If everyone likes it and it works out well I will send the changes upstream.
Edit: Changes stable and sent upstream.
This was the commit.
https://github.com/IsmAvatar/LateralGM/commit/d7abae97c3aa06be7c6a5fbfa2e3e80e22e5e91d
The LateralGM version has been incremented to 1.8.6 and also includes egofree's room editor improvements.
The new LGM can be obtained via the extra packages page or through the python script.
http://enigma-dev.org/docs/Wiki/Install:Extra_Packages#LateralGM
A new Portable is also available for download.
http://enigma-dev.org/docs/Wiki/Install:Windows
There are a couple of differences to note however. In the ENIGMA version if you have focus on the search filter and hit enter the selected resource is automatically opened in its editor, Studio does absolutely nothing so I just thought this was a nice little addition. I would appreciate it if everyone could test this new feature and give me some feedback or let me know of any errors encountered and whether or not you like the feature. If everyone likes it and it works out well I will send the changes upstream.
Edit: Changes stable and sent upstream.
This was the commit.
https://github.com/IsmAvatar/LateralGM/commit/d7abae97c3aa06be7c6a5fbfa2e3e80e22e5e91d
The LateralGM version has been incremented to 1.8.6 and also includes egofree's room editor improvements.
The new LGM can be obtained via the extra packages page or through the python script.
http://enigma-dev.org/docs/Wiki/Install:Extra_Packages#LateralGM
A new Portable is also available for download.
http://enigma-dev.org/docs/Wiki/Install:Windows
62
General ENIGMA / Updated Version
« on: August 31, 2014, 12:16:03 pm »
I have decided to pull and test all the recent changes made and done my best at building a new Portable ZIP where everything appears to be working.
You can manually update the ENIGMA sources using git and then obtain the LateralGM and plugin jars manually if you so choose.
http://enigma-dev.org/docs/Wiki/Install:Extra_Packages
You can also download the newest Portable ZIP, however I have not addressed the issue with Chrome flagging it as malicious.
http://enigma-dev.org/docs/Wiki/Install:Windows
Change Log
* Addressed an issue with drag and drop parsing when parameters are left blank with 0 length. https://github.com/enigma-dev/enigma-dev/issues/810
* Addressed a GMX action reading issue, setVal needed called anyway and this is why DND actions loading from a GMX that referenced resources were not working, not the entire action just the specific argument.
https://github.com/IsmAvatar/LateralGM/commit/bea63c57213af221e375379a799c4c5b19495594
* All of egofree's improvements to the room editor should be included as well as preCreationCode
* Various fixes by sorlok for timelines, iterators, scoping and other compiler issues.
If anybody wants a more detailed change log just list the items and I'll update my post.
You can manually update the ENIGMA sources using git and then obtain the LateralGM and plugin jars manually if you so choose.
http://enigma-dev.org/docs/Wiki/Install:Extra_Packages
You can also download the newest Portable ZIP, however I have not addressed the issue with Chrome flagging it as malicious.
http://enigma-dev.org/docs/Wiki/Install:Windows
Change Log
* Addressed an issue with drag and drop parsing when parameters are left blank with 0 length. https://github.com/enigma-dev/enigma-dev/issues/810
* Addressed a GMX action reading issue, setVal needed called anyway and this is why DND actions loading from a GMX that referenced resources were not working, not the entire action just the specific argument.
https://github.com/IsmAvatar/LateralGM/commit/bea63c57213af221e375379a799c4c5b19495594
* All of egofree's improvements to the room editor should be included as well as preCreationCode
* Various fixes by sorlok for timelines, iterators, scoping and other compiler issues.
If anybody wants a more detailed change log just list the items and I'll update my post.
63
This is just a quick opinion topic I want to get you guys thoughts on some things.
First, script_thread should not automatically execute, like any other programming language we should be able to create the thread and then execute when want, so I propose the addition of the following function.
thread_start(threadid);
I would also like to propose syntax handling to allow inline threads like Java.
First, script_thread should not automatically execute, like any other programming language we should be able to create the thread and then execute when want, so I propose the addition of the following function.
thread_start(threadid);
I would also like to propose syntax handling to allow inline threads like Java.
Code: (EDL) [Select]
thread_create() {
show_message("Thread Running");
}.start();
// also the following
var thread = thread_create() {
show_message("Thread Running");
}
thread_start(thread);
64
General ENIGMA / Mipmapping Implemented
« on: July 31, 2014, 11:22:54 pm »
Well after cleaning up all of the latest texture handling to put us back on par with Studio you can now use mipmapping. You can generate mipmaps with the new texture_add or the traditional sprite_add/background_add and then set the filter using the new texture functions. You'll have to pull my changes from GitHub to start using the updated functions, I am waiting to update the ZIP so I can add it into the compiler and let you toggle mipmaps on sprites and backgrounds in LateralGM since it is anticipated that this will also be a feature of Studio. Why you ask? Because I asked Dailly a couple of times in person and he confirmed it, he just for some reason thinks it takes more effort than it really does? He literally told me it's a complex feature that takes time to test and implement on multiple platforms, but for some reason application_surface and other changes are implemented abruptly and brutally, idk, don't ask me because I am not him.
Documentation is available on the Wiki.
http://enigma-dev.org/docs/Wiki/Texture_Functions
The functions work the same for all graphics systems and utilizing mipmapping on high resolution textures should improve your games performance dramatically, for instance my terrain demo goes from 100fps to around 500 as you can see in the screenshot.
The updated version that is watered down for the sake of showing off mipmapping is available for download.
Download: https://www.dropbox.com/s/ls34n8lrb81bbi5/texturefiltering.zip
Size: 1.22mb's
Documentation is available on the Wiki.
http://enigma-dev.org/docs/Wiki/Texture_Functions
The functions work the same for all graphics systems and utilizing mipmapping on high resolution textures should improve your games performance dramatically, for instance my terrain demo goes from 100fps to around 500 as you can see in the screenshot.
The updated version that is watered down for the sake of showing off mipmapping is available for download.
Download: https://www.dropbox.com/s/ls34n8lrb81bbi5/texturefiltering.zip
Size: 1.22mb's
65
Developing ENIGMA / Font Pixel Alignment
« on: July 31, 2014, 09:27:02 pm »
Ok so I need to describe a fault in our text drawing functions in detail. Some of you may have noticed the interpolation distorts your fonts, but not in the way you would expect. Examine the following.
Note: It really helps to open these images in Paint or another program with no filtering and zoom down to examine the pixels.
In this first image we see what happens when we draw the text at full integer coordinates with interpolation enabled. Notice interpolation does not effect most of the characters and most have crisp edges, as if interpolation is not even enabled.
In this second image we see what happens when we draw the text at half integer coordinates with interpolation. Notice interpolation is mostly working on most of the characters but a few have crisp edges.
Note: This is the behavior observed in Direct3D9 as well, except the behavior appears to be reversed appearing interpolated with full integer coordinates and not with half integer coordinates.
This is not something which can be fixed purely by disabling interpolation or padding the font textures though they still need to be anyway. This could have also been the cause of other font anomalies for some of you at an earlier time. I have also confirmed this issue to be the result of characters rendering at different locations between OGL and D3D if we round and draw at full integer coordinates the characters appear at the exact same location in all graphics systems. The problem exists in our text rendering functions, they either all need to be at full integer coordinates or all at half. Generally they should always be at half integer coordinates with vector graphics, like half pixel alignment in Inkscape.
However, when scrolling backgrounds or text it helps to allow them to transition between half and full pixel integer coordinates to make them blend smoothly. My proposal is simple, we merely need to align all the characters of a draw_text call to either full or half integer coordinates and no in-between, this is something we can all mutually agree on. Now me and Josh disagree however about when extra spacing should be applied, Josh believes it should be every 3rd or 4th character where as I believe the excess spacing should be applied immediately after it reaches a whole number.
It basically has to do with how we handle xx as you can examine on the following line.
https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Graphics_Systems/General/GSfont.cpp#L374
With the following modification to the drawn text function, the text and all characters are drawn at full integer coordinates and properly and evenly spaced between all graphics systems at the exact same coordinates with or without interpolation enabled.
These are the results with the above changes. The following is drawn starting at full pixel passed to the draw text function and interpolation enabled, this is actually what it should look like with interpolation enabled when the font texture is not padded.
The following is drawn starting at half pixels passed to the draw text function with interpolation enabled, this is how GM avoids interpolation on font textures, it always draws at full integer coordinates like most game engines.
Now as I said GM and most game engines always render fonts at full integer coordinates, but this can cause them to be blocky when you want scrolling text, it makes the transition much more abrupt, you want this blurring that is caused by half integer coordinates when drawing 2D objects, sprites, backgrounds, and text. Therefore, I believe I will temporarily prepare a pull request to be merged immediately that draws our text at full integer coordinates like everyone else until we can come up with an alternative or decide on a solution.
It would help if everyone including Josh could weigh in and offer their opinions.
Note: It really helps to open these images in Paint or another program with no filtering and zoom down to examine the pixels.
In this first image we see what happens when we draw the text at full integer coordinates with interpolation enabled. Notice interpolation does not effect most of the characters and most have crisp edges, as if interpolation is not even enabled.
In this second image we see what happens when we draw the text at half integer coordinates with interpolation. Notice interpolation is mostly working on most of the characters but a few have crisp edges.
Note: This is the behavior observed in Direct3D9 as well, except the behavior appears to be reversed appearing interpolated with full integer coordinates and not with half integer coordinates.
This is not something which can be fixed purely by disabling interpolation or padding the font textures though they still need to be anyway. This could have also been the cause of other font anomalies for some of you at an earlier time. I have also confirmed this issue to be the result of characters rendering at different locations between OGL and D3D if we round and draw at full integer coordinates the characters appear at the exact same location in all graphics systems. The problem exists in our text rendering functions, they either all need to be at full integer coordinates or all at half. Generally they should always be at half integer coordinates with vector graphics, like half pixel alignment in Inkscape.
However, when scrolling backgrounds or text it helps to allow them to transition between half and full pixel integer coordinates to make them blend smoothly. My proposal is simple, we merely need to align all the characters of a draw_text call to either full or half integer coordinates and no in-between, this is something we can all mutually agree on. Now me and Josh disagree however about when extra spacing should be applied, Josh believes it should be every 3rd or 4th character where as I believe the excess spacing should be applied immediately after it reaches a whole number.
It basically has to do with how we handle xx as you can examine on the following line.
https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Graphics_Systems/General/GSfont.cpp#L374
With the following modification to the drawn text function, the text and all characters are drawn at full integer coordinates and properly and evenly spaced between all graphics systems at the exact same coordinates with or without interpolation enabled.
Code: (cpp) [Select]
unsigned xxx = xx;
draw_vertex_texture(x + xxx + g->x, yy + g->y, g->tx, g->ty);
draw_vertex_texture(x + xxx + g->x2, yy + g->y, g->tx2, g->ty);
draw_vertex_texture(x + xxx + g->x, yy + g->y2, g->tx, g->ty2);
draw_vertex_texture(x + xxx + g->x2, yy + g->y2, g->tx2, g->ty2);
draw_primitive_end();
These are the results with the above changes. The following is drawn starting at full pixel passed to the draw text function and interpolation enabled, this is actually what it should look like with interpolation enabled when the font texture is not padded.
The following is drawn starting at half pixels passed to the draw text function with interpolation enabled, this is how GM avoids interpolation on font textures, it always draws at full integer coordinates like most game engines.
Now as I said GM and most game engines always render fonts at full integer coordinates, but this can cause them to be blocky when you want scrolling text, it makes the transition much more abrupt, you want this blurring that is caused by half integer coordinates when drawing 2D objects, sprites, backgrounds, and text. Therefore, I believe I will temporarily prepare a pull request to be merged immediately that draws our text at full integer coordinates like everyone else until we can come up with an alternative or decide on a solution.
It would help if everyone including Josh could weigh in and offer their opinions.
66
Off-Topic / MacOS Counter-intuitive?
« on: July 30, 2014, 12:09:12 am »
Is Macintosh the most counter-intuitive operating system in the world? Let's examine the evidence.
67
General ENIGMA / Indentation Styles
« on: July 20, 2014, 03:07:56 pm »
Well I recently provoked IsmAvatar on GitHub about two spaced indentations in which she raised some interesting counter arguments.
https://github.com/IsmAvatar/LateralGM/pull/128
I also recently updated the coding techniques article to address this.
http://enigma-dev.org/docs/Wiki/Coding_conventions
Anybody with a GitHub account respond there, otherwise respond here.
https://github.com/IsmAvatar/LateralGM/pull/128
I also recently updated the coding techniques article to address this.
http://enigma-dev.org/docs/Wiki/Coding_conventions
Anybody with a GitHub account respond there, otherwise respond here.
68
General ENIGMA / Sampler States and Texture Handling Poll
« on: July 16, 2014, 12:15:26 am »
Please read the earlier topic for more discussion.
http://enigma-dev.org/forums/index.php?topic=2091.0
After some more digging, I found most of my initial assumptions are correct. Allow me to quote some various sources.
http://www.virtualdub.org/blog/pivot/entry.php?id=180
http://forum.unity3d.com/threads/setting-sampler-state.21442/
http://docs.unity3d.com/Manual/ComputeShaders.html
This goes back to my main premise, OpenGL did not properly abstract texture resources for being the low-level graphics API it claims to be. Now I am mostly in favor of going with a mix that allows you to create sampler objects in your own custom shaders and by default having texture information per-texture, but this is compatibility breaking. This means you would have to code each texture you want repetition for and each one you want to set the filtering of, unless you use a custom shader.
The choice is ultimately up to everyone else, as I really can't make up my mind on the issue, but I would like to see a sample of everyone's opinions.
http://enigma-dev.org/forums/index.php?topic=2091.0
After some more digging, I found most of my initial assumptions are correct. Allow me to quote some various sources.
http://www.virtualdub.org/blog/pivot/entry.php?id=180
Quote from: DirectX vs. OpenGL
On the flip side, one of the more annoying aspects of OpenGL I've found is the tying of sampler parameters — filtering, addressing, mip map LOD bias, etc. — to textures. For a software renderer that modifies texture data for these changes, this makes sense, but it doesn't make sense for modern hardware where these are usually sampler states. It can also make sense if you consider them intrinsic to the texture, but that then breaks down if you want to do something beyond what the hardware can support. A high quality image processor really needs to support higher quality filtering than bilinear; bilinear filtering gives a really crappy gradient map. To do this, you have to emulate the higher-order filtering using lower-order filtering, and you run into the problem that if you ever need the same texture bound with different parameters in the same pass, you're screwed, because you only have one set of parameters on the texture. I do this when rendering bicubic in VirtualDub's D3D9 driver, and I can't port it to OpenGL because it's impossible to do so. I looked at the source for various OpenGL binding layers, and they all seem to emulate sampler states by pushing them into texture parameters. This sucks.
http://forum.unity3d.com/threads/setting-sampler-state.21442/
Quote from: Unity3D ShaderLab Threads
If you want to use the same texture with different filtering modes, and can't have some script executed in between, then yes, it does get tricky.The gentlemen in that post gave slightly misleading advice, OpenGL does in fact allow you to create sampler objects, but they are an extension and not officially core until 3.3
There's no separate sampler state in OpenGL (filtering and other modes are set onto a texture), so exposing it in D3D style is not easy.
http://docs.unity3d.com/Manual/ComputeShaders.html
Quote from: Unity3D Manual
Texture samplers in compute shaders
Textures and samplers aren’t separate objects in Unity, so in order to use them in compute shader you have to follow some Unity specific rules:
Either use same as texture name, with “sampler” in front (e.g. Texture2D MyTex; SamplerState samplerMyTex). In this case, sampler will be initialized to that texture’s filter/wrap/aniso settings.
Or use one of “predefined” samplers; name has to have “Linear” or “Point” (for filter mode) and “Clamp” or “Repeat” (for wrap mode). For example, "SamplerState MyLinearClampSampler" - this will have linear filter and clamp wrap mode.
This goes back to my main premise, OpenGL did not properly abstract texture resources for being the low-level graphics API it claims to be. Now I am mostly in favor of going with a mix that allows you to create sampler objects in your own custom shaders and by default having texture information per-texture, but this is compatibility breaking. This means you would have to code each texture you want repetition for and each one you want to set the filtering of, unless you use a custom shader.
The choice is ultimately up to everyone else, as I really can't make up my mind on the issue, but I would like to see a sample of everyone's opinions.
69
Developing ENIGMA / Texture Handling
« on: July 07, 2014, 02:23:06 am »
Well this is something that needed discussed a long time ago. OpenGL stores sampling information per texture without the use of the OGL3 sampler object extension approved by the ARB for that core version. Direct3D has done it with sampler objects and properly abstracted the concept since the beginning of time.
Now, with YoYoGames essentially building a cross-platform DirectX emulator ("ANGEL dust") they are basically sticking to sampler states. In fact, I don't really know who I hate more them or the ARB. Don't get me wrong I love a lot of things about Direct3D, but Microsoft is purposefully responsible for fucking up a lot of OGL, but this this fuck up rests on the ARB's shoulders.
Anyway, because of this, OpenGL1 needs a sampler state emulator object which I've already written and works fine, however Project Mario takes a 10fps hit. OpenGL3 needs further integration with its shaders and the extension sampler objects, which I've already programmed and I can not find my way through Harri's shaders to integrate. Direct3D9 is fine, in fact it and OpenGL1 have working texture filtering.
Based on these two functions my assumption is that YYG is going to make all of the texture stuff based on samplers unlike Unity3D which stores texture repetition information, filtering, and what not per-texture.
http://docs.yoyogames.com/source/dadiospice/002_reference/drawing/texture_set_interpolation_ext.html
http://docs.yoyogames.com/source/dadiospice/002_reference/drawing/texture_set_repeat_ext.html
They may also change their minds once they begin implementing proper mipmapping and things which they have indicated interest in doing.
http://gmc.yoyogames.com/index.php?showtopic=608392
At any rate, if they don't change which I don't believe they will I have begun coding everything this way. These are the proposed texture functions, however they are not all documented yet I haven't had time as I've been focusing on the coding.
http://enigma-dev.org/docs/Wiki/Texture_Functions
My suggestion is that my current pull request be merged into the OpenGL3 branch until Harri or myself has time to complete the OpenGL3 sampler object integration.
https://github.com/enigma-dev/enigma-dev/pull/770
A tutorial for the OpenGL3 sampler objects is available below.
http://www.sinanc.org/blog/?p=215
Now, with YoYoGames essentially building a cross-platform DirectX emulator ("ANGEL dust") they are basically sticking to sampler states. In fact, I don't really know who I hate more them or the ARB. Don't get me wrong I love a lot of things about Direct3D, but Microsoft is purposefully responsible for fucking up a lot of OGL, but this this fuck up rests on the ARB's shoulders.
Anyway, because of this, OpenGL1 needs a sampler state emulator object which I've already written and works fine, however Project Mario takes a 10fps hit. OpenGL3 needs further integration with its shaders and the extension sampler objects, which I've already programmed and I can not find my way through Harri's shaders to integrate. Direct3D9 is fine, in fact it and OpenGL1 have working texture filtering.
Based on these two functions my assumption is that YYG is going to make all of the texture stuff based on samplers unlike Unity3D which stores texture repetition information, filtering, and what not per-texture.
http://docs.yoyogames.com/source/dadiospice/002_reference/drawing/texture_set_interpolation_ext.html
http://docs.yoyogames.com/source/dadiospice/002_reference/drawing/texture_set_repeat_ext.html
They may also change their minds once they begin implementing proper mipmapping and things which they have indicated interest in doing.
http://gmc.yoyogames.com/index.php?showtopic=608392
At any rate, if they don't change which I don't believe they will I have begun coding everything this way. These are the proposed texture functions, however they are not all documented yet I haven't had time as I've been focusing on the coding.
http://enigma-dev.org/docs/Wiki/Texture_Functions
My suggestion is that my current pull request be merged into the OpenGL3 branch until Harri or myself has time to complete the OpenGL3 sampler object integration.
https://github.com/enigma-dev/enigma-dev/pull/770
A tutorial for the OpenGL3 sampler objects is available below.
http://www.sinanc.org/blog/?p=215
70
Developing ENIGMA / Command Line Interface
« on: June 20, 2014, 03:00:37 pm »
So I decided to do some testing and get the command line interface I started working and building an empty game. The program I have dubbed "emake" boots in less than 3 seconds initializing the library and all, and can compile and run an empty game in about the same amount of time. It is significantly faster than loading the IDE and building an empty game from there.
This has a lot of implications, you can build games without an IDE, you can build games much quicker, especially extremely large games like TKG makes. This also means we could significantly improve the performance of LGM working with large projects. This would be done by only loading the resource tree at startup, and loading and unloading resources or as you edit them or we could also just cache them.
This would allow someone like TKG to load a 100mb game much quicker, probably about 5-10 seconds, and build the game much quicker. The way we would accomplish building the game without loading it is by simply passing the file path of the project to the CLI and telling it to build the project.
A lot of these ideas are already utilized by Studio and it has many of the same restrictions that follow which are actually the same for most other IDE's. But we have some issues:
1) LGM does not have a guaranteed format, it lets you save and load from all formats.
2) This would require that you create the project directory when you want to make a new game, like in Studio, you couldn't get away with adding resources and saving later because the IDE has to have it on disk.
3) GMK is damn near impossible to optimize as a result of it being one giant ass file, you can't easily skip through parts of it and write a single resource.
4) You probably would not be able to build without saving your changes. I believe Studio has this same restriction.
Some possible solutions are the following:
1) Treat formats like GMK as an import/export where you can import a GMK but it will automatically be converted to GMX or EGM whichever format you choose.
Here are some benefits:
1) Faster loading times
2) Faster compile times
3) Less out of memory errors
4) Can build projects without an IDE
5) Makes it much easier for 3rd parties to write IDE's and other interfaces for the program
So the question is, does the cost outweigh the benefit? I am fairly certain most of you would say yes, but feel free to express your ideas on the matter.
*** Update ***
See latest forum post, the CLI now builds projects.
This has a lot of implications, you can build games without an IDE, you can build games much quicker, especially extremely large games like TKG makes. This also means we could significantly improve the performance of LGM working with large projects. This would be done by only loading the resource tree at startup, and loading and unloading resources or as you edit them or we could also just cache them.
This would allow someone like TKG to load a 100mb game much quicker, probably about 5-10 seconds, and build the game much quicker. The way we would accomplish building the game without loading it is by simply passing the file path of the project to the CLI and telling it to build the project.
A lot of these ideas are already utilized by Studio and it has many of the same restrictions that follow which are actually the same for most other IDE's. But we have some issues:
1) LGM does not have a guaranteed format, it lets you save and load from all formats.
2) This would require that you create the project directory when you want to make a new game, like in Studio, you couldn't get away with adding resources and saving later because the IDE has to have it on disk.
3) GMK is damn near impossible to optimize as a result of it being one giant ass file, you can't easily skip through parts of it and write a single resource.
4) You probably would not be able to build without saving your changes. I believe Studio has this same restriction.
Some possible solutions are the following:
1) Treat formats like GMK as an import/export where you can import a GMK but it will automatically be converted to GMX or EGM whichever format you choose.
Here are some benefits:
1) Faster loading times
2) Faster compile times
3) Less out of memory errors
4) Can build projects without an IDE
5) Makes it much easier for 3rd parties to write IDE's and other interfaces for the program
So the question is, does the cost outweigh the benefit? I am fairly certain most of you would say yes, but feel free to express your ideas on the matter.
*** Update ***
See latest forum post, the CLI now builds projects.
71
General ENIGMA / Indie DB and others
« on: June 18, 2014, 11:26:15 am »
This is just a heads up to everyone, ENIGMA has now been accepted on Indie DB so if any of you make any games with ENIGMA and want to upload them there be sure to set our engine, "ENIGMA Development Environment"
http://www.indiedb.com/engines/enigma-development-environment
Feel free to add games, tutorials, reviews or whatever you like to our page. Also feel welcome to offer constructive criticism but please keep it appropriate.
I hope that this may create a broader awareness of our engine and potentially attract more developers.
http://www.indiedb.com/engines/enigma-development-environment
Feel free to add games, tutorials, reviews or whatever you like to our page. Also feel welcome to offer constructive criticism but please keep it appropriate.
I hope that this may create a broader awareness of our engine and potentially attract more developers.
72
Announcements / Timelines Implemented
« on: June 04, 2014, 01:31:52 am »
That's right, timelines have been implemented by Seth N. Hetu (sorlok) in his quest to port Iji.
This was his pull request.
https://github.com/enigma-dev/enigma-dev/pull/738
This was the discussion topic about the implementation.
https://github.com/enigma-dev/enigma-dev/issues/636
You can get these changes via git or by downloading the new Portable ZIP.
http://enigma-dev.org/docs/Wiki/Install:Windows
Please test his changes and see how well everything works. And be sure to give him a round of applause for his contributions!
This was his pull request.
https://github.com/enigma-dev/enigma-dev/pull/738
This was the discussion topic about the implementation.
https://github.com/enigma-dev/enigma-dev/issues/636
You can get these changes via git or by downloading the new Portable ZIP.
http://enigma-dev.org/docs/Wiki/Install:Windows
Please test his changes and see how well everything works. And be sure to give him a round of applause for his contributions!
73
General ENIGMA / New Beginnings
« on: May 31, 2014, 10:13:52 am »
Ok, there has been a lot of discussion of creating a fork of ENIGMA which actually fixes some things in GM. I am beginning to seriously consider this now.
The purpose of the fork is not to remain compatible with any other program, and takes the GM approach in a fundamentally different direction allowing for greater optimization and an intuitive redesign.
Some of the features and differences would be as follow:
* Windowing system would be completely abstract allowing the creation of multiple windows.
* No fake fullscreen, aspect ratio handled natively by the display.
* No view options in room editor and no global constants, views can be controlled via screen_set_viewport functions, because there is an efficient trick to speed up games by allowing two views to be rendered in the same draw call.
* Revamped non-retarded implementation of the audio_* functions.
* Complete redesign of graphics allowing not only vertex buffers but index buffers and instance geometry, with a proper bridge of OGL and D3D and not just a tacky way of emulating D3D by use of an OGL backend like ANGLE.
* Branching path system with improved A* motion planning.
* Cross-platform video interface for hardware accelerated video playback and rendering.
* All resources handled as included files, each will have a "preload" option and if it is unticked you have to load in manually using _load* functions asumming that all resources are extracted locally to the executable, but you will still be able to control how the resources are extracted, kind of like in Visual Studio
* Completely unrestricted file hierarchy, the IDE will also support loading multiple projects at once, and will support only one file format.
* Because the IDE will use a single uncompressed file format, the IDE will also be much quicker with loading and saving and compiling projects.
* CLI programs will exist for building projects outside of the IDE
* Non-object oriented method of compiling and linking code into your game.
* Possibly, strict C++, meaning no GML or EDL and no hybrid language, pure C++, variant type would remain most likely however, only differences would be more strict syntax, which ENIGMA kind of already has anyway.
* File reading/writing revamp, will support the ability to work with multiple INI files at once.
* Script redesign, they will be actual source files, if you want them to act like functions in GM you will have to prototype the function, not sure what to do about forward declarations.
* As a result of the script redesign, there will exist an object resource, but the object structure will be redesigned to allow you to easily and simply code an object using a script, so for instance if an object has a sprite it will inherit an object_sprite class, if it has a model it will inherit an object_model, if it has physics it will inherit object_physics, or a combination of these entities. An event listener and stack may be created similar to Java, C#, or Qt Also important to mention the object resource will not be removed, it will remain allowing a more graphical approach to create an object.
* Possible drag and drop redesign that will follow a more schematic approach like you often see with material/shader editors.
* Certain aspects may follow a more entity component style system, for instance, since views will be removed, you will be able to place camera/projection entities in the room to accommodate, which will also allow you to control aspects such as fog. Unsure of how to handle instance translations and properties however, as it will be dependent upon what entities their prototype class inherits.
* Full threading support, atomic and immutable types etc.
This project will basically allow us to address things immediately by doing them our own way, discussion of feature and implementations will not revolve around compatibility vs. incompatibility. These are simply ideas floating in the air, but I am seriously consider turning this into a practical implementation. I am just sick of working on something that I can't improve or innovate with. Suggestions and feedback is welcome. The project also has no name yet and is simply a proposal.
NOTE: This project would be licensed the same as ENIGMA once licensing for ENIGMA is established.
Just to put some names into the hat or some keywords to work with for a name:
Perform - not an acronym, pretty simplistic
Fluid or FLUID - possibly an acronym, meant to be intuitive, has no relation to F.L.U.D.D.
Formulate - key term, relates to variables/formulas/equations/functions
The purpose of the fork is not to remain compatible with any other program, and takes the GM approach in a fundamentally different direction allowing for greater optimization and an intuitive redesign.
Some of the features and differences would be as follow:
* Windowing system would be completely abstract allowing the creation of multiple windows.
* No fake fullscreen, aspect ratio handled natively by the display.
* No view options in room editor and no global constants, views can be controlled via screen_set_viewport functions, because there is an efficient trick to speed up games by allowing two views to be rendered in the same draw call.
* Revamped non-retarded implementation of the audio_* functions.
* Complete redesign of graphics allowing not only vertex buffers but index buffers and instance geometry, with a proper bridge of OGL and D3D and not just a tacky way of emulating D3D by use of an OGL backend like ANGLE.
* Branching path system with improved A* motion planning.
* Cross-platform video interface for hardware accelerated video playback and rendering.
* All resources handled as included files, each will have a "preload" option and if it is unticked you have to load in manually using _load* functions asumming that all resources are extracted locally to the executable, but you will still be able to control how the resources are extracted, kind of like in Visual Studio
* Completely unrestricted file hierarchy, the IDE will also support loading multiple projects at once, and will support only one file format.
* Because the IDE will use a single uncompressed file format, the IDE will also be much quicker with loading and saving and compiling projects.
* CLI programs will exist for building projects outside of the IDE
* Non-object oriented method of compiling and linking code into your game.
* Possibly, strict C++, meaning no GML or EDL and no hybrid language, pure C++, variant type would remain most likely however, only differences would be more strict syntax, which ENIGMA kind of already has anyway.
* File reading/writing revamp, will support the ability to work with multiple INI files at once.
* Script redesign, they will be actual source files, if you want them to act like functions in GM you will have to prototype the function, not sure what to do about forward declarations.
* As a result of the script redesign, there will exist an object resource, but the object structure will be redesigned to allow you to easily and simply code an object using a script, so for instance if an object has a sprite it will inherit an object_sprite class, if it has a model it will inherit an object_model, if it has physics it will inherit object_physics, or a combination of these entities. An event listener and stack may be created similar to Java, C#, or Qt Also important to mention the object resource will not be removed, it will remain allowing a more graphical approach to create an object.
* Possible drag and drop redesign that will follow a more schematic approach like you often see with material/shader editors.
* Certain aspects may follow a more entity component style system, for instance, since views will be removed, you will be able to place camera/projection entities in the room to accommodate, which will also allow you to control aspects such as fog. Unsure of how to handle instance translations and properties however, as it will be dependent upon what entities their prototype class inherits.
* Full threading support, atomic and immutable types etc.
This project will basically allow us to address things immediately by doing them our own way, discussion of feature and implementations will not revolve around compatibility vs. incompatibility. These are simply ideas floating in the air, but I am seriously consider turning this into a practical implementation. I am just sick of working on something that I can't improve or innovate with. Suggestions and feedback is welcome. The project also has no name yet and is simply a proposal.
NOTE: This project would be licensed the same as ENIGMA once licensing for ENIGMA is established.
Just to put some names into the hat or some keywords to work with for a name:
Perform - not an acronym, pretty simplistic
Fluid or FLUID - possibly an acronym, meant to be intuitive, has no relation to F.L.U.D.D.
Formulate - key term, relates to variables/formulas/equations/functions
74
Developing ENIGMA / Win32 Nested Window
« on: May 25, 2014, 12:51:47 am »
Well, I didn't realize until recently we are creating two windows on Win32, one is the child window for graphics and the top one is the parent. Our whole system is programmed around this currently by utilizing it to maintain the aspect ratio of the window since we use somewhat fake fullscreen behavior. This does however have its costs, 1 we can't use this solution for XLIB and Cocoa, 2 Win32 is buggy as hell on its own let alone trying to use a parented window device.
A simple solution that I already tested and got working was to remove it completely and handle window adaptation in the screen viewport function. glScissor was needed to stop the window color from becoming the room background color, so you would get black bars, but it did not work in fullscreen, Direct3D did not require any extra functionality because its viewports already treat them as bounds, but like OpenGL it also did not work in fullscreen.
At any rate, the only cross-platform solution is to emulate window adaption for our fake fullscreen behavior in the graphics systems/viewports. I want to know what everyone's opinion on this is.
A simple solution that I already tested and got working was to remove it completely and handle window adaptation in the screen viewport function. glScissor was needed to stop the window color from becoming the room background color, so you would get black bars, but it did not work in fullscreen, Direct3D did not require any extra functionality because its viewports already treat them as bounds, but like OpenGL it also did not work in fullscreen.
At any rate, the only cross-platform solution is to emulate window adaption for our fake fullscreen behavior in the graphics systems/viewports. I want to know what everyone's opinion on this is.
75
Developing ENIGMA / Font Fractional Metrics
« on: May 19, 2014, 06:43:23 pm »
Well, after rigorous testing I have learned a lot of things about half-pixel alignment between Direct3D and OpenGL.
* You can not half-pixel align in the view or the bottom and right edges will be empty on the screen, or do similar for surfaces.
* You must add not subtract the pixel alignment in the projection function, if you subtract you'll get a similar issue to views.
* 0.25 appears to work the best in all cases, 0.5 may be driver/graphics card dependent
* OpenGL can not do a full half-pixel alignment (0.5) or games with repeating/scrolling backgrounds will skip and have a 1px gap sometimes between them.
* OpenGL and Direct3D pixel align differently, for instance, 0.25 is used in both systems, but when rendering text, you'll notice OpenGL has a space between lowercase 'r' and 't' whereas Direct3D does not, and Direct3D has a space between uppercase 'T' and 'Y' where OpenGL does not. One solution to this is to round up the glyph sizes in the font struct initialization.
NOTE: I used GM8 not 8.1, regardless of what the caption says, which did not have anti-aliasing options and by default used interpolation to render the font. And in ENIGMA I had the anti-aliasing disabled.
You can see GM8.0 renders the same as our Direct3D 9 system except it has interpolation because there were no aliasing options and it is turned off in ENIGMA. I used this code to test.
However, we still have the issue of the last bullet there. Because of font characters having fractional dimensions, they can still very easily become malaligned. The only solution I have thought of is to round up their dimensions, or else we need to find a way to truly fix half-pixel alignment.
Upon investigating the plugin I discovered that IsmAvatar has disabed fractional font metrics, which means subpixel accuracy. Or in other words the metrics should already be integer spaced.
http://docs.oracle.com/javase/7/docs/api/java/awt/RenderingHints.html#KEY_FRACTIONALMETRICS
https://github.com/enigma-dev/lgmplugin/blob/master/org/enigma/EnigmaWriter.java#L687
* You can not half-pixel align in the view or the bottom and right edges will be empty on the screen, or do similar for surfaces.
* You must add not subtract the pixel alignment in the projection function, if you subtract you'll get a similar issue to views.
* 0.25 appears to work the best in all cases, 0.5 may be driver/graphics card dependent
* OpenGL can not do a full half-pixel alignment (0.5) or games with repeating/scrolling backgrounds will skip and have a 1px gap sometimes between them.
* OpenGL and Direct3D pixel align differently, for instance, 0.25 is used in both systems, but when rendering text, you'll notice OpenGL has a space between lowercase 'r' and 't' whereas Direct3D does not, and Direct3D has a space between uppercase 'T' and 'Y' where OpenGL does not. One solution to this is to round up the glyph sizes in the font struct initialization.
NOTE: I used GM8 not 8.1, regardless of what the caption says, which did not have anti-aliasing options and by default used interpolation to render the font. And in ENIGMA I had the anti-aliasing disabled.
You can see GM8.0 renders the same as our Direct3D 9 system except it has interpolation because there were no aliasing options and it is turned off in ENIGMA. I used this code to test.
Code: (EDL) [Select]
draw_set_font(font0);
draw_set_color(c_black);
draw_text(0,0,"01234567890!@#$%^&*()_+-={}[]:;|\?/>.<,
QWERTYUIOPASDFGHJKLZXCVBNM
qwertyuiopasdfghjklzxcvbnm");
However, we still have the issue of the last bullet there. Because of font characters having fractional dimensions, they can still very easily become malaligned. The only solution I have thought of is to round up their dimensions, or else we need to find a way to truly fix half-pixel alignment.
Upon investigating the plugin I discovered that IsmAvatar has disabed fractional font metrics, which means subpixel accuracy. Or in other words the metrics should already be integer spaced.
http://docs.oracle.com/javase/7/docs/api/java/awt/RenderingHints.html#KEY_FRACTIONALMETRICS
https://github.com/enigma-dev/lgmplugin/blob/master/org/enigma/EnigmaWriter.java#L687