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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 »
271
General ENIGMA / Re: Mac's 3D
« on: January 27, 2015, 07:38:25 am »
People usually don't review their own games, so I haven't seen people saying that their gameplay is better than any AAA game. It's also useless to compare two different games (because indies and AAA's are usually in different genres, which makes the comparison impossible). But if you ask many reviewers or gamers on which game was more engaging and took more of their time, then it's often indie games even more than AAA's.
272
General ENIGMA / Re: Mac's 3D
« on: January 27, 2015, 03:11:35 am »
It really does come down to gameplay. Like minecraft is not a pretty looking game, but has been far more popular than many AAA titles. Just like Terraria with its 8bit style was a lot more popular. And so have been many other indie games (meatboy, fez and so on). That is because people can waste tens or hundreds of hours playing those games, yet you finish CoD in 4 hours and trow it out. Multiplayer is usually pretty bad for many AAA games too. AAA games that have been utter disasters both in polish and gameplay recently are such gems as AC:Unity, Watchdogs and even Far Cry4. Far Cry 4 has an interesting story line and interesting characters, but the gameplay is so boring, that rarely anyone can struggle trough it all. But I guess to each his own.
273
General ENIGMA / Re: Mac's 3D
« on: January 26, 2015, 02:01:30 pm »
The ENIGMA's engine code is partly generalized. Especially the drawing. So it's not like the draw_sprite() will be missing or something. All the drawing functions should be in Mac and be totally functional. Especially as the Mac actually uses GL, which is the most developed part of ENIGMA. So I don't think there will be big problems. Sorlok has already compiled several games in Mac, like Iji.
So in short, it's 3D should be exactly the same as on Window or Linux.
If the developer makes fixes or changes for the drawing system, then all of the platforms are affected instantly. But there is platform specific code too, and it's possible that a bug is fixed on Windows, but not fixed on Mac.
So in short, it's 3D should be exactly the same as on Window or Linux.
If the developer makes fixes or changes for the drawing system, then all of the platforms are affected instantly. But there is platform specific code too, and it's possible that a bug is fixed on Windows, but not fixed on Mac.
274
Developing ENIGMA / Everything in a seperate thread?
« on: January 24, 2015, 06:34:28 pm »
For my tools I love to make a resizible window. This is usually not that trivial, but we have everything working in ENIGMA to do this like so:
1) Break the modal loop and do everything yourself: http://sourceforge.net/p/win32loopl/code/ci/default/tree/ , but it seems like a lot of work, as you basically replicate everything Windows was doing.
2) Do everything in separate thread and allow windows to freeze the main thread. I seem to like this more. This can technically boost speed as well. The question: Has anyone done this? My naive idea was that maybe we can just create a thread in winmain(){} and do everything inside it from there. Thus there wouldn't be any problems with memory sharing and so on. The problems are callback functions (among other windows specific functions which use windows API) - will they work inside a child thread? I mean something like this function:
I do see that we have the Resize event working, which means I can do some of stuff inside the thread. The event is called whenever the window actually executes the modal loop. Like I tried screen_redraw() inside the event and it works. It redraws the screen and so I can have it look like it's not totally frozen. But the game itself is still frozen, because I would need to update all events for this to work. I guess we don't have a function for performing a full game loop. That would actually be useful.
Code: [Select]
if (global.window_width != window_get_width() || global.window_height != window_get_height()){
global.window_width = window_get_width();
global.window_height = window_get_height();
view_wview[0] = global.window_width;
view_hview[0] = global.window_height;
view_wport[0] = global.window_width;
view_hport[0] = global.window_height;
window_default(true);
screen_init();
}
So I check if the size has changed and if so, change the view size, reset window and screen. Those last two are needed to fix some visual bugs, as ENIGMA internally also needs to have it's sizes updated. This makes it work. I then noticed that maximize button was not clickable even if I enable resizing. I fixed it here (https://github.com/enigma-dev/enigma-dev/commit/a9f9238a2f50e423c567c50059b8e6765717d214). And then I noticed something that has troubled me for a long time - when you resize or move the window, everything inside it freezes. This is because of the way Windows is made and how they use modal loops. This means that the main thread is essentially frozen when you move or resize. There are two ways to fix this as far as I know:1) Break the modal loop and do everything yourself: http://sourceforge.net/p/win32loopl/code/ci/default/tree/ , but it seems like a lot of work, as you basically replicate everything Windows was doing.
2) Do everything in separate thread and allow windows to freeze the main thread. I seem to like this more. This can technically boost speed as well. The question: Has anyone done this? My naive idea was that maybe we can just create a thread in winmain(){} and do everything inside it from there. Thus there wouldn't be any problems with memory sharing and so on. The problems are callback functions (among other windows specific functions which use windows API) - will they work inside a child thread? I mean something like this function:
Code: [Select]
LRESULT CALLBACK WndProc (HWND hWndParameter, UINT message,WPARAM wParam, LPARAM lParam)
I do see that we have the Resize event working, which means I can do some of stuff inside the thread. The event is called whenever the window actually executes the modal loop. Like I tried screen_redraw() inside the event and it works. It redraws the screen and so I can have it look like it's not totally frozen. But the game itself is still frozen, because I would need to update all events for this to work. I guess we don't have a function for performing a full game loop. That would actually be useful.
275
Issues Help Desk / Re: "Precision" of floating points close to 0
« on: January 23, 2015, 06:21:55 pm »
I don't see why there would be differences between GL and DX other than the visual representation (even that should be the same though). Both systems use the same type (double) for direction and speed in the instance system (as the instance system is actually not connected to the graphics system). But floating point types cannot actually represent very small numbers. That is why you should never do hspeed == 0, but instead hspeed <= 0.00012 or something similar. That is true in every programming language. GM just seems to round some of its internal variables, like direction and speed.
I checked and we have direction as double, but only allow it to have integer values. So the calculation that sets direction from vspeed is this:
Also, you should probably use either GL1 or GL3, as DX systems are not as thoroughly tested and developed.
I'm not sure I will try to fix the speed not equaling zero, as that shouldn't be an issue even in compatibility with GM. You just should check ranges, not total equality.
Will have to investigate that weird DX bug, where it actually goes into reverse. Doesn't make much sense in my mind right now.
edit: Direction is rounded in this branch: https://github.com/enigma-dev/enigma-dev/pull/929 and in this commit: https://github.com/enigma-dev/enigma-dev/commit/0e358861fba53e7b6898df3696e94fc4fb2a3948
At some point it will be merged into master.
edit2: I honestly cannot tell why in DX mode the precision is different then in GL. Maybe some compiler options are changed which causes this. In GL is goes to E-12, while in DX only to E-06. So in GL the vspeed == 0 holds true, while in DX it does not, so the speed is decremented more. The proper fix for this is to actually test vspeed < 0.001 or we could just provide a special function for that (we do use one internally) or an epsilon value (precision) that can be checked against. So you could write vspeed < double_epsilon or something. Either way, I don't know if we want this for GM compatibility. As hspeed and vspeed are special variables, we can internally maybe do these checks and set them to 0. But I don't think we will do this for custom variables. So if you decrement your own variable, then you should check it yourself.
I checked and we have direction as double, but only allow it to have integer values. So the calculation that sets direction from vspeed is this:
Code: [Select]
*dir = int(180.0+180.0*(1.0-atan2(rval.d,*hspd)/M_PI))%360;
*spd = hypot(rval.d,*hspd);
Where rval.d is the set vspeed and hspd is the hspeed. This basically means that we evaluate "180.0+180.0*(1.0-atan2(5,0)/M_PI)" to something very close to 270, but not quite (269.9999999) and when we cast to int it truncates the decimal part, so we get left with 269.0. What I can do is just add a rounding there. This will fix this issue.Also, you should probably use either GL1 or GL3, as DX systems are not as thoroughly tested and developed.
I'm not sure I will try to fix the speed not equaling zero, as that shouldn't be an issue even in compatibility with GM. You just should check ranges, not total equality.
Will have to investigate that weird DX bug, where it actually goes into reverse. Doesn't make much sense in my mind right now.
edit: Direction is rounded in this branch: https://github.com/enigma-dev/enigma-dev/pull/929 and in this commit: https://github.com/enigma-dev/enigma-dev/commit/0e358861fba53e7b6898df3696e94fc4fb2a3948
At some point it will be merged into master.
edit2: I honestly cannot tell why in DX mode the precision is different then in GL. Maybe some compiler options are changed which causes this. In GL is goes to E-12, while in DX only to E-06. So in GL the vspeed == 0 holds true, while in DX it does not, so the speed is decremented more. The proper fix for this is to actually test vspeed < 0.001 or we could just provide a special function for that (we do use one internally) or an epsilon value (precision) that can be checked against. So you could write vspeed < double_epsilon or something. Either way, I don't know if we want this for GM compatibility. As hspeed and vspeed are special variables, we can internally maybe do these checks and set them to 0. But I don't think we will do this for custom variables. So if you decrement your own variable, then you should check it yourself.
276
General ENIGMA / Re: ENIGMA compiled EXE detected as virus!
« on: January 23, 2015, 06:41:15 am »
Most AV companies have a way to report false positives. Like for kasperskey you send them the exe compressed inside a password protected zip to their e-mail. Then they look at it closer and modify their stuff so it wouldn't trow a false positive. So you should probably try doing that for those two AV's. At least maybe they will say what to change on our side.
277
Issues Help Desk / Re: sprite_add not working?
« on: January 20, 2015, 04:45:48 am »
I just tested loading and drawing in my ENIGMA (which is very up to date and only few commits behind) and it's working fine:
Code:
edit: I tested both GL1 and GL3. Can you maybe try GDB and post the bt?
Code:
Code: (edl) [Select]
spr = sprite_add("C:\001.png",1,0,0,0,0);
draw_sprite(spr,-1,mouse_x,mouse_y);
edit: I tested both GL1 and GL3. Can you maybe try GDB and post the bt?
278
Issues Help Desk / Re: Extension .egm does not match EGM?
« on: January 20, 2015, 04:34:58 am »
Why can't we serialize the room data in an xml just like GM? How do you save GM files then? XML is extensible by design. Or you can do it in YAML or eYAML or whatever else we got there. I don't really see the problem. EGM itself is also actually quite extensible even now. Everything is in it's own folder and all we need are some XML files showing what is where. So if you add a new resource, you just add it to a xml config file and show it in LGM. If an XML entry is missing, then use a default value (one that would be used if you made a new project with File->New).
279
Developing ENIGMA / Re: MinGW 64
« on: January 18, 2015, 06:48:47 pm »
The only way I support removing mingw and git is if extremely easy and straightforward alternative is in place. Like maybe we need to make our own installer? Like a runner which handles auto-updates, dependencies (Java, Git, MinGW) and allows you to actually run the LGM. This is how UE4, Unity and GM:S (as far as I'm aware of) does it. Most game engines (and games) does that. That would be extra development effort though.
280
Issues Help Desk / Re: sprite_add not working?
« on: January 18, 2015, 04:46:42 pm »
Our idea is not to test things like that in normal Run mode. They will only be checked in debug mode, and in a lot of cases it is (like all the drawing functions check if the resource exists only in debug mode, in regular or release mode it will not check that). So you will still have a million ways to crash even if we implement it all fully.
Sound fade might not be implemented fully. You can try DirectSound and see if it's there. In OpenAL I think we don't support any sound effects, as there is no easy way to add them in OpenAL.
Sound fade might not be implemented fully. You can try DirectSound and see if it's there. In OpenAL I think we don't support any sound effects, as there is no easy way to add them in OpenAL.
281
Issues Help Desk / Re: sprite_add not working?
« on: January 18, 2015, 03:07:33 pm »
Yup, we need better error checking. Many parts of the code don't do any checks even in debug mode. We need to add a special error window and than add many more checks.
And we support png's, bmp's and most recently gif's. They are all identified by the extension of the file and default's to bmp.
And we support png's, bmp's and most recently gif's. They are all identified by the extension of the file and default's to bmp.
282
Developing ENIGMA / Re: MinGW 64
« on: January 18, 2015, 02:48:15 pm »
I think having two releases is the best option, and it's the most popular. Allowing people to compile to both from LGM's IDE would be magnificent, but as you already pointed out, it's hard to do. I have used TDM-GCC though and it does allow you to compile both 32bit and 64bit from the same installation, so it might be an option.
283
Issues Help Desk / Re: Create games for mobile platforms is possible with enigma??
« on: January 17, 2015, 09:20:11 am »
Actually about documentation thing. Those here that say that they would like to contribute, but can't because they don't know C++ or Java, they could go to wiki and just fill in the blanks. Doing that doesn't require any knowledge besides on what the functions do, which should be known for most of the stuff. There already plenty of examples on how the functions should be documented as well.
284
Issues Help Desk / Re: Create games for mobile platforms is possible with enigma??
« on: January 16, 2015, 05:57:02 am »
I for one don't needed or want 12yrlds here coming from GM. They can if they want, but if they only rage about how GM is better because it's more stable, then I don't need them. As Robert said, if someone wanted a stable mobile tool like GM, then they would come to ENIGMA and implement it. Yet the only ones who work on ENIGMA are people who want Windows and Linux support (and maybe Mac). Sorlok's idea is to port GM games to Linux, that is all he wants. And so he has done great job at fixing things and implementing things. I might implement GLES rendering system, but not for mobile, but ARM. Like I want my games/tools made in ENIGMA to work on RaspberryPi or Nvidia Jetson. I don't need them working on my phone. So this project, like most open source ones, are worked on based on personal needs. If I need to constantly make GUI's, I'll make a gui extension (which is coming along nicely by the way, I'll probably make a topic about it). If I need to make cool 3D effects, I'll work on shader support. Replicating GM has not been my goal in about 3 years, because I don't really have any GM version (besides 8.0) to test anything on. So I don't know what GM:S has or doesn't have. I just do what I need.
285
Developing ENIGMA / Re: LateralGM 1.8.6.844
« on: January 14, 2015, 07:34:49 am »
The new LGM (from the Download page) keeps crashing (when pressing the Run button, just like before), but it also trows errors when opening an egm file:
Added the egm to this post.
Quote
Operating System: Windows 8.1Then when I try to open some resources I get:
Version: 6.3
Architecture: x86
Java Vendor: Oracle Corporation
Version: 1.8.0_25
Available processors (cores): 8
Free memory (bytes): 16148096
Maximum memory (bytes): 259522560
Total memory available to JVM (bytes): 57532416
File system root: C:\
Total space (bytes): 255506509824
Free space (bytes): 161634590720
Usable space (bytes): 161634590720
File system root: D:\
Total space (bytes): 499967324160
Free space (bytes): 489319682048
Usable space (bytes): 489319682048
File system root: E:\
Total space (bytes): 500101541888
Free space (bytes): 493137895424
Usable space (bytes): 493137895424
Stack trace:
java.lang.NullPointerException
at org.enigma.file.EFileReader.readResource(EFileReader.java:666)
at org.enigma.file.EFileReader.processEntries(EFileReader.java:644)
at org.enigma.file.EFileReader.readNodeChildren(EFileReader.java:622)
at org.enigma.file.EFileReader.readEgmFile(EFileReader.java:560)
at org.enigma.file.EFileReader.readEgmFile(EFileReader.java:538)
at org.enigma.file.EgmIO.read(EgmIO.java:56)
at org.lateralgm.main.FileChooser$1.run(FileChooser.java:564)
at java.lang.Thread.run(Unknown Source)
Quote
Operating System: Windows 8.1And when I press Save it corrupts the egm.
Version: 6.3
Architecture: x86
Java Vendor: Oracle Corporation
Version: 1.8.0_25
Available processors (cores): 8
Free memory (bytes): 12028024
Maximum memory (bytes): 259522560
Total memory available to JVM (bytes): 57532416
File system root: C:\
Total space (bytes): 255506509824
Free space (bytes): 161598521344
Usable space (bytes): 161598521344
File system root: D:\
Total space (bytes): 499967324160
Free space (bytes): 489319682048
Usable space (bytes): 489319682048
File system root: E:\
Total space (bytes): 500101541888
Free space (bytes): 493137895424
Usable space (bytes): 493137895424
Stack trace:
java.lang.NullPointerException
at org.lateralgm.subframes.ResourceFrame.<init>(ResourceFrame.java:151)
at org.lateralgm.subframes.InstantiableResourceFrame.<init>(InstantiableResourceFrame.java:50)
at org.lateralgm.subframes.ShaderFrame.<init>(ShaderFrame.java:93)
at org.lateralgm.subframes.ResourceFrame$DefaultResourceFrameFactory.makeFrame(ResourceFrame.java:108)
at org.lateralgm.components.impl.ResNode.openFrame(ResNode.java:210)
at org.lateralgm.components.impl.ResNode.openFrame(ResNode.java:194)
at org.lateralgm.main.Listener$MListener.mouseReleased(Listener.java:798)
at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$400(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Added the egm to this post.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 »