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 »
991
Issues Help Desk / ENIGMA exe bloat
« on: November 12, 2013, 03:53:29 pm »
ENIGMA's exported games hasn't been very small for a while now. But I noticed that since last few commits (in the last month or so I guess) an empty game (one empty room) with all extensions disabled and Audio-None, Widgets-None, Collision-None and GL-1.1 - I get 6.4mb. About a month ago it was about 3.4mb. So somebody really bloated the thing. I think we should take a look why it is like that. We should probably get it a lot smaller than 3.4mb as well.
GL1.1 - 6.4mb
DX9 - 5.8mb
GL3 - 6.4mb
GL1.1 - 6.4mb
DX9 - 5.8mb
GL3 - 6.4mb
992
Issues Help Desk / Re: Compiling on linux fails without error
« on: November 10, 2013, 11:17:26 am »
Not sure about CLI issues, but I am pretty sure the compile button should also be in Linux. If it is not (if no ENIGMA menu is present at all) that means the plugin didn't load correctly. That is an issue that should be looked at. What does output_log.txt says when you run LGM?
993
Announcements / Re: LateralGM Update
« on: November 10, 2013, 06:48:30 am »
Stretch it? I though you must scroll it. If the scroll is broken then that truly is a bug. Though it works for me. My screen is big enough for the event selector to be full height by default, but if I shrink it and then scroll it works fine.
994
Announcements / Re: LateralGM Update
« on: November 10, 2013, 06:35:21 am »
Yeah, Robert sadly does 1000 things at the same time and so very often things break. It's also our fault, as poly and me don't usually thoroughly test the commits before we merge. That is actually the point why Robert cannot merge to ENIGMA master directly. But I would really want that backwards testing though. I think forthevin was the one making it. Would be cool if he finished it.
Also, I do see draw event in that event selector. Don't get the problem there.
Also, I do see draw event in that event selector. Don't get the problem there.
995
Programming Help / Re: [Question] post-render Filters/FX
« on: November 10, 2013, 06:30:35 am »
I just tried some more shaders, but sadly they are still broken in 99% of the uses. We use deprecated stuff as GL hasn't been rewritten to use a manager and so even basic things are hard to make. Plus there are some bugs with texture binding I guess. Sadly all of this is going really slow as we still don't have that backwards testing one of the guys were making. That would ensure all the graphics systems work the same and don't break when new commits are made.
Anyway, I do have an example on how surfaces can be used for effects. The sun ray example - https://dl.dropboxusercontent.com/u/21117924/Enigma_Examples/sun_rays/sun_rays.gmk
As well as reflection example - https://dl.dropboxusercontent.com/u/21117924/Surfaces/reflections_surface.gmk
I tried to upload the rays example to EDC, but it seems it's broken, because of the transition to cloud storage. Dunno if anyone is still working on it.
Anyway, I do have an example on how surfaces can be used for effects. The sun ray example - https://dl.dropboxusercontent.com/u/21117924/Enigma_Examples/sun_rays/sun_rays.gmk
As well as reflection example - https://dl.dropboxusercontent.com/u/21117924/Surfaces/reflections_surface.gmk
I tried to upload the rays example to EDC, but it seems it's broken, because of the transition to cloud storage. Dunno if anyone is still working on it.
996
Programming Help / Re: [Question] Adding 2d blur/glow and other filters
« on: November 09, 2013, 06:04:31 pm »
Blur, chromatic aberration, reflections, displacements and so on can all be done purely with surfaces. But a more modern method (and a lot faster, but less compatible) is to use shaders. ENIGMA supports both methods. Of course when using shaders, you still have to use surfaces for these effects, but the end result will be a lot faster.
Tomorrow I will try to make a few examples on this. No promises.
edit: To save framebuffer, you need to use surfaces. Render to surface and then save a few frames. It will allow things like basic motion blur. But the results you can get via simple blending is.. well.. simple. Effects in Teleglitch were more complicated.
Tomorrow I will try to make a few examples on this. No promises.
edit: To save framebuffer, you need to use surfaces. Render to surface and then save a few frames. It will allow things like basic motion blur. But the results you can get via simple blending is.. well.. simple. Effects in Teleglitch were more complicated.
997
General ENIGMA / Re: SVG Graphics
« on: November 08, 2013, 11:45:39 am »
I think he meant as icons. With Qt you can have SVG icons for programs (on Linux). I don't think he wanted to load and draw SVG's as sprites.
Anyhow, if we do look at them as sprites, I don't think we should write it on our own. Seems like a pain in the ass... although supporting the very basic stuff like paths and basic shapes shouldn't be that hard.
We still need to finish batching in GL3 so it doesn't use any deprecated functions. Until that is done, I don't think we should indulge in this. Maybe someone can play with this as an extension at the start.
Robert, so you won't do that device manager for GL? Trying to replicate the one you did for DX seems like a pain for me as I didn't make it.
Anyhow, if we do look at them as sprites, I don't think we should write it on our own. Seems like a pain in the ass... although supporting the very basic stuff like paths and basic shapes shouldn't be that hard.
We still need to finish batching in GL3 so it doesn't use any deprecated functions. Until that is done, I don't think we should indulge in this. Maybe someone can play with this as an extension at the start.
Robert, so you won't do that device manager for GL? Trying to replicate the one you did for DX seems like a pain for me as I didn't make it.
998
Issues Help Desk / Re: Obsolete Functions in ENIGMA
« on: November 08, 2013, 07:09:15 am »
Short answer - No, ENIGMA will not have them either. ENIGMA's games are compiled (just like GM:S is now with YYC). That means we cannot easily create new objects and add code to those objects at runtime. That would require us to ship either a compiler or some kind of interpreter with the .exe. So these functions will probably never be implemented:
Code: [Select]
object_add
object_delete
object_event_add
object_event_clear
object_set_parent could be though. As parenting is done at runtime.Code: [Select]
variable_global_exists
variable_local_exists
variable_global_get
variable_global_array_get
variable_global_array2_get
variable_local_get
variable_local_array_get
variable_local_array2_get
variable_global_set
variable_global_array_set
variable_global_array2_set
variable_local_set
variable_local_array_set
variable_local_array2_set
These functions could be implemented (and some quick implementation were done before), but they would be relatively slow and memory consuming (as all variables would be stored in string form). None of them are actually needed though. If you make a new project, then you probably can make what you want without using these functions.
999
General ENIGMA / Re: SVG Graphics
« on: November 08, 2013, 04:35:49 am »
Linux (and also not all distros) is the only one that supports SVG icons. Linux rarely has icons at all (which is the main reason ENIGMA didn't have icons for such a long time). On Win/Mac you are meant to include and .ico which has sizes up to 256x256 32bit+alpha. That is large enough to have high quality in many sizes. But SVG support while drawing in OpenGL - that could be cool.
1000
Issues Help Desk / Re: Plugins don't appear to work
« on: November 07, 2013, 05:13:26 pm »
What were the errors exactly? Because I wasted a few days getting ENIGMA to work on Windows where it also couldn't load the plugin properly. It ended up being my Java installation. ENIGMA works only with 32bit Java. If you have 64bit JVM, then it will crash.
1001
Issues Help Desk / Re: Step Event code does not work?[solved]
« on: November 07, 2013, 01:12:42 pm »
Robert explained it, but I just wanted to add something.
So the correct way to use collision functions in ENIGMA is this:
Quote
It was returning true when it should have been returning false.It DOESN'T return true or false at all. It returns the ID of the instance with which it collided with or -4 (aka, the constant "noone") if it didn't collide with anything. It's just that in GM before GM:S anything <=0 was false and anything >0 was true. This is not true in C/C++. Just as Robert quotes - anything other than 0 is true. So -4, which was "false" in GM, is true ENIGMA. And so it is actually impossible for the function to return false if used like this:
Code: [Select]
if (collision_line(...))
This is basically as if you wrote:Code: [Select]
if (true)
Instances can't have an ID of 0 either, so it shouldn't ever have collision_line returning 0.So the correct way to use collision functions in ENIGMA is this:
Code: [Select]
if (collision_line(...)!=noone)
1002
Announcements / Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
« on: November 07, 2013, 12:54:44 pm »Quote
Shouldn't the draw_sprite_ext still include the simplest check to cut off cases where image is drawn without certain effects?It does not. This is current implementation:
Code: [Select]
void draw_sprite_ext(int spr, int subimg, gs_scalar x, gs_scalar y, gs_scalar xscale, gs_scalar yscale, double rot, int blend, gs_scalar alpha)
{
get_spritev(spr2d,spr);
const int usi = subimg >= 0 ? (subimg % spr2d->subcount) : int(((enigma::object_graphics*)enigma::instance_event_iterator->inst)->image_index) % spr2d->subcount;
texture_set(textureStructs[spr2d->texturearray[usi]]->gltex);
rot *= M_PI/180;
const gs_scalar w = spr2d->width*xscale, h = spr2d->height*yscale,
tbx = spr2d->texbordxarray[usi], tby = spr2d->texbordyarray[usi],
wsinrot = w*sin(rot), wcosrot = w*cos(rot);
const gs_scalar ulcx = x - xscale * spr2d->xoffset * cos(rot) + yscale * spr2d->yoffset * cos(M_PI/2+rot),
ulcy = y + xscale * spr2d->xoffset * sin(rot) - yscale * spr2d->yoffset * sin(M_PI/2+rot);
const double mpr = 3*M_PI/2 + rot;
const gs_scalar ulcx2 = ulcx + h * cos(mpr),
ulcy2 = ulcy - h * sin(mpr);
const gs_scalar r = __GETR(blend), g = __GETG(blend), b = __GETB(blend);
const gs_scalar data[4*8] = {
ulcx, ulcy, 0.0, 0.0, r, g, b, alpha,
ulcx + wcosrot, ulcy - wsinrot, tbx, 0.0, r, g, b, alpha,
ulcx2 + wcosrot, ulcy2 - wsinrot, tbx, tby, r, g, b, alpha,
ulcx2, ulcy2, 0.0, tby, r, g, b, alpha
};
plane2D_rotated(data);
}
This is also the behavior of GM (at least in GM8, which is the last one I have). There it also didn't matter if you rotated and scaled the sprite or if you just drawed it like it is. It actually didn't even matter if you used draw_sprite or draw_sprite_ext, as all of the sprite drawing functions were basically just wrappers for draw_sprite_general. At least speed difference is negligible.The reason for that though, I think was the fact it used DirectX8. In directx you draw a sprite with 1 line of code. And I think you could draw it scaled and rotated with the same line.
It's possible that when you are actually using these functions to draw rotated and scaled sprites, then the 3 if checks could potentially slow it down (if drawing hundreds and thousands of sprites). Anyway, the best would be to give the right tools for the right job. So in this case different functions for color blending and alpha.
edit: But I guess when we implement things like draw_sprite_color, then draw_sprite_ext could just short circuit to that or draw_sprite/draw_sprite_transformed. I think the speed difference wouldn't be that big.
edit2: I just noticed we do 2 cos(rot) and 2 sin(rot). Probably should change that.
1003
Issues Help Desk / Re: Getting an error from compiler I do not understand
« on: November 07, 2013, 12:27:21 pm »
That's the interpreters bug. It happens when you use things like local variables together with temporary variables. The bug I guess is on this line:
edit: We do have a quite cool (and fast) light engine here: http://enigma-dev.org/edc/games.php?game=62 . Maybe it works for you.
Code: [Select]
_lm_Light_radius = tempsize*max(_lm_Light_xscale,_lm_Light_yscale);
You could try this:Code: [Select]
_lm_Light_radius = tempsize*max(self._lm_Light_xscale,self._lm_Light_yscale);
Or this:Code: [Select]
_lm_Light_radius = tempsize*fmax(_lm_Light_xscale,_lm_Light_yscale);
Or this:Code: [Select]
_lm_Light_radius = max(_lm_Light_xscale,_lm_Light_yscale);
_lm_Light_radius *= tempsize;
I personally have this bug a lot. But I always manage to go around it. If you are porting something though, then it probably won't be as easy.edit: We do have a quite cool (and fast) light engine here: http://enigma-dev.org/edc/games.php?game=62 . Maybe it works for you.
1004
General ENIGMA / Re: Animated Portable Network Graphics
« on: November 04, 2013, 01:33:08 pm »
1) APNG is a "standard" for quite some time now. Whether people use it or not is another question.
2) Pain.net doesn't support APNG without a plugin. So I am pretty sure you have one. I use Paint.net 3.5.11 and I cannot save to APNG.
2) Pain.net doesn't support APNG without a plugin. So I am pretty sure you have one. I use Paint.net 3.5.11 and I cannot save to APNG.
1005
Announcements / Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
« on: November 03, 2013, 10:07:14 am »Quote
Default color being black is GameMaker behaviour. You could change it (which would totally make sense by the way), at a price of that small part of behaviour.Not necessarily small. This is partly discussed here and here. If we change the default color to white, then things like text will break and so on. So while it's possible, I am still not sure which will be better.
Quote
Also, if you're aiming for GameMaker compatibility, draw_set_color should not influence blending of sprites - it only applies to text and primitives in GMWe know that. That is the current behavior.
Quote
draw_set_alpha was made to apply to sprites in GameMaker: Studio, but that does more evil than good (in terms of introduced possibility to turn half of your sprites invisible with a forgotten alpha reset).This at least is a lot less likely to break compatibility, as the default alpha is 1. So 90% of the stuff should work with this change (probably the reason they did it). We could probably do that as well. The problem with color blend and alpha blend not influencing sprites and backgrounds is that we need to use _ext to draw them blended. The _ext has scaling and rotation too, which means if you just want to draw 0.5 alpha sprite, you suddenly have to use a function which has cosine and sine + other calculations which are not needed. I had an urge to add a lot more drawing functions just because of this (like draw_sprite_color), but I didn't.
So we need to decide how we are going to do this (which is why I made the topics). Of course for compatibility we should have this as an option as well. We have all these compatibility options though, which gets cumbersome. Maybe we need a "Simple" and "Advanced" - so "Simple" would just have a compatibility options where you choose the GM version you want to be compatible with - and "Advanced" would allow you to choose more detailed.
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 »