Pages: « 1 2 3
  Print  
Author Topic: Massive GL3.3 changes.... again  (Read 11175 times)
Offline (Unknown gender) TheExDeus
Reply #30 Posted on: November 04, 2014, 02:41:40 PM

Developer
Joined: Apr 2008
Posts: 1872

View Profile
Alright. I just reverted the xlib changes. Now please try again. I have installed Ubuntu on a virtual machine, but sadly, that doesn't allow me to use new graphics functionality, as the gpu is virtual as well. So I ended up without GL2.1 support max. But I could compile it without errors and run GL1.1 until surfaces were used. Then it breaks, as the virtual driver doesn't support framebuffers.

So on Linux try all the examples, but ignore minecraft bug, as there is a problem in draw_getpixel, not drawing itself. I will try to get ubuntu somehow going (I guess in dual boot) and try testing again.

Can everyone please test this, hopefully, final version? It works for me on Nvidia and AMD.
Logged
Offline (Unknown gender) sorlok_reaves
Reply #31 Posted on: November 09, 2014, 10:56:21 AM
Contributor
Joined: Dec 2013
Posts: 261

View Profile
Testing results on Linux Mint:

Minecraft: Shows consistent behavior on GL1 and GL3. The world is still empty, but block placement and movement works.

Shaders test: Crashes ENIGMA. I'm looking into this.

Project Mario: Shows the opening title screen, but hangs, spinning forever, on a black screen when trying to load the world. I'm looking into this too.


Edit: Shaders test works, but with a lot of tearing. Note that this tearing is not present in screenshots:
http://i.imgur.com/PGxJqyQ.png
« Last Edit: November 09, 2014, 11:05:27 AM by sorlok_reaves » Logged
Offline (Unknown gender) TheExDeus
Reply #32 Posted on: November 09, 2014, 01:55:55 PM

Developer
Joined: Apr 2008
Posts: 1872

View Profile
Compile in debug mode and try "gdb compiled_game.tmp" and see where the segfault happens. For me it happened in "surface_reset_target()" because the driver I was using inside the VMWare didn't support much. Another thing was loading and using resources. Project Mario tries to play some audio resources it doesn't load, so if there is no "== -1" checks, then it crashes at that screen. I did add those checks to audio system however. Also, when running mario you must do it from the directory where all the mario files are.

Is the glass cube in shader example also visible? I'm not sure what would cause the tearing. Maybe flickering on the glass surface, but not tearing.
Logged
Offline (Unknown gender) sorlok_reaves
Reply #33 Posted on: November 09, 2014, 04:29:25 PM
Contributor
Joined: Dec 2013
Posts: 261

View Profile
Ah, thanks for the hint. Turns out I was using an old PM file. It works fine now. (The window is "squished", but this was fixed on master, so you'll get it with the merge.)

What do you mean by the "glass cube"? Can you provide a screenshot of how it should look?
Logged
Offline (Unknown gender) TheExDeus
Reply #34 Posted on: November 09, 2014, 04:44:54 PM

Developer
Joined: Apr 2008
Posts: 1872

View Profile
Like the screenshot in the original topic:
Logged
Offline (Unknown gender) sorlok_reaves
Reply #35 Posted on: November 09, 2014, 08:34:01 PM
Contributor
Joined: Dec 2013
Posts: 261

View Profile
Oh, I certainly don't see it. Is there a way to change the zoom level? The default view starts out very zoomed-in.
Logged
Offline (Male) Goombert
Reply #36 Posted on: November 09, 2014, 11:30:21 PM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3110

View Profile
I would like to add Harri that I am planing on wrapping up LateralGM 1.8.7 soon after some additional fixes and integration of other new features.  I would like to have the OpenGL fixes in so that I can also fix the Direct3D surfaces. But we should decide on whether we want to add a draw_set_viewport function that does not scale the viewport and a screen_set_viewport that does scale the viewport to screen scaling coordinates or perhaps just add a booelean scaleToWindow to the existing function. But anyway I would like the GL3 fixes to be finalized so it can also be included in the new Portable ZIP alongside sorlok's array length functions and the new LGM.
Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Unknown gender) TheExDeus
Reply #37 Posted on: November 10, 2014, 11:54:01 AM

Developer
Joined: Apr 2008
Posts: 1872

View Profile
Quote
Oh, I certainly don't see it. Is there a way to change the zoom level? The default view starts out very zoomed-in.
Zoomed in? You should be able to move with WASD and look around with mouse. The FOV doesn't seem to be really wrong in your screenshot, but it's hard to tell.

Quote
I would like to add Harri that I am planing on wrapping up LateralGM 1.8.7 soon after some additional fixes and integration of other new features.  I would like to have the OpenGL fixes in so that I can also fix the Direct3D surfaces. But we should decide on whether we want to add a draw_set_viewport function that does not scale the viewport and a screen_set_viewport that does scale the viewport to screen scaling coordinates or perhaps just add a booelean scaleToWindow to the existing function. But anyway I would like the GL3 fixes to be finalized so it can also be included in the new Portable ZIP alongside sorlok's array length functions and the new LGM.
I'm not sure either. I think either way is fine if by default it works like it should. You can then allow users to call those functions as well, but not sure what use they really would have. In my mind when you bind a surface, it should have the surface as the viewport, so you can draw on it like you would on screen. And draw like on an arbitrary size monitor. If a person wants a different viewport or projection, then he should set that AFTER binding the surface. Just like GM.
Logged
Offline (Male) Goombert
Reply #38 Posted on: November 10, 2014, 03:34:38 PM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3110

View Profile
Quote from: TheExDeus
If a person wants a different viewport or projection, then he should set that AFTER binding the surface. Just like GM.
Actually, that's just it, in GM you can't set the viewport on a surface because the only way to set the view in GM is the built in variables which do not affect surfaces. This is exactly why I added screen_set_viewport to ENIGMA.

So we either need to have screen_set_viewport(boolean scale); view scale controlling whether it takes the scaling options into account to scale or maintain aspect ratio, if it is false then it just passes the viewport the user provides which would be the case with surfaces. Or we could break it into two functions screen_set_viewport which scales the provided viewport to the screen, and draw_set_viewport which just sets a generic viewport without scaling it for use with surfaces. It's up to you but this is how I wish you would fix it. Additionally as I suggested on GitHub, try to use a negative viewport to flip the rendering upside down on the surface, if we can do that to flip the rendering on surfaces, then I suggest we also add the function surface_set_viewport
https://github.com/enigma-dev/enigma-dev/issues/861#issuecomment-62361596
Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Unknown gender) TheExDeus
Reply #39 Posted on: November 17, 2014, 07:37:45 PM

Developer
Joined: Apr 2008
Posts: 1872

View Profile
I don't think it can be fixed with glViewport and scissor functions. Here it requires the matrix to be changed and there is a problem. I can change the d3d_set_projection_ortho() in surface_set_target from "d3d_set_projection_ortho(0, 0, surf->width, surf->height, 0);" to "d3d_set_projection_ortho(0, surf->height, surf->width, -surf->height, 0);" and it will work fine. But then whenever the user tries to do anything with the matrices that require an identity (like d3d_set_projection_scale()), then he will have to manually flip it again. So this will fix many cases, but not all. Now sure what to do. I think this is basically the modification I wanted previously, but we used gl matrices previously, so we didn't want this solution (glScale(1,-1,1) looked ugly).

edit: Good news is that the shadow example here (http://enigma-dev.org/edc/games.php?game=62) actually works faster now. Previously in GL1 it was 2285FPS. Now it's about 2350FPS in GL1.1 and 2810FPS in GL3.3 (with all the lights placed in the same positions). So we have improved.
« Last Edit: November 17, 2014, 07:44:03 PM by TheExDeus » Logged
Offline (Male) Goombert
Reply #40 Posted on: November 24, 2014, 03:24:02 PM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3110

View Profile
You're right, I tried flipping the views, doesn't seem to work. Another possible solution is to just transform the texture coordinate matrix when a surface texture is bound, this would make surfaces work as textures in 3D as well as 2D.
Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Unknown gender) TheExDeus
Reply #41 Posted on: November 24, 2014, 05:28:43 PM

Developer
Joined: Apr 2008
Posts: 1872

View Profile
In GL3 there is no such thing as texture matrix right now. And as it is seldom used, then I wouldn't really want to add it just for this.
Logged
Pages: « 1 2 3
  Print