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 »
826
General ENIGMA / Re: Realtime 3D Shadows, Animations, & Outlined Cel Shading
« on: March 23, 2014, 03:58:41 pm »Quote
The problem is that GL has the opposite-handed coordinate system for texture sampling and rendering. If it were just the texture loading, you could just flip the texture and everything would work.The problem is both. Because if it only had the bottom-left origin coordinates, then it would render everything upside and we would notice from day 1. As it loads textures flipped as well, then it compensates and we don't notice. Until we use surfaces, which are right side up.
Quote
Rendering is easily fixed with a projection, which makes sense; it isn't as though it screws with projection matrices you set yourself.It does. d3d_set_projection_ortho() and other "set" functions overwrites previous projection matrices. So in ENIGMA it will work differently from GM. But all my trying to figure out how to flip the projection has failed, because I don't want to flip the projection in a way that reverses the camera direction. For example, when you look straight up and you render to surface, you should still look up. If we just flip the projection or view matrix, then he will actually face down, because the matrix will have inverted values. So basically I just need to change the "up" vector I guess (in d3d_set_projection), but that ortho is used on surfaces which don't have an "up".
Quote
For future reference, O-R-T-H-O. And 32000 isn't a very special magic number.It seems there are typos there. Doesn't change anything though. I will fix them. Also, 32000 is there just because it was there previously (since day 1 I suppose). Not sure who came up with that or why. Mathematically it doesn't change much, because if one is -x and the other +x, then the sum is 0 and the matrix just has zeros in it. In other examples I have seen it actually is 0f and 1f which makes more sense.
So other than a typo and a magic value, is there anything else particularly that should be improved upon? And real ideas with solutions on how to fix surfaces in a way to be compatible with GM?
edit: Lol, I just went back and looked at the math and figured out how to flip orhto. It wasn't hard of course, but the fact we use GM functions (d3d_set_projection_ortho()) in surface functions made it less apparent. There is still problems with view though. But I guess we keep the coordinate system? Because technically it's not pretty that we abuse GL like that, but it does help with compatibility with DX and allows us to make more General functions.
edit2: The 32000 thing is the brain child of Robert - https://github.com/enigma-dev/enigma-dev/commit/ba85fa04e7285af5238a937df68828411cafb354
Dunno why.
edit3: Yup we still basically have the same problem. Right now it stems from the fact that all GM d3d_set functions overwrite the previously set matrices. This means that all the d3d_set_projection_ortho() called during screen_redraw() in G3screen.cpp are overwriting the projection set in surface_set_target(). I guess what we want again is to check if FBO is bound and only then use d3d_set_projection_ortho() and screen_set_viewport(), just like it was done previously with glScale(1,-1,1);
edit4: Also, those who aren't still aware the bug I am fixing now is when screen_draw() is called after surface_set_target() - i.e. when trying to draw screen to surface.
827
Issues Help Desk / Re: 3D functions and capabilities
« on: March 23, 2014, 03:44:14 pm »
Yeah, GL3 lights were never completely finished and debugged. Work on that kind of stopped when surfaces broke. I'll try fixing it later, but I don't know when I will have the time.
828
Issues Help Desk / Re: Windows 7 x64 and ENIGMA?
« on: March 22, 2014, 04:33:34 pm »
I just tried installing ENIGMA from scratch using the installer. And everything works. I had to delete the .eobjs folder in C:\ProgramData\ENIGMA so it recompiled the engine. Otherwise it does error out about undefined functions.
I encourage the OP also to delete that folder (by default C:\ProgramData\ENIGMA\.eobjs on Windows7 and up). Then when you compile it should recompile all the objects (so it can take longer, but you at least know there are no conflicts).
I encourage the OP also to delete that folder (by default C:\ProgramData\ENIGMA\.eobjs on Windows7 and up). Then when you compile it should recompile all the objects (so it can take longer, but you at least know there are no conflicts).
829
Third Party / Re: FakeFullscreen.dll
« on: March 22, 2014, 01:17:51 pm »Quote
Yeah no, that is not what the function is at all.It also works in Windows (read the doc you linked). And that is exactly why I said I will implement window_get_focus(), because that is the function we actually wanted. Like check if window_get_focus()==true and only then center the mouse. Also, your current implementation still doesn't do what os_is_paused does in GM. It does what window_get_focus() is supposed to do. I just implemented it too and basically the same way. To make os_is_paused() work like GM it will have to be a lot less pretty (we need additional variable to check if window was in focus last frame).
Quote
Or you could just, you know, amend my commit since I've outlined other functions as well.I am not really interested in those functions.
830
Issues Help Desk / Re: Windows 7 x64 and ENIGMA?
« on: March 22, 2014, 01:08:21 pm »
Btw, I just got the "undefined reference to `enigma::gameInformation'" when updating ENIGMA. To fix it I had to recompile the .dll (because gameInformation writing was implemented only in last commit). It should do it automatically when the .dll is deleted.
831
Third Party / Re: FakeFullscreen.dll
« on: March 22, 2014, 12:49:18 pm »Quote
function return a boolean value (enigma::gameFroze) that already exists in code.That wouldn't work, as the boolean is set only when "Freeze the game" thing is enabled. But that check isn't really necessary and can be put in the main loop instead.
Quote
YYG is just trying to make those functions more cross-platformish I suppose.But that again break not only the naming convention but common sense. The OS is NOT paused when that function returns true, the game is not even paused. The game just lost focus. But at least if I make two versions they can be both used - this one will work just like GM:S and the window_get_focus() will work like it really should.
Quote
Because of ENIGMA's current implementation, it will behave exactly the same as GM, please do not change it, just implement the function and be done.It will NOT work like GM implementation. It will actually not work at all. The bool will be set to true only when you have "Freeze the game when the window looses focus" enabled and that will then break because the bool will be the false again when the window regains focus. This means no events are going to be executed in the middle and in the game os_is_paused() is never going to return true.
Quote
Edit: I have gone ahead and implemented os_is_network_connected and os_is_paused for Win32 in the following pull request.It seems you still don't try your own pull requests. I wrote why it wouldn't work and after testing that commit - surprise - it doesn't work. There are about 4 reasons why it wouldn't.
I will implement this to make it work like a window function and then implement the os_ one to work like GM.
832
Issues Help Desk / Re: Windows 7 x64 and ENIGMA?
« on: March 22, 2014, 12:25:17 pm »Quote
No it is written to the temp folderSo when I asked if .ico is written to the temp folder, your answer is NO, it is written to the temp folder?
But I just did a test for myself. .ico is written to the temp folder and no, it's not called the same way as the game. I compiled an example to the desktop named motion_plan_gl33.exe with a custom icon, but the icon was written to the temp folder named "egm_ico1277297429185104899.ico".
Also, while looking at the temp folder while compiling I noticed what those cccSlX5b.ltrans1.ltrans.o files are. They are actually temporary files created by the compiler (mingw) and they are deleted when the object is linked. So it seems that the OP can't compile anything on his PC and it's not just ENIGMA. The compiler and linker doesn't have permissions to run for him and I am sure it's some antivirus or something like that which is not letting it. Probably needs to either whitelist or disable it.
edit: Also, then you maybe should also update the Portable ZIP. The Windows version in Master seems to work now. It's very likely he has newer .jar's than ENIGMA itself. Or the other way around (as PortableZIP pulls the newest from Git at first launch??).
833
Off-Topic / Re: CPGCL - Cross Platform Game Creation Language
« on: March 22, 2014, 12:16:09 pm »
onpon, the OP idea is not about a file format. It's about a way to code the game. So it's a lot more about the compiler/parser than how data looks. If you make a compiler/parser than can turn structured JSON into .exe, then I am willing to check that out as well.
834
General ENIGMA / Re: Realtime 3D Shadows, Animations, & Outlined Cel Shading
« on: March 22, 2014, 12:12:06 pm »Quote
It's actually a good possibility the texture data could be flipped.That was my original thought, but now I am almost certain it's not. DX loads it as you give it, and that means DX loads the data right side up. GL loads it by considering the first point being at bottom left corner and so it flips the image while loading. Here is an image I made to illustrate:
The first one is the original 75x75 sprite. We resize it to nearest power of two for compatibility and then we load it in memory. When I took the DX image from GPU memory we can see that it is right-side up. When I took the image from GPU memory in GL, then we can see the image is flipped. That is because the glTexImage2D function loads it considering the first element to be at bottom-left corner. As we provide the top-left origin image, then it loads it flipped.
Quote
One salient point is that GL expects texture data to start in the lower-left corner (like bitmap files), so keep that in mind while dealing with texture loading code.That is exactly what the problem is and what the discussion is about.
835
Off-Topic / Re: CPGCL - Cross Platform Game Creation Language
« on: March 22, 2014, 09:22:09 am »Quote
That's not exactly special.Nothing is really "special". UE4 is also nothing really special. But his take is quite original. It seems to give the ease of development given by GML and the same time allows you to do so without a special IDE. It's basically like python, only better (because almost everything is better than python).
836
Off-Topic / Re: CPGCL - Cross Platform Game Creation Language
« on: March 22, 2014, 06:47:42 am »
So it supports GML for coding? Although just using vk_down to check a button is slightly different. If it supports syntax like GML or EDL, then it could be possible to make an export for LGM, which would take a GMK/EGM or whatever and create this file with resources.
Looking forward to seeing the video.
Looking forward to seeing the video.
837
General ENIGMA / Re: Realtime 3D Shadows, Animations, & Outlined Cel Shading
« on: March 22, 2014, 06:43:39 am »Quote
How is it doing this?I don't think it is. The math makes sense either way even if GPU/driver/software doesn't do anything. Check this image I made:
You can see that when passing the same UV coordinates with the given texture to GPU, it will sample the same point in both GL3 and DX9. So for GPU it doesn't matter and it doesn't do any conversion whatsoever. That is because not only we flip texture coordinates, we flip also the textures in memory. That is why we can provide the same texture coordinates for GL and DX in General/GSsprites.cpp and they both render sprites identically.
But for surfaces it's different, because it doesn't flip the texture data. If we didn't flip the textures (or rather if it didn't do it when using glTexImage2D) in GL, then we would have to give texture coordinates different from DX.
So if we did it "properly" and had all our textures right-side-up then we would have to provide coordinates like this:
http://uploads.gamedev.net/monthly_06_2011/ccs-8549-0-98845200-1307472511.jpg
As we flip the textures, then we provide the DX variant:
http://i.msdn.microsoft.com/dynimg/IC282223.jpg
838
Issues Help Desk / Re: Windows 7 x64 and ENIGMA?
« on: March 22, 2014, 06:24:02 am »
Did you set Widget System to None in this example? Because the gameInformation bug could be fixed in the newest commit and it was mostly broken for "None". But it might be better in general.
The whole error line seems weird though. I don't recognize the object file it tries to use. On windows we don't have "cccSlX5b.ltrans1.ltrans.o" or something like that and they should always be in C:\ProgramData\ENIGMA\.eobjs folder. So I don't know why it looks for objects in Temp.
When you open LGM and go to Enigma Settings, what is the Make Directory? Mine is "%PROGRAMDATA%/ENIGMA/" where %PROGRAMDATA% is C:/ProgramData (you can see what %PROGRAMDATA% is by opening console (CMD) and typing %PROGRAMDATA% and pressing Enter).
Robert, is .ico written to temp even when compiling to other directory? I would actually recommend writing it to a constant file in C:\ProgramData\ENIGMA. The icon is usually named randomly anyway, so it's impossible to reuse it. Then maybe we could just write icon to C:\ProgramData\ENIGMA\.eobjs\Windows\Windows\Compile\icon.ico (or similar) and use that. And overwrite it whenever you compile something else.
The whole error line seems weird though. I don't recognize the object file it tries to use. On windows we don't have "cccSlX5b.ltrans1.ltrans.o" or something like that and they should always be in C:\ProgramData\ENIGMA\.eobjs folder. So I don't know why it looks for objects in Temp.
When you open LGM and go to Enigma Settings, what is the Make Directory? Mine is "%PROGRAMDATA%/ENIGMA/" where %PROGRAMDATA% is C:/ProgramData (you can see what %PROGRAMDATA% is by opening console (CMD) and typing %PROGRAMDATA% and pressing Enter).
Quote
All that I meant is that my computer's security, antivirus, generally wouldn't want a java application accessing sensitive directories like Temp and putting an executable in there...Well that might as well be the problem. Of course if your antivirus or computers security doesn't allow ENIGMA to write out data, then ENIGMA will not be able to write out data. Just try for 1min disabling antivirus and then launch LGM and compile. Just to verify that it is the problem. If it really is antivirus (which should tell you when it blocks something actually), then there is little we can do but just say to add ENIGMA to whitelist.
Robert, is .ico written to temp even when compiling to other directory? I would actually recommend writing it to a constant file in C:\ProgramData\ENIGMA. The icon is usually named randomly anyway, so it's impossible to reuse it. Then maybe we could just write icon to C:\ProgramData\ENIGMA\.eobjs\Windows\Windows\Compile\icon.ico (or similar) and use that. And overwrite it whenever you compile something else.
839
Third Party / Re: FakeFullscreen.dll
« on: March 21, 2014, 05:48:26 pm »Quote
BTW, GMS has a OS focus command, you could use it to trigger your pause menu / routine. Is this function active in ENIGMA ?No, I don't think we currently have that function. I guess I could add it. What is it called in GM? All I found was "os_is_paused()". I would prefer be called window_get_focus() or something. But I guess we can overload it for os_is_paused() as well. And while GM says os_is_paused() will return true only for 1 step, I think it would be better if it was true all the time while out of focus.
Quote
I know what you meanHe is actually talking about mouse issues in 3D shooters. In 3D games your mouse is always centered every step. This means if you ALT+TAB and it still does that, then you cannot move your mouse (even though you are in the desktop). That is often a problem with 3D examples in GM.
840
Issues Help Desk / Re: Windows 7 x64 and ENIGMA?
« on: March 21, 2014, 05:04:02 pm »Quote
But this time, it can't find my game informationThat probably means that you recently updated ENIGMA? You might also need to update .jar's in that case together with recompiling the compileEGMf.dll (it should do it automatically when you launch the .exe after you delete the .dll).
Quote
The last thing that java would do is allow administrator permissions to children.I didn't quite got that. You mean that you don't want to do it because of security reasons or that you just don't think it would work anyway? It could work, because it is a permission issue after all.
Quote
Similar issue, once again related to my "Temp" folder...Did you actually compile using "Build>Compile" and choosing a different folder? Because it shouldn't even touch Temp in that case. For example, when I compile to desktop the only places it touches is the ProgramData folder (which is accessed fine on your PC) and the desktop when it finished linking. The only thing it could still export to Temp folder is the icon.
Permission denied can also be related to mingw installation itself. I remember having permission denied when I tried to compile the .dll trough CMD, while it did work when I compiled trough git-bash.
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 »