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 »
1876
Off-Topic / Re: I think we can put our differences behind us. For science. You monster.
« on: June 21, 2010, 11:58:24 am »
XD
Yes, stereograms can cause horrible eye strain and headaches. Maybe it wouldn't be so bad if generated by a computer (such as 3DS).
Game_boy, what you describe would vastly alleviate this, but would require the DS be held at a certain distance from your face. It probably uses "tilt this VHS box to see the cover art plus scared faces or sans clothing" technology. The little triangular prisms covering alternating lines of pixels. I always hated those. Perhaps it will be better since you don't have to move the DS to see them. Turning the DS upside down would invert the 3D, though, and twisting it past a certain point would remove 3D completely (And possibly visibility). Glare on one side would also remove 3D.
Yes, stereograms can cause horrible eye strain and headaches. Maybe it wouldn't be so bad if generated by a computer (such as 3DS).
Game_boy, what you describe would vastly alleviate this, but would require the DS be held at a certain distance from your face. It probably uses "tilt this VHS box to see the cover art plus scared faces or sans clothing" technology. The little triangular prisms covering alternating lines of pixels. I always hated those. Perhaps it will be better since you don't have to move the DS to see them. Turning the DS upside down would invert the 3D, though, and twisting it past a certain point would remove 3D completely (And possibly visibility). Glare on one side would also remove 3D.
1877
Off-Topic / Re: I think we can put our differences behind us. For science. You monster.
« on: June 20, 2010, 11:06:21 pm »
Cloned the Wii? Nah, they cloned the Eye Toy. Which was "kind of cool," but never really did Sony any good. Of course, no one is as good as Microsoft at tooting their own horn, so maybe they'll manage some good sales.
I've not heard of the 3DS and don't want to go looking; what exactly is it? (Other than a model format I'm going to hate implementing)
And yes, the Wii is the only console that would really make sense to put Portal 2 on. The controls would be perfect. Damn you, valve. Probably too much effort to get working.
I've not heard of the 3DS and don't want to go looking; what exactly is it? (Other than a model format I'm going to hate implementing)
And yes, the Wii is the only console that would really make sense to put Portal 2 on. The controls would be perfect. Damn you, valve. Probably too much effort to get working.
1878
Announcements / Re: Var 4
« on: June 20, 2010, 12:52:48 am »
Copy on write will be implemented as well. Basically, scripts can return arrays via this new magic. At no efficiency cost. However, there is a detriment on setting equivalent a var and a large array. Because of that, I believe I will be making as many globals as possible use scalar types. (Or variant if I have to).
Variant will now be a type at the user's disposal. Not boost::variant, just R3's enigma::variant.
Also, string() is handled more beautifully, such that string str; will still get you a string, but string(somevar) will work as well. This is possible via a simple macro, #define string(x) toString(x). (Luckily, string alone will not error nor attempt to unfold the macro function.)
Variant will now be a type at the user's disposal. Not boost::variant, just R3's enigma::variant.
Also, string() is handled more beautifully, such that string str; will still get you a string, but string(somevar) will work as well. This is possible via a simple macro, #define string(x) toString(x). (Luckily, string alone will not error nor attempt to unfold the macro function.)
1879
Announcements / Re: Battling
« on: June 19, 2010, 08:01:37 pm »
That may be a good idea. But we've not devised such a format. I'll wait until your versioning branch is the trunk.
1880
Announcements / Re: Var 4
« on: June 19, 2010, 02:04:43 pm »
That's what I was thinking. In fact, the new instance system also uses quite a bit more memory than the old. We're talking nearly half a megabyte for a game with 1,000 instances at 10 events apiece. But it introduces a beautiful mechanism for the instance functions, and even with() and the like.
1881
Announcements / Re: Battling
« on: June 19, 2010, 01:29:43 pm »
It will so long as the calling process has them as well. Problem is, Java explodes when groped by GDB. Even if what's called is perfectly healthy.
1882
Announcements / Var 4
« on: June 19, 2010, 07:12:35 am »
Questions on which to pick and why have boiled down to the need to separate var into individual sources, each implementing a behavior. Var 4 will apparently implement several options.
The first of these is in how arrays are handled:
- GM uses a Map for everything, as some of you know. I guess I could make that an option.
- ENIGMA R3 uses a simple dynamic array. It checks for size, then dereferences O(1).
- Lua uses both. It would implement no additional overhead from R3, but would add some in computing whether it should use the map for large indexes.
The second of these is in how variants store memory.
- GM's method cannot be determined simply through experimentation. Presumably, since it is interpreted, Mark keeps close track of type (an extra check among a map lookup is nothing).
- ENIGMA R3 kept variant next to double for max speed, but high memory usage.
- I am capable of constructing and destroying string on the site, at the cost of an additional check per = operation (and of course, constructor and destructor call). This will reduce memory usage, but slightly(?) lower speed as well.
I will spend today trying to implement them (among other things).
The first of these is in how arrays are handled:
- GM uses a Map for everything, as some of you know. I guess I could make that an option.
- ENIGMA R3 uses a simple dynamic array. It checks for size, then dereferences O(1).
- Lua uses both. It would implement no additional overhead from R3, but would add some in computing whether it should use the map for large indexes.
The second of these is in how variants store memory.
- GM's method cannot be determined simply through experimentation. Presumably, since it is interpreted, Mark keeps close track of type (an extra check among a map lookup is nothing).
- ENIGMA R3 kept variant next to double for max speed, but high memory usage.
- I am capable of constructing and destroying string on the site, at the cost of an additional check per = operation (and of course, constructor and destructor call). This will reduce memory usage, but slightly(?) lower speed as well.
I will spend today trying to implement them (among other things).
1883
Announcements / Re: Battling
« on: June 18, 2010, 01:23:27 pm »
Yeah, it works fine for me due to hardware sync. But...
1884
Announcements / Re: Battling
« on: June 18, 2010, 12:29:38 pm »
Luis:
Nope, I don't think she can. Haha. Besides, it would have been more difficult to find than that, it seems.
MrJackSparrow2:
Indeed. When I had the compiler generate the segment of code responsible for event iteration, I omitted the function call that handles FPS calculation. That will be fixed after the implementation of var4 and further segfault testing today.
Nope, I don't think she can. Haha. Besides, it would have been more difficult to find than that, it seems.
MrJackSparrow2:
Indeed. When I had the compiler generate the segment of code responsible for event iteration, I omitted the function call that handles FPS calculation. That will be fixed after the implementation of var4 and further segfault testing today.
1885
Announcements / Re: Battling
« on: June 17, 2010, 04:21:57 pm »
Sorry. Forgot to install new FPS limiter. So you're probably getting some ridiculous framerate.
1886
Announcements / Re: Battling
« on: June 17, 2010, 10:30:09 am »
I was trying to allow for a separate target ("link") to take care of everything, then just rename the file to Dll on windows or so on Linux. That's the only part that's different (It looked much better on paper than in code).
Anyway, I found the problem, I believe; these things tend to be much easier to find when you actually experience them. So the segfault on random platforms and architectures should be resolved, as of the just-committed r266. Hopefully that's the end of our trouble; I'll proceed for now.
I'm happy to report that the new instance system is, as I'd hoped, faster. than. all. fucking. greased. lightning.
Holy. Hell.
I can safely say that this is the best idea I've had all year. Pics and code will follow.
Anyway, I found the problem, I believe; these things tend to be much easier to find when you actually experience them. So the segfault on random platforms and architectures should be resolved, as of the just-committed r266. Hopefully that's the end of our trouble; I'll proceed for now.
I'm happy to report that the new instance system is, as I'd hoped, faster. than. all. fucking. greased. lightning.
Holy. Hell.
I can safely say that this is the best idea I've had all year. Pics and code will follow.
1887
Announcements / Re: Battling
« on: June 17, 2010, 09:43:58 am »
It almost seems that the problem is with 32bit systems... and with Freezway's 64bit arch. <_<" Love me some consistent data. Let me run some diagnostics...
Plague:
Yep, that's Microsoft's way of dealing with a segfault, I'd forgotten.
Plague:
Yep, that's Microsoft's way of dealing with a segfault, I'd forgotten.
1888
Announcements / Battling
« on: June 17, 2010, 01:05:13 am »
Ism reports a segfault when she runs Catch the Clown with what's uploaded of the new instance system, as does freezway. I can't reproduce this on any machine at my disposal. The new instance system is mostly done, but does not yet implement a (working) instance_destroy(). It just prints an error to the console at the moment. It is not difficult to implement, but I want to hear that people can compile Catch the Clown first.
I don't understand the problem. I checked out everything for the first time on a new Win7 machine. Downloaded RapidSVN, checked out, installed MinGW, ran. I had to edit six lines to get it to compile on Windows; after that, no segfault. No negative repercussions.
If anyone could provide useful insight into the segfault, that'd be useful. Current effective revision is 265. Catch the Clown is available from Ism's topic, ultimately from this link on her website: http://www.ismavatar.com/Catch_the_Clown.gmk.
Windows users can get MinGW here: http://sourceforge.net/downloads/mingw/Automated%20MinGW%20Installer/MinGW%205.1.6/MinGW-5.1.6.exe/
RapidSVN here: http://www.rapidsvn.org/download/release/0.12/RapidSVN-0.12.0-8051.exe
From RapidSVN, go to Repository->Check out. URL is https://enigma-dev.svn.sourceforge.net/svnroot/enigma-dev/trunk. Pick a directory yourself.
For the MinGW installer, select G++ Compiler and MinGW Make as well. ENIGMA needs both.
Run CMD and move to the folder containing ENIGMA. Execute `mingw32-make.exe -C CompilerSource windows`. You will need to identify where mingw32-make.exe is. It's probably `C:\MinGW\bin\mingw32-make.exe -C CompilerSource windows` for you. Windows is odd. If make errors towards the end, rename compileEGMf.exe to compileEGMf.dll yourself.
From Linux, install the following with your favorite package manager:
g++
libgl1-mesa-dev (or similar)
zlib1g-dev (tab complete is your friend)
subversion
sun-java6-jre (Or Java in general, but I -strongly- recommend this one)
Then run this:
svn co https://enigma-dev.svn.sourceforge.net/svnroot/enigma-dev/trunk enigma-test
cd enigma-test
make -C CompilerSource linux
java -jar lgm16b4.jar
In either case, when LGM loads with the ENIGMA background, load the GMK you got from http://www.ismavatar.com/Catch_the_Clown.gmk and try to compile and run it. If the game seems to compile but closes immediately on run, it probably segfaulted (Linux users, the OS will tell you if this happened). In that case... Well, just tell me it did along with your architecture and operating system and I will try to come close to it. I will be testing on my other machines. I hope I can reproduce the problem, or that perhaps the problem was magically resolved by some minor change in the meantime.
Too tired to proofread or bother further right now. Think I'll just bed.
I don't understand the problem. I checked out everything for the first time on a new Win7 machine. Downloaded RapidSVN, checked out, installed MinGW, ran. I had to edit six lines to get it to compile on Windows; after that, no segfault. No negative repercussions.
If anyone could provide useful insight into the segfault, that'd be useful. Current effective revision is 265. Catch the Clown is available from Ism's topic, ultimately from this link on her website: http://www.ismavatar.com/Catch_the_Clown.gmk.
Windows users can get MinGW here: http://sourceforge.net/downloads/mingw/Automated%20MinGW%20Installer/MinGW%205.1.6/MinGW-5.1.6.exe/
RapidSVN here: http://www.rapidsvn.org/download/release/0.12/RapidSVN-0.12.0-8051.exe
From RapidSVN, go to Repository->Check out. URL is https://enigma-dev.svn.sourceforge.net/svnroot/enigma-dev/trunk. Pick a directory yourself.
For the MinGW installer, select G++ Compiler and MinGW Make as well. ENIGMA needs both.
Run CMD and move to the folder containing ENIGMA. Execute `mingw32-make.exe -C CompilerSource windows`. You will need to identify where mingw32-make.exe is. It's probably `C:\MinGW\bin\mingw32-make.exe -C CompilerSource windows` for you. Windows is odd. If make errors towards the end, rename compileEGMf.exe to compileEGMf.dll yourself.
From Linux, install the following with your favorite package manager:
g++
libgl1-mesa-dev (or similar)
zlib1g-dev (tab complete is your friend)
subversion
sun-java6-jre (Or Java in general, but I -strongly- recommend this one)
Then run this:
svn co https://enigma-dev.svn.sourceforge.net/svnroot/enigma-dev/trunk enigma-test
cd enigma-test
make -C CompilerSource linux
java -jar lgm16b4.jar
In either case, when LGM loads with the ENIGMA background, load the GMK you got from http://www.ismavatar.com/Catch_the_Clown.gmk and try to compile and run it. If the game seems to compile but closes immediately on run, it probably segfaulted (Linux users, the OS will tell you if this happened). In that case... Well, just tell me it did along with your architecture and operating system and I will try to come close to it. I will be testing on my other machines. I hope I can reproduce the problem, or that perhaps the problem was magically resolved by some minor change in the meantime.
Too tired to proofread or bother further right now. Think I'll just bed.
1889
Tips, Tutorials, Examples / Re: Which should I use?
« on: June 15, 2010, 10:28:48 pm »
Sorry, but outside of the scope in which it is declared, postfix [] and prefix * are synonymous.
Code: (C++) [Select]
#include <stdio.h>
int array[3] = { 1, 2, 3 };
void function(int arg[]) {
puts((void*)arg == (void*)&arg ? "true" : "fail");
}
int main() {
return function(array), 0;
}
Quote
fail
1890
Tips, Tutorials, Examples / Re: Which should I use?
« on: June 15, 2010, 03:36:35 pm »
Sure, but good luck passing the array to a function and keeping that true.
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 »