ENIGMA Development Environment

Here is a x64bit Linux executable for anybody to lazy to compile...

Download: https://www.dropbox.com/s/37w694x34lmk0ts/fps_logging
Size: 1.37mb's

OS: Ubuntu/GNU + Linux
Release: 13.04 Raring Ringtail
Graphics Capability: DX10/11 & Shader Model 3.0 and OpenGL3 with GLSL 3.0
CPU: Advanced Micro-Devices AMD x64 Quad Core at like 2.1 GHZ or something

Here are my results...
room_speed: 10, fps: 10
room_speed: 30, fps: 30
room_speed: 45, fps: 45
room_speed: 60, fps: 60
room_speed: 100, fps: 100
room_speed: 200, fps: 200
room_speed: 500, fps: 500
room_speed: 1000, fps: 967
room_speed: 2000, fps: 984


Forthevin:

4) No, they let step events happen at 60hz and drawing happen at 30hz or vice versa.

TheExDeus, yep I know exactly what you are talking about.

Least YoYoGames managed to code a stable update loop, where as you can not.

Edit: After adding the IQ test using a process priority lower than Game Makers, I was able to churn out 8000 objects each one drawing its own cube with 2 extra triangles per cube or 16000 extra triangles at a solid 90fps...


I will rewrite this again in the morning to use a single object drawing them all as one batched model 

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.

I find the programming concept for shaders of Blender quite intersting and somewhat better that Drag and Drop and think this would also be something for us to look into. You basically can connect input and output to combine various textures and materials to get effects you are looking for.




Thoughts guys?

Yes Deus however in the new graphics system they are using Vertex Buffer Objects. That creates the problem there because when you pack the vertice data into the VBO it gets sent to the GPU and is then cleared. Now the polygon functions I have already added to my version of Box2D, as you know we have two extensions now. The shape functions are used for building the various polygonal collision objects and stuff within the world. I was just proposing the idea of making them drawable, and all inclusive. And there has got to be a way of modifying a VBO or how vertex data is stored so that a z value is not even passed, I can't think of why there would not be. But I am only proposing dropping d3d_* in the future really, because d3d_model_draw is not consistent with draw_sprite and other draw_* functions. If I am wanting to draw a model then I darn well need to know wtf models are and prefixing them with extra characters that I don't need to waste my time typing always, is not going to help me, in fact a clear abmiguation would help me more to see that their is in fact a difference.