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 »
421
General ENIGMA / Re: General Enigma Questions
« on: October 03, 2014, 03:25:19 pm »Quote
Thank you for that very thorough post! That list of Enigma specific functions was what I really wanted. You can disable extensions?! Holy cow that's awesome! Besides size, does disabling extensions have any positve effect on game speed? It's probably negligible if any...As Darkstar2 said, they are "on demand", which actually means extensions implement functions. If you don't use these functions, then the code is never run. We actually lack (or at least recently lacked) the possibility to extensions do something without you explicitly doing it. So they couldn't run a function or execute code just because it's enabled. That is slightly changed with the path_ fixes, which allows an extension to add an instance variable.
Also, the size would probably be smaller anyway, because the C++ compiler at maximum optimization actually removed unused functions and code. It sometimes might fail to do that, which is where extensions just help.
422
Finished Games / Re: Window Styler, Web Browser, and Embed Program
« on: October 03, 2014, 03:06:12 pm »Quote
confess the murder of Pancho Villa if they so chooseI will confess to that. But python being better than C++? Never!
423
Finished Games / Re: Window Styler, Web Browser, and Embed Program
« on: October 03, 2014, 02:34:24 pm »
Python is bad not because of its speed, it's bad because of its syntax. <Runs away now before nukes drop>
424
General ENIGMA / Re: Lateral GM question
« on: October 03, 2014, 10:57:43 am »
I guess the only concern for me is to make 64bit working with the dll. Because some people (like sorlok) cannot compile large projects on windows, because he runs out of memory and the whole thing crashes. Thought maybe CLI would help in that, because it wouldn't share memory with LGM. On the other hand of course it's better if it did share memory, but as you pointed out, LGM makes a copy for the dll anyway. So I guess we could optimize on that front.
425
Developing ENIGMA / Unstable master?
« on: October 03, 2014, 10:44:50 am »
Wanted to ask if Project Mario works in master now? Or I'm just mad? I am making my GL3.3 fixes and couldn't figure out why water wasn't drawing properly. Then I tried master and noticed that there GL1.1 and GL3 also doesn't draw water,. Is this true? Because it's weird, as I thought it ran it just fine. What are you guys running ENIGMA on when testing? I run like 3 example (Project Mario, Minecraft and now my shader example). We really need an automatic testing, because right now it's very hard to catch and fix bugs. Now I need to backtrace to figure out when the bug happened. Also, is text still messed up? At least in project mario it is.
Also, I see a large FPS improvement in GL1 which is nice. I get up to 2300FPS now, instead of previous 1200FPS. I guess that is because of the glList optimization. Having 2.3k FPS isn't really useful for a game, but still. Also Minecraft example ups from 700 to 900. There is a bug though, that doesn't allow GL1 models to be updated (mining in the minecraft didn't work), but I fixed that.
In my GL3.3 Fixes branch I get 1600FPS in GL3 up from 1400FPS in master. So not only it has more features + has no compatibility functions, it also is slightly faster. So after I fix the water and do more testing, it should be good for larger testing.
edit: The bug is in the screen_set_viewport() function. Was introduced when Robert fixed window scaling issues. For some reason it breaks the water, which could also mean it breaks surfaces in general, because surface_set_target() uses screen_set_viewport(). Investigating the problem.
edit2: Well long story short, surfaces don't need window functions in them. So I removed screen_set_viewport() and replaced them with glViewport and glScissor, which is the only two it needs.
Also, I see a large FPS improvement in GL1 which is nice. I get up to 2300FPS now, instead of previous 1200FPS. I guess that is because of the glList optimization. Having 2.3k FPS isn't really useful for a game, but still. Also Minecraft example ups from 700 to 900. There is a bug though, that doesn't allow GL1 models to be updated (mining in the minecraft didn't work), but I fixed that.
In my GL3.3 Fixes branch I get 1600FPS in GL3 up from 1400FPS in master. So not only it has more features + has no compatibility functions, it also is slightly faster. So after I fix the water and do more testing, it should be good for larger testing.
edit: The bug is in the screen_set_viewport() function. Was introduced when Robert fixed window scaling issues. For some reason it breaks the water, which could also mean it breaks surfaces in general, because surface_set_target() uses screen_set_viewport(). Investigating the problem.
edit2: Well long story short, surfaces don't need window functions in them. So I removed screen_set_viewport() and replaced them with glViewport and glScissor, which is the only two it needs.
426
Developing ENIGMA / Re: LateralGM 1.8.6.5
« on: October 03, 2014, 06:23:29 am »
In the new search feature "Matches" are number of lines where the word is found. Not the number of found words (which is what Matches seems to imply). Like "ball = ball2;" while searching "ball" will returns "1 Match" even though it will highlight both of them as it should. But I really like that representation. Can't wait until we can search in objects. And then we could actually use this tree structure to also open events.
427
Finished Games / Re: Window Styler, Web Browser, and Embed Program
« on: October 03, 2014, 06:18:11 am »Quote
The world does not evolve around C++Blasphemy!
428
General ENIGMA / Re: Lateral GM question
« on: October 03, 2014, 06:09:19 am »
I also think saving to disk and then using CLI could be faster, because writing to disk really isn't a slow operation. Even a larger project in LGM saves to disk in less than 2-3 seconds. And even then I'm sure it's no the speed of the drive, but the Java's code which is doing conversion. Imagine if LGM only saved files that have changed. Then it wouldn't matter at all. My idea on how this would work is this for EGM:
You open .egm project. LGM loads it in ram.
You run it. LGM makes a copy of the project into a temp directory (a copy operation should be really fast). Then it runs CLI on it.
You make changes to an object and sprite, but not save the project.
Run it again. LGM modifies the appropriate files in .egm which is in the temp directory. This could only be a change of few kb. Then it runs CLI on it again.
Now if you loaded non-egm format. Then it would require a conversion. Like so:
You open .gmx project. LGM loads it in ram.
You run it. LGM converts it to .egm and saves in temp folder. This will be slower than a copy, but not very much. Then it run CLI on it.
You make changes to an object and sprite, but not save the project.
Run it again. LGM modifies the appropriate files in .egm which is in the temp directory. This could only be a change of few kb. Then it runs CLI on it again.
You then save it. LGM saves to the .gmx like it does it now. gmx should allow saving only changes as well, while gmk and other older formats would require writing the whole file. Isn't much of a problem though.
You open .egm project. LGM loads it in ram.
You run it. LGM makes a copy of the project into a temp directory (a copy operation should be really fast). Then it runs CLI on it.
You make changes to an object and sprite, but not save the project.
Run it again. LGM modifies the appropriate files in .egm which is in the temp directory. This could only be a change of few kb. Then it runs CLI on it again.
Now if you loaded non-egm format. Then it would require a conversion. Like so:
You open .gmx project. LGM loads it in ram.
You run it. LGM converts it to .egm and saves in temp folder. This will be slower than a copy, but not very much. Then it run CLI on it.
You make changes to an object and sprite, but not save the project.
Run it again. LGM modifies the appropriate files in .egm which is in the temp directory. This could only be a change of few kb. Then it runs CLI on it again.
You then save it. LGM saves to the .gmx like it does it now. gmx should allow saving only changes as well, while gmk and other older formats would require writing the whole file. Isn't much of a problem though.
429
Off-Topic / Re: What we could have if Enigma would be closed source :(
« on: October 02, 2014, 05:47:05 pm »
I think the only point you have to consider is this:
If ENIGMA wasn't open source, there wouldn't be ENIGMA. That is all.
If ENIGMA wasn't open source, there wouldn't be ENIGMA. That is all.
430
Off-Topic / Re: What we could have if Enigma would be closed source :(
« on: October 02, 2014, 10:07:03 am »Quote
At the moment ENIGMA seems to be in this state thoughIt's currently in this state:
Which is good enough for me. And getting better by the day.
431
Off-Topic / Re: What we could have if Enigma would be closed source :(
« on: October 02, 2014, 03:42:11 am »
Sucks to be an Aussie then. In Europe several countries have extensive programs to use free software. Some succeed, some fail. Many companies and most research institutions also use FOSS.
432
General ENIGMA / Re: Lateral GM question
« on: October 02, 2014, 03:39:53 am »
The only thing LGM does is give information to ENIGMA's parser (the .dll) which then generates the code which is then compiled. This is required because ENIGMA itself cannot open project files (gmk, gmx, egm, etc.) and interpret the information in them. Robert made a CLI that loads gmx (and maybe egm), and talks to the .dll directly. This means LGM is not actually required for ENIGMA to work and ENIGMA isn't required for LGM to work.
433
Off-Topic / Re: What we could have if Enigma would be closed source :(
« on: October 02, 2014, 03:16:08 am »Quote
Do you mean ugly and 'not-fit for purpose'?He means secure and fit for everything. The idea of FOSS is that you can turn it in anything you need. This happened to ENIGMA several times already. Like I have used this "game development tool" in robotics, computer vision and even interactive art. It's only possible because I can modify the source as I see fit, which would be much harder or sometimes even impossible otherwise.
434
Proposals / Re: Extend LateralGM's room editor to be usable as a generic level editor
« on: October 01, 2014, 04:28:21 pm »
That's my idea. Basically allow reading access to the whole EGM and writing access only for the room file (when it's in text). That is the easiest way to do it without making a complicated interface for LGM to give data to.
435
Proposals / Re: Extend LateralGM's room editor to be usable as a generic level editor
« on: October 01, 2014, 04:07:57 pm »
LGM should also allow a way to open an external room editor, like it allows with sprites and code. I actually wanted to make a room editor in ENIGMA once, which would then interface with LGM. But never got around to it.
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 »