ENIGMA Development Environment

First, tbx and tby are both 1 for Po2 textures.

I am aware.

But as I stated. (GL_TEXTURE_WRAP_S,GL_REPEAT) draws only the min(window_width,window_height). Maybe there is another parameter that needs to be changed, but for now I can't see any way to fix this. For example, I added a picture on how draw_sprite_tiled_n2 draws. It should tile the whole room, but it tiles a square of 480x480.

Second, I believe the most efficient way to code this function is by giving it this structure:

Well keeping the second thing in mind it should be:
max_size = min(window_width,window_height)
if (tbx == 1 && region_width < max_size)
  if (tby == 1 && region_height < max_size)
    //YOUR CURRENT METHOD
  else if (region_width < max_size)
    //DRAW LARGE TILED HORIZONTAL STRIPS OF SIZE REQUESTED_WIDTH * SPRITE_HEIGHT
else
  if (tby == 1 && region_height < max_size)
    //DRAW LARGE TILED VERTICAL STRIPS OF SIZE SPRITE_WIDTH * REQUESTED_HEIGHT
  else
    //THE INEFFICIENT METHOD

Cool, I'm gunna work on a 2d raytracing shadow engine. Could do it better if enigma had surfaces but w/e

Yeah I am waiting for surfaces for quite some time too. I am trying to implement them myself but I hate C++ and its header files. Just useless piece of shit design that language has. I am doing everything properly as far as I know, but I just can't get it work. I have:
#include <GL/glext.h>Inside of OpenGLHeaders.h and that file glext.h which is in MinGW/Include/GL directory has declarations for glGenFramebuffersEXT, GL_FRAMEBUFFER_BINDING_EXT etc., but when I try to compile I always get:

GSsurface.cpp:98:30: error: 'glGenFramebuffersEXT' was not declared in this scope
GSsurface.cpp:106:16: error: 'GL_FRAMEBUFFER_BINDING_EXT' was not declared in this scope
GSsurface.cpp:107:23: error: 'GL_FRAMEBUFFER_EXT' was not declared in this scope

And so forth. Josh said that I need to run the makefile .sh but I can't do that on win. And I actually don't get why I would need to do that, as that would just generate Makefile inside the Graphics_Systems\OpenGL directory and that file has this:

.eobjs_$(MODE)/GSsurface.o: GSsurface.cpp OpenGLHeaders.h ../../API_Switchboard.h
   $(CXX) -c GSsurface.cpp      -o .eobjs_$(MODE)/GSsurface.o $(FLAGS)

Which seems all I need.... I always had problems with this in C++ and so I always made my small projects in one .cpp file. 

Yeah, but surfaces have a 1024 x 1024 limit as i've heard... I was using surfaces initially, but then read they have limitations

Where did you read the limitations? The limitation is just the max texture size your video card supports. With my, now quite old, geforce8800 its 8192x8192 or even more. Usually its just how much memory you have. Even when the max limit is 1024x1024, you can still make several surfaces and work on them in tandem. I have used surfaces for extremely large rooms in the past.

Also, surface is the same as a texture. If you can't have a surface larger than 1024x1024, then you won't be able to hold a texture larger than that too.

edit: Here is a little demo on very large surface array. Sorry its 7.2mb, because I needed to include FMod.dll. My original milestone was to convert this to Enigma, but OpenAL doesn't support easy get_Spectrum functionality. Press O to see both channels and the part of the spectrum it looks for the beat.

Looks to me like you're missing the autocrap package. I would look on Cygwin's package list for autotools, automake, autoconf, or something and make sure it's installed.

I checked the package list and c_incl was not there. I did install all make and auto... packages. From this I understand it is a program, and so I should be able to find it in the package list if it existed.

edit: So basically I guess there is no way to run this .sh from win.

Great, thou finishing that font support would awesome. ISM says she already has done everything and so we all can blame you.

In kind of related note, I get this error in rev591 when compiling the curve example (in that thread about the curves):
"Subimages of sprite `spr_font' vary in dimensions; do not want."
And when exactly can that happen? I know that it happens when dimensions don't agree (doh), but when can that happen? When LGM screws up and returns cropped sprites or something?
Added the gmk if someones interested.

edit: Also, I know I shouldn't post it here but what directories does make check? I try to disable vsync in opengl via the windows extension <wglext.h>, but I when I do #include <GL/wglext.h>, it says the file doesn't exist. I placed it C:\CodeBlocks\MinGW\include\GL where make you totally check right? The header can be downloaded here: http://www.opengl.org/registry/api/wglext.h

IDE_EDIT_resourcenames.h is the bit I was talking about, the problem with changing them is that all references to them also have to be changed to each variable will have to be checked if it is a resource name and if so append the relevant prefix.

I still doubt its hard, as some Java based obscurer(?) did this too for gmk's. I could be wrong thou, maybe there is some via ass method on how Josh did something and so its hard to implement.

Yeah, it would look like so:

Welcome to ENIGMA forums
Check out the wiki for more information:http://enigma-dev.org/docs/wiki/index.php

The end.

Yes, all of these will be queued in each event if used. Pay attention to that last clause. If no one uses the when(), step{}, or draw{} statement, they will not be added to any of the objects. As polygone mentioned, most of the events are entirely queue-based anyway, so the performance cut from when() will be roughly negligible. Those who are concerned about the negligible (such as myself) can opt to program the checks in manually so they are not stacked anywhere and iterated.

I just meant drawing. As far as I know drawing is not queued, and thus using draw{} inside step event would cause problems with depth. That was all I was saying. Maybe I misunderstood something thou.