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.

Messages - RetroX

Function Peer Review / Re: NEEDED FUNCTION LIST
« on: December 07, 2010, 07:32:54 PM »
You should rename everything.  Folders names like "Ism's Concoction" are horrible.

General ENIGMA / Re: variable_* Functions
« on: December 07, 2010, 07:23:19 PM »
it would be a massive map of pointers, which would be slow as hell

General ENIGMA / Re: Linux Repositories
« on: December 07, 2010, 04:33:58 PM »
When you add the repository to the source, be sure to remove the source repository.  Ubuntu adds it by default for some stupid reason and I didn't make one, which is why it fails.

I mentioned it in the first post, but probably wasn't clear enough.

Function Peer Review / Re: NEEDED FUNCTION LIST
« on: December 06, 2010, 03:44:06 PM »
This is merely a list of functions.  Even if draw_text is done, others will have to do draw_text_color, etc.

Also, someone please implement c_orange.

Function Peer Review / NEEDED FUNCTION LIST
« on: December 05, 2010, 04:40:20 PM »
I was bored and made one.

I compared GM8's fnames file to the function, definition, and types list for ENIGMA.  Here are the functions and definitions that need to be made:

I can imagine this being very useful for some people.

Note that not some things on this list might already be made.  Inversely, there might be things that were inserted as placeholder functions (like show_message) and aren't on this list.

General ENIGMA / variable_* Functions
« on: December 05, 2010, 03:29:29 PM »
This is one thing that I stumbled upon today.  Like execute_string, these functions will be a bit tricky.  And I happened to use one in a GM project, and they don't work in ENIGMA currently.

Code: [Select]

I'm not entirely sure how to go about doing these, but the best idea that I can think of is keeping an array of variable names from the parser and storing pointers during runtime.  It would really decrease speed, though, and I think that it would be best to make this kind of system enable/disable-able.  Nonetheless, these do happen to be relatively common functions that will have to be supported by ENIGMA.

Usually, code tends to be:

Code: [Select]
if (variable_global_exists('bob'))
  bob = global.bob;
which would cause a compile error in C++.

You also face the problem of:
Code: [Select]
bobvar = "bob"
if (variable_global_exists(bobvar))
  bob = global.bob;

Which would run into even more problems.

Why not let the GPU handle it and use transformation matrices?  Or do they not work that way?  I haven't gone too much into GL, so, I don't know how it's done.

Question: Why do they all have the type int if you're just returning 0?  In what case would they be non-zero?  Lack of a graphics card?  I mean, I can't think of anything.

Issues Help Desk / Re: Can't draw anything inside _begin _end
« on: December 03, 2010, 09:44:16 PM »
Code: [Select]
for (int i=0; i<points; i++){
The one thing that I could see for this would be implementing a draw_add_circle function, which is essentially draw_circle without the glBegin and glEnd; that way, it draws the points in the current primitive  It would probably specify a starting angle for which point to draw first, but I can see it as being useful for speed in minor cases such as this.

You could draw the point, draw the circle starting with the angle on the line, go back to the point, then go to the next point, and repeat.

Announcements / Re: Scalability
« on: November 28, 2010, 09:14:23 PM »
Why not add a separate column to the users table that stores the safe name, and when adding users, check for safe name, not regular name.  Problem solved, and you can still keep your regular names for the wiki.

For the record, Josh @ Dreamland is a valid MediaWiki username.  The only invalid ones would be ones that contain special symbols like [ and ].

Announcements / Re: r/coderaid
« on: November 20, 2010, 09:32:27 PM »
How much use would such a coder raid actually be?
coder aid

Announcements / Re: r/coderaid
« on: November 19, 2010, 06:49:14 PM »
The fact that there isn't a lauchpad reminds me of something.  If someone with the proper permissions could edit the download page to link to a topic that talks about obtaining ENIGMA (via SVN on Windows and my Linux repos), it would probably be a good idea.

Off-Topic / Re: C++0x and garbage collection
« on: November 18, 2010, 05:59:07 PM »
Firefox has areas where it isn't a memory leak that causes high memory usage, but a large amount of fragementation. If you can't allocate memory in evenly sized blocks without being overly pessimistic so that small objects bloat the memory usage though, then I guess that's your own fault
Really I think the issue is that when people say manual memory management, they think malloc/free. I've been leaning more towards mmap as of late, but then you're outside of standard C. I was recently toying with an explicit memory manager which also had compacting, though the implementation was rather brain dead due to the half ass proof of concept nature of the project. Garbage collection is a design pattern, and where it isn't supplied by the underlying framework, it'll end up being poorly implemented by the application. There are a number of refcounted APIs in C, but refcounting isn't necessarily the superior mechanism. It's only that refcounting is suitable for explicit use by the programmer, as it doesn't deviate much from malloc/free
In any case, you should learn to read Rusky's responses at times. He answered your questions, albeit with hostility. He over evangelizes, but that's what happens when one is forced to play devil's advocate in a crowd
I read his post.  It was calling me stupid because I didn't know what I was talking about (which I didn't), then proceeded to explain as if I knew anything.  I don't know how memory is allocated; based upon my extremely simplistic knowledge on the subject, it seemed like GC was a bad idea.  I kind of see why it's a better idea now.

I'll admit that I was being terribly ignorant on the subject.

After looking at luis's example, there's a reason that static variables exist.  Why recreate a variable for every call to a function when you can create it once and reuse it?  The first example is extremely inefficient for regular variables, and I always define variables outside of a block and try to use as few as possible.

I still think that while GC can help memory allocation be a lot faster, it's not always the best option.  Or maybe it is.  I still don't know enough about it.

Off-Topic / Re: C++0x and garbage collection
« on: November 17, 2010, 04:26:38 PM »
Great job, you have shown a complete and utter lack of knowledge about both GC and non-GC systems.
Gee, thanks for letting me know.  You might as well have said "You fucking moron, why the fuck do you not know what GC is, what the fuck, you're stupid," because it probably would have said the same thing.

You're terrible at explaining things, and you're a dick when you do it.

On the topic of what you actually said, I honestly don't know anything about how managing memory works, but as far as I know, it's removing unclaimable "garbage" objects.  In other words, if I store a new pointer to an object over an old, and that object isn't pointed to anywhere, it will be deleted.

That's probably wrong, but both you and wikipedia do an extremely terrible job at explaining it to people that haven't had five years of education on the subject.

Off-Topic / Re: C++0x and garbage collection
« on: November 16, 2010, 10:13:40 PM »
Unilaterally condemning garbage collection as "disgusting" is extremely short-sighted. GC has practical benefits beyond ease of use, and while they may not apply to your area of programming they definitely apply to others. GC greatly improves cache usage, improves allocation performance (which in some cases, no matter how hard it is for you to believe, can result in an overall performance increase) and can occasionally improve collection performance.
Although, you fail to explain how.  If there actually is a good reason, I'd like to know what it is.

I'm especially irritated by Retro's hypocritical attitude of "If you leak memory, that's your own fault." You have an incredibly powerful machine sitting in front of you - why not take advantage of it? The trade-off is often worth it, and you do it all the time anyway, with things like type systems (static or dynamic, they automatically choose the right opcodes for your data types), shell scripts (oh my gosh dynamic typing and garbage collection you horrible sloppy pig), your CPU's MMU (Singularity, an operating system written in C#, eliminates the need for this and is much faster despite using garbage collection and "over-use" of classes) and a secure operating system (if you run malicious programs or let stupid people use your computer it's your own fault).

Really, these technologies have uses. There's almost never such a thing as an unconditionally bad technique or tool.
Yes, I have an incredibly powerful machine.  AMD's drivers leak 20 MB from opening a window.  That's a massive amount of memory, and if there was GC, it would all be solved.

How many calculations does it require to collect 20 MB of memory?  If we assume that all of those MB are in floats or integers, we can pretend that it's one calculation per 4 bytes.  That's 2 * 1024^2 "calculations."  Sure, four integers per frame in a game isn't bad for GC, but 20 MB?  There are some cases where GC might be a bit much, and these things add up.  If it's 20 MB per window, and you open multiple windows at once, that number doubles or triples or quadruples.  Now, it takes a few seconds for programs to start when they could start instantaneously.

Good programming is far better than having some garbage collector come and pick up the trash that you leave behind.  I agree that for finding these errors, GC is extremely useful, but not in every case should it be used as common practice.