Canardia

Screw it, don't use any GC command in bmx, they only make things worse. I just wish bmx would never have implemented those. You could also use the engine.dll from BlitzMax and get much more tested code, or just drop the whole BlitzMax which is not supported anymore anyway and use Code::Blocks C++.

Controlled chaos is my Senf. I let brainstorms, ideas and inspirations come and catch them, write them down, realize them as time allows. Then again, it's only controlled chaos for the observers, as for me it's all very structured and logical. It's the lack of information and background explanations which makes a bit more complex things look like a chaos to observers. But I have to use the terms which the observers do, else it would be not connected at all. And no, I'm not phychic, I'm gnostic. It's a delicate difference, the other one is for real

1) Both can be faster or slower at certain things. Rendering a 3D texture is slower than just displaying 2D text, but then againg movin a 3D window is much faster than moving a 2D window. 2) Bmx, Lua, C++, anything goes and will be fast enough, it's the GPU which is the bottleneck. 3) That's just a question of plain logic. I suggest you write it down on paper how it should behave, and get away from the computer, because the computer disturbs thinking with all its subcognicious distractions. As a hint: basically you can make it very simple by working with boolean flags. Have a flag for if mouse started drag action on window, if mouse was released while drag action was active, etc....

You didn't vote for Space Invaders, but for RTS. Anyway, one has to follow the majority, and not be turned down by some random individual opinions, that's the way it works. Unless you are an avantgarde artist, then you do just the opposite, which works also. So, in the end, you can do anything you want, and always find someone who likes it. As a hint: usually the rich people are avantgardists and want to pay a lot for exclusive items. They don't want to buy anything which is cheap, as they feel it's not worth enough then.

Great of you to keep the C# headers up-to-date with various environments

Things change and other things using those things must be updated from time to time to keep them working properly. Leadwerks Engine C/C++ was originally designed to work only with VS 2008, but keeping GNU C++ in mind, then a few updates were made to make it work with MinGW 3.4.5. Now MinGW 4.5.2.1 has been updated to support the newest C++ standard, and so a few updates need to be done in the Leadwerks Engine C/C++ headers too. But don't worry, those updates are fully backwards compatibe, so it will still work in MinGW 3.4.5. I've fixed today a few warnings with MinGW 4.5.2.1, and a few more are still remaining, which I will fix today also. VS 2008/2010 and Dev C++ work of course too, as these are only official C++ standard related fixes. When the official headers are updated, I will proceed with adding klepto2's new commands into a seperate community edition of the C/C++ headers, while he is maintaining the C# community edition headers. And even after that, GameLib needs to be updated too, to give no warnings with MinGW 4.5.2.1. But these will be natural updates as I fix them while I'm writing a few small example games with gamelib. I've setup release dates for these things also: 2011-07-22 Official C/C++ headers update 2011-07-23 Guess A Number game: Adding gameplay features 2011-07-25 Community Edition C/C++ headers 2011-07-30 Fortran headers Now I'm taking ideas what kind of other mini games you want to see made with gamelib. I've already planned a Tower Defense 3D game, but that is not so mini EDIT: Status update on 2011-07-25: engine.cpp and engine.h are ready and sent to Josh LEO was missing Body::SetForce and Body::SetTorque completely, so I added them all gamelib warnings with MinGW 4.5.2.1 have been fixed Guess A Number game is almost ready for beta testing Seems like the votes go for a mini RTS game next

I'm still not convinced about perks, but the same graphical display idea could be used, as the player knows anyway what he has guessed already, and he can see in the text mode version the history of his guesses anyway. So a graphical display just to serve as a memory helper for the player would be good (and to display jokers also).

Yeah, I thought of that too, to make the textout be presented as 3D graphical effects. The textout could be still there, but it could be hidden with some keystroke. Ah you mean like bonus cards. Yeah those could be earned after scoring well in a few matches. Not sure if that's good, what if the player has already tried a higher number, it would get very complicated and confusing Yeah I was thinking to add some distracting background action too, like just for fun and laughs Good idea! Not sure about starts, but I have already a high score table for the next step. No way! Interesting idea.

I'm starting now to make some small games with gamelib, since it needs some good examples. Documentation alone is not enough.

Banning after 30 days sounds a bit harsh, I would just stop supporting them with answers Some kids have no money, but they will get money after they have saved up enough, and it can take several months. Their parents get the payroll every month, so if they are low on money, it might take a few months to pay the kid her/his salary. Don't rule them out as potential customers, give the kids a chance to make games and not go on the streets to do hooliganism.

DrawText("Memory Used: "..gcinfo().."KB",0,20)

I tried multithreading earlier without mutex locking, but then it crashed on every LE2 command, so I didn't investigate further. Now Lazlo showed that actually all commands work with mutex locking, except the one's which are using buffers/FBO's. And those remaining commands work also when they are first used from the same thread which created the Graphics window, so even in this state it's already useful, but the ultimate goal would be of course to have FBO's working on all threads without preloading.

It's up to you to make the locking so that you don't let time critical parts get sliced by other threads. Normally the locking is just concurrent behaviour, and the CPU does things all the time. When one thing is locked, then it does another, and so an, so there is no time lost in that sense. I don't think the lock/unlock command itself takes much time, of course this can be tested also. And ultimately, you should get number of cores times faster programs, if you use the multithreading in the right way.

This error tells it all: "already defined in engine.obj". It means you must not include engine.cpp and leo.cpp when using gamelib.cpp. There is also a tutorial how to setup a Code::Blocks projects with engine, LEO or gamelib: http://www.leadwerks.com/werkspace/page/Documentation/LE2/tutorials/_/programming/cpp/gamelib-tutorials-r70

Well, it's basically good for using the other cores too, instead of just one. Without mutex you can't call any LE2 commands on the other threads. So for example if you have some heavy AI calculations, you can now do them on another thread and still use LE2 commands there.

It had nothing to do with memory structure. It's just that OpenGL doesn't return anything useful on other threads if it's not done first on thread which creates the graphics window. Even when I hardcoded the maximum texture size to 8192, it still failed on the OpenGL compileshader command. Klepto2 said it has something to do with FBOs.

#include "engine.h" int DoorCollision(TEntity e1, TEntity e2) { if(GetEntityType(e2)==1) // only interested in balls AddBodyForce(e2,Vec3(0,1000,0)); return 0; } int main(int argc, char* argv[]) { Initialize(); Graphics(800,600); CreateFramework(); DebugPhysics(1); TBody door=CreateBodyBox(1,2,0.3); MoveEntity(door,Vec3(0,1,0)); SetBodyMass(door,1); EntityType(door,2); TBody ball=CreateBodySphere(); MoveEntity(ball,Vec3(0,2,-8)); SetBodyMass(ball,1); EntityType(ball,1); TTerrain terrain=CreateTerrain(128); EntityType(terrain,3); Collisions(1,2); // ball with door Collisions(1,3); // ball with terrain Collisions(2,3); // door with terrain TCamera cam=GetLayerCamera(GetFrameworkLayer(0)); MoveEntity(cam,Vec3(0,2,-10)); SetEntityCallback(door,(BP)DoorCollision,ENTITYCALLBACK_COLLISION); AddBodyForce(ball,Vec3(0,0,500)); while( !AppTerminate() and !KeyHit() ) { UpdateFramework(); RenderFramework(); Flip(); } return Terminate(); }

It sounds logical to me.

Unlike many other 3D tools, they get paid requests from the 3D format makers to include their format, because UU3D is already the best tool, so everyone wants to be included in that. It's kinda like marketing also.

I can put the main thread which loads the engine and creates the graphics window to another thread, but the problem remains that the first LoadModel must happen from that thread.

Yeah, but the specular is there to bring more contract in the color range. You should also darken the ambient a lot that it doesn't look so flat. In real even a matte rusty oildrum has a greate color spectrum, which can be only achieved with HDR+SSAO+specular+dark ambient: http://1.bp.blogspot.com/-6pWTuEIVdUQ/TgAPO2oBV5I/AAAAAAAAAEs/7T0_NfZEn9o/s1600/IMG_2833.JPG

You can't move models which are not loaded, because they are not in the model vector yet. So everything which is in the model vector is already loaded.

Save it as png, a screenshot shouldn't be bigger than 300k then.

Maybe you need to bridge the cards: http://www.xtremesystems.org/forums/showthread.php?169509-Home-made-3-Way-SLI-results And/or check the nVidia SLI setting:

The new oildrum specular is horrible. I wonder who suggested to tune it down, because now it looks as ugly as CoD or something. Crysis uses realistic higher specular values which makes it the only game which looks realistic.