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 »
61
Works in Progress / Re: Croky
« on: November 17, 2015, 09:38:51 am »
I don't think that ENIGMA recalculates them. If you go to the sprite properties and check "Full Image" or if you manually enter large values then it works fine when compiled. So everything seems fine on ENIGMA side.
He is using gmk apparently (he posted on here and mentioned that he also compiles his game in GM), so it's not EGM issue.
He is using gmk apparently (he posted on here and mentioned that he also compiles his game in GM), so it's not EGM issue.
62
Issues Help Desk / Re: Extension .egm does not match EGM?
« on: November 17, 2015, 06:38:51 am »
There are a lot of other things wrong with GMX as well though, like the fact the tags and attributes are not consistent. You already pointed that out in the past and you have documented it here: http://enigma-dev.org/docs/Wiki/GMX_Format
So what I want is a clean, consistent, backwards compatible, future compatible and extendable format. Making EGM with YAML just because GMX uses XML is stupid at best. We already want to support new things like custom resources, includes in EGM, version control with an extracted format (EGX? And I know GM has GMZ here), reordering the resources with several different types in one folder and so on. I cannot do any of that without breaking GMX, which I don't think we need to use at all.
But YAML ain't the only thing - we need EEF as well, because e-YAML cannot save code. But I guess it wouldn't be that pretty in XML either.
Long story short - I still stand by XML because it's more standard then coming up with two of our own formats, even if one of them is a subset, which doesn't mean anything if we are the only ones who implement it.
But in the end I don't really care what you choose (like I mentioned previously), but at least remake the f-ing thing e-YAML+EEF so it at least doesn't break.
We also need a proper specification for EGM, because now it is very ad-hoc. We don't have version information in EGM, so if we do change something we cannot even differentiate. So it is very easy to break it. We also need a lot more delta checks there, so things that are default are not saved. Like every EGM saves an empty .rtf file (still 163 bytes) which in 99.9% cases are not used, because who the hell uses that information thing anyway. It was used during the age of examples back in 2005, but not today.
So what I want is a clean, consistent, backwards compatible, future compatible and extendable format. Making EGM with YAML just because GMX uses XML is stupid at best. We already want to support new things like custom resources, includes in EGM, version control with an extracted format (EGX? And I know GM has GMZ here), reordering the resources with several different types in one folder and so on. I cannot do any of that without breaking GMX, which I don't think we need to use at all.
But YAML ain't the only thing - we need EEF as well, because e-YAML cannot save code. But I guess it wouldn't be that pretty in XML either.
Long story short - I still stand by XML because it's more standard then coming up with two of our own formats, even if one of them is a subset, which doesn't mean anything if we are the only ones who implement it.
But in the end I don't really care what you choose (like I mentioned previously), but at least remake the f-ing thing e-YAML+EEF so it at least doesn't break.
We also need a proper specification for EGM, because now it is very ad-hoc. We don't have version information in EGM, so if we do change something we cannot even differentiate. So it is very easy to break it. We also need a lot more delta checks there, so things that are default are not saved. Like every EGM saves an empty .rtf file (still 163 bytes) which in 99.9% cases are not used, because who the hell uses that information thing anyway. It was used during the age of examples back in 2005, but not today.
63
Works in Progress / Re: Croky
« on: November 16, 2015, 06:22:43 pm »
Thank you for reporting!
1. Haven't been able to replicate this yet. Is this happening only sometimes? Or does it happen at certain time, like if the snail is very close to the character or something like that?
2. Can replicate. This is actually an LGM bug. If you open sWall2 you can see that the Bounding Box (which is by default used in collision checking) is 0,0,0,0 when set on Automatic. This is because LGM trows out all pixels which alpha is not 255, while GM probably does it only for alpha 0. I think the way GM does it is more logical. We could also add a slider or a box where you could input the alpha cutoff, but then it is hardly automatic. So this is a thing Robert can fix for next LGM release. Right now you can set Bounding Box to "Full Image".
3. This is also something Robert should look into. When does this happen exactly, or is it random? By default in room editor there is a checkbox "Delete underlying" checked. What it does is removes everything underneath the mouse when adding new object. Maybe this is the issue? Try unchecking it and see if still happens.
4. Can you post the error here? The current state of BasicGUI is totally different from what you are having because the installer is not updated. So it is possible the error has already been fixed. If you want (and know how) you can download the branch here: https://github.com/enigma-dev/enigma-dev/commits/GL3.3NormalMatrix . That is the very latest ENIGMA. Tens of bugs fixed, tens of optimizations and hundreds of functions added. And I can run your example in that branch fine as well. So I guess nothing has broken.
edit: Your game did reveal a bug in the tiling system though, which causes the GL3 graphics system to not render correctly. I fixed it here: https://github.com/enigma-dev/enigma-dev/commit/4eddce1683602b99c2260726a9df3a709fb4d888
Also tried texture batching in you example and found that tiled backgrounds currently don't work if batched. It is because the texture positions are precalculated. This same bug will apply in custom drawing functions as well. Will have to figure out good solution to that.
1. Haven't been able to replicate this yet. Is this happening only sometimes? Or does it happen at certain time, like if the snail is very close to the character or something like that?
2. Can replicate. This is actually an LGM bug. If you open sWall2 you can see that the Bounding Box (which is by default used in collision checking) is 0,0,0,0 when set on Automatic. This is because LGM trows out all pixels which alpha is not 255, while GM probably does it only for alpha 0. I think the way GM does it is more logical. We could also add a slider or a box where you could input the alpha cutoff, but then it is hardly automatic. So this is a thing Robert can fix for next LGM release. Right now you can set Bounding Box to "Full Image".
3. This is also something Robert should look into. When does this happen exactly, or is it random? By default in room editor there is a checkbox "Delete underlying" checked. What it does is removes everything underneath the mouse when adding new object. Maybe this is the issue? Try unchecking it and see if still happens.
4. Can you post the error here? The current state of BasicGUI is totally different from what you are having because the installer is not updated. So it is possible the error has already been fixed. If you want (and know how) you can download the branch here: https://github.com/enigma-dev/enigma-dev/commits/GL3.3NormalMatrix . That is the very latest ENIGMA. Tens of bugs fixed, tens of optimizations and hundreds of functions added. And I can run your example in that branch fine as well. So I guess nothing has broken.
edit: Your game did reveal a bug in the tiling system though, which causes the GL3 graphics system to not render correctly. I fixed it here: https://github.com/enigma-dev/enigma-dev/commit/4eddce1683602b99c2260726a9df3a709fb4d888
Also tried texture batching in you example and found that tiled backgrounds currently don't work if batched. It is because the texture positions are precalculated. This same bug will apply in custom drawing functions as well. Will have to figure out good solution to that.
64
Issues Help Desk / Re: Extension .egm does not match EGM?
« on: November 16, 2015, 07:16:40 am »
I cannot expand GMX without breaking it (which some will try to load in GM:S and fail). I actually don't have anything against it and it is very similar to what I think EGM should be - a zip file packing XML resource descriptors with custom (even binary) data, like images and sound. That is what DOCX is compared to DOC. And a lot of other formats are like that too. And EGM is basically the same thing, but uses a non-standard markup language (e-YAML and some other which I don't even remember) and binary room data. I want everything that can change between versions to be non-binary. I just don't see why we need to create two different markup languages (or in YAML case, an extension) just to save textual data? Historically it has always been good to not reinvent the wheel. Especially if nobody in this project finishes the things that they start (including me in many cases). So better is to use something existing so all of this could be fixed in 3 days, instead of making a new language for 3 years and never finish.
65
Works in Progress / Re: Croky
« on: November 14, 2015, 06:06:44 pm »
And that only happens on Windows? If it is a platform dependent bug, then it is an ENIGMA bug. But it's hard to imagine that something like that would be platform dependent (I assume you use some collision or math functions there, which are platform agnostic). Can you try making a simple example that you could post here replicating the bug? Right now it seems that the snail direction is not synchronized with the sprite direction (which probably uses scaling, not image_angle). This could be just a bug in your code.
I played it and it was fun. I also think level design needs to be rethinked so some kind of progression happens. Things like 10 coins in the same place is also usually not done unless it is a secret. Now you just reward the players for nothing - they have to earn it you know. Don't let them slack off. Liked the graphics though.
Also, what made you think windows needed "libwinpthread-1.dll"? As far as I know it doesn't and I just ran your game without it.
I played it and it was fun. I also think level design needs to be rethinked so some kind of progression happens. Things like 10 coins in the same place is also usually not done unless it is a secret. Now you just reward the players for nothing - they have to earn it you know. Don't let them slack off. Liked the graphics though.
Also, what made you think windows needed "libwinpthread-1.dll"? As far as I know it doesn't and I just ran your game without it.
67
General ENIGMA / Re: Splashscreens
« on: November 14, 2015, 05:04:20 pm »
Wait, Rusky said it's "too angular" and then he later suggested "more rectangular and less rounded"? Those two are contradictory. There isn't a single rounded corner in that image.
I like rcobra's too. But I guess adding the red color wouldn't hurt. So maybe take the robert's one, reduce size of the red LGM logo so it fits the rcobra's one and call it a day.
I like rcobra's too. But I guess adding the red color wouldn't hurt. So maybe take the robert's one, reduce size of the red LGM logo so it fits the rcobra's one and call it a day.
68
General ENIGMA / Re: Splashscreens
« on: November 14, 2015, 09:51:36 am »
Still liking this one:
I don't really care about the gamepad icon. I personally haven't made a game in ENIGMA in the past 3 years. But I have made tens of software applications.
Or even the original:
This one has a gaming feel to it because the buttons make the arrow keys.
And "too angular" doesn't seem like a negative thing. Good or bad design isn't based on angles.
I don't really care about the gamepad icon. I personally haven't made a game in ENIGMA in the past 3 years. But I have made tens of software applications.
Or even the original:
This one has a gaming feel to it because the buttons make the arrow keys.
And "too angular" doesn't seem like a negative thing. Good or bad design isn't based on angles.
69
General ENIGMA / Re: Splashscreens
« on: November 13, 2015, 02:05:26 pm »
I do like this one:
But I don't think it needs to be "gameish" because of two reasons:
1) ENIGMA isn't for games only.
2) Other game engines aren't using a screen like that either. I think it's because of the same thing - they cannot figure out something that looks good, is related to games, and isn't a pacman. Just look at unity (https://www.google.lv/search?q=unity+splash&biw=1920&bih=947&source=lnms&tbm=isch) or Unreal4 (https://www.google.lv/search?q=unity+splash&biw=1920&bih=947&source=lnms&tbm=isch#tbm=isch&q=unreal+4+splash). I remember years ago Unreal engine loading screen was a scene from Unreal 1 or something, but that is because it was very tied to that game. Now most engines don't want to add a specific gaming reference, because it is not limited to a specific game. If we add a packman, then most people would think we can only do 2D packman stye games.
But I don't think it needs to be "gameish" because of two reasons:
1) ENIGMA isn't for games only.
2) Other game engines aren't using a screen like that either. I think it's because of the same thing - they cannot figure out something that looks good, is related to games, and isn't a pacman. Just look at unity (https://www.google.lv/search?q=unity+splash&biw=1920&bih=947&source=lnms&tbm=isch) or Unreal4 (https://www.google.lv/search?q=unity+splash&biw=1920&bih=947&source=lnms&tbm=isch#tbm=isch&q=unreal+4+splash). I remember years ago Unreal engine loading screen was a scene from Unreal 1 or something, but that is because it was very tied to that game. Now most engines don't want to add a specific gaming reference, because it is not limited to a specific game. If we add a packman, then most people would think we can only do 2D packman stye games.
70
Ideas and Design / Re: LateralGM seems a little clunky overall, Ideas but not sure how to develop them.
« on: November 12, 2015, 09:24:49 am »Quote
I am really interested in working on this IDE again and adding the actual logic. But there's some things I have to straighten out first. With this new LGM release I am also writing the GMX API in C++, which is a reusable library for loading GMX projects. This is needed in NaturalGM, and C# can call native code, so I'd just use it instead of rewriting it again in C#.Forget GMX, do EGM.
71
Issues Help Desk / Re: Extension .egm does not match EGM?
« on: November 10, 2015, 07:14:47 am »
This is still an open question. EGM rooms are still binary and we need to fix that. I still vote for XML on how fast it is to parse and how "compact" it can actually be. Also, it is quite easy to implement and use. Josh's arguments didn't convince me and I think I gave good examples. But I don't have anything against e-YAML though. We already use it to save object data and we could use it in rooms as well. If this wasn't LGM side I would gladly do it, as I made an XML format for saving and loading in one of my projects and it was trivially easy.
I also added a function to e-YAML parser to return if a value exists, so we could do default values as well. Sadly LGM and the parser/compiler doesn't actually do this checking, so even by missing an optional value we get segfaults. I can fix the parser/compiler part, but not the LGM part.
I also added a function to e-YAML parser to return if a value exists, so we could do default values as well. Sadly LGM and the parser/compiler doesn't actually do this checking, so even by missing an optional value we get segfaults. I can fix the parser/compiler part, but not the LGM part.
72
General ENIGMA / Re: Splashscreens
« on: November 08, 2015, 08:52:20 am »Quote
And back at rcobra's, I think it's a lot more fitting than the Adobe one, and tbh, I don't actually like Adobe's, I think he made something much nicer for LateralGM. The Adobe one is just a wall of text and horrible colors. I like Harri's modification as well, but it still needs something like a vignette to distinguish it from the desktop and other windows. That said, I was already considering dropping the progress bar, ideally the program would load instantly, but I am not sure yet if we want to drop the progress bar or not. It still does give you an idea if you are halfway or a quarter of a way there, though progress bars are, as usual, never accurate. They can be more accurate when weighted or using monte carlo approximations.Adobe uses a small drop shadow to distinguish and it's not that it totally blends together or something. Also, uses percentages, which will be as inaccurate as the loading bar, but will represent the same information just in text.
My idea is this:
And when combined with a desktop:
Of course it can be any of the proposed images. I am just demonstrating what was meant with transparency and drop shadows. I don't think vignette or gradient is needed in this case. And I actually like this flat look more. I guess because Win8, Win10 and lots of new styles like Material as using that. Just got used to it.
Also, what about a loading screen for when ENIGMA is installed? Can it be done or is the plugin loaded after LGM?
73
General ENIGMA / Re: Splashscreens
« on: November 06, 2015, 07:42:57 am »
I see where you got the idea:
But even so I like that and wanted to show the Adobe loading screens as a reference myself. We should change it so it isn't so blatantly obvious, but I think something similar is a good idea. For example the white parts could be transparent. This blending with the desktop can be very cool looking.
Like my 3min attempt:
But even so I like that and wanted to show the Adobe loading screens as a reference myself. We should change it so it isn't so blatantly obvious, but I think something similar is a good idea. For example the white parts could be transparent. This blending with the desktop can be very cool looking.
Quote
No specific dimensions, the splashscreen adapts the progress bar, but I'd say a power of two is a good recommendation, but that's not absolutely necessary. Transparency is allowed, but I generally prefer a flat rectangular look personally. Only thing to note about the transparency is that there is still the progress bar that fills the width at the bottom, and it takes the look of the current look and feel, so it may look native or like something else.Do we really need a loading bar? How about just showing what is loading? This is how it is done for Adobe, or MS Office software and I like that.
Like my 3min attempt:
74
Issues Help Desk / Re: Is Mario Isometric supposed to play music in the background
« on: November 02, 2015, 04:54:41 pm »
I have tried it and the reason why it doesn't play music is because it is in an unsupported format. By default our OpenAL system plays flac, wav, ogg and mp3. But it doesn't play Midi which the background music is in. So conversion of the music is needed.
On Windows you could select DirectSound as the sound system and it does support Midi and Mp3, but it seems that it is broken. It crashes on sound load. I will maybe try fixing it later, but it ain't my priority.
On Windows you could select DirectSound as the sound system and it does support Midi and Mp3, but it seems that it is broken. It crashes on sound load. I will maybe try fixing it later, but it ain't my priority.
75
General ENIGMA / Re: What Java version do you use?
« on: November 02, 2015, 05:20:47 am »Quote
Yeah that's probably because of things I mentioned. I know JavaFX was pretty buggy too from experience in the first 8u45 release. Eclipse is even being affected by these Swing changes, so yeah. And like people are saying, it's most likely to occur where you are doing undefined things by the API. So I think a lot of those are going to creep up and break if they haven't already.Yeah, but I said its more STABLE, not UNstable. I couldn't get from that paragraph if you understood me or not.
I did notice the external image editor bug, but found that it works again if you close the sprite properties window and open again. It wasn't that big of a deal if you knew this workaround but I'm glad it is now fixed.
And thanks for all the changes and fixes. Do you also included the changes from the other contributors? Like the selection box thing in room editor? Because we sadly didn't make a new LGM release after those were added which made some contributors feel their work not being appreciated.
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 »