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.
46
Announcements / Re: Rejoice
« on: March 02, 2010, 05:37:28 am »
Blame Josh and the tendency to spell in the manner recently read. I can't find a case past where I made such an err, and I wrote it as draw_mandelbrot in the source
Also, on the topic of standardized typos, obligatory HTTP REFERER
Also, on the topic of standardized typos, obligatory HTTP REFERER
47
Announcements / Re: Rejoice
« on: February 22, 2010, 10:46:12 pm »Quote
(03:18:56) Nark Pvermars: draw_mandlebrotEnigma now supports more drawing functions than GM. At least 2dwise, for now. But don't worry, we'll have d3d_draw_mandlebrot to beat YYG there too when the time comes
(03:18:57) Nark Pvermars: do it
(03:18:58) Nark Pvermars: fgt
And d3d_draw_mandlebrot will have an UNMANLY label too
48
Announcements / Re: Domain Name Provider Transfer
« on: February 16, 2010, 09:46:54 pm »
They could probably save space by using Josh's GMzip's technique. Integrate it into the browser plugin, and they'd lower bandwidth too. Perhaps that's how they already go about it? I'd hope
Also, Retro, why are you talking about compiling bash scripts?
Also, Retro, why are you talking about compiling bash scripts?
49
Issues Help Desk / Re: A replacement for draw_text
« on: February 16, 2010, 09:39:53 pm »
Stop calling text simple. If you want a replacement, you could put together a sprite based implementation. Preferably, an implementation would make use of 1bit images embedded in the binary of the font for portability. Therefore, the compiler has to be updated thusly. Doing so in the R3 compiler would raise snark from Josh. Once that's done, one would have to add a facility to EnigmaSys to process the embedded fonts into textures or some other such form which would appeal to the actual rendering functions
50
Announcements / Re: Missed one.
« on: January 16, 2010, 09:17:50 pm »Now why did I think ... was only for stdargs?Because ellipsises are only for stdargs in Standard C++. Variadic macros are coming with variadic templates, which it seems you've also forgotten to go about
51
Announcements / Re: Happy New Year
« on: January 07, 2010, 03:39:52 pm »
Silly Rusky, that's not failure of grammar; it's ambiguity, something which I'm quite fond of. In this case I disambiguate it though, which I'm not prone to so much
As for Josh and C++, it's his lack of being able to settle. I shouldn't have been surprised he wasn't ready to settle and marry
As for Josh and C++, it's his lack of being able to settle. I shouldn't have been surprised he wasn't ready to settle and marry
52
Announcements / Re: Happy New Year
« on: January 05, 2010, 07:51:41 pm »
On the topic of covering the GML functions and Rusky, I've been working on what Rusky failed at. Except to keep it a hassle for Josh, I've been implementing ds_* functions for a different engine: http://github.com/serprex/dysvk/blob/master/dss.c
53
Announcements / Re: Happy New Year
« on: January 03, 2010, 04:56:24 pm »
gnu99, single statement: goto*(++year==2012?&&END_OF_THE_WORLD:&&NEW_YEARS_DAY);
54
Announcements / Re: Happy New Year
« on: January 02, 2010, 04:44:16 pm »
R4 isn't just a new parser. It'll also be when Josh decides to finally merge in my R3 branch's ENIGMAsystem which is a branch of his updated R3 ENIGMAsystem
55
General ENIGMA / Re: Useful Tips
« on: December 28, 2009, 12:01:36 pm »
D and C# allow for both integers and strings to be used in switch statements, relying on the compiler to choose a suitable form of jump table (Probably hash jump table, as in the case of sparse integers). Functional languages have pattern matching to cover the syntactic terseness of a switch, and due to an abundance in the semantic qualitiy of referential transparency, optimizations can be applied to output assembly resembling a switch
#3, why are you explaining types? The only languages I've come across that lack multiple primitive types are esoteric languages, and I don't think any of these suggestions would really suit Thue
I disagree with delta timing. You suggest a naive approach which can cause wall jumping in extreme cases. Just program efficiently in the first place, and all is well
Pseudocode is a joke. If I want simple syntax and clear semantics, I'll use Python. If you want to do the whole writing out algorithms without dealing with language hassles, draw out some graphs. Pseudocode doesn't offer enough useful abstraction to call for leaving away testing at a click of a button
#8 is a whole lot of nothing about something
#3, why are you explaining types? The only languages I've come across that lack multiple primitive types are esoteric languages, and I don't think any of these suggestions would really suit Thue
I disagree with delta timing. You suggest a naive approach which can cause wall jumping in extreme cases. Just program efficiently in the first place, and all is well
Pseudocode is a joke. If I want simple syntax and clear semantics, I'll use Python. If you want to do the whole writing out algorithms without dealing with language hassles, draw out some graphs. Pseudocode doesn't offer enough useful abstraction to call for leaving away testing at a click of a button
#8 is a whole lot of nothing about something
56
General ENIGMA / Re: Useful Tips
« on: December 28, 2009, 06:50:14 am »
STL mandates that even linked list have O(1) size functions. And as for function call overhead, it's called inlining
Trust your compiler's optimizations, or get staked and use assembly
Like that loop tip. If you're using a tracing JIT, loops are what they feed on. If you're using C, they've already thought about it. Also note code cache might make a loop faster than an unrolled one
As for Josh's talk of std::string, ignore him. Spec doesn't define implementation, hence
Trust your compiler's optimizations, or get staked and use assembly
Like that loop tip. If you're using a tracing JIT, loops are what they feed on. If you're using C, they've already thought about it. Also note code cache might make a loop faster than an unrolled one
As for Josh's talk of std::string, ignore him. Spec doesn't define implementation, hence
57
Issues Help Desk / Re: GPL?
« on: December 25, 2009, 10:46:04 am »
& on the topic of GCC compiled code not being GPL: http://www.gnu.org/licenses/gcc-exception-faq.html
58
Announcements / Re: Hats
« on: December 23, 2009, 02:46:32 pm »
Josh has game design projects for which GM proved too inefficient
I spent three years becoming intimate with GML. It catches my fancy
Notice that we're using C/++ while developing Enigma. Why do people design games? If it's to play, they lose interest fast enough. There are puzzles to be thought out, and GM offers a group of people to which we can offer a product through our solving of such puzzles
I want to help with projects. I'm not much for web oriented programming, but something like Enigma seems interesting enough. Josh has made it easy enough for me to be able to get a payoff from that feeling that something is being made. It's really all about the human need to create
Josh started Enigma as a learning process with C/++. Similarly, Mono's developer first started writing the C# parser in C# to learn C#
I spent three years becoming intimate with GML. It catches my fancy
Notice that we're using C/++ while developing Enigma. Why do people design games? If it's to play, they lose interest fast enough. There are puzzles to be thought out, and GM offers a group of people to which we can offer a product through our solving of such puzzles
I want to help with projects. I'm not much for web oriented programming, but something like Enigma seems interesting enough. Josh has made it easy enough for me to be able to get a payoff from that feeling that something is being made. It's really all about the human need to create
Josh started Enigma as a learning process with C/++. Similarly, Mono's developer first started writing the C# parser in C# to learn C#
59
Announcements / Re: Hats
« on: December 23, 2009, 02:11:16 pm »
Language implementation is interesting in its own right. Though Luda and I converse of such more than I do with Josh. But there's simply frustration in how inefficient GM is. There's no reason for it to be that way. The type system is too simple to really be called dynamic