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

2356
Announcements / Re: Rejoice
« on: February 20, 2010, 11:00:32 PM »
A bounds check every time a sprite is drawn? That's just one of them that really sticks in my mind. I might prevent the untimely death of the game by modding the index by the number of sprites, but aside from that... Hell, I wouldn't even just mod it. I'd waste another ((1 << ceil(log2(sprite_count))) - sprite_count) * sizeof(sprite_struct*) bytes (as in, wrap the sprites to a greater power of two) and use an & instead.

It's the little, "oh, this won't really hurt anything" ideas that end up in projects behaving like GM. "Oh, all those local variables are negligible." "Oh, using a map to store array elements won't slow anything." Whatever I can save, I will, or it'll all build up into slow gunk.

Also, score_, I'm not sure if all structs are compile-only in the sense that they will not affect size if unused. I'm thinking vtables might be stored regardless (Not a C thing).

2357
Issues Help Desk / Re: A replacement for draw_text
« on: February 20, 2010, 12:53:20 PM »
Quote
GM's loading screen cannot be eliminated by compilation. What on earth gave you that idea?
The fact that at present, ENIGMA doesn't have one. Most things that compile in ENIGMA have presently not been big enough to have a noticeable load time, so no one has really missed a loading bar. That will likely change in the future, so I'll have to install one that's on by default. Click the Clown should never require a loading bar. <_<"

And no, Game Maker uses the font the game was compiled with, whether it exists on the new computer or not.

2358
Announcements / Re: Rejoice
« on: February 20, 2010, 10:15:42 AM »
Game_Boy--
Precisely.

Everyone else--
Listen to Game_Boy.

@"Perhaps you could implement a function set ... to make his/her application look out for errors"
The point of removing error checking is to save on multiple ifs each call. That's part of the reason GM is slow; the runner can never be recompiled to your needs. I would be no more happy to find that a user of my finished game had it throw an error on them (especially one that could be ignored) than to find that it had just acted funny or died (in the case that ignoring the error was inevitable).

@"you/the team has to work more on the error messages"
That's been a goal since the beginning.

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

plague--
I'm hoping so.

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

Retro--
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.

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

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

2361
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).

2362
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.

2363
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.

2364
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.

2365
Issues Help Desk / Re: A replacement for draw_text
« on: February 18, 2010, 06:51:21 PM »
Both:
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...)

2366
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.

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

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

2368
Issues Help Desk / Re: A replacement for draw_text
« on: February 17, 2010, 08:26:05 PM »
Luis:
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).

Grundoko:
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.

2369
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. :(

2370
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.