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 - Josh @ Dreamland

Announcements / Re: Rejoice
« on: February 19, 2010, 09:20:49 pm »
All the object data is in one file, but built-in functions are in many, many different files.

I'm hoping so.

It would be a great option if the team guaranteed its readiness. Until then, I'll stick with what I've worked on.

I've not found such a flag, but I'd think there is one.
I will definitely need such a test done. The time will come for that.

Issues Help Desk / Re: A replacement for draw_text
« on: February 19, 2010, 11:11:46 am »
That's when decryption is done and trees are generated.

I'm not sure why that's the case. Maybe he does the smoothing himself. O_o

Announcements / Re: Rejoice
« on: February 19, 2010, 11:07:54 am »
Anymore i think you're sharing these things just to have something to share. "When its C++ support is a little more mature"? When the hell is that? Should I just wait for them to figure out what they're doing? Mine took a while, but it's done now (or as done as it needs to be). Let me know when Clang is more... mature.

As for "quite fast," it was used in lieu of a number. It meant "much faster than R3 as far as can presently be discerned." Though one object in each file would be nice (and doable) if LGM kept track of which objects were modified since last compile, I don't believe it does, so there isn't much point to putting them in separate files at the moment (I'll ask Ism about it next I see her, actually).

Announcements / Rejoice
« on: February 18, 2010, 11:33:14 pm »
Everything I wanted to work at this juncture works now. It's almost bittersweet; the teeth-grating hard part is seemingly over.
There is a problem, though. Typical student-made C lexers take upwards of minutes to parse the STL headers. I figured since I didn't need much of the data a compiler needs, I could do a lexless run-over to gather desired information, thus saving oodles of time. Well, it worked, but not well enough. On average processor load on my pretty average computer, parsing all the STL headers takes between one and two seconds. The latest result being 1.53662. Honestly, it's nothing to cry about, but this means I shouldn't just parse this stuff each compile, meaning Ism and I have to work something out to have LGM load ENIGMA as a DLL. This way, it will be able to retain such information.

I had typed up a report of what comes next on the school computers, but those have lately been failing to post here. I guess I'll summarize:

- As soon as I have access to a Windows box, I will reparse the STL headers on it, and then test windows.h to make sure it works (I have no doubt that it will). I also need to test the GL headers.
- Development will need to be carried out on said Windows device for a few cycles. This is because I assume said device (the one I have picked out) is 64 bit. Serprex had some problems with 64 bit machines in the past; I need to be sure they do not persist.
- Speaking of serp, I need his version of the system. He has been optimizing it for a while now. This will probably all be done inside tomorrow.
- Since the development of ENIGMA's parser, a new GM format has been released, along with a new EGM File format. ENIGMA needs to be versed in this new format. The parser also needs updated to use the CFile parser's list instead of the small list of built-ins I used to keep. This is a large step on the road to full extensibility.

And speaking of extensibility, with it come implications. Logically, I can't optimize for run speed, compile time, and output size all at once. So, here's what seems to be destined:
  • When testing your game, it will compile quite fast. The output size will be tremendous (approaching the size of GM output as the project grows). Speed will be "decent," which is great by GM standard. Error handling will be as follows, as debated long ago:
    • In regular run mode and release mode, errors will either kill you or they won't. They are not likely to be checked for.
    • In debug mode, thorough checking will be done that could cause slowdown
    • The jury is out on build mode.
  • When compiling your game for final release, the process will take from 10 seconds to a minute. This depends not so much on your computer as on your optimization settings. C++ comes with a set of native-related optimizations, ENIGMA's most notable optimizations are to be as follows:
    • Unused functions will not be included. This is possible thanks entirely to the CFile parser. [size optimization]
    • Unused local variables can be removed. [memory optimization] [possibly {semi-}manual]
    • Switch statements will be replaced with a type of hash map where possible. This will be another feat of mostly the C parser. [speed optimization]

Other optimizations become difficult to describe and list due to number and insignificance (they only add up in the long run). Not to mention I'm really tired.

Before I go though, I should elaborate on the implications of having removable systems.
Each of ENIGMA's systems is designed now to be optional. Since R3, when compile time was too high, these groups of related functions have been divided into individual source files. The problem with doing so is that many files in ENIGMA are highly interdependent. Many sources need a few members from instances, most often id, sprite_index, and mask_index. To give access to these variables without requiring all variables, R4 will require a super-parent, if you will, that contains only the most basic of locals. Other locals, like speed and direction, will be stored in a derived parent from which all other objects will derive. This will allow for all non-essential locals to be removed without major recompile.

*yawns* I need sleep today.

Announcements / Re: Domain Name Provider Transfer
« on: February 18, 2010, 11:13:37 pm »
I know who their provider is and what their provider charges for a variety of servers. I also know their old provider, when Mark still made major decisions. I believe they were even better for this job... I don't care what they blindly wandered into.

Announcements / Re: Domain Name Provider Transfer
« on: February 18, 2010, 09:59:06 pm »
Suggesting that I don't know everything Sandy and Mark do is not the fallacy; using that to suggest that my claims that they are inefficient are invalid is where the fallacy is.

Issues Help Desk / Re: A replacement for draw_text
« on: February 18, 2010, 06:51:21 pm »
GM can use any sprite the *creator* has installed (it can import any sprite the end user has installed at runtime). Being able to render custom fonts is proof *something* is stored in the EXE. Transforming text causes pixelation. That means it's being stored as a bitmap before draw; whether before load time is unknown at this point. We can't prove it doesn't store the actual font file in the exe with what we know here; you'll just have to take my word for it that it is in fact part of the GM exe format. (And I know this for a fact, so unless I've been miserably mistaken for a long time...)

Issues Help Desk / Re: A replacement for draw_text
« on: February 18, 2010, 07:09:43 am »
The GM way is nicer-looking, but completely incompatible with the unicode way (unless, as I assume, SFML went to the trouble of anti-aliasing their gylphs).
I can't store a sprite for each of two byte's worth of glyphs.

Announcements / Re: Domain Name Provider Transfer
« on: February 18, 2010, 07:07:08 am »
Roughly $140 has gone in, $100 has come out. That puts me at as big a loss as Yoyo, percentage wise. XD

Take an upper-level philosophy course; you'd be hard-pressed to find one that won't teach you about fallacies.

Issues Help Desk / Re: A replacement for draw_text
« on: February 17, 2010, 08:26:05 pm »
That would definitely be a consideration if GM was unicode-friendly, but since we know exactly how GM does it, I don't think that's a good idea here. Perhaps for future extensions of draw_text (Listen to us talking about drawing text like we're some sort of connoisseurs. Hmph).

No worries; our job is to make it look harmlessly simple. I pretty much failed at that in R3, but hey, "if at first you don't succeed, call it the beta."
I don't think anyone can just throw together some code to do so... Perhaps the stuff in R4 has been fixed since. Serp would probably know.

Announcements / Re: Domain Name Provider Transfer
« on: February 17, 2010, 07:24:04 pm »
Special pleading is a form of spurious argumentation where a position in a dispute introduces favorable details or excludes unfavorable details by alleging a need to apply additional considerations without proper criticism of these considerations themselves. Essentially, this involves someone attempting to cite something as an exemption to a generally accepted rule, principle, etc. without justifying the exemption.


  • assertion that the opponent lacks the qualifications necessary to comprehend a point of view

Example: I know you think that I should be giving my money to the poor, but you've never been rich before. There are things about wealth that you don't understand.

In this case,
You don't work for Yoyo. You don't understand. :(

Issues Help Desk / Re: A replacement for draw_text
« on: February 17, 2010, 10:14:35 am »
Draw_text has been my least favorite function to implement due to deciding how to handle newlines. Presently, ENIGMA (R3) uses GL lists to hold the instructions for drawing individual glyphs. When you call draw_text, the string you pass is iterated by the card (ideally) with a single GL call. This is quite efficient, but it creates ugly glyphs and makes newlines impossible. The reason for that is simple; GL lists can't interface with variables on the RAM. Each time a glyph is drawn, the drawing window is translated in the viewport, and the list for that glyph is called. There is no way to preserve the starting location. That leaves me with the option of making my own pass, or just drawing the glyphs in myself, both of which are unattractive choices.

When you call draw_text in Game Maker, it doesn't do any of those things. It iterates the string itself, yes, but then it draws a sprite corresponding to the desired glyph, as serp suggested. This leaves a bad taste in my mouth for a number of reasons, but seems to be the best way to mimmic Game Maker.

Perhaps the other, more efficient technique can be implemented as a backup feature.

Announcements / Re: Domain Name Provider Transfer
« on: February 17, 2010, 10:03:20 am »
Miky- I assumed they'd invested in a cloud server to hold the plethora of games they host. Such a server, at their provider, has unmetered traffic. That would have been the first thing I did.
Rusky- The major fallacy was "you have no idea what goes on internally."

Serp and those concerned- I imagine they are using that technique. If you remember, that's what really set my hat on fire (Fred's outright anti-support for the idea until Sandy made clear they were going to make off with it).

Announcements / Re: Domain Name Provider Transfer
« on: February 14, 2010, 10:24:46 pm »
Special pleading. Argumentum ad ignorantiam. A cute ad hominem. I'll just add tu quoque and move on.

As stated, their server will run them for roughly $150 monthly. They're making more than that *daily*. And Bandwidth, assuming you actually meant "traffic," is whatever the server can put out; 1&1 doesn't limit it. (They may pay more for additional bandwidth in the literal sense, but if they do, it's not much).

And frankly, it's irrelevant what goes on internally if the budget has gone down more than 30%.

Announcements / Re: Domain Name Provider Transfer
« on: February 14, 2010, 07:39:29 pm »
So they have three coders, a web team and a Sandy.
They could make do with three or four of the above at this point (Sandy could poke around the forum and make bizarre suggestions there, and/or one of the Mac developers could storm off about it).