ENIGMA Development Environment

Simple 4 sentences and 7 swear words. Must be a bad day.

Anyway, Harri, please tell me what happened.

Right now I can compile fine, but the exe is empty (white windows) even when I add a room (blue background by default) and objects. Someone can replicate this?

Basically it almost seemed that the data from the project was not written to IDE_EDIT. But I checked and it did. So whatever the project I open and compile I still get the white window which is usually open when not even a room is present. I guess this is because of the changes done for compile directory (move from enigma-dev to appdata?)? Dunno. Maybe I just need new jar's. I used the newest ones available in the wiki links.

If anyone can upgrade to newest from scratch and not replicate my problem, then I will try something else.

It seems that all the changes now being made to object system and whatnot have broken ENIGMA. While it's something that usually happens, I don't think we should keep doing that. The guy making the changes could of just finished the whole thing and then it could be merged. Same with many other pull requests.

Although it's possible my current problem is not connected to these particular changes, but who knows. Right now I can compile fine, but the exe is empty (white windows) even when I add a room (blue background by default) and objects. Someone can replicate this?

But this bug aside, we should merge only when functional. That is why I am still waiting for those integration tests from fortevin.

Some major commits (especially related to Linux) have been made. Maybe try upgrading, but beware that I am not sure if the newest version is functional. I will try upgrading on my Windows machine and see if everything runs.

It seems to work for me. At the start there is the Sslaxxworks logo, then after about 2 seconds it goes to The Last Alpha room where the logo slowly goes from top to middle, while a sound is being played. I think that is what you wanted. Are you sure you end up in rm_TitleScreen in your case? Because the only explanation I would have why it's not working for you is because alarm gets broken and you don't even go to rm_TitleScreen and stay in rm_SslaxxWorks.

Also, in rm_Initer's creation code you have "obj_Logo.TitleInCenter = false" which is invalid. Obj_logo isn't created at that point and so you are assigning an unexisting variable. "Obj_logo." doesn't change the whole object, but only an instance. It usually is the last (or the first, can't remember) instance of that object created, but in rm_Initer you don't have that instance at all. It should technically scream about uninitialized variables in Debug mode, but our debugger sadly doesn't catch this right now. It just doesn't really do anything. Also in obj_Logo mouse enter you have "global.TitleInCenter" which is not actually global. So this variable is also uninitialized. If you run Debug, then this will error.

*Slow compile time on windows

Define slow. I can compile an empty game in about 4 seconds. The first compile is of course slower (up to maybe 20sec), but subsequent are very fast. I of course have a good PC and ENIGMA is installed on an SSD though.

Oh I see, but yah people say glColorPointer is for vertex arrays but I use it anyway because it is easier than using the damn attribute functions. All it does is tell OpenGL the offset and stride, Direct3D is a lot nice with this.

Attributes are not that hard to use as they are barely different from these pointers, but it's just that attributes require shaders to be used and pointer functions like glColorPointer are deprecated in GL3. So again, if we want to write it as best as possible, we will have to ditch them.

But what neither of you guessed is that OpenGL and Direct3D's FFP both expect only a 4 byte color

I know that it "can" expect that. That's what glColorPointer type argument is all about. But the fact that "The initial value is GL_FLOAT." (see http://www.opengl.org/sdk/docs/man2/xhtml/glColorPointer.xml) should give the idea that float is the most common way. Either way, as you just set "GL_UNSIGNED_BYTE" in glColorPointer type, then it will work fine. But I just realized that if attributes are used then you can still pack them just fine inside a float and also show type in glVertexAttribPointer. So basically nothing changes.

very large batches to be run through my mesh class and be converted to a single draw call

But previously it was also converted into 1 draw call. What I am saying is that you try to apply "optimizations", but those are not necessary when we already write optimized functions for sprites/backgrounds/surfaces etc. They can be applied when a user uses vertex functions, but I doubt they are necessary for when you are just drawing 1 sprite. Like this is the current draw_sprite:
void draw_sprite(int spr,int subimg, gs_scalar x, gs_scalar y)
{
    get_spritev(spr2d,spr);
    const int usi = subimg >= 0 ? (subimg % spr2d->subcount) : int(((enigma::object_graphics*)enigma::instance_event_iterator->inst)->image_index) % spr2d->subcount;
       
        const float tbx = spr2d->texbordxarray[usi], tby = spr2d->texbordyarray[usi],
                        xvert1 = x-spr2d->xoffset, xvert2 = xvert1 + spr2d->width,
                        yvert1 = y-spr2d->yoffset, yvert2 = yvert1 + spr2d->height;

        draw_primitive_begin_texture(pr_trianglestrip, spr2d->texturearray[usi]);
        draw_vertex_texture(xvert1,yvert1,0,0);
        draw_vertex_texture(xvert2,yvert1,tbx,0);
        draw_vertex_texture(xvert1,yvert2, 0,tby);
        draw_vertex_texture(xvert2,yvert2, tbx,tby);
        draw_primitive_end();
}draw_primitive_end(); will call d3d_model_primitive_end(); and that will call mesh->end(). Mesh->end() has this for trianglestrips (which the sprite is):
case enigma_user::pr_trianglestrip:
                        triangleIndexedVertices.insert(triangleIndexedVertices.end(), vertices.begin(), vertices.end());
                        if (indices.size() > 0) {
                                for (std::vector<GLuint>::iterator it = indices.begin(); it != indices.end(); ++it) { *it += triangleIndexedCount; }
                                for (unsigned i = 0; i < indices.size() - 2; i++) {
                                        // check for and continue if indexed triangle is degenerate, because the GPU won't render it anyway
                                        if (indices[i] == indices[i + 1] || indices[i] == indices[i + 2] || indices[i + 1] == indices[i + 2] ) { continue; }
                                        triangleIndices.push_back(indices[i]);
                                        triangleIndices.push_back(indices[i+1]);
                                        triangleIndices.push_back(indices[i+2]);
                                }
                        } else {
                                unsigned offset = (triangleIndexedVertices.size() - vertices.size()) / stride;
                                for (unsigned i = 0; i < vertices.size() / stride - 2; i++) {
                                        if (i % 2) {
                                                triangleIndices.push_back(offset + i + 2);
                                                triangleIndices.push_back(offset + i + 1);
                                                triangleIndices.push_back(offset + i);
                                        } else {
                                                triangleIndices.push_back(offset + i);
                                                triangleIndices.push_back(offset + i + 1);
                                                triangleIndices.push_back(offset + i + 2);
                                        }
                                }
                        }
                        break;
                As you are using draw_vertex_texture() which doesn't add indices manually, and this means that you are doing that second loop to push back indices. If you used a function which added indices as well, then it will do the first double loop to check for degenerated vertexes (which of course there are none, as sprite function is very specific that it draws a quad). And so in both cases there is useless if checks and useless loops. You should be able to populate the index buffer from draw_sprite() and reduce some of the operations used. Of course in quad case the loop will run twice, and the compiler will probably unroll it, but still. I think it would be a lot better if the operations wasn't done for stuff we can do for manually.