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 »
1501
General ENIGMA / Re: Enigma and the Liberated Pixel Cup competition
« on: June 26, 2012, 10:43:57 am »
Yes, ENIGMA is totally free.
And when you compile a game you can get its binary. Don't know how it works on Linux, but on windows its in temp folder. Sadly, ENIGMA can't output 100% clean (without console and with icon) binaries and I don't know when or if it will change. Icon problem was because of winres (which is apparently fixed) and console window problem is because of wrong settings in makefile.
And when you compile a game you can get its binary. Don't know how it works on Linux, but on windows its in temp folder. Sadly, ENIGMA can't output 100% clean (without console and with icon) binaries and I don't know when or if it will change. Icon problem was because of winres (which is apparently fixed) and console window problem is because of wrong settings in makefile.
1502
Announcements / Re: Parser Progress
« on: June 17, 2012, 08:42:12 am »
That sucks, as there is almost no one here who knows LGM insides at all.
1503
Announcements / Re: Parser Progress
« on: June 16, 2012, 06:36:15 pm »
Good to hear. I would want to work on ENIGMA as well, but I need to present my thesis next week, so I will not be able to do anything until that is finished. I was thinking maybe fixing some window problems, like full screen while switching rooms.
Also, tried gource'ing the ENIGMA GIT and it was pretty funny seeing how since 2009 this project has been rewritten from scratch a bazillion times.
Also, tried gource'ing the ENIGMA GIT and it was pretty funny seeing how since 2009 this project has been rewritten from scratch a bazillion times.
1504
General ENIGMA / Re: Linux and Windows Mobile Enigma
« on: June 15, 2012, 05:32:43 am »
Half of the developers use Linux as their main platform, so yes, ENIGMA works on Linux, Mac and Windows.
And no, nobody has tried (as far as I know) compiling for windows mobile. There have been tries to compile for Android and IPhone/IPad, but no real progress on that front. If someone was able to create a basic working system then I would be able to create all of the drawing functions. Other functions should work fine as is.
And no, nobody has tried (as far as I know) compiling for windows mobile. There have been tries to compile for Android and IPhone/IPad, but no real progress on that front. If someone was able to create a basic working system then I would be able to create all of the drawing functions. Other functions should work fine as is.
1505
Issues Help Desk / Re: Path trouble
« on: May 23, 2012, 02:46:44 pm »
And using this code:
Code: [Select]
static inline double blen(const path_point* p0, const path_point* p1, const path_point* p2)
{
double x1=p0->x, y1=p0->y,
x2=p1->x, y2=p1->y,
x3=p2->x, y3=p2->y,
length=0,/*lx=0.5*(x1+x2), ly=0.5*(y1+y2)*/lx,ly,x,y;
double t=0.5;
lx = 0.5 * (((x1 - 2 * x2 + x3) * t + 2 * x2 - 2 * x1) * t + x1 + x2);
ly = 0.5 * (((y1 - 2 * y2 + y3) * t + 2 * y2 - 2 * y1) * t + y1 + y2);
t+=0.05;
for (int i=0; i<=19; i++){
x = 0.5 * (((x1 - 2 * x2 + x3) * t + 2 * x2 - 2 * x1) * t + x1 + x2);
y = 0.5 * (((y1 - 2 * y2 + y3) * t + 2 * y2 - 2 * y1) * t + y1 + y2);
length += hypot(x-lx,y-ly);
lx = x, ly = y;
//std::cout << "i: " << i << " t: " << t << "length: " << length << " x: " << x << " y: " << x << " dx: " << dx << " dy: " << dy << std::endl;
t += 0.05;
}
return length;
};
You can get correct lengths for points when in straight line, but this is still not correct, because lengths for curved path is still wrong (by as much as 200 pixel difference between GM and ENIGMA for a simple path). I still don't have time to do this right now, so I will have to postpone it. Maybe you will be able to figure this out.
1506
Issues Help Desk / Re: Path trouble
« on: May 23, 2012, 01:44:15 pm »
The reason I posted previously. Look at the picture, there you will see where the length is calculated. I have made some changes and for a straight line the length is calculated correctly, but I still have problems with returning the correct 24pixel length. It is a lot closer now though.
1507
Issues Help Desk / Re: Path trouble
« on: May 23, 2012, 12:04:37 pm »Quote
And it's nothing to do with the total path length, you're multiplying back by that in the t value so it doesn't matter.Not the total path length, but the length of each segment.
Quote
The smoothing doesn't affect the path between these points at all.The short answer is that it does affect it.
Quote
fourth-order equationThen it will not look like interpolation used in GM.
The length itself is actually correct (that is why total length is correct as well), but the "distribution" is wrong, in that point 0 has length non-zero while in linear paths its correct (zero). The problem is that the quadratic bezier spline does not start or end at the points, but between them. Here is a picture I made in last august for Josh:
https://www.dropbox.com/s/cth3rda3lh0q8na/path_interp.png
I will look into some methods on how to fix that.
1508
Issues Help Desk / Re: Path trouble
« on: May 23, 2012, 02:53:23 am »
Looking at the example I must say that it is normal. I didn't think you have a path that is so long. On very long paths this difference is a lot bigger. If you make it go around the path at constant speed, then you will see that it will slow down at times and go faster at other times, that is what creates this error. Me and Josh were not able to fix that problem, as theoretically (mathematically and code wise) everything should be fine. Maybe I will look at it again at some point. Basically, the problem arises (I think) from wrong length calculation. I need to calculate the length of each segment and then divide by total to get the position on where one segment ends and another begins, and while I tried 3 different algorithms for that (which returned almost the same values) I still was not able to fix that problem... maybe the problem is somewhere else then. I won't have time to look into this for a few weeks now (need to do my thesis).
edit: Poly, the "precision" thing I used and you as well in functions like path_get_direction should probably be like 1/path_get_length, because now if the path is very long then it could return wrong number. Although 0.0005 seems reasonably small.
edit: Poly, the "precision" thing I used and you as well in functions like path_get_direction should probably be like 1/path_get_length, because now if the path is very long then it could return wrong number. Although 0.0005 seems reasonably small.
1509
Issues Help Desk / Re: Path trouble
« on: May 21, 2012, 06:35:06 pm »
Not sure what you mean. Position argument in get_x function should be from 0 to 1, so I am not sure why you do 24/get_length. Maybe make an example? I know that there are some problems with get_x and get_y functions (they don't match GM's exactly), but the difference shouldn't be that big.
1510
Issues Help Desk / Re: Path trouble
« on: May 21, 2012, 08:36:03 am »Quote
surface_destroy (which is missing)Its called surface_free in both GM and ENIGMA. It was briefly called surface_destroy() in ENIGMA (until I found this mistake). If you want, then you can create a macro or a wrapper so you can use surface_destroy() as well, but I think we should standardize and use one whenever possible (this case _free, for compatibility with GM). We could also add both functions, but document only _destroy() and leave _free() undocumented for GM compatibility.
Quote
path_get_positionAnd what would it return? The 0-1 position on the path? But path_position is part of the object struct you created, so you might as well create the function. I don't use or save any variables between frames, so I don't have any "position" I could return.
1511
Issues Help Desk / Re: LGM standalone game not running!
« on: May 18, 2012, 07:19:47 am »
ENIGMA currently only has C++ port, and as one, can't run natively in a browser like HTML or Flash. HTML5 for ENIGMA was briefly in development, but it made no real progress and stopped so the developer could concentrate on the main project.
1512
Announcements / Re: Windows GIT patch
« on: May 15, 2012, 04:16:06 pm »Quote
However, for a time-intensive operation, adding global will only need to perform the check once, rather than every time.Wouldn't you need to check the global every redraw anyway? Like what Poly just did with GLEW_EXT_framebuffer_object.
Quote
It's fine I've sorted it. This is getting far too over-discussed it's beyond trivialThat is not the most elegant way, but I also can't think of anything better. Also, you declare "int FBO;" twice, so I don't know why it doesn't error at compile time for you. Also, I am glad someone got around making the paths part of instances. I doubt its working right now because you don't execute path_update() anywhere yet (also, the path_update function doesn't have the position calculations in it anyway), but at least its moving forward.
1513
Announcements / Re: Windows GIT patch
« on: May 15, 2012, 01:17:54 pm »
Adding global will not change anything much as you still need to do the if check somewhere. And you can't ifdef it as you still can compile the project even when you don't have it supported and give it to others who have FBO support and they can run it fine. And if I compile a project where I use surfaces and you run it on a PC which doesn't have FBO support it will still flip the screen. So we need to do real time if checking either way. Maybe creating the global variable static would make the compiler to compile the tertiary operation as static as well, like true?0?1 would optimize as 0 no? But it can only do that at compile time, so again, same problem. But this is the worst case (and only for now) scenario to fix this:
Code: [Select]
glScalef(1, (surface_is_supported()?(FBO==0?-1:1)?-1), 1);
1514
Announcements / Re: Windows GIT patch
« on: May 15, 2012, 10:18:55 am »Quote
Did all the systems you test it on have fbo support? The fact that I don't might be the underlying problem.Ah, yes. I didn't know there existed PC's without FBO support, but that could certainly be the problem. I tested it on all PC's and friends PC's I know (oldest is about 6-7 years old PC) and all of them support FBO's so I didn't notice any problem. Adding additional check inside the redraw function would make it unnecessarily slower... I don't really know what to do then. Maybe Josh has an idea? Theoretically using surface_is_supported() shouldn't be that big of an impact, but I am not sure. Does surface_is_supported() return 0 on your PC Poly?
Quote
Here is a compiled game:Yes, it looks fine. So its your cards lack of GL support.
Quote
While on the subject of surfaces did you ever look into pbuffer for surfaces at all? I'm looking for an alternative for those without fbo support, of course directX is also an option.pbuffers are old (out of date), a lot slower (on newer hardware) and more limited. If you want to make a directx port then go ahead. I have never done anything with it, so I don't know anything about it.
1515
Announcements / Re: Windows GIT patch
« on: May 15, 2012, 04:49:48 am »Quote
. I'm going to change it back to how it was in my next commit.And I will change it back, as that will just break surfaces when using screen_redraw(). The problem is something on your end, and I will maybe try the other gl check and send it to you so you can see if that helps. I have ran that code with surfaces on 2 PC's (one of which is laptop), and without using surfaces on about 4 more (my friends tested some programs I made). As well as Ism. So its something weird on your PC and changing the code to break on all is not the best option. Maybe its something to do with your driver or gfx card. What gfx card do you have? I suppose it could have sketchy support for GL standard. Also, compile a game with the upside down screen and send it to me. Wanna know if its compile time or runtime problem.
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 »