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: C++, Linux and 39DLL.
« on: May 14, 2010, 08:46:20 am »
He knows. Hence option 5

Announcements / Re: Fixed those Makefiles
« on: May 14, 2010, 08:04:12 am »
You have local shops with computers running X? Most people around here don't really know what Linux is...

Issues Help Desk / Re: C++, Linux and 39DLL.
« on: May 14, 2010, 07:54:49 am »
I was wondering that myself, really. I mean, not how to make a server, but how to bring multiplayer functions to ENIGMA cross-platform.

I, unlike the Game Maker brigade, see the potential and beauty in importing all-popular projects such as 39Dll. My thought was a mix of #1 and essentially #2, though ting wasn't my personal thought. Perhaps ting is worth looking in to for it. In other words, I want to incorporate a cross platform version of 39Dll into ENIGMA's default functions.

You're thinking of disaster cases on a forum regarding at least a mildly better option. ENIGMA is like five revisions away from letting you #include ting and use it in your scripts, which I imagine you'd like better than being lost in the world of C++ without a graphics library.

I don't want to begin a cross-platform port of 39Dll just now, for obvious reasons. Perhaps you should turn this into a development plea for ENIGMA and someone will take it on themselves more immediately. Otherwise, I'll get to it "eventually" but would recommend--since I assume you don't wish to wait--doing the same; using ting to recode the contents of 39Dll. If you succeed, and it works well, and you give it to us, we can add it right in as part of the language.

Not sure how similar ting is to WinSock. Good luck either way.

Announcements / Re: Fixed those Makefiles
« on: May 13, 2010, 10:38:54 pm »
You know, few things are more annoying than your OS dying because Java really blows on it.

Issues Help Desk / Re: Physics bugs
« on: May 13, 2010, 08:01:05 pm »
I'll also inform you that ternary works in ENIGMA. (Y)

Proposals / Re: Tiering vs Components
« on: May 13, 2010, 07:58:58 pm »
The point of this system is not to implement separate debugging. That never had -anything- to do with the point. I explained that if I need debugging done, a single function call will be inserted. And I did give a tier implementation; the rest differ only in the names of the variables declared which can be inferred. I don't feel like posting them; I know what they look like, and anyone who wishes to see them can use SourceForge's SVN browser.

And yes, you made that apparent by including X and Y in with the sprite component, which I regard as a bad move. And it doesn't matter how many configurations you propose; I've already went through them all and I can't find one less outwardly dependent on everything than the configuration established with my tiers. You should never, ever, ever, ever, ever, ever (and do note that I typed manually every ever ever), include the 2D sprite component/tier with a "focused" or "specific" 3D component/tier. 3D games don't use sprite_index and image_index, except in GM. So how does the tier system provide for that? It already does! Nothing changes, it's as simple as that. Now, when you decide you want to include a more specialized system for 3D, you drop the planar tier; you drop instance_nearest for instance_nearest_3d, you drop bitmasked-based place_free and whatnot for yet-unplanned model collision functions; you drop anything that was based in design and principle for a 2D game in favor of the 3D equivalents.

The tier system implements a total of *does some counting*... zero functions. There's nothing in them to debug. Functions like sprite_draw, should they under any circumstance require debug information, will have it called as an external function via a macro. This isn't negotiable in the tier system, and the component system isn't worth it for that one feature, outside of which nothing is offered.

Announcements / Re: Fixed those Makefiles
« on: May 13, 2010, 02:30:16 pm »
I'm not sure if Retro's makefile could magically discern what OS you are on, but mine can't. From the main directory's makefile, call make ENIGMA PLATFORM=linux.

And yes, threading and console output would be nice. If you like, I can prefix messages to redirect with "enigma: ".
Don't worry, compile is only slow the first time, then it completes in seconds.

Proposals / Re: Tiering vs Components
« on: May 13, 2010, 02:24:37 pm »
And you keep missing the point that we are discussing ENIGMA's lowermost systems. And as a side note, I have no debug code to add to tiers; nothing can possibly go wrong with them until you start linking in and using systems that aren't accounted for, which the compiler makes impossible.

"What you've thought about more are the specific dependencies present in a GM-like system."
And this is precisely what we're debating. All that thinking considered, tiers appear to me to be the perfect method for the key systems.

"Wherever you put coordinates, it needs that component or tier. There is absolutely no difference in this respect."
Good, simpler system wins.

"Dependencies are resolved better with components because they're more specific- you can have something depend on one other section rather than all the others below it, you can have two depend on each other, etc."
Yes. Now think about that in the context of the systems we're debating. If every tier in my system was likewise paired with a component in yours, the relative dependencies would be exactly the same. Your sprite component still needs the 2D component, your collision component still needs the sprite component. There is neither an audio tier nor component. I have no debug info to pile onto either system, nor anything else to make use of the features components offer. All they'd do is ugly up my code and slow the system (yes, minutely, but as I've said and will continue to say, I'm accounting for each little piece).

Proposals / Re: Tiering vs Components
« on: May 13, 2010, 09:08:32 am »
"They may be readable on their own, but less, more focused code is always  more readable than more, unfocused code."
You'd best define focused if you're going to assert that yours is more so.

"Your code would be much longer, so you just omitted most of it and basically pretended the entire system. It's no wonder it's more readable here."
Is this your argument? My code is redundant, making it very simple for our zip-like memories to generalize them without having to examine them constantly. And considering tiers are more efficient nonetheless, I don't see how this is a problem.

"yours is coming from a long-standing plan. You've thought about the dependencies more, you can reorganize the components if you feel like."
And after all this thought, I say tiers are the way to go; you disagree. That implies you still feel you know better. How did that help your argument?

"you can reorganize the components if you feel like. Put coordinates in the collision component and pass it the other way."
I could do the same thing with tiers; it'd be a huge pain in the ass and it'd be counter-intuitive. Instance_nearest doesn't need the collision system or the sprite system; it just needs X and Y. Yes, you showed how to resolve those dependencies; they're easier with tiers, too, as you've agreed.

Announcements / Re: Fixed those Makefiles
« on: May 13, 2010, 08:21:08 am »
I did so in R3 where the only compiler we'd be using was the native GCC, but accounting for the Wii, I realized we would need makefiles at some point. I still didn't want to, so I considered the full set of benefits and flaws that would come with it;

- Labor. Oooh, labor.
- Any system under Platforms/ or Graphics_Systems/ could be compiled without ENIGMA even knowing they exist.
- - - This means that more systems could be added without any further hard-coding in the compiler.
- Make would enable compilation for more fragile systems, such as the Wii, which always use makefiles to get the job done right.
- Make would ultimately handle dependency resolution for me, compiling only what needed to be (as it does now).

At that point, it was clear that whatever work it took to learn make and write makefiles, even for newer systems down the road, it'd be worth it.
So I went the extra mile and wrote a shell script to write makefiles for me/other developers.

Also, it should correctly locate Make on Windows now, if anyone would bother to test 218.

Proposals / Re: Tiering vs Components
« on: May 13, 2010, 08:14:10 am »
Last I checked, cout << 's are usually pretty readable. Even when called debug_print.

I included a tier below. The others look identical, save the names. Somewhat of a nice part about tiers, really. My code would be much bigger, though; not without justification.

Your code is set up such that a separate component needs coded for a game that doesn't want to use sprites but still would like to use instance_nearest. So much for reusable behavior.

Oh sure, you can separate it into another component, but then an amazing thing happens; each component is dependent on another, kinda like my tiers. Astounding, really. It exhibits the same behavior.

General ENIGMA / Re: ENIGMA's value
« on: May 13, 2010, 06:51:52 am »

General ENIGMA / Re: ENIGMA's value
« on: May 12, 2010, 06:54:45 pm »
That may hold. I was referring to the fact that my incentive behind developing ENIGMA isn't to get paid for the hour, which will happen whether anything gets done or not; the people off whom that calculation is based put in what effort it takes to not get fired/stay on the boss's good side.

Off-Topic / Re: FREE PORTAL
« on: May 12, 2010, 06:52:03 pm »
It's "If at first you don't succeed, skydiving is not for you."

Proposals / Re: Tiering vs Components
« on: May 12, 2010, 06:48:04 pm »
Your edit doesn't follow; it's okay for your code to be unreadable if it's only unreadable in a sense that you don't care about?