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

466
Developing ENIGMA / MinGW 64
« on: January 17, 2015, 12:41:35 PM »
Ok so I decided to see what it would take to finally support 64bit in ENIGMA.

The first thing was getting JDI and the Compiler to build with MinGW64
https://github.com/enigma-dev/enigma-dev/commit/331235e30f971ca7e38393efe1423cd38f1ff027
https://github.com/enigma-dev/enigma-dev/commit/f1e8cfdd0d55e6b901fef60dce19781f43d36859
https://github.com/enigma-dev/enigma-dev/commit/355d2d8fd8c5d17fa7232034a18d63475658a4f5

Edit: Josh approves as of this commit.
https://github.com/enigma-dev/enigma-dev/commit/9d49bf81c81106f8d8ed78d60c03001681a15c31

Edit: Josh advised me to use the fixed size types for the overload, so now the compiler builds with C++11 support too for both 32bit and 64bit GCC
https://github.com/enigma-dev/enigma-dev/commit/5b99151173b1dad9acb059f9e99a75974801d42b

I should not have wrote those straight to master but they may need reverted, anyway...

64bit Java/JNA can only load 64bit dll's and 32bit Java/JNA can only load 32bit dll's. This means that the users Java installation with ENIGMA thanks to the plugin and using ENIGMA the way we do will have to match the architecture of that the user not only has but also intends to target.

So if you have 64bit Java, with any ENIGMA release you will only be able to make 64bit games. And if you have 32bit Java you can only build and use the 32bit version of ENIGMA. But you could install both 32bit and 64bit ENIGMA in parallel and Java in parallel to be able to build for both architectures if you have a 64bit OS.

One possible alternative is to remove the requirement of JNA and compileEGMf all together replacing it entirely with the CLI allowing you to build both 32bit and 64bit applications with either a 32bit or 64bit Java installation. We could then use a MinGW that supports dual target though the exception support would be pretty grotesque, just because that's the state of current dual target MinGW compilers. Another way of accomplishing the same thing is to build compileEGMf for the supported Java architectures which would still require a dual target MinGW.

1) Do we want both a 32 bit and 64 bit ENIGMA portable, or just a very large single ENIGMA portable? If the former you would have to download both portables in order to build for both architectures.
2) Do we want to be able to build 32 bit games when we have a 64 bit Java installed to run LGM?
3) This is tied to the first question, but do you want proper gcc exception support or not? Because if we go with dual target either 64bit exception support is bad or we maintain two separate releases. If not we could include both mingw32 and mingw64 instead of a dual target mingw64, and that may or may not mean we have two separate portables.

Addressing this problem would fix several issues.
1) 64bit Java would be supported to run ENIGMA
2) 64bit compilation support would be added.
https://github.com/enigma-dev/lgmplugin/issues/20

For the record Qt Framework also makes you install separately, as does Java and .NET and a lot of other programs.
https://www.qt.io/download-open-source/#section-3

Note: The good news is also that JNA supports both 32bit and 64bit so there's no need to distribute two versions of it.

467
Announcements / Re: Java Easy Image Editor 0.0.1
« on: January 16, 2015, 07:32:59 PM »
Yes sort of, but then why don't we have one for Linux? The answer is simple, we package a specific MinGW because it's always breaking with every update and installed MinGW's are never compliant. Code::Blocks does the same thing and so does Qt.

I would have no problem with it if we could automate the Portable ZIP to be generated by the server so that I did not have to do it by hand. Then the user could configure a Portable ZIP to include certain things, and even certain plugins. Fundies had this all set up but nobody has done anything to move it to the main ENIGMA server to package it for me, so for now I keep doing it by hand as well to set the icon and copyright info.

468
egofree is exactly right the problem is not Java, even GM8.1 loaded giant binary blobs in Delphi. Second egofree, to replace it with my CLI project you would first have to fix my CLI because it was broken when preCreateCode was added and I haven't managed to get it working because of other changes. But using it would basically mean getting rid of GMK support in LGM. I mean the CLI can load and compile a GMK no problem. But for the CLI to make LGM itself more efficient requires LGM to not load the entire project into memory at once, but load each resource as you open it. So for instance when you open a script, that is when the script is loaded into memory, and when you close it is unloaded from memory. Right now LGM loads every resource into memory when you load the project and keeps it there until you close or load another project.

Then when you hit run LGM does not have to pass anything to ENIGMA, it just makes you save open resources like all other IDE's including Studio's now. Studio does it this way and makes you convert GMK's to GMX when you load them. Then LGM just passes the path to your project to the CLI and the CLI handles all the compiling with native C++. So you can see why it is more efficient and why this can't be easily done with GMK. With GMK it is impossible to just load a single resource because it is a huge binary blob, and that is why Studio makes you convert to GMX.

But primarily GMK projects are where ENIGMA has the best support right now, and one of the primary reasons LGM is still used, and in fact recommended by some GMC moderators is because it can be used in fixing corrupted GMK's where GM8.1 has failed.

And Darkstar2 while you may be right about ENIGMA being better if it were its own project, which I've argued before. Doing that would essentially destroy the very reason many people show up, to compile GM projects, which is why I showed up here and ported my Project Mario game to ENIGMA so that it would run natively. While this may be the exception and not the rule with me and Sorlok, the project would be missing two very important contributors, not to degrade the importance of other contributors of course because I am not really sure why egofree contributes other than just like me he just likes to help.

Additionally settings.ini is not a hack, LGM does in fact have 64bit support and so does the plugin. It's in fact ENIGMA that does not have 64bit support. But the plugin is where most of the instability exists.

469
I know ego, but specifically what I am trying to point out to you is that i did in fact make substantial progress, it's not about what I did, it's that you don't need to worry about me doing plenty of different things because I historically finished them, a lot of them. And yes I agree the scope of the project is way too big, but I have no solutions for fixing that, for a while I was the solution.

470
Quote from: TKG
A little off topic, isnt it weird that YYG hired Brawl as a sandbox moderator when he was  only 16? Or Honno who is 16 and hired for GameJolt...
Then you have no reason to question why the GMC is not a constructive or friendly community.

Quote from: Darkstar2
what the fuck did you lot do all these years ?
I wasn't here yet, see the following topic:
http://enigma-dev.org/forums/index.php?topic=1031

Quote from: Darkstar2
What a shame Lonewolf's video engine cannot run in ENIGMA, he was so willing to work with ENIGMA to integrate it FREE....would have been great.
Uhm, first of all relax because it's not that complicated to port it. We just haven't decided on how to overload variant for pointers, it can be done with simple hacks but we haven't even discussed how to do it the proper way. That's only one issue, the number of Studio extensions using the new window_device() function I can probably count on my fingers. Second I was hoping after the major release of LGM that I would have time to implement the extension resource and make store extensions work, but I got side tracked with constants.

Quote from: Darkstar2
I mean yeah ok GMS is flawed on many levels and YYG is crap to deal with
Extensions and what not are actually one place ENIGMA shines. If some part of the engine is not store compliant you can just rip it out and rebuild your game because the whole thing is modular as well as open source. And for those reasons it's also extremely easy to wrap C++ in an extension and add new functions, in fact, it's extremely easy to add new functions to ENIGMA. My DirectShow extension is the perfect example of how easy it is to wrap functions and add them to ENIGMA.
https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Universal_System/Extensions/DirectShow/DSvideo.cpp#L32

Quote from: egofree
It has been poorly documented, had many bugs and had many functions not really unimplemented.
Yes, but what can you do about it egofree? What can be done to solve that? I was the biggest contributor to fixing the former with the Wiki documentation, which is not as complete as people would like but is still much better than nothing which is what we started with.
Drag and drop actions are fully documented, every single one.
http://enigma-dev.org/docs/Wiki/Action
Instance and motion is near completely documented except a few motion planning functions because I wanted Harri to document those since they were extraneous, some of the functions were also added in Studio.
http://enigma-dev.org/docs/Wiki/Instance_and_Motion_Functions
Date and time functions have been documented for ages.
http://enigma-dev.org/docs/Wiki/Date_and_Time_Functions
Data structures have been documented for ages.
http://enigma-dev.org/docs/Wiki/Data_Structure_Functions
File functions have been documented for ages.
http://enigma-dev.org/docs/Wiki/File_Functions
Input functions too.
http://enigma-dev.org/docs/Wiki/Input_Functions

There's not much more I can do, I've already done my fair share of the documentation. It takes a lot of effort to document all 2000 some functions and other constants and things and do it properly, this simply can not be done by a single person alone, especially one that now goes to college. I've also only been with this project for two years and besides contributing a substantial amount, GM itself did not start out completed it started as a simple animation program which was improved over subsequent years, from 1999 to about 2008/9 when GM8.1 was released, approximately a decade to reach the point of what GM is today, YYG's is of course the de-evolution of that decade.

In case none of you remember, this is LGM just 2 years ago.

This is LGM today.


Now the point of this is not to brag about how much I've contributed, but to put it into perspective for you guys about how much work it actually takes, you simply can not expect miracles. It takes time, skill, and dedication to pull this off, but the goal is never only money as has been repeatedly stated, my main objective was just to see how great I could make the software, and whether or not I may have failed I still tried, money is not a necessity.

Quote from: egofree
but also often you are starting too much tasks at the same time without really finishing them.
This is what I have the most problem with, and why I wanted to put the former into perspective. I don't care and nobody else does how much I've done, though I appreciate your understanding. The main reason is because I generally think I can manage to finish every single thing in ENIGMA, which is just simply not true, I'm a pretty quick and dedicated developer, but the work is too insurmountable. Generally I also tried to lay the framework for other developers to come in and finish something, if I didn't have the time to fully complete something I at least put the framework in place for it to be completed, and in some cases Sorlok and TheExDeus have finished my incomplete work.

This is generally cited as a problem with open source projects.

Quote from: Darkstar2
Well some people have the wrong idea and come to ENIGMA thinking it is a carbon copy of GM but free when it isn't, not exactly, because it is not 100% compatible.  and most people don't bother reading, so they won't read the fine print so to speak :D
This is what I've consistently identified as the problem, it has no real objective. Its goal is simply to be an augmentation of GM, but what it should do is undefined and has consistently been left up to the users to decide.

Quote from: Darkstar2
abandon the dog shite they left behind, and nobody left to wipe up the mess, it keeps piling up and eventually not much people have time or skill to fix it.
The only real place we've had that problem is in LGM and specifically with the EGM format. In fact, I hate the whole ENIGMA plugin. Josh has made sure not to let this happen as badly with the compiler, specifically he defragmented write_object_data.cpp when it got too verbose and complex.

Quote from: Darkstar2
Unless they are the nerdy type who know 16 languages and can code C++ with their eyes closed - they do exist, but you are not LIKELY to find them on the GMC of all places. :D
I agree with this and I have nothing against children or professional developers, the fact is there is no reason you can't have the best of both worlds. But D&D is not the way to achieve that, and as I've said countless times I find the whole thing to be extremely counter-intuitive and it never helped me learn anything, I never figured out how to make games with D&D in GM they were just broken messes, like all D&D games, it's a failed concept.

I also specifically hate the event system and think the objects should just be scripts. There's no reason you can't still provide an event tree for quickly adding events to the object like you can do in Visual Studio's form designer. In fact this would be a great alternative to GM, just click to add an event to your script object like you do in Visual Studio, and then present a tree of all the methods and the structure of the script like Eclipse. It's much easier to just cut copy and paste text to reorder and move events than what GM does. The following screenshot should clarify, the event tree would automatically add the event code to your script for you like in Visual Studio, and below the event tree could be a separate tab with a docking interface that outlines all the methods and events of the class. The interface would still be graphical and just as easy for novices and advanced users alike to work with, the same could be done with drag and drop actions, they could just cut copy and paste the actual code for you. GM's whole interface is extremely counter-intuitive, and do you know why? Because it is over 15 years old, a lot of research has gone into interface design since then.



I have also specifically requested from Dreamland that the event and instance system be rewritten in a way that makes the above more graceful to accomplish for people who for instance would like to use ENIGMA's engine as an SDK and write their own event/instance systems.

The point is, I don't know what to tell you guys. All I can say is that I am available to help once in a blue moon if somebody needs it, I don't care much for debating I'm a pragmatist. But writing this post has already wasted about an hour of my time that I do not have.

471
Announcements / Re: Java Easy Image Editor 0.0.1
« on: January 16, 2015, 02:23:51 PM »
Let me explain exactly why I am skeptical about putting it into the Portable ZIP. Primarily I see this application as having the potential to be standalone by itself as a separate product, much like LGM is from ENIGMA. In fact this is a really good alternative for a Windows Paint like program on Linux which really does not exist, yes there's GIMP which I prefer but many people would like something closer to Paint or Paint.NET which I also use (the latter I use because of available plugins). Second, you may not want to update the image editor as frequently as the ENIGMA package and in fact may want it installed in a different location because again it is technically its own separate program. JEIE is in fact simple enough we could wrap it with an install creator for Windows.

Also, I am not really sure how you would link JEIE with LGM, I know the preferences exist but I never learned how to work them. Additionally someone somewhere on this forum once wrote a tutorial that displays my ignorance.

472
Allow me to speak candidly for a minute here. If there is so much demand for all these platforms, why are there not more developers flocking here to make ENIGMA compatible and stable for these platforms? If there was really that much interest in or market for it then why has it not happened? It's just supply vs demand, the supply is limited and there doesn't seem to be any demand. Anybody is free to come here and fix whatever they have a problem with in ENIGMA, but nobody seems to, a few do, but not as many.

ENIGMA and LateralGM are so much more than what meets the eye, a large portion of the Game Maker infrastructure open source and freely available. Why hasn't more been done with it? I've come to assume there just is not enough interest. Take Linux for example and a lot of open source software on it like Libre or Open Office, the programs aren't great but there's enough demand to keep them actively developed. The developers here never really had any need for ENIGMA, that's an fundamental problem. Sorlok is a good example of the opposite of this, he had a specific objective and that was porting Iji and a lot of popular GM projects to other platforms and he managed to accomplish what he wanted. The real problem here is that this project has no clear objective, I've stopped using GM for a long time now, and I feel developers deserve a much better tool. My goal was only ever to help this project and those who needed help or needed something, and I still intend to carry on that agenda.

Finally, I agree with TKG, he may be a little comical at times, but he can also be an extremely reasonable and practical person. That is also absurd that YYG's advertises features that do not even work, they've been doing this since the release of GM: Studio. They never even finished their road map which someone posted about on the GMC, all they've managed to do is break more stuff and hurt the brand. But yet GM: S 2.0 is supposed to be coming? They still have a Delphi IDE, it will be a cold day in hell when GameMaker becomes relevant again.

473
Issues Help Desk / Re: yet another xp java run/compile error
« on: January 15, 2015, 07:29:21 PM »
Ok wonderful! If you have any more issues don't be afraid to ask for help!

474
Issues Help Desk / Re: yet another xp java run/compile error
« on: January 15, 2015, 08:25:45 AM »
Hello qwerty, the settings.ey has actually been changed and we hard code the values now until we can create a better interface for the global compiler settings. Follow the directions in the following topic with the updated XP fix:
http://enigma-dev.org/forums/index.php?topic=2379.15

Quote from: RobertBColton
Just change it manually in the file
CompilerSource\settings-parse\parse_ide_settings.cpp:146:  make_directory = "%PROGRAMDATA%/ENIGMA/";

You won't need the CLI, so just change that one line then launch ENIGMA again and then everything should finally work.

Let me know if this fixes it!

475
francot, currently it's possible to do some hacking to get an Android game running but your GL3 graphics system is not entirely GLES 2.0 compliant yet. Once that happens we will can include an official Android bundle that will let you run the games in an emulator and compile for the platform.

476
Developing ENIGMA / Re: LateralGM 1.8.6.844
« on: January 15, 2015, 08:21:24 AM »
We already have default options though I never considered an interface for changing them. All resources have a default property map.

But yes precompile should be set to true I suppose, since in ENIGMA we actually check the string type to make sure it can compile, in other words we only compile GLSL in GL. Right now it is false, but we can definitely change it, I have no problem with that because even if we didn't check them the shader compilers fail silently, not necessarily silently, but it won't crash the app if you accidentally compile an HLSL shader with the GLSL shader compiler.
https://github.com/IsmAvatar/LateralGM/blob/master/org/lateralgm/resources/Shader.java#L38

I am also aware the EGM format is broke in this release thus why it does not appear in a new portable zip yet. Fixing the EGM format the correct way is something I do not have time for, but we have a ticket posted on GitHub. You should still be able to run GMK/GMX just fine.
https://github.com/enigma-dev/lgmplugin/issues/29

477
Developing ENIGMA / Re: [GL3.3] Multiple render targets (MRT)
« on: January 13, 2015, 07:16:09 PM »
1) The number of graphics systems we try to support is less than or equivalent to that supported by other abstraction API's. Direct3D11 is necessary for Xbox 360 and modern Windows platforms including Windows Phone. Direct3D9 is necessary for older Windows version which still have at least 25% of the market share, and Steam/Valve hardware surveys are useless in this regard because they don't differentiate between casual and hardcore gamers so the market is probably under-represented in their statistics. OpenGL1 is not really a must anymore, we could honestly get rid of that, if their hardware doesn't support OGL3 features they will likely rather have Direct3D9 than use such an old OGL version, I doubt there's a single Linux computer out there that doesn't have framebuffer support. But to get rid of OpenGL1 means to get rid of what has been our most stable graphics system.

2) You may not care about it but potential users do when a lot of the Studio examples include shaders written in both languages. But I'll cede that I always cared more about CG.

3) Is not that big of a plus, we'd get it with GLES anyway. The only real reason it is a plus because it brings support for also other windows platforms where we haven't finished implementing the graphics, like Direct3D11/Xbox 360.

4) Windows Vista and XP still have a lot of market share, and polygonz computer don't work right because the default Vista drivers have poor OpenGL support, most of the time users can update the driver to get the support but polygonz is just a fail.

Quote from: TheExDeus
I personally haven't done anything for DX at all, so i'm sure it's already broken because of changes I have done elsewhere.
That's really a poor position to take on the issue considering before and after changes to OpenGL3, Direct3D9 still gets better performance on some systems including mine.

At any rate I do not have the time, I am starting discrete math and chemistry this semester so I have to be cracking the books. I do not really know what ANGLE would entail, from what DaSpirit has told me it seems to be that you can only use GLES 2.0 and they are adding GLES 3.0 support soon, which means the code still has to be written in OpenGL3, it would just take our OpenGL3 system port it to GLES 2.0 and plug in ANGLE and it would work everywhere. In fact, we could write all the GLES in one abstract GLES system and allow you to optionally run it with ANGLE. So in other words we only support OpenGL3 natively and you can optionally turn on ANGLE for other platforms.

So in other words we just make ANGLE optional, we get the best of both worlds including fully native GL where it will run and optionally building with a little overhead for older platforms or platforms like Xbox 360.

478
Developing ENIGMA / Re: [GL3.3] Multiple render targets (MRT)
« on: January 13, 2015, 05:57:05 PM »
First I would like to mention we don't just make a tool, we make a tool that is supposed to make it easy for newcomers. Maybe we should just accept the fact that we are too small of a group to writing our own graphics abstraction, it really is beyond the scope of this project and even YYG's uses ANGLE. There are many positives to using ANGLE:

1) ENIGMA would finally have its shit together in the graphics department and little duplicate graphics code, which despite my efforts we still have a lot of.
2) We can use HLSL and GLSL at the same time.
3) We would actually have working graphics for embedded systems and mobile.
4) Everybody could use surfaces, and there wouldn't be inconsistencies in the behavior of our graphics systems.

The only real downside is that it is not fully 100% native, and we have just a little added overhead, but this day and age, who cares? Additionally Harri I don't think you should be mapping the enumerators to OpenGL constants because that pollutes the enigma_user namespace, thus why we mapped them to arrays in the other systems. In the end, do we want to continue banging our heads against the wall over these abstraction issues or do we want to just make good games and have a solid game engine?

Anyway, did you even bother to Google search Harri? Why can't you swap the color attachments?
https://www.opengl.org/discussion_boards/showthread.php/183185-Multiple-FBOs-or-attachment-swapping

PS: Also I see that it is still and undocumented function, they must have just forgot.
http://gmc.yoyogames.com/index.php?showtopic=602766

479
Off-Topic / Re: Disable Right click on target HWND
« on: January 12, 2015, 06:47:17 AM »
TKG, usually the player just has an easy way of letting you disable it. The following question was asked about a VB.NET SWF player.
http://www.codeproject.com/Questions/839571/How-to-disable-Adobe-Flash-Player-context-menu-in

Basically if the API don't offer you'll have to offer some very ugly hacking, which I could pull off if I was dedicated to but I suggest you just find another API, or is that not feasible?

Quote from: TKG
The problem is I can find the "Window Class Name" of the right click popup menu via GetClass.exe, but how do I use that to get the menus handle to destroy it? It isnt a window, and the only way to get a menu handle is by GetMenu() which uses the parent window's hwnd, which as I said only works with the menubar items at the top of the client.
That's because the menu itself might not be a native context, it could in fact be entirely written in Flash just like Java Popups are really JMenu's or ContextMenu's.

480
Off-Topic / Re: Disable Right click on target HWND
« on: January 11, 2015, 10:18:59 AM »
After running it in ENIGMA I see how it behaves and works. Your source code for this isn't really important at all, what's important is that you mention specifically what flash embedding extension this is because it likely has a way of disabling the popup. The second is that you shouldn't really worry about this, these settings are meant to be there for a reason, just shut down your flash extension and close it on game_end, I don't see what's wrong with that? Otherwise you need to find out if the extension lets you disable the context menu or else find a way to hack around that which may not go well because that context menu is likely built into the flash player.