ENIGMA Development Environment

You guys are so useless. He doesn't want to share the source code of his game. When you build it it errors after parsing room creation code and says "Error; see scrollback for details" and there is nothing in the scrollback indicating what wen't wrong.

Correct me if I am wrong but TKG also tried removing all the room creation code to no avail.

All I know is they use the native functions on Win32, if GM uses those functions, there should be no reason why numerical keys would not work.

All of the functions are implemented here.
https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Platforms/Win32/WINDOWSregistry.cpp

Can you provide an example GMK or something as well so that I can test?

0.01,0.01 works in Direct3D9 as well and fixes blurry text for me. The pull request can be merged.
https://github.com/enigma-dev/enigma-dev/pull/750

Now it is important to note that font characters in Direct3D9 appear 1px to the left of where they do in OGL, this is further related to the issue we've been discussing. So this is clearly differences in the sampler of the two API's as well as differences in driver implementations of the two API's. Also D3D9 does this whether you have offsets 0.25 or 0.01 or no offsets.

Alright good I was just going to tell you to patch DX as well. But please leave any FS fixes or anything out of this pull request. Anyway, go ahead and send it and I'll tell Josh or Harri to merge it.

Yeah if you notice I used the delta_time or w/e constant to calculate my scrolling background.

Anyway, no I said I don't wtf to your code you sent me in a PM because your rounding was mixed with earlier suggestions we made for vertices, not the projection coordinates. Thus my wtf response.

Anyway, wonderful, good thing it works, and yeah I'm certain nobody would ever have a need for a camera at a half pixel would they? When the camera is at half-pixels all you ever notice are artifacts, it looks the same as if it were at the rounded coordinate except shittier. So am I correct in my assumptions or does someone have evidence to the contrary?

Also, we don't need to worry about this with the perspective function because it shouldn't be used for 2D rendering.

Yeah I like to do things the hard way, plus I don't like using anything built into GM because it's always designed around a fixed time step and not delta timing.

And yes Robert is right, this fix is only a patch, assuming you are on a 0,0 projection view or fixed view that is not negating the +.01 / +.01 fix.  SO, for example if your X/Y projection ortho is set to 0.99/0.99, the result will be an integer and thus negating the fix and the motherfuckers of artifacts will be back!!!  Whatever X/Y you use make sure when added to .01 that it does not = to an integer.

The ortho projection function can be further fixed with the following code.

x = round(x) + 0.01f; y = round(y) + 0.01f;
That stops anybody from negating it. We can also fix it in DX the same exact way. Because round will guarantee it is a whole number with the offset that works for everybody. Ortho projections should never be at fractional coordinates anyway.

My only concern is Josh that it could be getting included incorrectly or scoped improperly, by which I am referring to the connect() function.

Anyway, oddly the function does not get syntax highlighted, so it is not in namespace enigma_user, and clearly not in namespace enigma or we wouldn't be having this issue. It could also be coming from OpenAL because it's dll is showing up when I regex for "connect" other than that only Berkeley Sockets shows.

Also I have tested and have reproduced this bug in an empty game with 1 object with the following code.
var connect;

connect = 5;
And received the same function assignment error as the 11th plague.