ENIGMA Development Environment

How the hell are you criticizing my card? Mine is the one that draws everything fine with no offset, yours is the one that can't round.

LMAO!

BTW, is there a way to dynamically affect this alignment using EDL or GML functions within the game
you mentioned the code in the past...

At any rate, we're still fucked, we need a magic number that works perfect for both of us.

Try this one.
0.125,0.125 and 0.125,0.125

Fs, window, text = bad.
scroll = ok.


There is one little thing I will try tomorrow, not having to do with these settings,
I am calling it a night for today

I will progressively post these as I am testing them:
0.375,0.375 and 0.175,0.175
text ok in window NOT ok in fs.
scroll ok, no border.  When tested at 1920x1080 screen res the numbers displayed well, though certain ones slightly fatter, but to me a test fails if at any resolution it does not show correctly. To me it has to show all resolution ok. the lowest to highest.

Same results for the inverse.

Testing the other pair now.

Right but can you explain why did I have to modify the GL/GL3Matrix.cpp and remove what you added previously, for things to work, when you added them there to fix things in the first place, this is what I am wondering now....... and again, why should I use 0.375 now that removing 0.25 altogether displays fonts fine and background scrolling works ...

It's just possible that it works for one, but doesn't work for the other (GPU differences). What GPU do you have? Maybe 0.375 really is the magic number.

Actually I didn't change GPU or systems.
Initially it was tested by Robert and he also had the problem, so he added those lines and it worked fine.  However, since a latest fix update, even with his new pixel alignment fix, the fonts are not displayed correctly so I had to remove them, and now they work.

My GPU has not changed, it is a GeForce GTX660 Ti SC 2GB

and no, 0.375 is not the magic number unless you want flickering and gaps in scrolling rooms.

As I was testing the new changes since #732, I accidentally ran into the same issue I had with font rendering.  I thought this was fixed with the 0.25/0.25 thing, but now it's back:

To reproduce create a project using OGL1 or OGL3, as both exhibit the problem:

Add to the draw code
draw_text(10,10,"11111111111111111111");

Be it window or full screen mode, not displayed right.

In Direct3D window mode it's ok, but could not test full screen as Direct3D fullscreen is still broke, nothing gets displayed in D3D full screen.

Both GM and ENIGMA use "fake fullscreen" so say you have a room 640x480. When you fullscreen the game the parent window will be 1920x1080 or w/e your display resolution is and stretch the 640x480 child window with the graphics context to fit the area based on your aspect ratio. In any other game it will set your display resolution to 640x480 and just make the 1 window that has a graphics context fill the whole window. The "black bars" are then handled by your display monitor.

Exactly.  In my opinion this the best option, letting your display handling it. Nothing wrong with seeing black bars to the left and right.  If the game sets 16:9 compatible resolutions, the display automatically switches to 16:9, that's how commercial games work.   If I were to now set my monitor to 800x600 I would see black bars left and right.  It's not that bad I mean people were using CRT for years at that ratio   and if I revert to my native resolution, the whole screen fills.   I think any emulation / faking is unnecessary.  Most games don't do that.  Also was not aware GMS did that, I thought they had gotten rid of the fake FS shit ages ago.  From what I recall, real FS is faster (rendering, 3D, etc.).  and last time I checked I had no issues alt-tabbing from commercial games.

Now emulating by using viewport etc, this would have you take control over viewport.  What if we make games and we need to manually manipulate viewport etc how will it be possible since it will already be used and locked.

end up with the whole window being cleared to your background color,

I think that would be quite ugly.  Personally I believe black bars would be a better contrast against any colour.  Personally don't like the idea of filling the entire area with the background colour.....lol that would make it look sort of like Commodore 64 with its foreground/background thingy.

Anyway, people like me don't like this, because well, GM games have a tendency to be shit, be fullscreen, not freeze on lose focus, and capture the mouse and force it to the center of the window, so you have absolutely no way of ALT+Tabbing because of the lack of foresight by budding game developers.

True but that is up to the developer and should always be.  Personally I would have the game automatically go into a pause menu if lost focus and everything paused, AND at the end game I would have it returned to whatever resolution the screen was originally before running the game.  I am aware of certain bad habits people did in GM games.

Also there is one scenario where it is required to manually change screen res within a game in ENIGMA..... One of the changes you made to allow for dual screens, had the side effect that if your viewing area is larger than your display res, the area would be zoomed out - Remember this was seen in TKG's alien game, it scaled fine in GMS but not in ENIGMA, and I later found out that I could fix this problem by either setting my screen resolution = to or greater than the view area of the game.  So this is an example where changing res internally would be critical.

What the hell are you talking about? I'm talking about sacrificing 1 uneeded window, there is just no need for our code to be designed around working two window handles. This does not rule out the possibility of a window_create function. I am actually certain GM has been doing it this way since 8.1, I just can't emulate the "black bars" in full screen mode for some odd reason.

Sure I mean getting rid of unneeded stuff particularly if it has no impact on other things would be a good thing, however not if it causes issue with the views/ports options in the IDE or functions, allowing a developer to fully control them.  Also I have followed GM since the days of Mark Overmars, until now......and I'm quite sure they did major changes to the display/rendering, one of them now is handling real full screen.  I' quite sure they don't use an extra window.

No I did not, I doubt it would affect performance much unless you have a really shitty card and it don't like clearing the background of two windows.

I think my GF 660GTXTi SuperClocked handles it fine But what about a person running your game using onboard video or an old gfx card. ?  Also what about complex games with lots of rendering ?

I think I remember now reading lots on the topic of real/fake fullscreen think it was mentioned that the real FS have higher priority or some shit related to DX, priority or something like that I can't quite remember, it was so long ago.   I remember on older games when alt-enter to put game in windows mode it would run slower and going back to real fullscreen made it faster again, giving it highest priority as opposed to shared, something along those lines.

I have not had a chance to test the new changes yet.  Will do so later, but I'm really puzzled about Ben's sprite issue, it's mysterious I think that there is something outside ENIGMA/LGM causing his issues.

So maybe TKG will be happy when he comes back in a few months from his trip to the sun lol.

Darkstar2, actually it's kind of nice really because it means most GM game don't fuck with your display resolution, it would extremely piss me off if they did. But you

I completely disagree with you.  You'd probably be pissed at most commercial games out there, some impose a minimum resolution others offer you a choice/menu.
Nothing wrong in changing screen res as long as you set it back to its origin once game ends.  Why the HELL would anybody be pissed off if it did not mess with anything else ? In ENIGMA so far I don't see that screen res changing messes anything up.

So which is it now I am confused, does ENIGMA do real FS or fake ? What do you define as "fake" ? is it my understanding that you smply resize the window instead of actually doing a real FS ? that was utter shit, and that was how it was done in older GM.

But the whole point here is that I can emphasis enough, aspect ratio doesn't do shit on XLIB right now, and we can't do this on all platforms, it needs to be more cross-platform so we have consistent behavior. But if we really want I'm sure we could find a way to hack the fuck out of XLIB to do it, but then our code is just shit for every platform instead of simplistic.

Hmm looks like we are getting into some YYG scenarios here, I guess it's up to developers to decide if they want to sacrifice windows for multi platform (as YYG did) or leave things as they are, working at fixing things separately, or for windows first, etc.) In my opinion, since there are probably more windows users, more emphasis should be placed on platform used the most, for now.

Harri, yes that is exactly what Josh said that it was because of OpenGL, but he did not elaborate before leaving. At any rate, my tests worked fine with using only one window and OpenGL, literally everything was working fine, I was just working on fixing it up before I decided to revert it and ask everyone else's opinion.

Did you run any bench ? did we gain some performance gains ?

The lack of blanking between room changes could make for some interesting seamless effects.