Show Posts
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.
1
Issues Help Desk / Re: enigmofo fucked after java update
« on: January 07, 2018, 11:46:22 pm »
@hpg678
I've never had an issue doing parallelization. All of my java applications are using the default 64-bit java, eclipse is using its in-built EJC, and ENIGMA is configured and happily using the 32-bit java.
@tkg
Open your ENIGMA folder, edit the file "settings.ini", find the line "idecommand=" and change "java" or "java.exe" to the fullpath of 32-bit java. For example, on *MY* Windows 10 computer, 32-bit programs reside in Program Files (x86), java notwithstanding, so *MINE* looks like this:
idecommand="C:\Program Files (x86)\Java\jre1.8.0_74\bin\java.exe -jar -Xms256m -Xmx1000m"
The wiki also has an article on this:
https://enigma-dev.org/docs/Wiki/Install:Parallel_Java
I've never had an issue doing parallelization. All of my java applications are using the default 64-bit java, eclipse is using its in-built EJC, and ENIGMA is configured and happily using the 32-bit java.
@tkg
Open your ENIGMA folder, edit the file "settings.ini", find the line "idecommand=" and change "java" or "java.exe" to the fullpath of 32-bit java. For example, on *MY* Windows 10 computer, 32-bit programs reside in Program Files (x86), java notwithstanding, so *MINE* looks like this:
idecommand="C:\Program Files (x86)\Java\jre1.8.0_74\bin\java.exe -jar -Xms256m -Xmx1000m"
The wiki also has an article on this:
https://enigma-dev.org/docs/Wiki/Install:Parallel_Java
2
Issues Help Desk / Re: enigmofo fucked after java update
« on: January 04, 2018, 07:49:50 pm »
I believe the issue is 64-bit Java. Switch to 32-bit, or point ENIGMA to your 32-bit java installation.
3
Graphics and Video / Re: [WIP] Collada (.dae) 3d Animated Model Loader
« on: December 10, 2017, 02:38:45 pm »@Solitudinal if you were worried about executable file size, you could've made it an ENIGMA extension, that way, if the user needs it and doesn't mind the file size increase, they can tick the checkbox, otherwise, they can leave the feature out of their builds completely.Yes, that's what I want to do. I just couldn't figure out how to do it. I created an extension folder almost identical to some of the other ones and ENIGMA wasn't automatically picking it up. Was hoping someone more familiar with it would take my code and do it/show me how to do it - probably once my code is closer to completion.
w.r.t. AssImp, though, I was more worried about ENIGMA's size, not the resulting executable size. AssImp alone is almost as big as ENIGMA, meaning if it were shipped with ENIGMA, it would just about double ENIGMA's size for a feature that's not even going to be checked on in 10% of ENIGMA games.
I quite agree. I tried to use it following his instructions and somewhere along the way broke my ENIGMA. ALL my fault! So I never actually got to see it in action. I so wanted to try in out in my game. Oh well, I have to use sprites instead.If you want it so bad, feel free to try again. Try and look at the code where you're inserting it to make sure that it makes sense - line numbers change. Obviously you don't want to stick it in the middle of a function. If I had more time, I'd make a patch, but I'm kinda busy developing the code so I don't have time to maintain a patch.
4
Off-Topic / Re: Developing Games
« on: December 05, 2017, 04:17:17 pm »
Actually I don't think that would be uncommon, due to the oversaturation in the Windows market and the relative low-supply-high-demand of games available to linux users.
Anybody willing to pay for a game would probably be willing to pay for a higher quality and relatively cheap Windows game, but if they are unwilling to use windows, they'll settle for a lower quality competitor.
Like let's suppose there's Flappy Eagle, a Windows-only game that's high quality, popular, and costs $5.
Then there's Flappy Penguin, a cross-platform clone that's lower quality but still fun, and costs $5.
Let's suppose there's 90 windows users paying to play these games, and 10 linux users paying.
85 windows users will all flock to Flappy Eagle.
5 windows users will prefer Flappy Penguin (maybe they just like penguins).
10 linux users play Flappy Penguin.
We see Flappy Penguin is making more money on Linux, but that's only because Flappy Eagle has claimed the Windows market.
Alternatively, there may be an occasional example of a game that as written and released for Linux, but eventually expanded into the Windows market and flopped there.
Anybody willing to pay for a game would probably be willing to pay for a higher quality and relatively cheap Windows game, but if they are unwilling to use windows, they'll settle for a lower quality competitor.
Like let's suppose there's Flappy Eagle, a Windows-only game that's high quality, popular, and costs $5.
Then there's Flappy Penguin, a cross-platform clone that's lower quality but still fun, and costs $5.
Let's suppose there's 90 windows users paying to play these games, and 10 linux users paying.
85 windows users will all flock to Flappy Eagle.
5 windows users will prefer Flappy Penguin (maybe they just like penguins).
10 linux users play Flappy Penguin.
We see Flappy Penguin is making more money on Linux, but that's only because Flappy Eagle has claimed the Windows market.
Alternatively, there may be an occasional example of a game that as written and released for Linux, but eventually expanded into the Windows market and flopped there.
5
Issues Help Desk / Re: Missing Cursor
« on: December 01, 2017, 02:11:39 pm »
LGM doesn't directly support Java 9 yet. It's too new. I'm sure this will quickly change, but in the meantime, you can quickly get stuff working again by simply using Java 8 or older.
6
Issues Help Desk / Re: Missing Cursor
« on: November 30, 2017, 07:09:34 pm »
I wouldn't be so quick to blame this on Swing. The code editor (JoshEdit) is a custom written widget specifically designed for LGM using partially custom rendering and poor integration with Swing. It's bound to be buggy.
I haven't personally noticed the cursor glitch that you've mentioned, but the code editor can be painfully buggy. That said, I'm very thankful for the amount of stuff that *does* work in it, and remain hopeful that it will only continue to be improved and the bugs slowly fixed.
And yeah, from my experience, LGM has never played nice with Oracle JDK - but the error you see is very specific; I'd be curious to poke at it and see if it can be fixed now. At first glance I can't find any reference to "rtf" anything in LGM.java, but my code is probably outdated.
johnno56: Can you run the following from a command line:
$ java -version
And report the results.
Your error is caused by LGM doing exactly that - trying to parse your Java version, and failing.
I haven't personally noticed the cursor glitch that you've mentioned, but the code editor can be painfully buggy. That said, I'm very thankful for the amount of stuff that *does* work in it, and remain hopeful that it will only continue to be improved and the bugs slowly fixed.
And yeah, from my experience, LGM has never played nice with Oracle JDK - but the error you see is very specific; I'd be curious to poke at it and see if it can be fixed now. At first glance I can't find any reference to "rtf" anything in LGM.java, but my code is probably outdated.
johnno56: Can you run the following from a command line:
$ java -version
And report the results.
Your error is caused by LGM doing exactly that - trying to parse your Java version, and failing.
7
Function Peer Review / d3d_unproject
« on: November 07, 2017, 03:27:49 pm »
This handy function set allows you to convert a 2d screen coordinate (such as the mouse position) into 3d coordinates - basically the 3d coordinates that it's pointing at.
This is sometimes called unproject, because it reverses the projection process (which converts 3d coordinates into 2d screen coordinates). It's also sometimes called raycasting, since you are effectively casting a geometric ray from the camera/viewport into 3d space, and then in this case colliding it with the z-depth of whatever pixel it is (e.g. z=0 if you click on the floor).
4 functions are provided:
d3d_unproject returns a Vector3, if you are ok with OO programming.
d3d_unproject_x/y/z returns the respective x, y, and z coordinates, in GM's regular functional programming (where functions return a single number, rather than an object).
All functions take an x and a y coordinate, which refer to the location respective to the viewport. I.e. d3d_unroject(mouse_x,mouse_y)
Or if you're weird and actually use views in conjunction with 3d:
d3d_unproject(mouse_x - view_xview[view_current], mouse_y - view_yview[view_current])
These functions are a little expensive due to complex math going on behind the scenes, so try not to use them more than a few times every step. I.e. if you're using them for mouse coordinates, consider storing the results in a global variable.
NOTE this only works in OpenGL1, as it depends on a call to gluUnproject. I tried porting the code to OpenGL3, but I'm terrible with matrices and ENIGMA uses an awkward matrix format. I've included my attempted OpenGL3 code below if you want to try and fix it.
OpenGL3 BROKEN code, which I created by researching a few places explaining how gluUnproject works:
This is sometimes called unproject, because it reverses the projection process (which converts 3d coordinates into 2d screen coordinates). It's also sometimes called raycasting, since you are effectively casting a geometric ray from the camera/viewport into 3d space, and then in this case colliding it with the z-depth of whatever pixel it is (e.g. z=0 if you click on the floor).
4 functions are provided:
d3d_unproject returns a Vector3, if you are ok with OO programming.
d3d_unproject_x/y/z returns the respective x, y, and z coordinates, in GM's regular functional programming (where functions return a single number, rather than an object).
All functions take an x and a y coordinate, which refer to the location respective to the viewport. I.e. d3d_unroject(mouse_x,mouse_y)
Or if you're weird and actually use views in conjunction with 3d:
d3d_unproject(mouse_x - view_xview[view_current], mouse_y - view_yview[view_current])
These functions are a little expensive due to complex math going on behind the scenes, so try not to use them more than a few times every step. I.e. if you're using them for mouse coordinates, consider storing the results in a global variable.
NOTE this only works in OpenGL1, as it depends on a call to gluUnproject. I tried porting the code to OpenGL3, but I'm terrible with matrices and ENIGMA uses an awkward matrix format. I've included my attempted OpenGL3 code below if you want to try and fix it.
Code: [Select]
enigma::Vector3 d3d_unproject(gs_scalar x, gs_scalar y)
{
GLdouble model[16];
GLdouble proj[16];
GLint view[4];
GLdouble retX, retY, retZ;
GLfloat gly, glz;
glGetDoublev(GL_MODELVIEW_MATRIX,model);
glGetDoublev(GL_PROJECTION_MATRIX,proj);
glGetIntegerv(GL_VIEWPORT,view);
//invert mouse y into openGL y
gly = (float)view[3] - (float)y;
//Read the depth of the moused pixel as the z
//this stops the raycast at the first pixel collision
glReadPixels(x,int(gly),1,1,GL_DEPTH_COMPONENT,GL_FLOAT,&glz);
gluUnProject(x,gly,glz,model,proj,view,&retX,&retY,&retZ);
//TODO: Provide a raycast_to_floor, stopping at a desired z rather than the first pixel collision
//I believe the way to do this is to call gluUnProject twice at glz=0 and glz=1 to raycast,
//then somehow collide that ray with the desired z.
return enigma::Vector3(retX, retY, retZ);
}
gs_scalar d3d_unproject_x(gs_scalar x, gs_scalar y)
{
return d3d_unproject(x,y).x;
}
gs_scalar d3d_unproject_y(gs_scalar x, gs_scalar y)
{
return d3d_unproject(x,y).y;
}
gs_scalar d3d_unproject_z(gs_scalar x, gs_scalar y)
{
return d3d_unproject(x,y).z;
}OpenGL3 BROKEN code, which I created by researching a few places explaining how gluUnproject works:
Code: [Select]
//This code does not work. Please fix it.
enigma::Vector3 d3d_unproject(gs_scalar x, gs_scalar y)
{
GLint view[4];
GLfloat gly, glz;
oglmgr->Transformation();
glGetIntegerv(GL_VIEWPORT,view);
//invert mouse y into openGL y
gly = (float)view[3] - (float)y;
//Read the depth of the moused pixel as the z
//this stops the raycast at the first pixel collision
glReadPixels(x,y,1,1,GL_DEPTH_COMPONENT,GL_FLOAT,&glz); //Not sure but I think this is broken
//Now perform the unproject.
//create an unprojection matrix by inverting the MVP. This is probably the part I screwed up.
enigma::Matrix4 inv = enigma::view_matrix * enigma::projection_matrix;
inv.Inverse();
//Create the normalized ray in GL-space [-1,1]
enigma::Vector4 tmp = enigma::Vector4((float)x / (float)view[2],gly / (float)view[3],glz,-1.0f);
tmp.x = tmp.x * 2.0f - 1.0f;
tmp.y = tmp.y * 2.0f - 1.0f;
tmp.z = tmp.z * 2.0f - 1.0f;
//Cast it
enigma::Vector4 obj = inv * tmp;
//Un-normalize the result (the magnitude is 1/obj.w)
return enigma::Vector3(obj.x / obj.w,obj.y / obj.w,glz / obj.w);
}
8
Graphics and Video / Re: [WIP] Collada (.dae) 3d Animated Model Loader
« on: October 23, 2017, 12:22:17 am »
I'd looked at AssImp, but the library is massive, so I passed it by. The zip is 30+ MB. I don't know how that would pan out with the rest of ENIGMA.
As far as a pull request goes, I don't actually have a github account, but once the code gets large enough (and stable enough) to warrant it, I'll consider it.
Slow dev or otherwise, I'm happy; with just a little tweaking and some customer support, you have the features I need for my game programming needs.
As far as a pull request goes, I don't actually have a github account, but once the code gets large enough (and stable enough) to warrant it, I'll consider it.
Slow dev or otherwise, I'm happy; with just a little tweaking and some customer support, you have the features I need for my game programming needs.
9
Graphics and Video / Re: [WIP] Collada (.dae) 3d Animated Model Loader
« on: October 08, 2017, 04:10:14 pm »
Awesome, thanks Goombert. Any luck digging up a copy of that multitextured terrain example?
I'll keep an eye open for changes to the graphics system and try to keep my code current with them, but if you could poke this topic (or the forums in general) when you do revisit and update the model/mesh class, that'd really help me know to re-integrate my code with it.
In the meantime, I'll keep chugging away.
I'll keep an eye open for changes to the graphics system and try to keep my code current with them, but if you could poke this topic (or the forums in general) when you do revisit and update the model/mesh class, that'd really help me know to re-integrate my code with it.
In the meantime, I'll keep chugging away.
10
Graphics and Video / Re: [WIP] Collada (.dae) 3d Animated Model Loader
« on: October 07, 2017, 01:57:43 pm »
Just another quick update.
GLM:
I've successfully ditched GLM and replaced it with enigma::Matrix4 and such for the Collada. That actually went smoother than expected, so... thanks?
GL1 / GL3 / shaders:
It's come to my attention that generating my VAO/VBOs currently uses calls to glVertexAttribPointer (generic attributes), which requires GL2.0+. In GL1.1, we used to use fixed attributes glVertexPointer/glNormalPointer/glTexCoordPointer/glColorPointer. I use generic attributes to communicate each vertex's meshed Joints (and its Weights) to the shader. This takes me back to the decision point I was making before, where I either store/render animations CPU-side (as we used to do in GL1.1), or ditch GL1.1 and render them in the shader via calls to glVertexAttribPointer.
Unless someone can suggest some way to salvage GL1.1 support, I'm forced to ditch OpenGL1 and port my code into OpenGL3.
Non-animated code (OP):
The code I shared in the first post, for the base (non-animated) model is fully compatible with GL1.1 (OpenGL1), as it does not depend on VBOs or generic attributes. Feel free to continue using it, and I will continue to support it, but due to the above note, I have no intention of ever adding animation to it. If you want animation, you'll want to switch to OpenGL3. If you're just using it for static models, you can stick to OpenGL1.
Edit: Looking at enigma's GL3 code, you guys didn't make it easy on me. Enigma's Meshes don't support generic attributes either, so I'll probably just bypass Mesh.
GLM:
I've successfully ditched GLM and replaced it with enigma::Matrix4 and such for the Collada. That actually went smoother than expected, so... thanks?
GL1 / GL3 / shaders:
It's come to my attention that generating my VAO/VBOs currently uses calls to glVertexAttribPointer (generic attributes), which requires GL2.0+. In GL1.1, we used to use fixed attributes glVertexPointer/glNormalPointer/glTexCoordPointer/glColorPointer. I use generic attributes to communicate each vertex's meshed Joints (and its Weights) to the shader. This takes me back to the decision point I was making before, where I either store/render animations CPU-side (as we used to do in GL1.1), or ditch GL1.1 and render them in the shader via calls to glVertexAttribPointer.
Unless someone can suggest some way to salvage GL1.1 support, I'm forced to ditch OpenGL1 and port my code into OpenGL3.
Non-animated code (OP):
The code I shared in the first post, for the base (non-animated) model is fully compatible with GL1.1 (OpenGL1), as it does not depend on VBOs or generic attributes. Feel free to continue using it, and I will continue to support it, but due to the above note, I have no intention of ever adding animation to it. If you want animation, you'll want to switch to OpenGL3. If you're just using it for static models, you can stick to OpenGL1.
Edit: Looking at enigma's GL3 code, you guys didn't make it easy on me. Enigma's Meshes don't support generic attributes either, so I'll probably just bypass Mesh.
11
Off-Topic / Re: Interesting News
« on: October 04, 2017, 10:23:20 pm »
Pretty sure that's just a non-oxford comma. "Open-source" modifies developers, not Visual Studio.
Unless you were trolling and I missed it.
Unless you were trolling and I missed it.
12
Graphics and Video / Re: [WIP] Collada (.dae) 3d Animated Model Loader
« on: October 02, 2017, 12:25:32 am »
Another update (attn Goombert?):
It's been a while, so I figured I'd check in so you guys know that I'm still hard at work on this.
Static code status:
In case you've missed it, I've made a few changes to the static model code, making it quite a bit leaner.
Animation status:
After endless debugging, I've finished porting the animation code over to C++, and it finally works fantastic. I did break down and start using GLM, and I have a pretty heavy dependency on it right now, because it just made the matrix math that I need so much easier. The end result is about 850 lines of code or 25kb (source, not compiled), plus the shader (50 lines), plus pugixml (375kb source), plus GLM (ehhh...), plus another 200 lines for spinning up my own main/glfw window/glew calls/camera (stuff which ENIGMA normally handles, so that wouldn't be ported over).
I did write GLSL1 shaders for it, and it works great, so that's excellent. Now I'm half waiting on Goombert to share the code for his multi-textured terrain example (the dropbox link is 404) and/or whatever he's secretly doing with shaders -- and half figuring it out myself (which would probably include hacking it a bit myself)
Next:
Porting my code to ENIGMA. This involves figuring out how ENIGMA handles shaders and maybe forcing it to handle how *I* want to use shaders (or hopefully not). Then I'd probably have to replace all my dependencies on GLM with enigma's matrix math, because GLM is massive (2mb) and I don't think ENIGMA wants to add that library just to make model animation a little easier.
Here's a few good notes for users at the current time:
* Multiple models are supported, of course. One model (animated, static, or both) per file. Just construct a new collada model for each one, and point it to the file.
* Static and Animated models will both be supported, with a simple boolean switch in the constructor to determine how to read it in (so exclusively static models don't have to have animation data), and animated models can be read in as animated and still render their static/base model version by simply using a shader that ignores the animation data (in theory, the Fixed Function Pipeline (FFP) should suffice).
* Relatively simple API lets you construct a model with one call, get how long the animation is, set the animation frame (increment each step to animate), and render. There may be a couple other calls to set up the shader, and don't forget to set up the texture, too.
* A single model can be rendered as many times as you'd like in as many different frames (or same frames) as you'd like. In my test code, I've got two guys running and two guys standing, going around in a circle like a merry-go-round.
* No error checking at this time keeps things fast. If anything is missing, it will be omitted, which could easily cascade down to your model not rendering, but the rest of your game should still be playable.
* In order to keep the code small, we make a few assumptions about how the model is constructed and behaves, so a lot of the fancy Collada features will not be present, like materials, special interpolation methods, Collada lights (you have to program your own lights in ENIGMA, you know that), and so on. Refer to the java example model for what features you can use, or feel free to hack in anything I missed.
Hopefully next time you hear from me (may take a while again), I'll have some animation code that you can stick in ENIGMA and use!
If anybody wants to see my current independent (working) code, let me know and I'll consider sharing it, but again keep in mind that it has dependencies on GLFW, GLEW, and GLM, which took me a while to figure out how to set up.
Also, if anybody wants to help, either in this or in the game that I'm working on (no, it's not a 3d MMORPG), that'd be super awesome. Let me know and we can figure out what parts you can work on and/or what parts need done. But I'm assuming most of you guys are probably busy working on your own things right now, so that's fine, I'll just keep chugging away at this
It's been a while, so I figured I'd check in so you guys know that I'm still hard at work on this.
Static code status:
In case you've missed it, I've made a few changes to the static model code, making it quite a bit leaner.
Animation status:
After endless debugging, I've finished porting the animation code over to C++, and it finally works fantastic. I did break down and start using GLM, and I have a pretty heavy dependency on it right now, because it just made the matrix math that I need so much easier. The end result is about 850 lines of code or 25kb (source, not compiled), plus the shader (50 lines), plus pugixml (375kb source), plus GLM (ehhh...), plus another 200 lines for spinning up my own main/glfw window/glew calls/camera (stuff which ENIGMA normally handles, so that wouldn't be ported over).
I did write GLSL1 shaders for it, and it works great, so that's excellent. Now I'm half waiting on Goombert to share the code for his multi-textured terrain example (the dropbox link is 404) and/or whatever he's secretly doing with shaders -- and half figuring it out myself (which would probably include hacking it a bit myself)
Next:
Porting my code to ENIGMA. This involves figuring out how ENIGMA handles shaders and maybe forcing it to handle how *I* want to use shaders (or hopefully not). Then I'd probably have to replace all my dependencies on GLM with enigma's matrix math, because GLM is massive (2mb) and I don't think ENIGMA wants to add that library just to make model animation a little easier.
Here's a few good notes for users at the current time:
* Multiple models are supported, of course. One model (animated, static, or both) per file. Just construct a new collada model for each one, and point it to the file.
* Static and Animated models will both be supported, with a simple boolean switch in the constructor to determine how to read it in (so exclusively static models don't have to have animation data), and animated models can be read in as animated and still render their static/base model version by simply using a shader that ignores the animation data (in theory, the Fixed Function Pipeline (FFP) should suffice).
* Relatively simple API lets you construct a model with one call, get how long the animation is, set the animation frame (increment each step to animate), and render. There may be a couple other calls to set up the shader, and don't forget to set up the texture, too.
* A single model can be rendered as many times as you'd like in as many different frames (or same frames) as you'd like. In my test code, I've got two guys running and two guys standing, going around in a circle like a merry-go-round.
* No error checking at this time keeps things fast. If anything is missing, it will be omitted, which could easily cascade down to your model not rendering, but the rest of your game should still be playable.
* In order to keep the code small, we make a few assumptions about how the model is constructed and behaves, so a lot of the fancy Collada features will not be present, like materials, special interpolation methods, Collada lights (you have to program your own lights in ENIGMA, you know that), and so on. Refer to the java example model for what features you can use, or feel free to hack in anything I missed.
Hopefully next time you hear from me (may take a while again), I'll have some animation code that you can stick in ENIGMA and use!
If anybody wants to see my current independent (working) code, let me know and I'll consider sharing it, but again keep in mind that it has dependencies on GLFW, GLEW, and GLM, which took me a while to figure out how to set up.
Also, if anybody wants to help, either in this or in the game that I'm working on (no, it's not a 3d MMORPG), that'd be super awesome. Let me know and we can figure out what parts you can work on and/or what parts need done. But I'm assuming most of you guys are probably busy working on your own things right now, so that's fine, I'll just keep chugging away at this
13
Tips, Tutorials, Examples / Re: Multitextured Terrain Example
« on: September 29, 2017, 04:04:37 pm »
(Dead topic, I know)
Does anyone still have a copy of this example or something similar to it? The dropbox link is giving me a 404.
As you may be aware, I'm trying to learn to use shaders in ENIGMA so I can incorporate animated models (which I currently have working fantastically in C++).
Does anyone still have a copy of this example or something similar to it? The dropbox link is giving me a 404.
As you may be aware, I'm trying to learn to use shaders in ENIGMA so I can incorporate animated models (which I currently have working fantastically in C++).
14
Graphics and Video / Re: [WIP] Collada (.dae) 3d Animated Model Loader
« on: September 16, 2017, 02:29:58 pm »
According to this:
https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/texture.xhtml
texture() was not introduced until GLSL 130, so I guess I'll have to stick with the deprecated texture2d for OpenGL1, but that's easy enough to swap out for OpenGL3/etc.
In my test program I've switched over to shaders without too much trouble. Also decided to use GLM, since handling my own matrices was becoming too much of a burden (much as I enjoyed doing matrix math, I could never get GL to render right). Hopefully this shouldn't be too hard to port back to ENIGMA.
Come to think of it, are there any examples using ENIGMA's shaders, especially in a 3d environment? I'm wondering how the MVP (Model-View-Projection) is handled.
https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/texture.xhtml
texture() was not introduced until GLSL 130, so I guess I'll have to stick with the deprecated texture2d for OpenGL1, but that's easy enough to swap out for OpenGL3/etc.
In my test program I've switched over to shaders without too much trouble. Also decided to use GLM, since handling my own matrices was becoming too much of a burden (much as I enjoyed doing matrix math, I could never get GL to render right). Hopefully this shouldn't be too hard to port back to ENIGMA.
Come to think of it, are there any examples using ENIGMA's shaders, especially in a 3d environment? I'm wondering how the MVP (Model-View-Projection) is handled.
15
Graphics and Video / Re: [WIP] Collada (.dae) 3d Animated Model Loader
« on: September 15, 2017, 02:23:05 pm »
Nope, that's what I said, and that's why I said it
Great, I'll do that then. Had to check cuz it's a little hard to find info on GL1 and GLSL. I just find a bunch of stuff for GL3+ and lots of deprecated functions without replacements (frustum? I 'ardly knew 'em). (and before you say anything, yes, I know you're responsible for your own matrices now. Just find it amusing that GL decided to nix all the useful functions)
Great, I'll do that then. Had to check cuz it's a little hard to find info on GL1 and GLSL. I just find a bunch of stuff for GL3+ and lots of deprecated functions without replacements (frustum? I 'ardly knew 'em). (and before you say anything, yes, I know you're responsible for your own matrices now. Just find it amusing that GL decided to nix all the useful functions)