ENIGMA Development Environment

We just don't bundle FMOD dll's with ENIGMA (as they are large and can only be used in a freeware game). I will probably have to write a wiki entry on how to make that work. SFML probably has the same problem. SFML also probably never worked on Windows the first place as it was created by a Linux user.

Hi. I just noticed that vertex color was not implemented. This effectively broke many model functions and all primitive functions. I then implemented color buffer, but what do we do about these cases:
draw_vertex() - I made it use bound color and alpha.I think that was how GM did it, but now I am not sure. Will check when I have the chance. Confirmed, this is how it's done in GM.
d3d_model_vertex() - Should this also use bound color and alpha? Problem is that default bound color is black. As examples in EDC which run in GM doesn't set any color to white before adding the vertexes, then I belive it doesn't use bound color and alpha and just uses c_white and 1.

1) So should we use bound color and alpha or just set everything to c_white and 1?
2) Should we just not bind color buffer at all if color is not used? It didn't seem to work in draw_primitive() case, but it works in d3d_model case. I made a bool which turns to 1 when color function is used. Otherwise it's 0. Question is also if its faster. We do use less memory and I guess model building is faster as it doesn't send useless data to GPU. So maybe this bool method is better than filling vector with c_white and 1.0 all the time (which is extra 4 gs_scalar's for every vertex).   

edit: I just tested and here are some clarifications:
1) GM uses bound color whenever no color is specified. So draw_vertex(), d3d_vertex(), d3d_model_vertex_texture() and so on just use bound color. It never defaults to 1 or c_white.
2) It uses this color when drawing, not when the vertex is added. So when d3d_model_vertex_color() is used, then it bounds color to that vertex at that point. But if d3d_model_vertex() is used, then it defaults to the set color when d3d_model_draw() is used. We cannot really replicate this behavior if we use VBO, as it would require us to loop vertexes and such. We could maybe use glTexEnvf to achieve this, but it would work on all vertexes and not only the changed ones.
I made changes to replicate the 1. part, but it will break the bool fix that I added now and it would break some compatibility. Like the cel shading example at EDC wouldn't work (as all the models would default to black) and it would have to be modified.

edit2: I can also actually make it work for 2) by using the bool fix differently, but then it would break in another case when vertex functions are used interchangeably like this:
draw_set_color(c_red);
draw_set_alpha(0.5);
draw_primitive_begin(pr_trianglelist);
draw_vertex(10,10);
draw_vertex_color(100,10,c_green,1);
draw_vertex(100,100);
draw_primitive_end();In GM this would draw a red transparent triangle with one solid green corner. In ENIGMA it would do the same, because the model is rebuilt all the time. But if d3d_model's are used like this:
//Create
model = d3d_model_create();
d3d_model_primitive_begin(model,pr_trianglelist);
d3d_model_vertex(10,10,0);
d3d_model_vertex_color(100,10,0,c_green,1);
d3d_model_vertex(100,100,0);
d3d_model_primitive_end(model);

//Draw
draw_set_color(c_red);
draw_set_alpha(0.5);
d3d_model_draw(model,0,0,0,-1);In GM this draws the same as the previous code. In ENIGMA this would break right now. It would break because d3d_model_vertex wouldn't add anything to color vector (and useColorBuffer would be false), but d3d_model_vertex_color would add the color and alpha to the color vector and would set useColorBuffer to true. That means the d3d_model_draw() would bind the color buffer and would think it has 3*4 floats in it (RGBA for every vertex), while in reallity there would be just 1*4.

If I fix this by making d3d_model_vertex add bound color and alpha, then it wouldn't be buggy, but it would draw differently. The code would draw a black solid triangle with one green corner. The bound color and alpha wouldn't change anything at the point d3d_model_draw is called.
I can fix this by using useColorBuffer bool. So make it add bound color and alpha if d3d_model_vertex is used, but don't bind it to VBO if only d3d_model_vertex's are called and no color functions. This would make examples on EDC work (as they only use d3d_model_vertex or d3d_model_vertex_color and not both together), but it wouldn't work like GM in cases where they are both used together.

This was also fixed by changing the drawing functions to have a half-pixel offset a few days ago.

Most graphics hardware do not support double point precision for rendering even by emulation, really only a few Nvidia cards do.

You make this hardware support mistake a lot. Just like you thought cards for some reason doesn't support primitive AA. So I'll just clarify - Nvidia supports non-emulated double precision since GTX2xx and it is supported on all cards since. The speed of course is lower and there was even a performance hit going from GTX5xx to 6xx as the architecture changed and no longer was tied to Tesla. But it still is supported. ATI has support for double precision since  Radeon HD 3xxx, but it sadly changes between low end <x700 which doesn't support it and >=x700 which do. So only ATI min-end/high-end ATI cards support it and all Nvidia cards.

Other than that I agree that graphics by default should be float. We also use glVertex2f which actually is float. So even when you change that scalar type to double nothing will really change on GPU side. It will just take more casting. For double it should be glVertex2d. So unless later we also make overloads/abstractions for all of the GL functions, then that scalar cannot impact GPU speed or precision in any way.

Well technically why not. Call it something reasonable so it doesn't overlap though (had this problem in another project, where a guy called one scalar FLOAT and it conflicted). Also there should be a different one for each system, so you can change it on per system basis.

Why just not make it default like GM does it? Just set the working directory to temp folder. The problem is not where the objects are built, the problem is where the .exe is ran from. The that ./Build wouldn't even actually fix the problem unless you set it the same as the gmk folder. Just change the plugin, so instead of exec(Game) it would be "cd to temp, folder and then exec(Game)". I am sure it should be possible with Java.

1) I will add png loading. Wanted to upload some stuff previously, but I still have problems with .bmp's and for some reason new bizarre bug which doesn't allow me to draw anything. Probably will have to revert and try again.
3) Ini's work as far as I know (on Windows at least).
4) Transformations also work as far as I know. I have used them in both 2D and 3D and haven't had any problems. A long time ago when I implemented them the order was wrong, but someone later fixed it and it should now work just like GM.

Sadly I can't find any easy to use library for jpegs and I am not really into mood of remembering discrete cosine transform to make them. Libs like libjpeg require dll's to be shipped with the exe and while it probably can be linked statically I cannot be bothered with that either. I personally believe that .png is the only format you need. It supports alpha, is lossless and compresses nicely. So while more formats for enigma would be good I don't think we should add them until some system that Josh proposed is in place. Until then I think we should just support .bmp and .png. I will try to fix .bmp, but it really is a mind bending bug.

Josh, can I commit the changes (or make a pull request) with the lodePNG library included? The good thing about is that it's only a header and .cpp file. No libs of any kind. Just include the header and you are set. I put the files the same folder as surface.cpp, but I guess it should be in Additional... So what do you propose? I think we need .png sooner or later and I could implement this rushed version and later when some extension system is in place we could redo it properly. They are total of 288kb. When compiled then 112kb. If I remove things we don't use (like english error messages, C++ wrapper (I can just use C), file functions (I just write them manually) and decoder functions (we only save, not load)), then it goes to 69kb. When linked then compiler probably optimized duplicate code and it's even smaller. Now the code is a little uglier though, as it no longer is 1 line to save the image.