This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 »
811
Issues Help Desk / Re: Windows 7 x64 and ENIGMA?
« on: March 26, 2014, 12:58:35 pm »
We still need to find a way for MinGW to stop writing to temp though. The error the user was having was purely because of Mingw writing files to temp and then reading them.
812
Programming Help / Re: libGME
« on: March 26, 2014, 10:58:35 am »
If it's an extension, then you can see the functions in the header: https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Universal_System/Extensions/GME/include.h
As you see it has only one - sound_add_from_gme(). That means it works together with OpenAL for playback. So you use that function to load GME and then regular sound functions, like sound_play() to play it.
Note that I haven't tested that extension and I don't know if it works. Supposedly it does.
As you see it has only one - sound_add_from_gme(). That means it works together with OpenAL for playback. So you use that function to load GME and then regular sound functions, like sound_play() to play it.
Note that I haven't tested that extension and I don't know if it works. Supposedly it does.
813
Issues Help Desk / Re: 3D functions and capabilities
« on: March 26, 2014, 09:37:42 am »
Well that sucks. I really need an example to test and make sure. Maybe you have some other games/examples you are willing to share that have D3D lights?
I can't really explain the black screen though. Maybe I left something important when commiting into Git. If it was just a regular conflict, then you probably wouldn't have been able to compile. I'll look into that.
I can't really explain the black screen though. Maybe I left something important when commiting into Git. If it was just a regular conflict, then you probably wouldn't have been able to compile. I'll look into that.
814
Issues Help Desk / Re: Windows 7 x64 and ENIGMA?
« on: March 26, 2014, 09:35:27 am »
Josh, it writes the icon to /temp folder and mingw uses /temp folder for it's temporary files. Also, if you just use Run command, then the game is also written to the /temp folder. Usually everyone has permission for the temp folder, but he clearly hasn't.
815
General ENIGMA / Re: Realtime 3D Shadows, Animations, & Outlined Cel Shading
« on: March 25, 2014, 09:11:59 pm »Quote
Anyway, that doesn't matter, even if you did fix it one of those ways, it would still be technically broken. My specific game it may not matter, but on someone elses game it would. Possibly 3D shadow examples, etc.It's broken NOW. That means when we fix it, not matter how, it will FIX the games or examples you speak of. None of them actually works now. The 3D shadows example mentioned in this topic doesn't work in ENIGMA now for other reasons, but if everything else worked, then it would break while rendering to surface right now. That is what we want to fix.
Quote
the two samplers are behaving differently.Sampler doesn't care what it samples, be it FBO or a texture. It doesn't handle them differently. The data is different.
Quote
And you can name your texture anything you like. There is no limit to how many texture coordinates you can have; you can sample any number. We can't know them all.Texture names are not significant. If you were thinking names of the attributes having texture coordinates, then yes, you can name them whatever you want. GM and ENIGMA gives the user In_Texture as a predefined attribute holding the texture coordinates of the rendered scene. But the fact that user may later have a custom attribute (right now impossible in ENIGMA) is the reason why I didn't want this fix to be in shaders. I don't want to force them having to change anything from GM:S just to make it work here.
816
General ENIGMA / Re: Realtime 3D Shadows, Animations, & Outlined Cel Shading
« on: March 25, 2014, 03:27:33 pm »Quote
one advocating OpenGL1 not focus on dumping the FFP or anything like thatDumping FFP would be dumping GL1. You cannot have GL1 without FFP. So we cannot change anything in it even if we tried.
Quote
Edit 3: Also non of you guys solutions is going to work anyway, why? Because of surface_get_texture() and games like Project Mario that use surfaces as texturesBut they are already broken! That is why we are trying to fix it. Surfaces in ENIGMA DOESN'T WORK right now. In Mario you use surfaces for freaking water - a symmetrical and tileable texture. Of course you don't notice and/or care that it is actually upside down right now. If you compared screenshots of Mario example in ENIGMA and GM:S you will see the difference.
817
General ENIGMA / Re: Realtime 3D Shadows, Animations, & Outlined Cel Shading
« on: March 25, 2014, 02:57:03 pm »Quote
Actually, that's been my doings, and I asked that he do the same.I don't see what the matrix class or matrix functions have anything to do with compatibility. Originally I only planned to replace GL3 matrices, but then I figured that they probably work faster than the GL1 implementation and so I added them there too. In the end it's possible we could have all that GLmatrix.cpp in General and even make DX use them (but in DX they would need to be transposed whenever used). I do have a feeling DX matrices are probably super optimized however.
818
General ENIGMA / Re: Realtime 3D Shadows, Animations, & Outlined Cel Shading
« on: March 25, 2014, 02:39:36 pm »Quote
If you want my honest opinion, we ought to draw *everything* to a framebuffer and only at paint time render the buffer to the screen.Agreed.
Quote
So you are trying to maintain forward compatibility. So that GL1 games can run on modern machines and old machines, while GL3 games only work on modern machines. I suppose that's acceptable, and probably beneficial as (1) it gives us more control over multiplication order (which was a problem for compatibility in the past) and (2) it gives users access to those matrices for math, in addition to a possible (3) that when lots of matrix math is done, communication with the graphics card can be reduced substantially.GL1 also uses the matrix class. There is actually very small difference between GLmatrix.cpp and GL3matrix.cpp - the difference being that in GL1 they are instantly uploaded to GL, while in GL3 we wait until we need to draw something. But that matrix class won't be a compatibility problem as it uses pure C/C++ (circa 97). Right now that class it not in enigma_user, but there are some function planned (like GM's http://help.yoyogames.com/entries/28707818-Matrix-Functions) but they are very limited and specific (basically only 4x4 matrices are supported). For general purpose badassness user should use Matrix extension (right now in git https://github.com/enigma-dev/enigma-dev/tree/master/ENIGMAsystem/SHELL/Universal_System/Extensions/Matrix). They are templated however and that means we cannot currently use it in EDL. I am waiting for the new parser for that.
Quote
If there is no math being done at the driver level, then it is being done at the software level.My point is that there is no math done AT ALL.
Quote
We are seeing different behaviors; the GL and DX samplers are "upside-down."We are not seeing that. Samplers are identical - textures aren't. Surfaces are not flipped, while all the other textures are. That is the difference we see. Check again these two images:
This one shows how the samplers are identical (because we give the sampler the same coordinates and it samples the same point in both GL and DX). So no math difference. If it did 1-y at this point it would break.
This image shows how the textures are represented in memory. If I had added a surface there as well, it would look just like the DX9 one, while we need it to be like the GL one. That is the only difference I can see.
Quote
Blazingly so. Too bad we don't know which values to invert.In GL3 shaders we input texture coordinates with attribute named in_TextureCoord. All we need to do for flipping is vec2(in_TextureCoord.s,1-in_TextureCoord.t). Just tested that and works fine. So it's not complicated.
Think of the whole problem this way - If we didn't use FBO's, then we would NEVER see the problem. GL loads the textures flipped and flips the coordinates origin as well. This means that samplers are identical, shaders are identical, drivers are identical, software is identical. The problem is that FBO's are not loaded as regular textures are. So GL flips the textures while loading, but it doesn't flip the FBO (because it doesn't load it). That is the problem.
819
Issues Help Desk / Re: 3D functions and capabilities
« on: March 25, 2014, 02:17:30 pm »
Spirit, I got around to fixing some of the problems with lights. Right now they are here in this branch: https://github.com/enigma-dev/enigma-dev/commits/GL3-cleanup
You can try that or you could give me an example I could test on myself. The fixes implement point lights (were totally not in previously) and fixes many bugs that were happening with lights previously. At least examples like Mario work fine. I don't have many examples that use GM lights.
I plan to make an extension that would invisibly replace the per-vertex lights with per-pixel lights (so all you would have to do is enable an extension). We currently don't have an easy system to use or replace shaders, so extensions will have to do for now.
You can try that or you could give me an example I could test on myself. The fixes implement point lights (were totally not in previously) and fixes many bugs that were happening with lights previously. At least examples like Mario work fine. I don't have many examples that use GM lights.
I plan to make an extension that would invisibly replace the per-vertex lights with per-pixel lights (so all you would have to do is enable an extension). We currently don't have an easy system to use or replace shaders, so extensions will have to do for now.
820
Issues Help Desk / Re: Enigma errors
« on: March 25, 2014, 08:04:46 am »Quote
I ended up ignoring the rest of what you saidThat's probably the issue. About 3 out of 5 posts you start with "No" as in disagreeing and then the rest of the post is how you agree. I don't have a problem with that, but it's just weird and can end up confusing to others.
Quote
still getting errors after deleting the eobjs http://pastebin.com/1f8g3711So this means when you reinstalled Windows you had the old files laying around? And did you recompile the .dll? Robert may make a new zip today/tomorrow and then you should try that. Before you do you should DELETE the main ENIGMA folder (the one with ENIGMA.exe inside, so NOTHING is left behind, don't overwrite anything) and the ENIGMA folder in the ProgramData as well.
The errors you seem to be getting are almost guaranteed to stem from conflicts between old versions of ENIGMA (or the combination of different versions of JAR's and ENIGMA).
821
Issues Help Desk / Re: Enigma errors
« on: March 24, 2014, 09:03:19 pm »
Exactly what I said. Thanks for agreeing.
822
Issues Help Desk / Re: Enigma errors
« on: March 24, 2014, 03:42:09 pm »
They are outdated, but usually they are the ones that work. So I encourage him to not get the latest GIT (unless there is something new you want) and not update any JAR's either. If you do want to update, then update both. If do that, then you also need to recompile the .dll (it should do it automatically if you delete the .dll).
The reason why I asked about formatting the drive is so that to make sure files in C:/ProgramData/ENIGMA/ are deleted. Especially C:/ProgramData/ENIGMA/.eobjs should not exist when installing new ENIGMA, otherwise conflicts can happen.
The reason why I asked about formatting the drive is so that to make sure files in C:/ProgramData/ENIGMA/ are deleted. Especially C:/ProgramData/ENIGMA/.eobjs should not exist when installing new ENIGMA, otherwise conflicts can happen.
823
Issues Help Desk / Re: Enigma errors
« on: March 24, 2014, 02:38:28 pm »
I suspect you formatted the drive when reinstalling Windows? And can you post the whole log? Also, try just installing from .zip and not updating from Git. The zip alone is known as the "working copy" and should work. The stuff in Git can break it, because maybe .jar's have changed as well and you haven't updated them.
824
Issues Help Desk / Re: 3D functions and capabilities
« on: March 24, 2014, 12:33:55 pm »
No, the reason why it's different is because they are made totally differently. GL1 has this thing called Fixed Function Pipeline - it basically means that it has predetermined things it can do and draw and so you cannot change anything. GL1 had vertex based (per-vertex) lighting with maximum 8 lights and limited amount of effects you could do. GL3 on the other hand requires you to do it all yourself. This is a lot harder, but it does mean a lot more customization. Like you can create normal mapping, per-pixel lighting, deffered shading and so on, but you have to do it yourself.
To make GL3 compatible with GM and GL1, the default lighting system would require to remake vertex based lights in FFP. This was not properly done (sorry, my fault) and I haven't been able to go back to that yet.
The shader used for drawing (including per-vertex lights) is here: https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Graphics_Systems/OpenGL3/GL3shader.cpp
And the light system itself is here: https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Graphics_Systems/OpenGL3/GL3d3d.cpp
To make GL3 compatible with GM and GL1, the default lighting system would require to remake vertex based lights in FFP. This was not properly done (sorry, my fault) and I haven't been able to go back to that yet.
The shader used for drawing (including per-vertex lights) is here: https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Graphics_Systems/OpenGL3/GL3shader.cpp
And the light system itself is here: https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Graphics_Systems/OpenGL3/GL3d3d.cpp
825
General ENIGMA / Re: Realtime 3D Shadows, Animations, & Outlined Cel Shading
« on: March 24, 2014, 08:18:49 am »Quote
the code had creeped its way into the view code.You mean projection code? Because I don't think we can get rid of that. They are actually one of the reasons fixing surfaces is a pain. All the d3d_set_projection_ortho() and screen_set_viewport() in screen_redraw() overwrite the same function calls in surfaces. And there isn't much you can do about that. You need those two functions in screen_redraw() because we can have many views and all the views need different ortho position and viewport position. Surfaces don't need those to change and so we need to check. Another, equally bad solution, is to put the FBO checking and ortho flipping code inside the projection functions themselves. That means we could get rid of the checks in screen_redraw().
Quote
it was checking horrifying shit like "are we in an FBO?And why wouldn't it check that? How exactly is that slow/bad? Because the truth is that FBO and main framebuffer are two different beasts in this regard. That is probably why GM:S now renders everything on a surface by default and only then draws the surface to screen. It also allows rendering views on surfaces. We maybe would need to consider the same, but compatibility with 10 years old PC's would be a problem.
Quote
asking for an orthographic projection gives you two fucking different matrices when GL is the system vs DirectX, which will probably confuse some poor bastard to tears later onThe only difference between them is that one is transpose of the other. And DX uses it's own matrices with its own functions, so they don't interfere with one another. The custom matrix classes and functions were made just for GL, because >GL3.0 no longer has FFP and any matrices whatsoever.
Quote
undo math already added by the driver.Driver DOESN'T do any math. The samplers in driver level ARE IDENTICAL. At least they should be, because the math works the same either way. Look my previous post with the sampler picture. So of course while I cannot be certain they work the same, I see no reason why they wouldn't.
Quote
In GL1, use glScalef(1,-1);- at the beginning of the game, as I had pointed out long ago and you had suggested earlier.I no longer believe this is a solution, because then we need to flip textures given by LGM. This means it will break DX unless we make an exception for it. So we end up having custom LGM code just for each graphics system.
Quote
In GL3, create a macro for the sampler call; ie, #define texture(sampler, coord) texture((sampler), invY(coord)), where invY takes vec2 in and computes y = 1-y in it, returning the result.It would be a lot faster to do this in vertex shader (then the inversion is only done once per vertex and interpolated when passed to pixel shader). But still, the same problem as before. We need to flip textures in memory and that means LGM needs to write those textures flipped.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 »