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.
196
General ENIGMA / DirectX Image formats and Fonts
« on: July 29, 2013, 09:15:06 pm »
Ok well this something we need to discuss. ENIGMA has its own code for loading various image formats, but Direct3D has a S*** TON of built in formats supported...
from...
http://msdn.microsoft.com/en-us/library/windows/desktop/bb172801%28v=vs.85%29.aspx
".. the following file formats: .bmp, .dds, .dib, .hdr, .jpg, .pfm, .png, .ppm, and .tga"
DirectX also has internal classes for dealing with fonts, you can simply request them by name and tell it to render, it takes like 5 lines of code...
http://www.two-kings.de/tutorials/dxgraphics/dxgraphics09.html
You can also ask it to build a mesh from font numerics and it will do so.
So this begs the question as to what to do about our fontstruct as it obviously needs moved so that its not included in our DX system when it doesn't need to be.
DirectX also provides internal classes for drawing sprites and batching them...
http://www.two-kings.de/tutorials/dxgraphics/dxgraphics09.html
Now this also leads to another thing as to whether or not we want to use those sprite functions for backgrounds as well. Not to mention in GameMaker sometimes people will apply transformations to text and sprite drawing functions to use them as 3D billboards. I would like some input from you guys Harri, forthevin, Josh.
Edit:
I have managed to get texture loading and draw_sprite implemented...
As you can see there is a tad bit of a problem, DX uses ARGB, ENIGMA loads textures into RGBA You can tell by the sprites pixel color being off.
from...
http://msdn.microsoft.com/en-us/library/windows/desktop/bb172801%28v=vs.85%29.aspx
".. the following file formats: .bmp, .dds, .dib, .hdr, .jpg, .pfm, .png, .ppm, and .tga"
DirectX also has internal classes for dealing with fonts, you can simply request them by name and tell it to render, it takes like 5 lines of code...
http://www.two-kings.de/tutorials/dxgraphics/dxgraphics09.html
You can also ask it to build a mesh from font numerics and it will do so.
So this begs the question as to what to do about our fontstruct as it obviously needs moved so that its not included in our DX system when it doesn't need to be.
DirectX also provides internal classes for drawing sprites and batching them...
http://www.two-kings.de/tutorials/dxgraphics/dxgraphics09.html
Now this also leads to another thing as to whether or not we want to use those sprite functions for backgrounds as well. Not to mention in GameMaker sometimes people will apply transformations to text and sprite drawing functions to use them as 3D billboards. I would like some input from you guys Harri, forthevin, Josh.
Edit:
I have managed to get texture loading and draw_sprite implemented...
As you can see there is a tad bit of a problem, DX uses ARGB, ENIGMA loads textures into RGBA You can tell by the sprites pixel color being off.
197
Announcements / DirectX 9 Implemented and Working! <Functions Can Now Be Written>
« on: July 28, 2013, 05:33:28 pm »
After trying this several times with DirectX 10 and failing, I decided to give DX one more chance to be a part of our game engine, and it finally worked with DX9. The headers and libraries are distributed with MingW for DX9 so no need to install the Windows or DirectX SDK, if you are on Windows you will simply be able to switch it under API settings and use it. Now of course not all functions have been implemented, the implementation status is listed below. This will increase the compatibility of ENIGMA on native Windows platforms and for those people Micro$hit likes to screw over with bad OpenGL support.
So we are now looking particularly for Windows users to help implement the graphics functions for DirectX. There's a lot of functions to be done, varying in difficulty so people from all skill-levels should be able to help. I am going to be writing a ton of the code as well, your help is going to be appreciated.
Currently Implemented:
Sprites: Full support
Backgrounds: Full support
Models: Full support
Primitives: Full support
Tiles: No Support
Fog: Experimental Support
Transformations: Almost full support
Projections: Full support
Views: Experimental Support
Curves: No support
Standard Draw: Almost full support
Lighting: Experimental Support
Shaders: Limited or Buggy support
Text and Font: Full support
Particle Effects: No support
Surfaces: Almost full support
Texture: Limited or Buggy support
Blend Modes and Color: Full support
Vertex Formats: No support
So we are now looking particularly for Windows users to help implement the graphics functions for DirectX. There's a lot of functions to be done, varying in difficulty so people from all skill-levels should be able to help. I am going to be writing a ton of the code as well, your help is going to be appreciated.
Currently Implemented:
Sprites: Full support
Backgrounds: Full support
Models: Full support
Primitives: Full support
Tiles: No Support
Fog: Experimental Support
Transformations: Almost full support
Projections: Full support
Views: Experimental Support
Curves: No support
Standard Draw: Almost full support
Lighting: Experimental Support
Shaders: Limited or Buggy support
Text and Font: Full support
Particle Effects: No support
Surfaces: Almost full support
Texture: Limited or Buggy support
Blend Modes and Color: Full support
Vertex Formats: No support
198
General ENIGMA / Doxygen Commenting Removed
« on: July 27, 2013, 07:07:07 pm »
This was the stupidest idea I had since I have been here. The original intention was to provide quicktips from an auto completion window in a new IDE and make our code more "friendly". In reality is just bloated the repository and made a mess of the source code, the Wiki is more thoroughly documented, can be run through an xml document processor for quicktips in an IDE, and also much better organized and where I want people focusing their attention.
199
General ENIGMA / Half Pixel Alignment
« on: July 27, 2013, 06:16:10 pm »
If any of you have ever worked with SVG or other vector graphics then you know you need to do half pixel alignment. OpenGL and DirectX work the same way. If nobody noticed, there was a bug where drawing an outlined rectangle wouldn't fill the pixel in each of its 4 corners, that was due to half pixel alignment.
I resolved this by changing the orthographic projection code to offset by half pixels instead of full pixels.
Anyway I am committing the fix soon and 2D stuff will no longer be misaligned or have edge artifacts. This was just a friendly reminder to everyone. Also be aware that DirectX9 eclusively has a half texel bug regarding sampling which must be resolved in a shader.
I resolved this by changing the orthographic projection code to offset by half pixels instead of full pixels.
Code: [Select]
glOrtho(x-1,x + width,y-1,y + height,0,1);
Should have been...Code: [Select]
glOrtho(x-0.5,x + width,y-0.5,y + height,0,1);
Anyway I am committing the fix soon and 2D stuff will no longer be misaligned or have edge artifacts. This was just a friendly reminder to everyone. Also be aware that DirectX9 eclusively has a half texel bug regarding sampling which must be resolved in a shader.
200
General ENIGMA / 3D Particle Effects
« on: July 26, 2013, 03:21:37 pm »
Yes hello, hai, this is something I have definitely been planning on adding the particle effects extension. It should be relatively easy to abstract into handling 3D particles without much changing. I do not know how Game Makers particles exactly work however as I never used them before because I tend to make 3D games. Forthevin, I don't know if you maybe want to take a crack at it, if so let me know, otherwise I am going to eventually do it myself.
201
Off-Topic / YoYoGames Compiler for 300$
« on: July 26, 2013, 02:40:04 pm »
Well they had everyone fooled thinking it was going to be the 1.2 update, but apparantly you have to pay 300$ to get it as a module, but if you have already paid more than 499$ then you get it for free, or in other words if you have Master.
http://gmc.yoyogames.com/index.php?showtopic=588680
This is commercial suicide for them....
http://gmc.yoyogames.com/index.php?showtopic=588680
This is commercial suicide for them....
202
General ENIGMA / Scalar Types
« on: July 26, 2013, 02:13:24 pm »
Well I was doing some thinking after converting graphics systems to use float precision. Now Box2D has a built in scalar type that can be used to switch the precision at runtime between double and float. I was wondering if it would make sense for us to do this for graphics and collision systems by providing a built in scalar type for ENIGMA. Josh, forthevin, Harri, what you guys think?
203
General ENIGMA / Graphics Systems Precision
« on: July 24, 2013, 10:47:07 pm »
Ok guys, now that I got all the common headers in all systems merged together removing bout 3100 duplicate lines of code. We need to switch all the draw functions in Graphics Systems to take float where previously they took double.
As OpenGL does not work in precision higher than float. Wherever you see like x or yscale they should also be switched. Width and height for images should remain as integer.
Code: [Select]
draw_text(double x, double y, string str);
becomes...Code: [Select]
draw_text(float x, float y, string str);
As OpenGL does not work in precision higher than float. Wherever you see like x or yscale they should also be switched. Width and height for images should remain as integer.
204
General ENIGMA / Porting Project Mario
« on: July 23, 2013, 11:33:31 pm »
I decided to give this another go. Blah blah *insert shit describing wtf my game is here* its a popular 3D mario game I made with Game Maker, blaha blahalha it used project k, blahhhhhhhh. Anyway, there is only a few things stopping it from working in ENIGMA, I want to cover them here if anyone wants to help pick up the task to get it work.
1) I use external resources in all my games, why you ask? Because it makes it fuckin slow to load your project to do coding when you have load ALL the resources ALL the time. I like people to mod my games, do texture packs, custom levels, etc. I refuse to use internal resources. Anyway, external png loading needs added to sprite_add for my textures, and wav for sound_add for my audio files, or I could convert those to ogg, I am fine with that. It would also be nice if I didn't have to manually set the working_directory, as that is FUCKING STUPID.
2) My 3D particle effects used inheritance as much of the code was the same. I can either remove them for the time being or get to work writing ENIGMA some 3D particle effects, which is what I think I would rather do.
3) I use ini files for my settings, I will use the one DaSpirit adds, or yaml functions, whichever come first.
4) Transformations in ENIGMA are clearly, fucked....
5) My object controlling the game state needs to be persistent, persistent dont work....
6) There really aint much else to port Project Mario other than to fix some minor anomalies and stuff, here is as far as I have gotten....
Source code is available in the other topic, http://enigma-dev.org/forums/index.php?topic=1161.0
It also only works for OpenGL3 if you do get as far as I did.
1) I use external resources in all my games, why you ask? Because it makes it fuckin slow to load your project to do coding when you have load ALL the resources ALL the time. I like people to mod my games, do texture packs, custom levels, etc. I refuse to use internal resources. Anyway, external png loading needs added to sprite_add for my textures, and wav for sound_add for my audio files, or I could convert those to ogg, I am fine with that. It would also be nice if I didn't have to manually set the working_directory, as that is FUCKING STUPID.
2) My 3D particle effects used inheritance as much of the code was the same. I can either remove them for the time being or get to work writing ENIGMA some 3D particle effects, which is what I think I would rather do.
3) I use ini files for my settings, I will use the one DaSpirit adds, or yaml functions, whichever come first.
4) Transformations in ENIGMA are clearly, fucked....
5) My object controlling the game state needs to be persistent, persistent dont work....
6) There really aint much else to port Project Mario other than to fix some minor anomalies and stuff, here is as far as I have gotten....
Source code is available in the other topic, http://enigma-dev.org/forums/index.php?topic=1161.0
It also only works for OpenGL3 if you do get as far as I did.
205
General ENIGMA / Contributing to the Wiki
« on: July 09, 2013, 04:34:44 am »
Hello everybody, I figured it was time I write a post about this. We have our Wiki for documenting functions, actions, tutorials, and everything regarding ENIGMA, so that everything can be found very easily. We also encourage members to edit and contribute as well, if you already have a forum account you can simply log in with the same credentials and begin editing and creating articles.
http://enigma-dev.org/docs/Wiki/Main_Page
Much contribution has come from TheExDeus, polygon, Josh, IsmAvatar, and myself. Lately I have been the driving force behind much of its improvement and documentation, and this can get rather tiresome. I would just like to say I appreciate any and all contributions no matter how small they may be, due to the sheer size of the thing it is very hard for me to get every single function documented. Any help is appreciated.
http://enigma-dev.org/docs/Wiki/Main_Page
Much contribution has come from TheExDeus, polygon, Josh, IsmAvatar, and myself. Lately I have been the driving force behind much of its improvement and documentation, and this can get rather tiresome. I would just like to say I appreciate any and all contributions no matter how small they may be, due to the sheer size of the thing it is very hard for me to get every single function documented. Any help is appreciated.
206
General ENIGMA / LateralGM and Plugin Packages
« on: June 05, 2013, 07:40:07 am »
I want to propose that we set up the various installers and other things to automatically retrieve both the latest plugin and LGM jar files from a single uniform location. I am the only one who is not lazy enough to keep them updated, and it is getting to much for me to repackage the WinPatch and the latest LGM release as well as the Windows installer, and I am not even able to update the python install.py package, and it is rather annoying for people to keep installing with older versions instead of the latest jar file release. It would not be such a problem if my internet would stop being KIA after a week, but 55mb's is wayyyyy too much for me to keep having to upload just over minor fixes to the jar file. This is why I would like a single unform package retreival system wherein I simply have to update ONLY the single jars, we could do it through repositories etc vs having them hosted on someone's dropbox. I haven't updated the Windows installer LGM since my first buggy release of the new jar
207
General ENIGMA / MinGW64, DirectX, and other things...
« on: May 31, 2013, 10:26:09 am »
Guys I want to start a discussion about ENIGMA migrating to use MinGW64 for several reasons and after being encouraged by the MinGW32 team themselves.
1) MinGW64 provides all the DirectX headers we need without asking people to get the Windows SDK in a 6 hour+ download, and I can't even get it to work like that anyway nothing links right at all and half the freaking headers are missing
2) MinGW64 has more developers and the release cycles are known to be more stable
3) Any new versions of MinGW32 for anything past XP will never get there properly even the GCC team has dropped it in favor of MinGW64
4) MinGW32 is always breaking crap everytime a new release is out ;_;
5) MinGW64 includes both the 32bit and 64bit prefixes allowing you to compile for both, so ya that pretty much speaks for itself
6) MinGW64 is backwards compatible all the way back to Windows XP, with a lot of Windows 2000 support but some things lacking
7) With MinGW64 it is easier to get help as it has the larger developer base and MinGW32 is pretty much dead
8) GCC only supports MinGW32 at versions < 4.8 anything newer only supports MinGW64
So yah, I think we should switch or at the very least we need support for it, otherwise I can not write a DirectX graphics system, it is that simple.
1) MinGW64 provides all the DirectX headers we need without asking people to get the Windows SDK in a 6 hour+ download, and I can't even get it to work like that anyway nothing links right at all and half the freaking headers are missing
2) MinGW64 has more developers and the release cycles are known to be more stable
3) Any new versions of MinGW32 for anything past XP will never get there properly even the GCC team has dropped it in favor of MinGW64
4) MinGW32 is always breaking crap everytime a new release is out ;_;
5) MinGW64 includes both the 32bit and 64bit prefixes allowing you to compile for both, so ya that pretty much speaks for itself
6) MinGW64 is backwards compatible all the way back to Windows XP, with a lot of Windows 2000 support but some things lacking
7) With MinGW64 it is easier to get help as it has the larger developer base and MinGW32 is pretty much dead
8) GCC only supports MinGW32 at versions < 4.8 anything newer only supports MinGW64
So yah, I think we should switch or at the very least we need support for it, otherwise I can not write a DirectX graphics system, it is that simple.
208
General ENIGMA / Perfect Circles
« on: May 27, 2013, 02:35:42 am »
I had a great idea of how we can make perfect circles in OpenGL3, make a flat plane, color it with a fragment shader
209
General ENIGMA / Networking Systems *forthevin*
« on: May 26, 2013, 03:25:11 am »
I recently got the chance to update the plugin and make networking systems show up as well as modified the makefile from SHELL and updated the compiler source to merge in the ENIGMANet multiplayer/networking functions from IsmAvatar. However I am having a problem, no matter what, it continues copying it as /None/ in APISwitchboard.h regardless of whether you set it in ENIGMASettings or I change its eyaml file to make it the default. You seem to know more about getting things to work properly in the engine like makefiles and stuff, do you think you could take a look at it? Everything is in my latest commit request.
210
General ENIGMA / Innacurate Framerate Counter
« on: May 24, 2013, 12:28:47 am »
Yah I think it is suffice to say I as well as many others have a few discrepancies regarding the frame rate counter.
1) The darn thing is so inncarute, it would be a better measure to use a random number seed to generate the proper count
2) Everybody who tries ENIGMA asks the same question, why does an empty game run at only 53 fps? Because its not doing anything, make it draw something. Why are 1000 objects in Studio faster? Because its not doing enough make it 100,000 objects.
3) It is horrible for when you are developing a game, take for instance when I was programming Project Mario. I knew that when I added particle effects my fps took a hit of 30fps, in ENIGMA it would probably go from 53 to 78fps because its alloted more CPU time, this is just stupid, there is no way then to accurately compare, and I for one can't work without it
4) A lot of Game Maker users I know will set_automatic_draw(false); then implement their own redrawing timer to lock draw events to 30fps and let the rest of the time go to updating, so you'd have perhaps 73 step events per second and 30 locked draw events, this is going to cause serious inconsistencies
5) Most game engines like Unity3D completely unlock the framerate and let vsynch catch, not even possible with ENIGMA, because ENIGMA may just decide your game does not need more than 53fps
Unity3D Reference 1
http://answers.unity3d.com/questions/15574/fixed-frame-rate.html
Unity3D Reference 2
http://forum.unity3d.com/threads/4607-Locking-the-framerate
If anything we need to have the option to uncap it if we want and control the CPU usage ourselves from Global Game Settings like you can in Game Maker, at least there I used to have control, but ENIGMA wants to just assume that every game runs at the same framerate, ignoring any other implications of testing and design of a game in the works.
1) The darn thing is so inncarute, it would be a better measure to use a random number seed to generate the proper count
2) Everybody who tries ENIGMA asks the same question, why does an empty game run at only 53 fps? Because its not doing anything, make it draw something. Why are 1000 objects in Studio faster? Because its not doing enough make it 100,000 objects.
3) It is horrible for when you are developing a game, take for instance when I was programming Project Mario. I knew that when I added particle effects my fps took a hit of 30fps, in ENIGMA it would probably go from 53 to 78fps because its alloted more CPU time, this is just stupid, there is no way then to accurately compare, and I for one can't work without it
4) A lot of Game Maker users I know will set_automatic_draw(false); then implement their own redrawing timer to lock draw events to 30fps and let the rest of the time go to updating, so you'd have perhaps 73 step events per second and 30 locked draw events, this is going to cause serious inconsistencies
5) Most game engines like Unity3D completely unlock the framerate and let vsynch catch, not even possible with ENIGMA, because ENIGMA may just decide your game does not need more than 53fps
Unity3D Reference 1
http://answers.unity3d.com/questions/15574/fixed-frame-rate.html
Unity3D Reference 2
http://forum.unity3d.com/threads/4607-Locking-the-framerate
If anything we need to have the option to uncap it if we want and control the CPU usage ourselves from Global Game Settings like you can in Game Maker, at least there I used to have control, but ENIGMA wants to just assume that every game runs at the same framerate, ignoring any other implications of testing and design of a game in the works.