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 »
766
Programming Help / Re: function error
« on: April 21, 2014, 09:37:52 am »
Because they don't exist. While "variable_local_exists" is possible, but inefficient (because that would require storing all variable names as strings in the code) we don't see a real use for it. execute_string also will probably never going to be supported. We since the beginning (like GM:S until recently) use compiled C++ for the games. So we don't have any parser or JIT compiler to execute code on the fly. If you want scripting in a game, then maybe a Lua extension could be made.
Both of these functions are the "Dark side" of coding though - if you think you need them for something, then most probably you don't. They allow large security holes (like using registry_ functions in the execute_string), crashes and bugs.
Both of these functions are the "Dark side" of coding though - if you think you need them for something, then most probably you don't. They allow large security holes (like using registry_ functions in the execute_string), crashes and bugs.
767
Issues Help Desk / Re: Are particles working in ENIGMA? Not for me !
« on: April 21, 2014, 08:43:31 am »Quote
For the pre-made stuff (action_effect) no, did not notice. For my fire1 custom particles, I noticed, but I cannot compare to anything since they did not work for me previously The fire1 example is a streamed particle, first instance does not slow much, but when adding another things start to really slow down.Okay I got around to testing the draw calls and indeed blend mode caused the VBO to render and blend modes were changed per particle. So it ended up rendering 1 quad per VBO which is rubbish. With 10400 particles I got 25FPS. After I fixed that I got 140FPS now. Current progress is here:
Now I already posted my PC and GPU specs they are up to date and fast, can run all latest games at their full settings. So CPU/GPU is not a limitation.
On the right is Code XL debugger. Right now it's total of 70GL calls and only 3 draw calls (being glClear to clear the screen, then one draw call for the text and one draw call for all the particles). In all the graphics systems I get 140-160FPS which leads me to believe this is no longer a drawing limitation, but now it's CPU bound (all the particles are calculated on the CPU).
I only have old GM8 installed in that I get about 35FPS with the same example. But I guess the new GM:S would probably work even faster than ENIGMA in that code (maybe someone can test? The example is here: https://dl.dropboxusercontent.com/u/21117924/particle_test.gmk) as they use GPU to calculate particles. So it might be a lot faster, but a lot more limited. Like they no longer have attractors, destructors and so on.
What we could do is use instances in in the particle system. It would lower bandwidth by factor of 4. We could technically use instances for all sprites, but that would not allow mixing vertices like we can do now.
The branch with fixes is here: https://github.com/enigma-dev/enigma-dev/tree/particle_fix . Could you Dark check and see what FPS you get now?
Also, I previously was mistaken. I was very sure we used batching even in GL1. That apparently is not the case. For backwards compatibility that thing is still immediate mode. But because of clever driver side stuff it usually runs a little faster than GL3. We still need to optimized GL3 though.
768
General ENIGMA / Re: LateralGM 1.8.5
« on: April 21, 2014, 05:49:15 am »Quote
I am convinced ENIGMA can be used to make MYST type games....There is support for video and external resource handling and other features obsolete in GMS, pretty much any point and click adventure,It can make any kind of game. The problem seems to be that you and others think that if ENIGMA doesn't have feature X that GM has, then it suddenly cannot do anything. Yes, there are bugs, but most of the time you can go around them. Like in case of particle system not working you could of made your own. Making a particle system in GML/EDL is less than 100 lines. So I am not only convinced, but certain that GM can make Diablo, Bastion, FTL, MYST, Fallout, Arcanum and even Portal. It's just that you won't have a "Portal extension" coming with ENIGMA just to make a portal game in 20 lines of code. You still have to do the work. But we already had an off-topic about that. So no reason to beat a dead horse.
MYST type, interactive / adventure, etc. That is a theory. In practice, can ENIGMA handle large resources, large games? I have not tried.
Quote
Ok I have made the exception handling a little better. In the event an exception occurs where Java continues pumping events (such as an exception when painting a control) you should now be able to close the main frame or even attempt to save a backup of your project to stop from losing changes because the dialog is no longer modal. The dialog also will no longer block other applications so you should be able to open task manger as a final solution if nothing else works.Thank you.
769
Issues Help Desk / Re: Are particles working in ENIGMA? Not for me !
« on: April 20, 2014, 02:24:47 pm »Quote
Thanks I will test this later today. You mentioned a quick fix by setting back shader, so if I understood correctly this would be a faster / more optimized way of displaying particles, but what are the downsides for this compared the the sprite_draw(ext) ?Yes, in GL3 that would technically be faster than using draw_sprite_ext() for every particle. I cannot say any specific number, but it still should be faster. When they are fixed (of if they are fixed) we could do some benchmarks. There are no real downsides besides the fact we would need to maintain more code. The draw_sprite() method also means things like lights work on particles, while if we used a custom shader they wouldn't.
Also, it wasn't as "quick" as I thought, as particles in GL3 crashed the game for me (unlike you who only had problems with drawing), so I ended up turning on the fallback.
Quote
1) BTW, is there a faster way to download files that have been modified instead of opening each file in a text editor copy / pasting ? Is there a way to directly download the modified files?You can do "View->Raw->Save As", but that is the same as copying. You can also download the whole branch via "Download Zip" from this page https://github.com/enigma-dev/enigma-dev/tree/particle_fix . Then copy all the files. But be careful not to overwrite your own custom changes if there are any. I just often have several version. Like enigma_master and enigma_test folders. In them I just pull all the changes via Git For Windows.
Quote
As far as speed, in a side scroller where I would use streamed particles in areas I would personally have them disabled when they are off view, I guess I see what you mean by "slower"Is it actually slow/slower for you? Or you cannot notice? Because I think you shouldn't really be able to notice. As I said our sprite rendering is actually quite optimized. Especially when you use the same sprite image to render a lot of sprites (just like particle systems do) and so in both GL3 and GL1 the particle system should use the batcher. Although there is possibly a bug why it doesn't (we call draw_set_blend_mode() before all sprite drawing which could make the batcher flush. I will test this later).
770
Issues Help Desk / Re: Are particles working in ENIGMA? Not for me !
« on: April 20, 2014, 07:59:59 am »
I will do a quick fix that will make the particle system run on all graphics systems. I will do it by forcing on particlesystem_fallback on all systems. That means all particles will be basically drawn with draw_sprite_ext() function. It will be slower, because particle system drawing can often be optimized just for particle systems. On the other hand our sprite drawing is batched and so one particle system should technically draw using one draw call.
edit: Also, Darkstar nothing displays because your code is wrong.
1) You need to create a particle system.
2) You call your particle fire1 and not particle1.
So your code would display nothing even particles actually worked. This is correct code:
edit2: The fixes are in this commit: https://github.com/enigma-dev/enigma-dev/commit/2a914cc52a1f48379c14dc6b46b1b60ddd9e844c in this branch: https://github.com/enigma-dev/enigma-dev/tree/particle_fix
I didn't merge into master so people could test and see if it works and doesn't break anything else. Also, as I implemented draw_get_blend_mode* functions I wanted to know if anyone else has a better solution.
edit: Also, Darkstar nothing displays because your code is wrong.
1) You need to create a particle system.
2) You call your particle fire1 and not particle1.
So your code would display nothing even particles actually worked. This is correct code:
Code: [Select]
Sname = part_system_create();
fire1 = part_type_create();
part_type_shape(fire1,pt_shape_line);
part_type_size(fire1,0.20,0.60,0,0);
part_type_scale(fire1,0.65,2.50);
part_type_color3(fire1,16749459,33023,255);
part_type_alpha3(fire1,0.04,0.06,0.07);
part_type_speed(fire1,0.70,2.60,-0.02,0);
part_type_direction(fire1,85,95,0,9);
part_type_gravity(fire1,0,270);
part_type_orientation(fire1,0,0,10,20,1);
part_type_blend(fire1,1);
part_type_life(fire1,60,80);
emitter1 = part_emitter_create(Sname);
part_emitter_region(Sname,emitter1,400,550,200,250,1,1);
part_emitter_stream(Sname,emitter1,fire1,30);
edit2: The fixes are in this commit: https://github.com/enigma-dev/enigma-dev/commit/2a914cc52a1f48379c14dc6b46b1b60ddd9e844c in this branch: https://github.com/enigma-dev/enigma-dev/tree/particle_fix
I didn't merge into master so people could test and see if it works and doesn't break anything else. Also, as I implemented draw_get_blend_mode* functions I wanted to know if anyone else has a better solution.
771
General ENIGMA / Re: LateralGM 1.8.5
« on: April 20, 2014, 06:30:58 am »
There is a bug with auto-complete. When you type a function (like draw_sp) and press Ctrl+Space and then Enter it will trow an exception (actually many exceptions, it will keep trowing them until I end LGM process). The bug is in the Enter part, because when I open the auto-complete window with Ctrl+Space and choose with mouse, then it works.
Exception - http://pastebin.com/YA3hcchF
Exception - http://pastebin.com/YA3hcchF
772
Issues Help Desk / Re: Are particles working in ENIGMA? Not for me !
« on: April 20, 2014, 05:02:50 am »Quote
Third, OGL3 seems to display the effects properly, snowflakes, flares, clouds, smoke, explosions, etc, however the annoying fuck of a thing clears all instances in the room and impossible to re-display them, even tried the draw_self and still does not work So this makes effects totally fucking useless lol!I think I know why that happens. GL3 now using shaders is mandatory (so we have our own shader that is used all the time), but extension system uses it's own shader and it doesn't set our shader back afterwards. It's actually easy to fix. But the rest probably would take some tinkering.
773
Issues Help Desk / Re: Are particles working in ENIGMA? Not for me !
« on: April 19, 2014, 03:43:21 pm »Quote
Also I recall the dev post stating it was completed and fully tested and on par with GM's........so I am confused.It was. It has all the features as far as I know and worked perfectly with GM's examples and games that used particles. But that happened some time ago (2012 and early 2013) and since then there has been massive changes in all graphics systems. That is probably why they don't work any more.
Quote
So with lights broken, 3d broken, particles broken, collision/path finding, and few others, what does it leave people to make ?That sadly is what happens when less than 2 people actually work on ENIGMA. And of course we also lack proper backwards compatibility testing, so when adding new stuff, old one usually breaks without knowing. So all the things you mentioned worked at one point or another, but when new stuff was added it all broke. Lights and 3D should work in GL1 just fine. They were also fixed in GL3, but that has not been merged because of some ATI bugs. Collision works as far as I know. And path finding also works, although we don't have path_start() working (as that allows modifying instance variables which are not possible via extension right now).
I actually encourage Robert to drop feature additions and start working on fixing things. That is why I haven't really added features for some time now. I rewrote GL3 (thought not completely), but it didn't add any features as that wasn't the point. Same with matrix function rewrite.
forthevin is the one who made the extension. Maybe he can look at the newest GIT master and fix it.
774
Issues Help Desk / Re: Are particles working in ENIGMA? Not for me !
« on: April 19, 2014, 09:35:33 am »
They were done at some point, but then became broken. They no longer work in all of the graphics systems. I would want the original developer of the particle system extension to fix that, but I am not use if that will happen.
775
General ENIGMA / Re: Unicode Fonts
« on: April 13, 2014, 10:54:30 am »Quote
string_length on UTF-8 is slow and extremely complicated to write correctly.Not any slower than actually drawing the text. Another reason I thought we should use classes is because then we could just add a .length member to the string and calculate it once when creating/assigning the string. It wouldn't make the "string_length("This is a string!");" any faster, but it would make faster cases when using variables.
Quote
The majority of GM and ENIGMA games don't need Unicode for anything but random symbols.And localizations.. you know, the main reason Unicode exists.
Quote
If you do want to use Unicode for other languages, GM's string interface is not the way to do it. An i18n interface would be better.How would i18n be of any benefit here? We need a way not only to store the strings, but to also draw them. Either way we need some kind of UTF encoding. We could include additional functions for easier localization of course. But that is besides the topic here.
776
General ENIGMA / Re: Unicode Fonts
« on: April 13, 2014, 07:04:52 am »Quote
No, they all work fine including the new string_length_utf8, GM Studio's on the other hand is still not working as of v1.3If by that you are implying to make a different function just for UTF-8, then that is exactly what I am afraid of. We DON'T need several functions for that. We should use UTF-8 everywhere and use one.
Quote
For the same reason we currently offer two overloads of string_length: one accepts const char*, the other accepts std::string. If all you have is const char*, then length is O(N), but does not necessarily entail a copy. If we only accept std::string, a copy becomes necessary, so now we're N in complexity and memory.And const char* is only possible in ENIGMA if explicitly used right? Like "char array[20]; string_length(array);"? Even though the code for "string_length(const char* str)" seems a little fishy. It doesn't seem to check end of line characters or anything like that. It just checks if the value is not null.
Quote
In order to have a utf8_string whose complexity is the same as std::string (which is completely possible), I must keep TWO strings. The first is a string of at most 4N characters, where N is the length in characters of the string; this translates to N bytes. The second string is of size_ts and denotes the byte of each character. So it'll usually look like ⟨0, 1, 2, 3, ...⟩ or ⟨0, 2, 4, 6, ...⟩ but will often be much uglier. Primarily where other languages use English (ASCII) punctuation.My idea was just to use UTF-16 or something which apparently has the best memory/speed tradeoff for most of earth's languages. But I guess it doesn't really matter. Most of the time (i.e. English) the complexity won't be large enough to cause real slowdowns. Maybe we could figure out a way to optimize that getUnicodeCharacter() though.
Quote
For your interest, I'll write the class. But I am disclaiming liability for slowdown from you two constructing one or more strings in addition to the simple ASCII strings you are usually asked to operate on.I guess there is no need for that. I just wanted a way to differentiate that all std::string's in our code is actually UTF-8 encoded. Because by default str::string isn't meant to be. Just the same way I don't want two versions of all string manipulation functions.
777
Announcements / Re: Heartbleed
« on: April 12, 2014, 06:11:42 pm »
With was is Josh actually going to work with if it's not a secret? Google is a large company, so just wanted to know what project/product/division you are planned to take part of? Even QA people have many divisions.
778
General ENIGMA / Re: Unicode Fonts
« on: April 12, 2014, 05:58:06 pm »Quote
I would offer to write a utf8 string implementation, but I'm afraid you two would start using it exclusively for everything.But why wouldn't we? I don't think using several encodings are a good idea. If we use UTF-8, then we should use it everywhere. Besides, all the normal std::string member stuff will not work either way. Things like string_length() probably already broke with that change. So we might as well have a custom implementation for it.
779
General ENIGMA / Re: Unicode Fonts
« on: April 12, 2014, 03:02:59 pm »Quote
I don't know, Josh didn't explain it thoroughly to me, ask him, all I know is that it does.Well, I now see how it "supports UTF8":
Code: [Select]
static uint32_t getUnicodeCharacter(const string str, size_t& pos) {
uint32_t character = 0;
if (str[pos] & 0xC0) {
character = (((uint32_t)str[pos] & 0x1F) << 6);
for (size_t ii = 1; ii <= 6; ii++) {
if ((str[pos + ii] & 0xC0) != 0x80) { pos += ii - 1; break; }
character |= (str[pos + ii] & 0x3F);
}
} else {
character = (uint32_t)str[pos];
}
return character;
}
If you do it like this, then you might even just use a vector<unsigned char> or char array[] as well. Or anything really. You just take all the bytes used for the char and add them together. I do have slight doubts about the efficiency though as a for loop per char isn't the best way to do things. But I guess the first IF short circuits the regular ASCII, so if you use the regular ASCII it will work basically just as fast as before.
780
Off-Topic / Re: Outcast Reboot HD
« on: April 12, 2014, 02:44:49 pm »
Well it's just hard to say from the stuff I have seen. The word "Voxels" have kind of lost the original meaning I guess. Like the Voxel Farm Engine doesn't actually use voxels for rendering as far as I know. They use it for the data and manipulations, but not the actual rendering. Because by that definition even Minecraft is a voxel engine, while in reality it isn't.
For me voxels are something that doesn't actually use polygons for rendering. That is why original Outcast was so cool. It was totally software rendered and didn't use polygon boxes as voxels. Voxels are more like ray-tracing.
So taking all of this into account I doubt they use voxels. I think they use voxels to represent data, but they don't use it for rendering. For rendering it's regular polygons.
For me voxels are something that doesn't actually use polygons for rendering. That is why original Outcast was so cool. It was totally software rendered and didn't use polygon boxes as voxels. Voxels are more like ray-tracing.
So taking all of this into account I doubt they use voxels. I think they use voxels to represent data, but they don't use it for rendering. For rendering it's regular polygons.
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 »