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

Issues Help Desk / Re: Out of memory error while compiling
« on: May 29, 2013, 11:29:08 pm »
Holy moses. How big is your game? Or are you just genuinely short on memory? I don't think the JVM's allocation bounds affect ENIGMA's compiler; if they did, it would be possible that your game was just big enough to only cause a memory issue when compiling.

Could you get us the size of the game file, and the memory consumption of each of LateralGM (javaw.exe) and cc1plus? The task manager should list those.

Thundercleese is already on GitHub, probably with a full SQL password along with Gary's IRC credentials. I'm aware of EnigmaBot's credentials file, and I'm weary of other files with SQL passwords.

General ENIGMA / Re: Perfect Circles
« on: May 28, 2013, 08:43:52 am »
I was speaking of circle outlines, but I would still use a hollow decagon for regular circles, too. The less of the fill we compute by taking the distance to center, the better.

General ENIGMA / Re: Perfect Circles
« on: May 27, 2013, 08:27:23 pm »
I'll just cut to the chase on this one: the distance computation for the needed fill rate on large circles would make one polygon worse than fifty. Maybe if you used exactly 20 to minimize the needed fill rate, you would be okay, but then the shader would need an x,y parameter, which would need to be factored into the struct passed from the vertex shader to the fragment shader. If you did that, though, you could reasonably draw perfect circles with mathematically perfect anti-aliasing.

I find Ideka's solution equally elegant.

General ENIGMA / Re: SwapBuffers Issue
« on: May 27, 2013, 12:24:16 pm »
Here's the issue: wgl is platform-specific. On Windows, it's wgl. On Linux, it's glx. Moreover, wglew is specifically for Windows. We need a Bridges/ folder between platforms and graphics/audio/widget systems.

Polygone[0]: I guess I can see merit in linking 64Digits files, but then we don't have control over whether the user can delete the file without deleting the game. If the EDC controls the files, then users can't accidentally break links.


Regarding the licensing issue: those were basically my thoughts, though the attribution clause concerns me; GPL does not require attribution except insofar as the license remains intact, and whether that is sufficient to meet the three clauses of that BSD license was unclear to me. Also, that still presents an issue if we want to put the theme up on GitHub, though I don't see how they could limit our ability to do that if their license is GPL compatible.

Regarding the regression tests: I've wanted to make a regression testing suite for a long time, but I never had the wherewithal to get the job done myself. The task is every bit as daunting as documenting all the functions; it'd be an endeavor for the entire team. The most intricate testing suite we ever had was TGMG's compiler test, which, using a collection of a couple thousand examples harvested from 64Digits, compiled each one sequentially with ENIGMA, noting missing functions. I have no idea what has become of this testing environment, but TGMG should be back with us in a month or so.

Regarding your EDC points: I had meant to express that the multiple download links were for each platform, but I forgot that they might also be used for mirrors and assumed that the idea was implied. But yes, that feature is definitely on the radar. I really like the HTML5 embedder idea; I was actually thinking about using TGMG's old Java applet that embeds ENIGMA games (talking of GMBed). Then users could play any ENIGMA game from within their browser, sort of (the game would still be an EXE running on their machine, but it'd give the illusion of running in their browser). I do like the HTML5 idea, though; I forgot to consider it. You can currently edit your own EDC submissions, but the thing is presently devoid of moderation features. So if someone makes an ass of themselves on it, I have to delete them manually using SQL queries, which will probably piss me off enough to IP ban that person. That's definitely also on the radar. What 64Digits (the site upon which the EDC is based) does is use an approval queue for all games; games aren't displayed until a moderator checks that it isn't a virus. Of course, that only works if it's not on a timer, or something, but it's still one decent measure.

IsmAvatar: I hope you're wrong about this, for once. Most of my idea is that security isn't an issue. The reason for this is that all of the SQL queries go through the SMF API, which handles all sanitation for you. Thanks to that, the only kind of exploits anyone will find are generic JavaScript-flavored XSS. The database access is all handled by SMF's library, which would remain far from the GitHub. And yes, most of our manpower is tied up in the engine, and that is right where it should be. But I mentioned the case with Robert as a good example of something versioned site code will fix; now no one needs me to edit theme-related code, because it's all right on GitHub. Meanwhile, the stuff I do *not* want people editing, is *not* on GitHub. Granted, if Robert wastes more time on that, that's still time he could have been spending on the project. But he's going to waste my time, too, if that's not an option. And keep in mind, some people will come along who want to contribute, but don't know any C++. Some of those will be web developers who might want to lend a hand.

Polygone[1]: That can be arranged.
Two other missing features of the EDC:

1) It does not correctly set the currently active page in the forums. It shows up as "Unknown action."
2) There's no way to watch threads/blogs/users/general activity.


General ENIGMA / Website and IRC Problems Version Control Could Fix
« on: May 26, 2013, 10:48:36 am »
Sorry to add yet another topic to this already overpopulated board. Maybe one day the whole forum will be this active, and I won't have to feel bad. I figure this is a good board to pollute, since people are already paying extra attention to it.

To cut to the chase, we need to start using version control EnigmaBot and other features of the website.
I have organized my points into •B•U•L•L•E•T•E•D• •L•I•S•T•S• to save everyone some brainpower and reading.

  • Security: We don't have anything to hide except password hashes and private messages, which are part of the SQL database and would not be versioned.
    • Moreover, we have tons of living proof that being open-source promotes contribution of security patches over exploitation of security holes (consider Linux).
  • Feedback: This lets people drop pull requests and submit bug reports for features of the website that irk them.
  • Disaster Recovery: This makes site-wide code backup obsolete.
  • Ease of development: This makes updating pieces of the website a no-brainer, lets users edit code in their own environments.
  • Peace of mind: This removes fear of fucking something up on the server and having to dig for the backup manually (yay, git checkout).
  • Robert: I'll never have to put up with another episode of "zomg this needs blue and yellow and a grid background, so shell into the server and install my CSS patch or I'm leaving"
  • Progress: Ism and I don't have to be the only people scratching our heads at why the fuck EnigmaBot has all these fucking issues
    • We can take care of separating sensitive information to produce redistributable code up front, once and for all.
    • Someone else can deal with the fact that our current SMF theme is based on ten-year-old code.
  • Appropriateness: We version a lot of dumber projects, Calico being the dumbest to-date.
    • Other people and communities could benefit from the shit I had to go through to hook the EDC up to SMF's database

The idea: EnigmaBot and the SMF/Wiki extensions we have written need placed under version control, possibly in the same repository, at some point down the road. 

Problems we need to address with which this change may or may not help:
  • EnigmaBot:
    • When operators join, they are not notified if they have messages.
    • Some of the repository search features are screwy
      • Something is seriously wrong with !egrep / !lgrep / !etcgrep. It often completely misses search results.
      • !grepnext cannot skip to the next file, in cases where there are nine hundred results in three files. The user is told only that there are 900 results.
      • !eurl is a bit inconvenient; it does not attempt to find a file of near match (eg, by adding .h or .cpp)
      • !eurl can not fetch the next file with a matching name, or a file with a matching name in a matching folder. Try !eurl'ing for SHELL/Makefile.
    • This hasn't been a problem lately, but if an SQL timeout occurs, the bot's next query will fail relatively unceremoniously, but then the connection will be re-established and subsequent commands will succeed. Why can't the current command succeed, too?
  • Forums:
    • The forums are using an SMF 1.x theme, despite being on a (now outdated) version of SMF 2.
    • One (very bitter, but still possibly correct) ex-user reported that this is a violation of the license used by SMF 1. I'll need to do more research on this.
      • I believe that the license only concerns code redistribution (which is a problem if we want to version this forum software!), but,
      • we may well need to update our footer code to include an SMF notice (which I don't have a problem with).
      • My license preference is GPL, so if possible, I would like to have our extensions licensed under it
    • A lot of good features are missing from our theme, due to its age and the consistency of our code at the time (Gary was 17, I 16, a2h 15).
    • The icons are a bit inconsistent, and aren't vectored (I also made them when I was 16).
    • SMF code and the extensions folder will not be versioned. If you want an extension added to SMF, file a tracker artifact.
      • The actual BBCode extension, multiple-verification-answers extension, and any other extensions unique to or maintained by the ENIGMA team will be versioned.
  • Site:
    • The header and footer are dated (as in old), outdated (as in incorrect), and ugly (as in ugly).
    • The transition to a2h's "v5" design will go much smoother in the presence of version control
    • We could really use site scripts to handle release control and package builds
      • The server could package the release zips currently maintained by Robert and Polydip
      • Users could vote (yes/no) whether a release package/zip works for them, and the zips/packages with the highest rating could be listed first.
  • EDC:
    • Written when I was 18 (what does this tell you?)
    • The badge system is not implemented, because I didn't understand how M:N relationships worked in SQL (comments seemed wasteful to me, and badges? Forget about it).
    • The download system is also not modular (you can only give one download link!)
    • Screenshots are unimplemented.
    • There's no way to view games and blogs by most recent activity (one of the things the forums would offer over the EDC for posting games)
    • You have to use external hosting for your games (meaning broken links will abound; cloud hosting is becoming extremely cheap compared to when I was younger
    • Virus flagging and game rating are not implemented. These are absolutely necessary before we start our own hosting and accumulate a large userbase.
    • If we do our own hosting, a file manager will be necessary.
  • Wiki:
    • Either the extensions folder will not be versioned, or pull requests to it will not be accepted. If you want a Wiki extension added or updated, file a tracker artifact.
    • There may or may not be problems with the EDL and YAML GeSHi plugins, both of which were written by me (I know there are problems with the YAML one; I'll fix those at some point).

Writing this has given me carpal tunnel.

Ism and I will get everything moved into a git repository and checked for sensitive information/passwords/etc at some point in the discrete future following discussion here. Any additional problem you have with the above, list them, as they are likely to be dealt with long before the site is on GitHub.

General ENIGMA / Re: Innacurate Framerate Counter
« on: May 26, 2013, 09:45:23 am »
I was going to write a novel about all the SYSCALLs we make being great reasons to put us back on the wait queue, but that would defeat the purpose of this post (especially if the scheduler's involvement was dwarfed by other features of the operating system which are invoked during the call; ie, features of WinAPI, since Microsoft feels that the kernel and window manager are basically the same component).

The point I am making is much simpler, and does not require a profiling analysis:

Robert: STOP blaming ENIGMA for features of your OPERATING SYSTEM. This includes bad calls to system functions slowing down the engine.
polygone: STOP programming ENIGMA to contain features of your OPERATING SYSTEM. This includes prefixing your own [snip]working_directory[/snip] to filenames.


General ENIGMA / Re: Innacurate Framerate Counter
« on: May 25, 2013, 08:11:12 pm »
Make no mistake; physics engines are a great point in favor of having multiple steps for one draw event. I'm sure that Bullet demo Robert keeps posting uses a dozen steps per frame, easily. But they have absolutely nothing to do with the framerate issue. At all. Half the issue with the framerate arises from all the shit that happens when redrawing the screen. (That, and the fact that Sleep() can't sleep for less than a millisecond, thereby eliminating framerates past about 700). The other half is not actually an issue unless you have a small IQ.

There was no problem with the system as it was before these "fixes" insofar as having five step events to a draw event is concerned. You just set an alarm in a control object and call screen_redraw() every five frames, with automatic draw off. Not even the vertical sync will stop you, then.

The vertical sync is our first framerate "problem." It just makes sure the monitor (a 60Hz or less device) is not scanning when you go to dump your buffer to the screen. It doesn't stall your game to ensure that you only have 53 frames per second; it stalls it to ensure that you don't *draw* more than 60 times per second. So if you're not drawing, your graphics card can't stall your program.

Now, the other "problem," which is even less a fucking problem, is the system scheduler. I've mentioned this like three times now. The system scheduler is the piece of the kernel responsible for deciding what programs get to run when, because as you may have forgotten, your empty game is not the only thing running on your machine. Windows is fat; it needs the CPU to bask in. And also, you probably have other programs open. Point is, if you aren't using any CPU, just sleeping periodically, the scheduler will have no inclination to give you priority over Windows Calculator, which needs that CPU time to send usage data back to Microsoft to help improve your customer experience.

So basically, your program has the CPU, uses it for maybe 2K cycles between SYSCALLs, and then makes another SYSCALL to sleep. The scheduler doesn't want anything to do with you. It'll treat you just like Calculator, and call you when you next click the window or when the number of milliseconds you asked it to sleep has expired, and it's done dealing with everyone else.

So basically, this huge, cruel and unusual problem (:() is only huge, cruel and unusual (:() because your system doesn't want to waste CPU time on a program that doesn't do anything. (:)) And users are too damn dumb (:() to figure out, hey, maybe I should conduct my stress testing using actual stress!

General ENIGMA / Re: NaturalGM Object Editor
« on: May 25, 2013, 12:58:25 pm »
I don't call everyone idiots; just cheeseboy and polyfuck. Though I'm rethinking my policy.

In general, the only numbers that should appear in your code are 0 and 1. If you decide that you want your game to run at a framerate of 60 later on, instead of 30, you will not have to change that code to make it 3 seconds instead of 1.5, unlike if you had used 90. So basically, it's just good practice.

If I thought you'd ever reference the invincibility time elsewhere, I'd have told you to use [snip=EDL]room_speed * invincibility_time[/snip], and set invincibility_time to 3 in the Create event.

Issues Help Desk / Re: Mac help
« on: May 24, 2013, 03:17:16 pm »
I think XCode ships with 100% of all libraries ever written for OSX. I also think TGMG made sure took care of the rest of the setup and binary acquisition.

Announcements / Re: Huge speed increase
« on: May 24, 2013, 03:03:16 pm »
forthevin: Apparently either I was hallucinating last night or the GNU for Windows implementation includes the POSIX [snip]usleep()[/snip] method. Could you refactor your code to use that? Other parts of the engine on Windows are already using it, so apparently it's not an issue.

EDIT: Also, check if that implementation contains [snip]nanosleep()[/snip] in [snip]<time.h>[/snip].
Some of this shit might need to work with [snip]<features.h>[/snip] to make sure it builds on everything, but frankly, I'm just sick of this mess.

General ENIGMA / Re: Innacurate Framerate Counter
« on: May 24, 2013, 02:52:43 pm »
That might be okay. What I'm thinking is using [snip]usleep[/snip], which apparently some holy GNU implemented in MinGW. [snip]Sleep[/snip] is not guaranteed to return, ever, but I believe [snip]usleep[/snip] is.