I think we should be able to configure texture wrapping on TiledBackgrounds. Why?

I'm working on a project that uses a large screen resolution and needs to be downscaled on most computers. When a TiledBackground is downscaled, filtering is applied to the texture to make it look nicer. However, it is not always desirable to tile in all directions, and this filtering can cause 'texture bleed' on the non-tiling edges. For example:

<img src="http://img197.imageshack.us/img197/8857/5d7l.png" border="0" />

This image tiles nicely to the left and right, but not up and down. And, when downscaled, the black border on the top bleeds through on the bottom, due to the filtering. In OpenGL, this problem can be solved with the use of the GL_TEXTURE_WRAP_S and GL_TEXTURE_WRAP_T texture flags. Allowing Construct to change these flags would make TiledBackgrounds much more useful. As it stands now, I have to mis-use 9-Patches to work around this problem.

Try examining Template SDK. Here are some tips:

-> object basically consists of two classes - EditTime Object (this one you see and access thru layout editor) and RunTime Object - used when game's working

-> in main.h you define all fields and Action, Condition, Expression methods (called ACEs in SDK), be sure to check #define IDE_FLAGS

-> actions.cpp, conditions.cpp, expressions.cpp have implementations of these methods

-> edittime.cpp - there is a place to make init of object when it's pasted on leyout editor. You define here also Properties

-> to make extension "see" this methods, edit ACE Table.cpp - it's shown how to add ACEs and set its required parameters

-> drawing.cpp contains methods for drawing object when in layout editor and when in runtime

-> runtime.cpp - there are some initialization/freeing methods you could use for memory allocation and stuff. Most of work at runtime is done by methods in actions.cpp, conditions.cpp and expressions.cpp

-> debugging.cpp, serialization.cpp - sorry, didn't learn how to use them, but names tells everything ^^

Sorry for this kinda messed explanation, still learning C++ x(.

I've already figured that stuff out, though I'm still unsure about how serialization is supposed to work (though for my DLL, I don't think I will be needing it). I'm rather new to C++ as well, and I could really use some examples so I can figure out the little things. For instance, I know that MMF extensions had unique identifiers so that the main program could verify that you had the correct extensions required to view the project file, and I figure Construct has something similar, but I haven't found it yet. Examples would help me to figure these things out for myself so I don't have to ask so many questions :p

... But all of that is beside the point of this thread. A DLL object would be very useful, regardless of whether I make the DLL into a construct plugin or not. Converting my DLL to a plugin is just something I need to do due to the lack of a DLL object.

I tried this yesterday, and Construct always crashed on exit. It also crashed whenever I closed a project, but it does that anyway.

Construct needs a plugin that can load DLLs and call functions from them. I spent the previous weekend creating a DLL from some code I found on the internet, only to find that Construct didn't have a plugin to use DLLs like MMF does.

The alternative would be to convert the DLL to a construct extension, but I would need to see some example extensions other than the blank template that is the SDK. The source code for the DirectSound extension would be a plus, as I might be able to remove the dependency on SDL.

> I was working on a proof of concept *.cap for you yesterday, however several bugs with the Layout object halted my progress. The level editor can still be done, but the GUI would be alot different than what I had in mind. I probably can't finish it before I leave for seattle though (going to the Penny Arcade Expo)

>

This is good news. And if you are thinking about a new approach for a level editor, you can also think about the points I described in this mail as some design issues.

Thanks,

- Ramesh

My plan was to make a level editor that was easily adaptable to any game... but it seems every time I try to work on this, I uncover some show-stopper bug before I make any significant progress. First it was the layout object. I figure it may take some time to get that fixed, so I decided to scrap my other layouts and hack together some other kind of UI... when I came across that bug where objects on deleted layouts remain in the application... somewhere... That bug has been fixed, but now the debugger doesn't work at all.

The debugger appears to be broken in this build. Attempting to debug any application, including a blank one, causes a runtime error.

I see artifacts like that on the Combo Box object... in the dropdown area below the actual control.

I was working on a proof of concept *.cap for you yesterday, however several bugs with the Layout object halted my progress. The level editor can still be done, but the GUI would be alot different than what I had in mind. I probably can't finish it before I leave for seattle though (going to the Penny Arcade Expo)

What I would do is create a level editor, and let your friends make levels with that. Plan out how you are going to save your level data into an array, and make your events accordingly. I have already done such a thing in Multimedia Fusion, and I don't see why the same thing can't be done in Construct.

EDIT: Now that I think about it, it would probably be easier to do in Construct, since Construct allows you to create objects by name. Less busy work, more useful eventing.

Python modules are not handled very well right now. There is no way to tell Construct which modules should be used when test-driving your application, unless you first export an executable. But even then, after closing your project and re-opening it, you have to export an executable again, and tell it what modules to use again. This list of modules should be saved with your .cap, and you should be able to change it without exporting an executable. Otherwise, trying to use python becomes a painful experience.

*bump*

There is a pathfinding extension for Multimedia Fusion which can possibly be used for things like this.

http://www.clickteam.com/epicenter/ubbt ... mber=68509

Maybe if someone asks the author nicely, he can share his source code, and it can be ported to Construct.