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

1876
Issues Help Desk / Re: There was an issue loading the project
« on: January 28, 2014, 03:27:37 AM »
Alright I just got done implementing some other plugin fixes, I'll investigate and fix this and it will be included in a major plugin/LGM update.

You were correct it was not adding a postponed reference for the room.
Code: (XML) [Select]
        <functionname>action_another_room</functionname>
        <codestring></codestring>
        <whoName>self</whoName>
        <relative>0</relative>
        <isnot>0</isnot>
        <arguments>
          <argument>
            <kind>11</kind>
            <room>title</room>
          </argument>
        </arguments>

The reason was because Room's were missing from the Action Library reading for GMX. I have addressed the issue fully in the following commit.
https://github.com/IsmAvatar/LateralGM/commit/22d6fd2bfc5fd5aff7a6fcaedf06916eb912c03a

I have tested this very well and it appears to have resolved the issue now and both of the actions in both objects load and save with the correct room. Please update both LateralGM and the plugin this time as this will include other bug fixes, you can obtain them from the following page.
http://enigma-dev.org/docs/Wiki/Install:Extra_Packages
When you have patched both jar files you need to run git fetch then git pull to have my new compiler callback implemented.

You can also simply update via re-downloading the Windows Portable ZIP.
http://enigma-dev.org/docs/Wiki/Install:Windows

1877
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.
https://github.com/enigma-dev/enigma-dev/pull/632

And for future reference, this is the repository where I maintain the MD5 hashes.
https://github.com/enigma-dev/ExtraPackages

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.

1878
Developing ENIGMA / Re: Make Directory
« on: January 28, 2014, 12:58:13 AM »
See my comments on GitHub.
https://github.com/enigma-dev/enigma-dev/issues/631

Also please try manually patching the enigma.jar from the extra packages page.
http://enigma-dev.org/docs/Wiki/Install:Extra_Packages

1879
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.

1880
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.
http://enigma-dev.org/forums/index.php?topic=1736.0

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.
https://github.com/enigma-dev/enigma-dev/pull/628
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.
https://github.com/enigma-dev/lgmplugin/commit/d21f29c3867ccbb072cb9b24214edf9291d7ea29

This means you will all need to update the plugin next time you update from the repository.
http://enigma-dev.org/docs/Wiki/Install:Extra_Packages
The portable ZIP has not been updated yet.

1881
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.

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

Name
: XInput
ID
: XInput
Description
: Input support including gamepads on Windows and Xbox 360.
Default-Windows
: true
Default
: false
Build-date
: 8/8/2013
Icon
: xinputlogo.png

Depends
: None
Dependencies
: None
Implement
: extension_xinput

This was the commit.
https://github.com/enigma-dev/lgmplugin/commit/56e826deda0d57200da5a79ccc4167f21cadf3c1

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.

1882
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:
    Layout
: Grid
    Columns
: 2
    -make-directory
:
        Type
: Textfield
        Label
: Make Directory
        Default-Windows
: "%PROGRAMDATA%/ENIGMA/"
        Default-Linux
: "%HOME%/ENIGMA/"
        Default-MacOSX
: "./ENIGMA"
        Default
: "./ENIGMA"
    -inherit-objects
:
        Type
: Checkbox
        Label
: Object Inheritance
        Default
: true

I implemented this to the plugin in the following commit.
https://github.com/enigma-dev/lgmplugin/commit/1f6071e1cf91c70a5c31a115cea60a397ef369f5
The settings were implemented to ENIGMA's repo in the following pull request.
https://github.com/enigma-dev/enigma-dev/pull/628

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.

1883
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.
https://github.com/IsmAvatar/LateralGM/commit/b63cf18a1efdf5607bafbe453a39feba607250fe
Please update LateralGM and the plugin and you'll be able to delete multiple resources at once properly.
http://enigma-dev.org/docs/Wiki/Install:Extra_Packages

I have also updated the Windows Portable ZIP.
http://enigma-dev.org/docs/Wiki/Install:Windows

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.

1884
No problem, glad I could be of assistance.

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

1886
Graphics and Video / converticon.com issues
« on: January 26, 2014, 03:50:27 AM »
Thanks to sorlok this is resolved and is included in LGM 1.8.6
https://github.com/IsmAvatar/LateralGM/pull/146

You can now use converticon icons.

* IGNORE THIS POST IT HAS BEEN FIXED *

I just want to write this post up explaining why converticon.com 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.
http://enigma-dev.org/forums/index.php?topic=1700.msg16563#new
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.
http://en.wikipedia.org/wiki/ICO_%28file_format%29

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

The following is a screenshot of me viewing a 192x192 ICO file from converticon.com 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 converticon.com 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 converticon.com 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.
https://www.dropbox.com/s/4y9ygbm7mqai6fy/DeathStar512.ico

A good image editing software is Paint.NET it is freeware and has a lot of plugins.
http://www.getpaint.net/
There is also GIMP.
http://www.getgimp.com/
Both of these tools can be used to export ICO files properly.

1887
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.
https://www.dropbox.com/s/qc58z4kizehqy9h/512icon.ico

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.
http://converticon.com/
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.
Quote
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.

1888
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.

1889
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.
http://code.google.com/p/angleproject/

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.
http://code.google.com/p/angleproject/wiki/BufferImplementation
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.

1890
I have merged Josh's GL3 screen redraw cleanup to OpenGL1 which fixes views stretching issue in the following pull request.
https://github.com/enigma-dev/enigma-dev/pull/626

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);
draw_rectangle(0,0,150,150,false);
This draws the healthbar on top.
Code: (EDL) [Select]
draw_rectangle(0,0,150,150,false);
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_set_font(font_arial);
draw_set_color(c_black);

//d3d_set_projection_ortho(0,0,view_wport[0],view_hport[0],0);

//Draw player1 hud
draw_rectangle(0,0,50,view_hport[0],false);
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_set_color(c_red);
draw_text(view_wport[0] - 65,100,o_player1.hp);
draw_set_color(c_black);
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.