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

General ENIGMA / Re: The last of the engine compile warnings
« on: June 17, 2013, 12:07:55 pm »
I've committed the changes. If someone could confirm that anything which happily used the particle system functions or ds_grid functions is still working, that would be great.

I have not removed warnings from the GL3 graphics system or the Win32 folder, or for that matter, any system other than the default Linux systems. Those might follow shortly.

General ENIGMA / The last of the engine compile warnings
« on: June 17, 2013, 09:04:47 am »
I was going to get started on a couple of the issues in the tracker (actually, I've done so), but the engine was so full of warnings, I had a hay day. I've created a new issue for the warnings that were my fault. The majority of the warnings were for variable-length arrays and floating point comparisons. I've corrected the floating point comparisons using a new header called <floatcomp.h>. From now on, instead of f1 == f2, include that header and use fequal(f1, f2). There is also an fnequal, fzero, and fnzero, which I trust are self-explanatory.

The only source that makes an exception is var.h in its division-by-zero checking. For that, it assumes only division by exactly zero is useful to report. If you think it's useful to strictly compare against zero elsewhere, let me know. The point of the header is mostly to make it easy to change out comparison behaviors, depending on need.

Other warnings that remain:

Universal_System/spriteinit.cpp: In function ‘void enigma::exe_loadsprs(FILE*)’:
Universal_System/spriteinit.cpp:105: warning: variable ‘collision_data’ set but not used [-Wunused-but-set-variable]
Forthevin: How are you accessing mask data in your precise collision system? It isn't being passed in from the sprite load mechanism.

Graphics_Systems/OpenGL1/glew.c:11678: warning: no previous declaration for ‘glxewContextInit’ [-Wmissing-declarations]|
Graphics_Systems/OpenGL1/glew.c:11960: warning: redundant redeclaration of ‘glxewContextInit’ [-Wredundant-decls]|
Our copy of glew is fucked up. Not touching it.

Universal_System/resource_data.cpp: In function ‘bool enigma_user::script_exists(int)’
Universal_System/resource_data.cpp:82: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Signed-unsigned comparison in script_exists (#228)

I'll commit this shortly.

Warnings to other developers:
Forthevin: I had to make a couple of your particle methods static.
Polygone: I tore the shit out of your grid functions.

General ENIGMA / Re: hey plions
« on: June 16, 2013, 02:47:34 pm »
I have done my best to use it where possible. I'm trying to avoid breaking the code in the process of removing those warnings, and fixing the disastrous way in which the code treats typename t and variant as interchangeable types.

I've completed the redecoration, at any rate. I have about 150 more warnings to fix, and then I'll commit it, and we can attempt some regression testing.

For the record, this has been fixed. It was discussed and fixed over IRC.

General ENIGMA / Re: hey plions
« on: June 16, 2013, 12:31:07 pm »
GCC has fifty warnings flags that need enabled (and a few that need disabled, because I fell they -should- be standard by now, and will be soon enough). One of ENIGMA's biggest offenses is use of variable-length arrays. It's a GCC extension that's too convenient to ignore.

I'm hung up on polyfuck's data structure code. It's a typecast nightmare. Total mess.

General ENIGMA / Re: hey plions
« on: June 15, 2013, 08:50:10 pm »
Because the engine needs it, too. It isn't just the compiler. ISO 11 is becoming commonplace: the game is set; the cards are on the table. I definitely need to concern myself with the compiler, but that'll only do us so much good if the engine is a wreck.

Make no mistake, the engine is a wreck. It's much better since you added that Bridges folder as I asked. One of the changes in this huge shitball I'm about to commit moves the rest of the X11 code there that shouldn't be in with the rest of the engine. It's amazing what you can find by enabling all compiler warnings.

It's also amazing that no one else fucking enables compiler warnings, or reads the compile output in ENIGMA—half the warnings I've fixed are checkable with the default C::B build settings. Not that anyone maintains the CBP. I committed a huge fix in that not long ago, and have only fixed more of it now.

General ENIGMA / Re: hey plions
« on: June 15, 2013, 05:20:00 pm »
Don't worry, forthevin; I've already corrected this and will commit it with countless other changes, soon.

For future reference of those who are concerned, const struct &x = y to copy big structs by reference. Lose the const to allow assigning to its members.

General ENIGMA / hey plions
« on: June 15, 2013, 07:29:33 am »
Two quick items:

(1) Your "fix" for arbitrary dot-access variables isn't working. I've had fifty people reporting segfaults in the compiler recently, and Frogg reported that someobject.unusedvariable[0] is the same object for any unusedvariable. So basically, your fix apparently doesn't work, and in development teams, correlation usually does imply causation, so I'm guessing the segfault is from your shit.

(2) You do this practically everywhere:

Code: [Select]
                enigma::tile t = dit->second.tiles[i];
                t.alpha = 1;

It doesn't do jack shit without an & after enigma::tile, or enigma::room_background, or any of the other fifty places you do it.


Okay, I'll just start listing things.

(3) Does your fucking tile system assign an alpha to every single tile, but use it exclusively for tile_layer_show/hide? Is it actually drawing hundreds or thousands of completely transparent tiles when a layer is hidden?

I won't even blame you for that, because at least you implemented it. But holy shit.

Proposals / Re: Wayland support?
« on: June 14, 2013, 05:38:00 pm »
I can't predict what will happen with either project, but I have every confidence in Canonical to crank out a shitty Mir release and force it on people anyway, probably by 14.04. We'll decide which (if either, and not both) project to support, then.

Proposals / Re: Wayland support?
« on: June 14, 2013, 10:38:16 am »
Wayland was going to be the new X; now isn't, because Canonical wants their own. I'm not saying that it won't be adopted by some distributions, just that it will no longer be the new X, because Canonical killed it.

General ENIGMA / Re: Start moving in one the selected directions
« on: June 14, 2013, 10:36:24 am »
Are you getting any exceptions in the terminal output? Or is there even a terminal, now that everyone's using that zip file "installer"?

Issues Help Desk / Re: Input box popup
« on: June 13, 2013, 08:11:31 pm »
The get_string function is part of the widgets library; you'll need to select one. On Linux, this is a hassle, because only GTK is supported, and GTK is a fat, ever-changing library. To use widgets on Ubuntu, you'll need to install the libgtk2.0-dev packages. Unfortunately, I don't remember their names; I usually tab complete for them. Once you get the widget system working, you should be able to use get_string.

Proposals / Re: Wayland support?
« on: June 13, 2013, 08:05:13 pm »
Wayland is dead. Mir killed it. We have no plans to support either; we'll probably make you use a different library over the two, unless absolutely necessary. I think GTKmm supports GL contexts, so that's probably where we'll go.

We originally used X11 because it was light and portable. The new trend is fat and specialized. Hence an increased likelihood of our supporting GTK or Qt.

I've recently written (well, been forced to write, really) an NES Mario Bros clone that incorporates a relatively robust multiple-collision-handling system. I believe I can port it to ENIGMA to be offered as an alternative, more invasive but more intuitive collision system. It handles the "hard parts" of collision handling for you, such as informing you which sides were contacted during the collision, what your velocity should be changed to, and where your position should be placed (all the features needed to implement move_contact and move_bounce, the two most-used functions by utter novices).

I'll check in this weekend with my plans to port it, or a ported version of it, depending how jumpy I am feeling.

General ENIGMA / Re: Start moving in one the selected directions
« on: June 13, 2013, 03:47:31 pm »
Java's always been bad at drag-and-drop. At one point it would crash the X server if a certain number of conditions were right.

Try just right-clicking the tile. That appends it to your code immediately.