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 »
916
Developing ENIGMA / Re: New feature: Complex Polygons (review requested)
« on: January 18, 2014, 02:40:50 pm »Quote
I've pushed a fix, and tested it on Linux & Windows.I will pull that for now, but I think Josh will have something to say about that fix. That is what I mean with "hackish" while I wanted "non-hackish".
917
Developing ENIGMA / Re: New feature: Complex Polygons (review requested)
« on: January 18, 2014, 02:38:01 pm »
I know that forthevin worked on that. At least I think he did. Someone was working on a python and Jenkins thing and had it hosted in github. The cheeseboy thing is different, but I guess it does the same thing.
918
Developing ENIGMA / Re: New feature: Complex Polygons (review requested)
« on: January 18, 2014, 02:12:48 pm »
Lack of regression testing is to blame. We don't test any pull requests, including yours.
edit: Robert, you batchers seem to break calling _end() right after _begin() (thus not adding vertices). That makes stride=0 and that makes division by 0 SIGFPE. For a quick fix I just added "if (vertices.size() == 0) return;" in End(). If it breaks something then you can make any appropriate fixes.
edit: Robert, you batchers seem to break calling _end() right after _begin() (thus not adding vertices). That makes stride=0 and that makes division by 0 SIGFPE. For a quick fix I just added "if (vertices.size() == 0) return;" in End(). If it breaks something then you can make any appropriate fixes.
919
Developing ENIGMA / Re: New feature: Complex Polygons (review requested)
« on: January 18, 2014, 11:44:37 am »
Okay, so I made that change to "__stdcall" so it compiled on Windows. Then you made a change for it to compile on Linux by changing it to "CALLBACK". But that again broke in on Windows. That is why we need regression testing. This is the error (just like the one before):
Quote
In file included from Graphics_Systems/OpenGL1/../General/glew.h:1169:0,Here is the full: http://pastebin.com/sqsuC5kb . This is the glew definition:
from Graphics_Systems/OpenGL1/../General/OpenGLHeaders.h:22,
from Graphics_Systems/OpenGL1/GLstdraw.cpp:20:
c:\mingw32\i686-w64-mingw32\include\gl\glu.h:78:15: error: initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum, void (__attribute__((__stdcall__)) *)())' [-fpermissive]
void APIENTRY gluTessCallback(GLUtesselator *tess,GLenum which,void (CALLBACK *fn)());
^
Graphics_Systems/OpenGL1/GLstdraw.cpp:227:76: error: invalid conversion from 'void (*)()' to 'void (__attribute__((__stdcall__)) *)()' [-fpermissive]
gluTessCallback(tessObj, GLU_TESS_END, (void (CALLBACK*)(void)) glEnd);
^
Code: [Select]
#ifndef CALLBACK
#define GLEW_CALLBACK_DEFINED
# if defined(__MINGW32__) || defined(__CYGWIN__)
# define CALLBACK __attribute__ ((__stdcall__))
# elif (defined(_M_MRX000) || defined(_M_IX86) || defined(_M_ALPHA) || defined(_M_PPC)) && !defined(MIDL_PASS)
# define CALLBACK __stdcall
# else
# define CALLBACK
# endif
#endif
So it seems that on mingw it is defined as "__attribute__ ((__stdcall__))" and not "__stdcall". Any non-hackish ideas how to fix this? For now I just comment out the functions, but we should fix, so people can actually compile on Windows out of the box. If I just add this to the top of the code:Code: [Select]
#define CALLBACK __stdcall
Then of course it works again. But then I think I override that previous declaration. Maybe we can just define our own. On Linux it can be empty and on Windows it should be __stdcall. Also, the functions do work, but they crash when drawing certain shapes.
920
Issues Help Desk / Re: GM8.2 and GM7 files not compiling - all fail at the C++ level
« on: January 17, 2014, 03:34:56 pm »Quote
It might never be fully compatible to import over your projects but at least if it was compatible one could re-write the games directly in ENIGMA.That is actually an important point - Yes, you won't be able to run most GM games without modification as there is too many differences between the two projects now. ENIGMA wasn't meant to be a GM clone, but an augmentation. And yes, you can re-write all those game in ENIGMA and make them work. I have done that for several of my projects just fine. ENIGMA has everything you need, but you just need to know how to use it properly. Right now it just isn't as friendly as GM (as we have things like data types among other changes) and might never be. But it is and will be faster, use less memory, have smaller binaries and so on. The rest of your post was non-guided rant.
Quote
What the fuck happened with your team then When I first came to your wee site, you had an extensive dev team and it looked promising, then it seemed to stall like a bloody train wreck. What went wrong ??There has never been "a team". And never an extensive one. At most about 3 people work on the project at any given time as it is a hobby, nothing more. I for example was a big contributor about 2 years ago, then I didn't have time. Now I made big changes about a month ago. And will probably start making changes month in the future. This is not a job for any of us. It's a learning experience and a hobby.
921
Issues Help Desk / Re: GM8.2 and GM7 files not compiling - all fail at the C++ level
« on: January 16, 2014, 05:35:06 pm »
Have you tried looking in the object_player collision event to see if the D&D is correct? The error seems to indicate that closing bracket is not added. ENIGMA could be more strict syntax wise than GM in this regard. Like in D&D this could work in GM:
Code: [Select]
IF
variable1 == true
{
variable2 = false
else
variable2 = true
}
In ENIGMA it may need it to look like this:Code: [Select]
IF
variable1 == true
{
variable2 = false
}
else
{
variable2 = true
}
This can probably be fixed if you can give a simple example.
922
Off-Topic / Re: What is a good programming language to start off with?
« on: January 15, 2014, 07:49:53 am »Quote
if a 12 year old can learn Basic and C# anybody canBut that is not for everyone. Some 12 year old's learned assembler (and some 7 year old's as well) - does that mean everyone can? Some people (in my experience most) cannot even install Windows. The average person needs something easy to start with, and GML is by design easier than many other languages. This is actually truer for older people, as a 12 year old could actually grasp new things quite easy, but if a person starts coding when he is 20, then it ends up a lot harder.
Quote
you are talking to the person (me) who argues that all programming languages are fundamentally the same.They are fundamentally the same. I am arguing the same thing. But they are not the same to learn and use. That is why I think learning GML did teach me the fundamentals a lot easier than learning C# (which I sadly will probably end up learning even though I don't want to).
Quote
for god sakes it has 1 data typeAnd that actually makes it more like C++11. Having 1 data type is also extremely important aspect why GM was so easy to learn and use. Yes, it does bring down performance (just like immediate mode drawing), but it does make it more understandable for new users. There is a reason why GM tutorials start with drawing a moving sprite, while C++ tutorials start with "Hello World!" inside a black console. It's because drawing a moving sprite in GM is even easier (to both do and understand) then drawing text in C++.
Quote
In fact most code you find is simply calls to existing built-in functions, most of GML is very very low-levelThis is a little contradictory because using built-in functions is usually higher-level. But I get your point. This is true for almost 99% of functions in 99% of languages. You think when you draw printf() you do something extremely low-level? It is a premade function and it calls other premade functions. But I also agree (and previously said) that the style GML is structured is quite low-level. And I also think this mix between easy to use and being low-level is why it is so good to learn.
Quote
This is the number one thing that you are completely missing and are completely wrong about.I am not missing anything, because you KEEP AGREEING WITH ME.
Quote
Harri it would not be 1 function to make a GUI label, you would still have to call draw set font vs just creating the label object where you want it, setting the font, and letting it be.I previously didn't use font function also in your label example to just show how easy it is to use one vs the other. If we use font setting it still is 2 functions for GML style and 5 functions for label style.
Quote
Even more complex code would be needed for a button such as handling inputAnd this is exactly what I have been saying for 2 pages now. Yes, in GM you have to do these things yourself and that is why it teaches you a little more. But the best thing is that even though you have to code this manually, it takes only a few lines of code. And if you don't want to repeat code you use scripts. This is what I was saying previously.
Quote
there is a reason why every other game engine handles GUI stuffThe reason is because IT IS more optimal. We already discussed this. This label type thing allows better memory management and better rendering (as you can batch all labels once and then render). And it was exactly my point I made previously (in the several posts in which I mentioned GL1/GL3). So you still keep saying the same thing I keep saying.
Quote
Basically what it boils down to for me is that you should use a tool suited for what you want to do and your experience level which means that I think GML is a good start.And I agree. If there wasn't ENIGMA I would still use GM, because I could create everything I need it in. Everything from CS:S HUD editors (http://css.gamebanana.com/tools/4483 which was create in about 1 week originally. No longer works because CS:S changed and because I used my server for auto-updates which is now offline. Was to lazy to update) to circuit drawing programs (https://dl.dropboxusercontent.com/u/21117924/22.03.2011_Day30_%28DevDayMaybe13%29.png, which was create in about 13 days). And GML did help me understand C++. I also agree with your bottom-up learning model as that is how I learn all programming languages. I have a project and I program. When I stumble on a problem, I try to fix it (by myself or by google) and that is how I learn new things. While reading a book once could be useful to understand the internals, I don't think that it is a practical way to learn.
923
Issues Help Desk / Re: Sprite font not displayed properly
« on: January 14, 2014, 07:16:27 am »Code: [Select]
draw_set_font(fnt);
draw_text(0, 0,
"!!!!!!!!!!!!!!!!!");
How do you just bind sprite as a font? You need to use the newly implemented draw_text_sprite (I haven't tested that function though) or we need to implement/fix font_add_sprite function. I will also pull the newest commit and try a sprite font. Usually a bug like that showed by Robert is when a) Batcher didn't change the texture before drawing or b) The texture is just non-existent.
924
Issues Help Desk / Re: Sprite font not displayed properly
« on: January 13, 2014, 03:19:04 am »
Could we get the font?
I think this is because we still don't do texture atlasing. This means every frame of every sprite is an individual texture. That of course screws things over in both terms of size and performance. The rendering bug could be because of texture interpolation.
I think this is because we still don't do texture atlasing. This means every frame of every sprite is an individual texture. That of course screws things over in both terms of size and performance. The rendering bug could be because of texture interpolation.
925
Off-Topic / Re: What is a good programming language to start off with?
« on: January 12, 2014, 12:44:58 pm »Quote
GM did not help me learn programming in the slightestAnd this seams very subjective for me. Of course there is no one way to learn programming, but saying GM is bad because it didn't help YOU isn't a good argument either. It did help me. GML was the first programming language I used (did see some Basic code a short while before, but didn't code anything in it) and I didn't use any other language for about 7 or 8 years. Then when I went to university I started using C++ and I found that it's mostly GML. Then I used different languages as well and in the end GML was stepping stone more for me. GML really looks like every language ever - because it has the most relaxed syntax ever. You can write GML that looks like C, you can write GML that looks like Delphi, you can even write GML that looks like python. So for me it helped a lot. Others (especially nowadays) say that Python is something people should start with, and I kind of agree as it is very easy and powerful, but I do dislike it more than GML. I think transition from GML to C (and to C++) is a lot easier than transitioning from Python to C. But I guess all of that is subjective.
Quote
That whole paragraph goes against everything we just discussed with you still not directly debating any specifics.Because I already said the specifics. Like the past 6 posts is how I say that GM is easy to learn and use - and most probably because the code for rendering is more like immediate mode than retained mode. You then disagree that it is, but then say exactly the same thing I do.
Quote
Take for instance the GUI functions I've wanted to add since I got here, something like the following...And? You do know that we already discussed this. I already agreed that GM doesn't have these functions and it does everything in immediate mode - and that means it is a lot more straightforward and easier to learn/use. Like with your functions it can take 4 functions to draw text on screen (create, position, set text, destroy) and while it is good for performance, it is easier for a total noob just to use draw_text(). That is exactly my point and you just keep pointing it out while mysteriously disagreeing.
Quote
I really really feel you are being biased here Harri.I don't think I am. I might be, as the biased one is not usually the one to notice. I don't think I am biased as I (and you) already pointed out everything I wanted to say together with arguments and examples. Also, all of this is mostly subjective. We can analyze it objectively (like I tried to do it here by counting how many functions it is need to do something), but mostly it is subjective.
926
General ENIGMA / Re: Mike Dailly Blog Stuffs
« on: January 11, 2014, 08:40:24 pm »Quote
I don't believe that, because in theory that sounds like a great idea, but in practice it would screw up depth ordering.It wouldn't. I pretty sure what he describes is meant to be in depth order. So of course changing depths will cause more flushes, but it wouldn't break anything. This is actually what we are doing in GL3 tiles right now. Only one model is made, but then rendered with different textures when textures change. So it can cause 50 render calls if you change 50 times between even only two textures. Right now we sort tiles by background id before rendering (and THAT breaks depth ordering), but that can be removed if needed. Good read though actually. Will probably read the whole posts where he describes all the stuff from 2009 to now.
927
Issues Help Desk / Re: Box2D Simulation Example Not Working
« on: January 10, 2014, 07:16:19 pm »
By Robert's report (the guy who uploaded that) these problems is because Box2D engine implementation was changed in ENIGMA, but right now updating in EDC is broken (or just non-existent). So as we now store files in cloud (on the server), then we cannot easily update them without some kind of interface which was never made. Previously EDC just linked to dropbox or whatever and then it was easier. So someone should finish EDC or at least make this feature a reality.
928
Developing ENIGMA / Re: GM5 Compatibility plugin --feedback requested
« on: January 10, 2014, 09:15:55 am »
Things like draw_polygon*() seem to be exactly like draw_primitive*(), so I don't think we should include them in main. That will only confuse people, as they will start using functions that are from 2002 and clearly shouldn't be used. So while I am ok for this being a plugin (and disabled by default) I think that only few functions (like draw_text_sprite) should be added in ENIGMA's main.
Quote
I feel like a lot of GM users won't even consider ENIGMA unless they can Load+Run an existing game.Yeah, but we don't really target the GM5 crowd (from which you are the only known person that I know). Originally we wanted ENIGMA to be something where you Load and without modifications Run an existing game. But as it is not even possible in GM (when a GM version changes) then we kind of abandoned the idea. We want the modifications to be quite minimal (like GM8 games will probably work without any changes in ENIGMA), but supporting deprecated functionality is no longer our goal. That will only bloat the engine and will make users accidentally use the deprecated functions. I think ENIGMA should be used just like GM - from the game's projects beginning. So instead of trying to load a GM game and then fighting with incompatibilities or bugs, people should just try code from scratch in ENIGMA. I do that all the time and that is why I think ENIGMA is mature enough, as I can create everything I could in GM with ENIGMA. And even more.
929
Off-Topic / Re: What is a good programming language to start off with?
« on: January 08, 2014, 05:29:36 am »Quote
I thought you were Aussie?No, I'm not.
Quote
The argument you're making though is equivalent to this.My argument is that the person here wanted to learn a programming language. Not a tool. That means he wants to start with something which actually requires programming. Like PyGame or some Javascript based thing. Or GM/ENIGMA. And yes, knowing assembly is also very useful as it gives you understanding on how your code works (that is why every CS class I know teaches it). You end up knowing what creates branches, cache misses and so on. And then you can code stuff more optimally. No one has to code anything in assembly though. Just like I wouldn't actually make a game in PyGame, but for learning it would work fine.
Quote
Every part of GM's design is wrong, and ENIGMA only partially corrects some of the issues, but that doesn't change the fact that the whole concept is just fucktarded.I guess that depends on perspective. I do think, and I doubt I will see anything that changes my made, that GM design is the best, user friendly and one of the productive (even when you have to code everything yourself) game design tool I have ever seen. That is why I still use and develop ENIGMA. It's very easy to learn, very easy to use and when you know enough, it takes minutes (yes, minutes) to create what you want. I have lots of programming tasks at university and if I used anything other than ENIGMA it would take probably a week per task. Now it takes about a day max. So the concept is awesome. It's hard to make it work very fast on hardware as it is more immediate mode than retained mode, but I guess that is one reason it is so easy to learn. And for 2D games the performance is in spades.
930
Issues Help Desk / Re: Catch The Clown example compilation failing [SOLVED]
« on: January 08, 2014, 05:17:28 am »
I already had the feeling yesterday that this was the problem, but when he said he tries to run "Catch the Clown" I assumed he tried the finished example. And in that example resources are named properly, so I though this could actually be an ENIGMA issue. Turns it out wasn't.
And yes, adding prefixes (as opposed to postfixes) like spr_, bkg_, scr_, obj_, rm_ and so on are the best way to do this. I would actually love if LGM would do it automatically and not even allow using resources without it, but I guess we need to have GM compatibility. And others maybe like to name their resources differently, but this freedom clearly leads to problems.
And yes, adding prefixes (as opposed to postfixes) like spr_, bkg_, scr_, obj_, rm_ and so on are the best way to do this. I would actually love if LGM would do it automatically and not even allow using resources without it, but I guess we need to have GM compatibility. And others maybe like to name their resources differently, but this freedom clearly leads to problems.
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 »