Show Posts
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.
31
Proposals / Re: EDL V.Next
« on: November 07, 2011, 03:24:17 PM »
Question: What is the point of a let statement? Why not just use { } ?
32
Off-Topic / Re: inb4 dead forums
« on: November 01, 2011, 02:18:08 PM »Everything to do with ENIGMA needs more documentation.
33
Proposals / Re: Laziness Buffer
« on: October 15, 2011, 04:49:39 PM »Quotetypedef signed char byte;Oh, no you didn't.
typedef unsigned char ubyte;
byte is(as of newest standards) required to be at least 8 bits, but not necessarily.
For precise sizes, see <stdint.h>(which does include int8_t and uint8_t)
Also, some languages(e.g. C#) have "byte" unsigned, and then have "sbyte", which is signed.
Quote
laziness buffer
Also, I probably would swap those two.
34
Proposals / Laziness Buffer
« on: October 15, 2011, 04:20:27 PM »
typedef signed char byte;
typedef unsigned char ubyte;
typedef signed char schar;
typedef unsigned char uchar;
typedef unsigned short ushort;
typedef unsigned int uint;
typedef unsigned long ulong;
typedef long long llong;
typedef unsigned long long ullong;
typedef unsigned char ubyte;
typedef signed char schar;
typedef unsigned char uchar;
typedef unsigned short ushort;
typedef unsigned int uint;
typedef unsigned long ulong;
typedef long long llong;
typedef unsigned long long ullong;
35
Tips, Tutorials, Examples / Re: How to properly use OpenGL
« on: October 07, 2011, 02:17:14 PM »
JoshDreamland: VBOs are far faster than lists because things are less generalised. Because the graphics pipeline doesn't have to go through loads of shit that isn't used (for example, transforming with identity matrices), it's much faster. Either way, ith 2-D stuff, the performance is practically unnoticeable.
Either way, support-wise, you should always use lists over glBegin/glEnd because it's much faster. The only case against it would be in cases draw_* functions.
Either way, support-wise, you should always use lists over glBegin/glEnd because it's much faster. The only case against it would be in cases draw_* functions.
36
General ENIGMA / Re: Builds, Packages, Releases, etc.
« on: September 24, 2011, 08:12:13 PM »
I haven't been maintaining these packages for a really long time. Unfortunately, the existing repository doesn't work. There are PKGBUILDs on the AUR (Arch User Repository), but those only work for Arch Linux. Once I find the time, I'll work on making build scripts for the Ubuntu packages instead of using my previous method, which was a giant hack.
37
Function Peer Review / Re: GM's Data Structures
« on: September 02, 2011, 10:23:24 AM »But I can see how functions, technically using no types, could be easier for the GM crowd to understand. Even if they're far too verbose for the rest of us.In all honesty, I think that they're easier for the advanced GM users, who know how to use them well, but not as much for the newer users that haven't used data structures before. Either way, I suppose that it's good to have a functional API as well as an OO one.
38
Function Peer Review / Re: GM's Data Structures
« on: September 01, 2011, 01:38:42 PM »I'm writing a Qt project right now, and I assure you that C++ data structures are WAY more difficult to learn and use than the GM's counterpart.Um.
I literally see no difference. Instead of:
Code: [Select]
var l = list_create();
list_add(l, 1);you have:Code: [Select]
vector<variant> l;
l.add(1);Which is a whole lot easier to understand, in my opinion. The only difference is an OO API versus a functional API, and an OO API makes a whole lot more sense in this instance.
39
Off-Topic / Re: GMHTML5 Alpha
« on: August 29, 2011, 10:47:20 PM »
Well, that's probably it, then. It's probably running at 30 FPS. 
EDIT: Damn, foiled by the page again.
EDIT: Damn, foiled by the page again.
40
Off-Topic / Re: GMHTML5 Alpha
« on: August 28, 2011, 09:28:20 PM »
Well, it's still JavaScript.
I'm running it under Firefox 6 and it seems a tad slow to me. Not really noticeable, but it's clear that it's not zooming along.
I'm running it under Firefox 6 and it seems a tad slow to me. Not really noticeable, but it's clear that it's not zooming along.
41
Graphics and Video / Re: ENIGMA Format Icon
« on: August 28, 2011, 07:20:55 PM »
Well, I changed my mind. 
42
Off-Topic / Re: GMHTML5 Alpha
« on: August 28, 2011, 07:18:33 PM »
And, it's pretty slow. That's to be expected of incredibly obfuscated JavaScript code.
43
Graphics and Video / Re: ENIGMA Format Icon
« on: August 26, 2011, 09:55:37 AM »
Yes, but then, you get to technical issues such as the fact that GM8 GMKs don't open in GM7. It's better to have icons that say GM5, GM6, GM7, and GM8, because those are far more descriptive to the average user than GMD, GM6, GMK, and GM81. To the average user, "GM81" means "GM version 81", which doesn't make any sense. For GMK, make it say GM7/8 to differentiate.
44
Graphics and Video / Re: ENIGMA Format Icon
« on: August 22, 2011, 10:02:00 AM »
(IMO)
It's kind of unnecessary to put the file extension on the icon. There should be one for EGM and one for GM. Not one for EGM, one for GM5, one for GM6, one for GM7, and one for GM8. If people want to know the extension, they can read the file name. If they've set Windows to hide file extensions, chances are that they really don't care about anything other than the fact that it's a GM project.
It's kind of unnecessary to put the file extension on the icon. There should be one for EGM and one for GM. Not one for EGM, one for GM5, one for GM6, one for GM7, and one for GM8. If people want to know the extension, they can read the file name. If they've set Windows to hide file extensions, chances are that they really don't care about anything other than the fact that it's a GM project.
45
Proposals / Re: Fix Wiki Namespaces
« on: August 21, 2011, 10:01:39 AM »
You don't need to actively go searching for bad pages; just stop making them and moving the ones that you see.