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 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »
1591
General ENIGMA / Re: The Life of a Games Progammer (GM dev blog)
« on: November 15, 2010, 09:51:54 pm »
1) Yes, I was thinking about how it could be applied, but then I realized that doing so would completely alienate a useful function: GL_WRAP based tiling. Honestly, I'm not entirely positive how to justify a check for texbordx and y (As you mentioned) against 1 just to determine if tiling is possible... I've been giving it some thought, but I'm not yet confident enough to just go through with it.
2) All of the wet dreams he mentioned for GM are already implemented in ENIGMA. I'm presently working to allow correct member access in templated structures. Regular (and multiple-inherited) structures work fine in ENIGMA in all contexts.
Honestly, the hardest part about implementing that has been trying to get Ism to highlight them. As you can plainly see, she has access to the list.
And no, we should not denigrate Dailly just because he works for Yoyo. He's the most intelligent person they have on staff. I can't afford to pay people like him or I'd find one for us.
2) All of the wet dreams he mentioned for GM are already implemented in ENIGMA. I'm presently working to allow correct member access in templated structures. Regular (and multiple-inherited) structures work fine in ENIGMA in all contexts.
Code: [Select]
RECT a; a.left = instance_nearest(x,y,0); a.left.speed = 5;
Honestly, the hardest part about implementing that has been trying to get Ism to highlight them. As you can plainly see, she has access to the list.
And no, we should not denigrate Dailly just because he works for Yoyo. He's the most intelligent person they have on staff. I can't afford to pay people like him or I'd find one for us.
1592
Graphics and Video / Re: ENIGMA examples - Games
« on: November 14, 2010, 12:42:44 pm »
Now you're seeing the project like I do.
Most of the hard things are done. Roughly five remain. These are the three I can most readily remember:
1) Proper template instantiation for accurate type resolution on template parameter typed members (Working on this one right now).
2) Switch statement optimization/implementation (I need to be able to get the integer value of constants).
3) Proper argument type resolution (This may never actually happen).
From there, we have other some milestones that I will more than likely be the one to do:
1) Proper local modularization (See Ism's alarm code; I described to her how to do once what the compiler would soon be streamlining).
2) Comment based output sectioning for compiler feedback parsing (Meaning if GCC errors from the user's object headers, I just read up to the nearest comment to find out what object/script the error was in).
3) Depth. I told everyone how to do this, but I know I'll be the one to do it when I feel like it. It's not difficult at all.
4) Design mode (Build Mode from R3). You've probably never heard of it, but it was ENIGMA's trump card (I'm sort of working on it now).
Additionally, r9k is working on a polygon collision engine, and Ism is doing what I was hoping someone would do, being to take my collision_bbox_rect and do some bbox-based collision functions to get the system up and running in general.
Once that's done, though, I can pretty much stamp a big "DONE" on ENIGMA as far as being a competent development application goes, because the rest of the GM library is trivia and nonsense.
And, eh, move your draw_primitive_set_line_width(20); above your draw_primitive_begin().
Also, I was thinking about adding an option for scripts (embed in all, use with(), automatic). For now, I embed them all because memory is cheap, but not so much the extra time to dereference a non-this. (ENIGMA's with is actually pretty damn efficient, but...)
Most of the hard things are done. Roughly five remain. These are the three I can most readily remember:
1) Proper template instantiation for accurate type resolution on template parameter typed members (Working on this one right now).
2) Switch statement optimization/implementation (I need to be able to get the integer value of constants).
3) Proper argument type resolution (This may never actually happen).
From there, we have other some milestones that I will more than likely be the one to do:
1) Proper local modularization (See Ism's alarm code; I described to her how to do once what the compiler would soon be streamlining).
2) Comment based output sectioning for compiler feedback parsing (Meaning if GCC errors from the user's object headers, I just read up to the nearest comment to find out what object/script the error was in).
3) Depth. I told everyone how to do this, but I know I'll be the one to do it when I feel like it. It's not difficult at all.
4) Design mode (Build Mode from R3). You've probably never heard of it, but it was ENIGMA's trump card (I'm sort of working on it now).
Additionally, r9k is working on a polygon collision engine, and Ism is doing what I was hoping someone would do, being to take my collision_bbox_rect and do some bbox-based collision functions to get the system up and running in general.
Once that's done, though, I can pretty much stamp a big "DONE" on ENIGMA as far as being a competent development application goes, because the rest of the GM library is trivia and nonsense.
And, eh, move your draw_primitive_set_line_width(20); above your draw_primitive_begin().
Also, I was thinking about adding an option for scripts (embed in all, use with(), automatic). For now, I embed them all because memory is cheap, but not so much the extra time to dereference a non-this. (ENIGMA's with is actually pretty damn efficient, but...)
1593
Graphics and Video / Re: ENIGMA examples - Games
« on: November 13, 2010, 10:41:29 am »
Hahahaha. Yes, since ENIGMA is the one that declares arguments, I should have had it add them to its list of script locals when parsing them. Silly mistake on my part; nothing to fret about.
1594
Graphics and Video / Re: ENIGMA examples - Games
« on: November 11, 2010, 11:35:57 am »
I can't think of any reason "if (nx*nx+ny*ny<radius*radius){" would behave that way. If you like, you can look at IDE_EDIT_objectfunctionality.h and find how the faulty code is exported. If you see something wrong with it, tell me and I'll probably be able to diagnose the problem.
1595
Proposals / Re: Re: Preprocessor Directives (The compile-time "if")
« on: November 09, 2010, 07:19:56 pm »
Yep.
1596
Graphics and Video / Re: ENIGMA examples - Games
« on: November 09, 2010, 06:50:03 pm »
Some part of me was hoping that game would work in ENIGMA and not Game Maker. Turns out the opposite was true.
1597
Proposals / Re: Re: Preprocessor Directives (The compile-time "if")
« on: November 09, 2010, 06:43:37 pm »
Since ENIGMA is responsible for understanding those macros to correctly parse its engine file, I would have to go out of my way to stop users from accessing macros like TARGET_IPHONE_SIMULATOR from your example. I of course have no intention of doing so.
So yes.
So yes.
1598
Graphics and Video / Re: ENIGMA examples - Games
« on: November 09, 2010, 01:35:43 pm »
I'd say use anything you like from Space Invaders. Maybe not the exact 8x8 two-color bitmaps, but the shapes and behaviors, sure.
1599
Graphics and Video / Re: ENIGMA examples - Games
« on: November 09, 2010, 10:38:56 am »
It's been 30 years, HaRRi. I'm pretty sure Space Invaders is fair game, too. But do what you like.
1600
Proposals / Re: Re: Preprocessor Directives (The compile-time "if")
« on: November 08, 2010, 05:13:05 pm »
Well, yes, but I'd much prefer directives to be inside something other than ^#(.*)$. The [[ and ]] seem to make for prettier code. (Besides, I'm pretty much doing away with #include: I may steal require from other languages.)
1601
General ENIGMA / Re: Linux Repositories
« on: November 08, 2010, 07:49:40 am »
Actually, he was right; I didn't notice it. And I just kind of want to hear it works so I can upload it.
But I am pinning it.
But I am pinning it.
1602
Graphics and Video / Re: ENIGMA examples - Games
« on: November 08, 2010, 07:34:24 am »
I'm in no way opposed to having code-only examples. That -is- ENIGMA's strongest suit.
1603
Proposals / Re: Thoughts on forum registration...
« on: November 07, 2010, 07:47:50 am »
That's SMF's default behavior. But for now, I'm enjoying the fact that we have three new members and zero new spam bots over the course of what, a week? That's three more members and four less spam bots than we usually get. I'm not sure what the correlation between a strong captcha and an increase in members is (perhaps they were lurkers who saw this post and wanted to see what the challenge was?) But I'm at this time quite enjoying the current set.
1604
Proposals / Re: Preprocessor Directives (The compile-time "if")
« on: November 06, 2010, 06:36:47 pm »
I see what you mean, Rusky. For a little bit I was thinking about doing something like that (C takes a lot of heat over the issues rising from copy-pasted macros, of course), but I don't think I should. The only reason I'm keeping any sort of macros is because of ENIGMA's C heritage. If it wasn't for that, they'd be expression based if they were in at all, but my reason for wanting preprocessors at all at this point isn't for macros. My number one concern is the #if directive. The rest are just kind of there. The reason I want #if is for altering behavior from platform to platform. I was discussing with marbs the other day the implications of ENIGMA compiling for iPhone, and he mentioned motion detecting devices.
Originally, I intended to offer controller_get_angle_x/y/z() and controller_get_shaken(). On Windows, they'd all return zero unless an applicable device was connected. On Wii, they'd all have an accurate return. On iPhone, _angle _x and _y would work, as well as _shaken (same for android). Issue is, what if that isn't enough? What if having a shake is a critical part of the game, and they would have to work around it with multiple lines of code (likely to test for a key combo instead)?
I like a number of features for Lisp's macros, but my focus is really more on preprocessors right now. Maybe we can pile on a new macro system as well, later. But for now I'm more concerned about being able to say
[[If Target_Device == eDev_iPhone]]
if (controller_get_shaken())
earthquake();
[[else]]
if (keyboard_check(vk_control) and keyboard_check_pressed(ord("E")))
earthquake();
[[fi]]
Granted, that's not a very good example, since a simple "or" could technically have sufficed with little overhead. But it conveys the basic idea.
Say we want our mobile game to always be oriented correctly, and which direction has the high resolution doesn't really matter.
Persistent Controller Step Event:
Granted, that code's kinda rough. But that's the kind of thing I'm talking about. You don't exactly want it doing that on Wii.
Originally, I intended to offer controller_get_angle_x/y/z() and controller_get_shaken(). On Windows, they'd all return zero unless an applicable device was connected. On Wii, they'd all have an accurate return. On iPhone, _angle _x and _y would work, as well as _shaken (same for android). Issue is, what if that isn't enough? What if having a shake is a critical part of the game, and they would have to work around it with multiple lines of code (likely to test for a key combo instead)?
I like a number of features for Lisp's macros, but my focus is really more on preprocessors right now. Maybe we can pile on a new macro system as well, later. But for now I'm more concerned about being able to say
[[If Target_Device == eDev_iPhone]]
if (controller_get_shaken())
earthquake();
[[else]]
if (keyboard_check(vk_control) and keyboard_check_pressed(ord("E")))
earthquake();
[[fi]]
Granted, that's not a very good example, since a simple "or" could technically have sufficed with little overhead. But it conveys the basic idea.
Say we want our mobile game to always be oriented correctly, and which direction has the high resolution doesn't really matter.
Persistent Controller Step Event:
Code: (EDL) [Select]
[[if Target_Device == eDev_iPhone or Target_Device == eDev_Android]]
int az = controller_get_angle_z();
if (az > 45 and az < 135 or az > 225 and az < 315)
view_wview[0] = display_get_width(),
view_wview[0] = display_get_height();
else
view_wview[0] = display_get_height(),
view_wview[0] = display_get_width();
[[fi]]
Granted, that code's kinda rough. But that's the kind of thing I'm talking about. You don't exactly want it doing that on Wii.
1605
Proposals / Re: Preprocessor Directives (The compile-time "if")
« on: November 06, 2010, 03:14:57 pm »
There's no point in using real types for macros... It's strictly interpreted... it'd just be more work.
#pragma once won't help us; this is for EDL in objects and scripts, which are always included once manually (they can't be included by the user...)
As for using ifdef and endif instead of {}, it's really a matter of preference. I like it text-based because you can always tell the preprocessor from the rest of the code. If we're going to be using [[]]. [[]]{} would look ugly. I'm opposed to so many _ in everything, but I suppose I'm not against using a word and {} instead of [[if]] [[fi]], if that's what everyone else wants.
Moreover, has anyone really been far as decided to use even go want to do look more like?
#pragma once won't help us; this is for EDL in objects and scripts, which are always included once manually (they can't be included by the user...)
As for using ifdef and endif instead of {}, it's really a matter of preference. I like it text-based because you can always tell the preprocessor from the rest of the code. If we're going to be using [[]]. [[]]{} would look ugly. I'm opposed to so many _ in everything, but I suppose I'm not against using a word and {} instead of [[if]] [[fi]], if that's what everyone else wants.
Moreover, has anyone really been far as decided to use even go want to do look more like?
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 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »