Will do and how do I pass the second set of value (model view) ?

Uh yeah, just pass the offsets to d3d_set_projection ortho.

Anyway, I only have a few more that work for me.
0.175,0.175 and 0.175,0.175
0.275,0.275 and 0.175,0.175
0.175,0.175 and 0.275,0.275
0.6,0.6 and 0.4,0.4
0.4,0.4 and 0.6,0.6

Try themtomorrow. The only way this would not be an issue is we could use the one that works when not in fs and do real fullscreen then the display resolution would 1v1 with the game resolution and one of those would work in both cases.

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

0.1875,0.1875 and 0.1875,0.1875

Complete mess   both fs and window bad text. scroll ok.  You see I have not had any scrolling issues. Now I remembered why I never laid my hands on AMD cards. The only shit from AMD I ever owned was CPU, and the only decent CPU I had from them was the Phenom II X4 965.... Now no more AMD I use Intel CPU and I couldn't be happier. No more shitty chipsets to deal with

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.

Ok the Dr. is in with the results
When I mention borders they occur only on screen resolution higher than 1600x900 for all tests. Anything at or below shows no border.

0.00,0.00 and 0.25,0.25
text ok - scroll ok - border top left

0.25,0.25 and 0.25,0.25 (original settings)
text bad - scroll ok - border top left

0.25,0.25 and 0.125,0.125
text ok - scroll ok - no border

0.125,0.125 and 0.25,0.25
text ok - scroll ok - no border

0.375,0.375 and 0.375,0.375
text bad - scroll ok - no border

0.125,0.125 and 0.375,0.375
text ok - scroll ok - border top left

0.25,0.25 and 0.375,0.375
text ok - scroll ok - no border

0.375,0.375 and 0.25,0.25
text ok - scroll ok - no border

0.375,0.375 and 0.125,0.125
text ok - scroll ok - border lower right
=======================
So the combinations that work for me
0.25,0.25 and 0.125,0.125
0.125,0.125 and 0.25,0.25
0.25,0.25 and 0.375,0.375
0.375,0.375 and 0.25,0.25

I didn't see the scrolling issue on any test.
So since 0.375 is recommended we should probably pick from one of the last 2.
The rest is in your hands.

If you need any more info or testing let me know. 

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 ...

difference, a properly coded HTML5 port should function better than GM's old interpreter/runner.

That's a big statement there, and not too encouraging, and would mean their interpreter / runner is really bad.. 

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.

Ok I don't know if this is in relation to the latest fixes in #723, and will wait for Robert's input on this, but apparently the half pixel adjustment is no longer needed after #723 ?

I fixed this by editing GLMatrix.cpp and GL3Matrix.cpp and commenting out the added offset codes for the HPA.

Code Select Expand


void d3d_set_projection_ortho(gs_scalar x, gs_scalar y, gs_scalar width, gs_scalar height, gs_scalar angle)
{
    // This is half-pixel alignment, 0.5 only works for some graphics cards, 0.25 works best for Nvidia, AMD, and other common graphics cards and drivers.
   // x += 0.25f; y += 0.25f;


The last line is the one I commented out.

Clean built and it worked for both gfx systems.

Before recent merges, this was required to display fonts properly.

Does this have to do with some of the recent changes made to 723?

If I uncomment and add them back, the problem is back.

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

Code Select Expand


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.

Yeah there are lots of good ideas, but as said many times, lack of developers and time

If I'm not mistaken GM did have something similar.I forgot what it was called but remember that thing they had where you could run your games through a website, by installing a plugin / addon? They probably removed it / discontinued it because of their multi platform one-size-fits-all-we-dont-wanna-work scenario.  They clearly showed their intention on making their product compatible to all platforms and that they won't work to accommodate any specific platform on its own.

But you have a point TKG.

and you're right it probably won't happen anytime soon, there are probably higher priorities.

And you're right, nobody wants to play shitty slow html5 games on their mobile........
Yet GMS allows for PS3, PS4, and soon other consoles - so I'm quite sure people will enjoy playing pixel land and the nice GM ports on their PS4 on their 60' TV ! 

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.

I don't think it works that way, if only it were really that easy   There would probably need some changes hardcoded in ENIGMA itself (components), etc.  Your compiled game is linked to an engine.  There would have to be many changes in the engine to support other platforms.  For example, currently OGL1, OGL3, DX9 is supported but no OGLES yet, that would be required for Android, etc.

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.

Wow this is a real mess.  I really hate to see FAKE and ENIGMA in the same sentence.  It reminds me back in the days of GM8 and older, they used "fake" full screen.  Remember, when there was screen resolution changes done inside a game it would fuck up people's desktop icon ? I was not even aware fake FS was used here, lol!

it's hard to give an opinion without testing anything, what are the implication for windows development, will this affect scrolling games? Will we still be able to use view ports, what other consequences to gaming, performance, etc.  Please provide more info. If this means improving speed and how things are done then no question about it.  What are the implications on the maintain aspect ratio / full scale manual scale in the LGM IDE, will these still function? etc.
Gotta give us more info