Show Posts

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.

Messages - Goombert

Developing ENIGMA / Re: Make Directory
« on: January 28, 2014, 02:27:13 AM »
sorlok, give me a minute to make the pull request, and no I just changed the Linux default because I felt the . and lowercase was extraneous and didn't match Windows, but it doesn't matter I'll just commit the version that works, minor aesthetic really compared to the real importance of what we want to implement which is choosing where each project gets outputted too and eliminating the need for temp files, and handling like any other program eg. Visual Studio handles outputting exe's.

Edit: Here is the pull request.

And for future reference, this is the repository where I maintain the MD5 hashes.

Let me know if there are any other issues that stem from this change, there should not be any I have tested this very extensively.

Developing ENIGMA / Re: Make Directory
« on: January 28, 2014, 12:58:13 AM »
See my comments on GitHub.

Also please try manually patching the enigma.jar from the extra packages page.

Developing ENIGMA / Re: Make Directory
« on: January 27, 2014, 11:37:29 PM »
Yes you are it checks the md5 hashes, which I updated earlier.

Developing ENIGMA / Make Directory
« on: January 27, 2014, 06:24:12 PM »

I recently started making some changes to update YAML settings, you can read about that in the following topic.

Along the way I made several bugfixes to the plugin, and also made the ability to set the make directory per-project. This way each game can have a /build/ folder next to its project file, kind of like you see in Visual Studio or Qt Creator where you are asked where you want binaries outputted to. This however holds two problems, 1 the compiler should output its binaries to one single directory, and then link them from wherever your game/preprocessor is written to, the theoretical "build" folder. This does however mean we could do away with use of temporary files, and write the executable directly inside the build folder, and this would stop the creation of many many temporary files that need cleaned up.

This was the ENIGMA commit.
This was the plugin commit with other fixes, including escaping the ENIGMA Settings YAML since it holds the spec header and is subject to it.

This means you will all need to update the plugin next time you update from the repository.
The portable ZIP has not been updated yet.

Developing ENIGMA / Re: YAML Settings Update
« on: January 26, 2014, 10:57:28 PM »
Are you thinking of extensions perhaps? Actually, come to think of it, I should do it for extensions too, because some extensions like XInput and MCI could be defaulted on for Windows as well.

I have now implemented the ability for extensions to only be turned on by default for specific platforms.
Code: (YAML) [Select]

: XInput
: XInput
: Input support including gamepads on Windows and Xbox 360.
: true
: false
: 8/8/2013
: xinputlogo.png

: None
: None
: extension_xinput

This was the commit.

This now allows certain extensions that are required for things like the CD actions to be enabled by default correctly on each platform, allowing the platform specific implementation to remain without the end-user having to ever give a shit or think twice about it.

Developing ENIGMA / YAML Settings Update
« on: January 26, 2014, 10:14:13 PM »
While implementing a new ENIGMA setting I also added the ability to set platform specific defaults to the compiler settings frame. It works as Default-TargetOS where TargetOS is the name of the operating system returned by TargetHandler.GetOS(), an example follows for the Make Directory setting.

If the platform specific default is not found, the generic default is used.
Code: (YAML) [Select]
-Build Options:
: Grid
: 2
: Textfield
: Make Directory
: "./ENIGMA"
: "./ENIGMA"
: Checkbox
: Object Inheritance
: true

I implemented this to the plugin in the following commit.
The settings were implemented to ENIGMA's repo in the following pull request.

When this is merged to the repository I will immediately upload a new version of the Plugin and LateralGM as well as the Portable ZIP that you will need to download the next time you update from the repository.

Issues Help Desk / Re: There was an issue loading the project
« on: January 26, 2014, 07:08:09 PM »
Either that or the project could be corrupted in another way, I'll take a look again in the morning egofree, I am tired at the moment from diagnosing the ICO format issue.

The resources reappearing was an issue in LateralGM when I implemented the recursive deletion I did not have it recursively iterate children of group nodes.
Please update LateralGM and the plugin and you'll be able to delete multiple resources at once properly.

I have also updated the Windows Portable ZIP.

You are good at finding bugs egofree, but hey at least were getting them fixed. Now back to figuring out why it won't compile.

No problem, glad I could be of assistance.

On Windows Vista or later the generated C++ is in C:/ProgramData/ENIGMA/Preprocessor_Environment_Editable

Graphics and Video / issues
« on: January 26, 2014, 03:50:27 AM »
Thanks to sorlok this is resolved and is included in LGM 1.8.6

You can now use converticon icons.


I just want to write this post up explaining why should not be used to convert large icons and images to and from the ICO format.

Upon discovering TKG's icon woes in the following topic, I discovered that the website does not adhere to the ICO file specification.
The ICO file specification states that the 7th byte will be the width of the image when the format is BMP, if the format is PNG the next part is simply the PNG header.

When I investigated I found out that every ICO file with a size layer larger than 192x192 exported from will be essentially broken.

The following is a screenshot of me viewing a 192x192 ICO file from which does match the ICO specification and the width is reported correctly.

The following is a screenshot of me viewing a 512x512 ICO file from which does NOT match the ICO specification and the width is reported as 0.

The following shows what a 256x256 ICO file using PNG looks like. The 7th byte is 0 but that is because that portion starts the PNG header. This header clearly does not match the corrupted version. So that rules out the possibility that LGM couldn't load as a result of the icon using the PNG format, because LGM loads this one fine.

I do not care if Windows and Studio can work with these corrupted ICO files or not. LateralGM will not support them, because they do not follow the specification and there is no way to tell exactly how to read them. Please do not use this site to convert large icon files, there are standards in computing for a reason.

For proof that LGM loads 512x512 ICO files when they are in the correct format, try to use the following icon and it should work fine.

A good image editing software is Paint.NET it is freeware and has a lot of plugins.
There is also GIMP.
Both of these tools can be used to export ICO files properly.

Issues Help Desk / Re: GMX Reader
« on: January 26, 2014, 02:55:09 AM »
To come back to this, I just found a 512x512 ICO file on the internet, which I loaded into a project of mine, and copied and pasted to a GMX project, and both of the projects loaded fine with LGM.

This was the ICO file that worked.

So I went to investigate further the program you used to convert the image, and sure enough it outputs corrupted Icon files when a size layer bigger than 192x192 was exported.
I went there and attempted to convert the following 512x512 PNG of the Death Star to a 512x512 ICO

Then LGM had an exception trying to use it on a project just like the one you are getting, so my advice to you is to find another image converter.

That image converter did not work on ICO files larger than 192x192.
Exception in thread "AWT-EventQueue-0" java.lang.IllegalArgumentException: Width (0) and height (0) cannot be <= 0
   at java.awt.image.DirectColorModel.createCompatibleWritableRaster(Unknown Source)
The reason is because every layer above 192x192 had a size of 0, which most likely means this image converter can't export ICO's at sizes larger than that, I went through and looked at the size of every layer, up to 192^2 was fine.
Something is clearly wrong with that converter, so please, use a different one.

General ENIGMA / Re: ANGLE Project
« on: January 25, 2014, 07:26:35 PM »
Actually, it is much more, this is a full graphics abstraction layer, which means we could remove all of our graphics systems and have all of it just GLES, but it can run in D3D9 and D3D11 mode. So this is exactly why Studio does not allow you to choose your graphics system. I have permission from Josh to implement it, but I am having a bit of trouble building it. This would also mean OpenGL framebuffers would work for people with shitty PC's like polygonz by use of the EGL_ANGLE_direct3d_surface extension.

General ENIGMA / ANGLE Project
« on: January 25, 2014, 06:29:14 PM »
So I recently discovered that Studio is using ANGLE for shaders. More information can be found on Google code.

ANGLE basically lets you use GLSL/GLES shaders in Direct3D. It is used in Google Chrome and Firefox.

As you can see Studio is using it.

Now I was originally spouting nonsense about CG which is even more proprietary than HLSL and just as bad. This may actually be one of the few things YoYoGames did correctly. However it is important to note that this project is BSD licensed and I am not sure if we could make it optional if implemented.

I also discovered that Studio does not mention them in the licenses tab of the launch section like they do Box2D and other things. This either means they made a mistake and are inadvertently or purposefully infringing the copyright, or they have some sort of deal with Google.

However I am still missing something fundamental here I think, because the following page suggests that ANGLE also abstracts vertex/index buffers.
This could explain why Studio does not allow you to choose the graphics system because it only has 1 graphics system, in theory, but I have no evidence.

I have merged Josh's GL3 screen redraw cleanup to OpenGL1 which fixes views stretching issue in the following pull request.

I have also attempted to fix the depth issue but it appears fine.
This draws the rectangle on top.
Code: (EDL) [Select]
draw_healthbar(50, 50, 100, 100,50,c_silver,c_red,c_red,1,true,false);
This draws the healthbar on top.
Code: (EDL) [Select]
draw_healthbar(50, 50, 100, 100,50,c_silver,c_red,c_red,1,true,false);

So upon further investigation, you were drawing the rectangle over top of the healthbar.
Code: (EDL) [Select]
//Draw player2 hud
draw_rectangle(view_wport[0] - 50,0,view_wport[0],view_hport[0],false);  // this is overlapping the healthbar because the healthbar is drawn before this
draw_sprite_ext(s_player,1,view_wport[0] - 25,30,.30,.30,90,c_white,1);

The fixed version is right here, just stick this code in your GUI event.
Code: (EDL) [Select]


//Draw player1 hud
draw_sprite_ext(s_player,0,25,30,.30,.30,90,c_white,1);//spr,index,x,y,xscale,yscale,rot,colorblend,trans 1-0

//draw_healthbar(x1, y1, x2, y2, amount, backcol, mincol, maxcol, direction, showback, showborder)

//Draw player2 hud
draw_rectangle(view_wport[0] - 50,0,view_wport[0],view_hport[0],false);
draw_sprite_ext(s_player,1,view_wport[0] - 25,30,.30,.30,90,c_white,1);

draw_text(view_wport[0] - 65,100,o_player1.hp);
draw_healthbar(view_wport[0] - 75,65,view_wport[0] - 25,75,o_player1.hp,c_silver,c_red,c_red,1,true,false);
And you should get the following picture.

I have also attached the fixed GMK to my post.

Issues Help Desk / Re: There was an issue loading the project
« on: January 25, 2014, 04:41:34 PM »
I just checked the preprocessor environment folder, and indeed the variable is not being declared for the object.
Code: (C++) [Select]
struct OBJ_obj_display_level: object_locals
  // Local variables
  var game_state;
  var rectangle_height;

Josh, this can't be anything LGM related, as this game compiled in just the last few releases, and I haven't changed anything to do with writing objects or any of that.

Testing on a blank project, for some reason, does allow a variable to be named "counter".
Changing the DND actions to a code action with
Code: (EDL) [Select]
rectangle_height = view_hview[0]/2;
counter = 2;

in the create event, does not resolve the problem.