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

Proposals / Re: GL3 changes from immediate to retained mode
« on: July 31, 2013, 07:25:33 AM »
The point of the GL3 graphics system is to assume that the hardware supports VBOs and shaders, as opposed to call lists and matrices.

This has been planned for a loooong time, but has only recently begun being implemented.

Purging immediate mode from GL3 is certainly a goal. Texture batching is also an interest, if possible.

If you're getting 50,000 sprite draws at 30 fps, my guess is that you have the batching on at full power. What I mean is, try drawing an arm sprite, then drawing a torso sprite over that, then drawing another arm sprite over that. You'll probably be disappointed.

Proposals / Re: Vertex color
« on: July 30, 2013, 02:50:28 PM »
Erm. I was speaking on the pretense that this was for the newer systems with shaders.

I was also working with the pretense that this was to emulate GM's exact behavior when intermixing calls with and without _color. Even with GL lists, if you draw one red vertex, one colorless vertex, one green vertex, and then another colorless vertex, the two colorless vertices will receive, respectively, red and green. Just how the pipeline works. GM's behavior could be simulated by pushing and popping the color in the list where needed. The boolean wouldn't really be required otherwise, as not specifying a color just means not changing the current color.

Now, with shaders, the boolean would need added to the vertex format to simulate GM's behavior. The boolean in RAM could be useful for determining the required vertex format and possibly shader—I actually really like that idea.

Proposals / Re: Vertex color
« on: July 30, 2013, 10:30:27 AM »
The space wasting is only done until d3d_model_primitive_end() as then all the vectors are destroyed. And I don't know how specifying vertex formats will help here.
"Destroyed" and "moved to the GPU" are two very different concepts. They exist *somewhere*.

I'm not sure what to make of that behavior. I guess your boolean idea is acceptable.

As an alternative, we could allow a secondary alpha parameter, which specifies the amount to use of the model color vs the draw color.

Indexed palettes are a third option, but an uglier one.

General ENIGMA / Re: DirectX Image formats and Fonts
« on: July 30, 2013, 07:20:08 AM »
I still am uncertain what to do with formats. I think the best course of action is to assume that there are differences in the formats that will be offered by each system's base installation, and that the user will only choose extensions for codecs/formats that are missing. So basically, the LoadPNG code would go in an extension, and would register an image format reader. Before loading any image, the loader function cycles through those loaders and asks each one, "can you load this?". If the extension returns true, it is asked for the data, and the search is over. Otherwise, the next extension is asked. When all extensions have been asked, the data is handed to the base system. In GL's case, that means it's a bitmap, or you're SOL. In DirectX's case, I guess that means it's .bmp, .dds, .dib, .hdr, .jpg, .pfm, .png, .ppm, or .tga, or you're SOL.

As for fonts, GL can do that, too; we don't want mesh fonts. We want nice, anti-aliased sprite fonts. When ENIGMA used meshes for its fonts, they were infinitely ugly. Moreover, you're also relying on an assumption you should certainly not be making: All computers have the font the user requested available. Turns out, not everyone has the super cool font the user picked out in the IDE that looks kind of alien-y. Guess Arial will work in its place, right? In embracing this, you also damn the font_add_sprite() function. The answer is no, no, no, no, and a thousand times, no.

I have no idea what you're asking with regard to sprites vs backgrounds. Maybe it'd help if you gave the correct link, instead of the first one twice. :P
In principle, the only difference between sprites and backgrounds is that backgrounds are not animated, are used as tilesets (meaning, are much more frequently drawn in pieces), and are more frequently tiled. If your sprite batching can accommodate that, I see no reason not to use it for both. Assuming that's what you're asking.

I promise DX can load from RGBA data.

Supposedly, thanks to the WINE team, it comes with DX10, too. There was just some difficulty using it, which isn't surprising.

Either way, if he's comfortable writing these functions for all of them, that's fine; the ones which are most used will naturally be the most maintained. I fear DX10 will basically never be used, but, que sera, sera.

Proposals / Re: Vertex color
« on: July 30, 2013, 07:02:40 AM »
How does GM allow specifying vertex formats manually?
Code: (GML) [Select]

Notice the UK spelling of color, inconsistent with the other spellings in GM. Can't tell if that's deliberate.

The problem is that it is not how GM does it.
Originally, it probably used the equivalent to GL lists in DX. Meaning it was purely an accident—the FFP expected everything to be in the format which was not disabled expressly. So it automatically assigned vertices the current color. This is likely not something Mark coded deliberately. You could use drawing color to work around GM6 Lite not having draw_vertex_color, but still having draw_vertex. Quite funny.

To emulate it outside the FFP, use draw_get_color().

EDIT: You seem to be under the impression that the currently bound color affects model vertices. That shouldn't be the case if they're in a VBO. In this case, all points will be blended by the current draw color, regardless of their own color or texture.

Off-Topic / Re: YoYoGames Compiler for 300$
« on: July 30, 2013, 06:07:30 AM »
Reading hard? Shaders are going to be given for free
Oh, my mistake. I've never been this wrong in my life. To make it up to you, I'll give you a few acres free beach-front property completely free, if you buy this island off of me.

it seems clear to me that YoYoGames' business model does not rely on building a good reputation amongst its customers. I don't know if that will work out for them in the long run.
Unfortunately, it will. The GMC has users who have been around for a long time and are on to Yoyo's tricks. Most of them are not overly interested in purchasing the newest Game Maker at present, but are waiting to see how the fight ends between them and Unity, as part of them buys into Duncan's promise that GM will be the best 2D game creation suite on the market.

The other 95% of the GMC comprises 14-year-olds who are just happy to try making games. These are in no short stock. They show up, sing Yoyo praises for a bit, maybe buy the cheapest GM, then realize Yoyo's a pit of retarded snakes and leave. This process takes a matter of months. But it's okay; customer loyalty is not required when the product rakes in $300 quarterly.

ENIGMA becomes easy, reliable and stable enough for most users
We've been fishtailing around this enormously. ENIGMA has been about that stable for a total of 20 minutes in its past. I don't see it as very likely for this to happen in the near future, but I suppose time will tell.

What's most amazing to me is how all the problems you named are massive, and concern strictly their business model, and are incompatible with ENIGMA's own. I wholly intend to capitalize on their "pirate sprite" faux pas in the future. If not the other two, as well. Granted, ENIGMA 3.5 Mac is not really supported, either; the key difference is that we refunded everyone who was disappointed in double.

Proposals / Re: Vertex color
« on: July 30, 2013, 05:55:20 AM »
We need to do something about that. The options are to waste space for each vertex format or to allow specifying vertex formats manually (as Yoyo has already done; didn't think they had it in them).

If the vertex format specifies draw color, and no draw color is supplied to create it, the current draw color should be used. It's that simple.

What we should do is just mimic their vertex format functions and then construct the d3d_model_ API around that. So d3d_model_vertex_color() would just be a wrapper to whatever new primitive function they use. That function would deal with passing the current draw color to the vertex format if not otherwise specified. The only issue with that is the default draw color of black; in general, the color will have to be white if they want their models to look right.

The intention is to keep the interfaces all but identical, forthevin. I believe it's in our best interest to encourage DirectX on Windows and OpenGL on Mac/Linux. The differences in behavior should be minimized, if not eliminated, to prevent any incidents with porting.

This will be necessary, anyway, for when we start "officially" supporting embedded systems.

Personally, though, I think DX9 Is a step in the wrong direction. Nothing written for it will be compatible with DX10 or 11.

DirectX11 would be my personal choice in target. It works on newer Windows service packs, and on the XBox One, which if anyone actually purchases, promises to support homebrew natively.
Moreover, DirectX11 has this. It's an XNA-like layer over DirectX11. As far as I know, it's .NET free. So you could use its SpriteBatch class for a quick, efficient solution.

Note: All ENIGMA games which use DirectXTK will have to be closed-source due to intentional licensing conflicts by Microsoft.

General ENIGMA / Re: Doxygen Commenting Removed
« on: July 27, 2013, 07:26:38 PM »
Agreed. This takes a lot of the stress off of JDI, so I don't need to focus on its ability to grab that information (though it will still be an objective later on).

Teamwork / Re: Looking for well rounded programmer
« on: July 27, 2013, 02:20:31 PM »
Hi there,

I'm not sure why you're looking for a C++ programmer. EDL (the codename for ENIGMA's language) can be remarkably similar to GML. While it offers strong typing and explicit declaration, both mechanisms are unnecessary. Barring missing functions, and a couple syntactical elements which appeared to be bugs in Game Maker and have therefore been deliberately omitted, EDL is supposed to be 100% backward-compatible with GML. In practice, of course, your mileage may vary, but that's why we have a bug tracker.

Either way, good luck with your search.

Off-Topic / Re: YoYoGames Compiler for 300$
« on: July 27, 2013, 01:13:30 PM »
A measly $300 for shaders? I should stop developing ENIGMA and use GM:S.

General ENIGMA / Re: Scalar Types
« on: July 27, 2013, 06:33:24 AM »
The coordinate space uses the collision system/physics system scalar.

This seems to universally be float.


While this would ideally be done as a complement rather than supplement to manual testing, until the regression testing suite is more complete, I think it's in our best interest to set something like this up as soon as we are prepared for branching. My only major concern is how it will handle things like antialiasing and rounding issues (for arithmetic tests). For example, the test suite might expect a given pixel to be any color between pure blue and pure white, while in fact it ended up being one or the other due to minute hardware differences. Likewise, the suite may expect .1 + .1 + .1 to be roughly .3, while in fact the value differs with the phase of the moon. On a happier note, I have high hopes for its performance with string, data structure, and I/O operations, as those tend to have only one right answer (not to imply that .30000000004 is a right answer to .1 + .1 + .1).

That said, if the system seems to do well in these cases, though, I'm fine entrusting it to the complete task. Especially considering one of the worst (and, incidentally, most frequent) regressions is a complete lack of ability to compile with ENIGMA on one platform or another.

It would be particularly useful if we could get cross-compilation working as part of this system, too, as contention between the tastes and preferences of MinGW on Linux vs Windows have led, on a thousand separate occasions, to the dysfunction of one system or the other. Reports are rolling in now that OpenAL doesn't work at all on Windows, and the simple explanation for this is that cheeseboy couldn't get AL working on MinGW for Linux, so he packaged his half-assed SFML system in his installer without paying any attention to AL. Then polygone and Robert decided, "WOW, A WINDOWS INSTALLER THAT ACTUALLY WORKS," buried my zip patch elsewhere on the Wiki, and put his up as the only installation candidate. Also, the bundled SFML doesn't work on Windows. Look where that leaves us.

The point is, as far as making sure the system actually compiles on each platform, this automated testing is invaluable. Pitted against our current system of "commit everything to master and wait for the flood of bug reports," I think the winner is clear.