Unstable master?

[TheExDeus]

Wanted to ask if Project Mario works in master now? Or I'm just mad? I am making my GL3.3 fixes and couldn't figure out why water wasn't drawing properly. Then I tried master and noticed that there GL1.1 and GL3 also doesn't draw water,. Is this true? Because it's weird, as I thought it ran it just fine. What are you guys running ENIGMA on when testing? I run like 3 example (Project Mario, Minecraft and now my shader example). We really need an automatic testing, because right now it's very hard to catch and fix bugs. Now I need to backtrace to figure out when the bug happened. Also, is text still messed up? At least in project mario it is.
Also, I see a large FPS improvement in GL1 which is nice. I get up to 2300FPS now, instead of previous 1200FPS. I guess that is because of the glList optimization. Having 2.3k FPS isn't really useful for a game, but still. Also Minecraft example ups from 700 to 900. There is a bug though, that doesn't allow GL1 models to be updated (mining in the minecraft didn't work), but I fixed that.

In my GL3.3 Fixes branch I get 1600FPS in GL3 up from 1400FPS in master. So not only it has more features + has no compatibility functions, it also is slightly faster. So after I fix the water and do more testing, it should be good for larger testing.

edit: The bug is in the screen_set_viewport() function. Was introduced when Robert fixed window scaling issues. For some reason it breaks the water, which could also mean it breaks surfaces in general, because  surface_set_target() uses screen_set_viewport(). Investigating the problem.
edit2: Well long story short, surfaces don't need window functions in them. So I removed screen_set_viewport() and replaced them with glViewport and glScissor, which is the only two it needs.

[Goombert]

Yeah I was already aware of it and had plans to fix it, but I was thinking about adding surface_set_viewport function Harri. But then again I still don't know if we want to add application_surface or not.

[Darkstar2]

Yeah I was already aware of it and had plans to fix it, but I was thinking about adding surface_set_viewport function Harri. But then again I still don't know if we want to add application_surface or not.

Wouldn't that cause a performance hit ?

[Goombert]

No actually, it would increase performance for games that scale up because currently we resize the backbuffer and the game gets rendered at a higher resolution. GM always keeps application_surface the same size as the region and then scales it, so when you set the game fullscreen the resolution doesn't increase it just scales, ENIGMA does increase the resolution.

[Darkstar2]

No actually, it would increase performance for games that scale up because currently we resize the backbuffer and the game gets rendered at a higher resolution. GM always keeps application_surface the same size as the region and then scales it, so when you set the game fullscreen the resolution doesn't increase it just scales, ENIGMA does increase the resolution.

I seem to remember some talk about surfaces back at GM, it was not a popular option and people complained of very noticeable slow downs on their mobile port,
and even on windows, I'm quite sure I remember reading about some cons of using surfaces, even for windows export.  Luckily at one time this was optional, but now GMS uses it by default.  Would it be made optional in ENIGMA or forced as in GMS ?

[Goombert]

I seem to remember some talk about surfaces back at GM, it was not a popular option and people complained of very noticeable slow downs on their mobile port,
and even on windows, I'm quite sure I remember reading about some cons of using surfaces, even for windows export.  Luckily at one time this was optional, but now GMS uses it by default.  Would it be made optional in ENIGMA or forced as in GMS ?

Yeah I know what you are talking about and I was thinking about just that. I really don't understand how it could slow down unless they were doing something wildly wrong. You see just creating the surface takes some more RAM, obviously, but then when you render your game you're rendering at a smaller resolution, so explain to me how that causes it to run slower? Did YYG write their implementation with draw_pixel or something?

They might blit instead of rendering it as a poly.
http://stackoverflow.com/questions/9711747/sdl-blitting-is-being-really-slow

Because otherwise I see not too many results, most are for OpenGL.
https://www.google.com/?gws_rd=ssl#q=direct3d+surface+scale+slow
https://www.google.com/?gws_rd=ssl#q=direct3d+surface+slow
https://www.google.com/?gws_rd=ssl#q=opengl+framebuffer+scale+slow
https://www.google.com/?gws_rd=ssl#q=opengl+framebuffer+slow

Another explanation is non-power of two surfaces.