Canardia

Yeah, but people want to create PDF files programmatically in realtime from their HTML web server. That's what verypdf does.

We tried adobe's service also, but it didn't work because they don't have a command line tool which you can install on your server.

Scopes! Of course, that's what I have been telling too, just forgot it myself now

I tried also with pointers, but then no destructors are called at all, and I need manually empty the vector. The code gets also unreadable with those -> instead of .. I think the only viable solution is to use the infamous .Create() and .Free() methods, and not let C++ decide when a constructor and destructor should be called. That way I have also more control over the performance, since I don't want any additional methods being called in time critical loops.

Both perform as well. The difference between languages is usually in nanosecond range, while the engine's graphical rendering is in millisecond range, for example 17 milliseconds per frame would result in 60 FPS (60 frames per second, 1 second = 1000ms, 1000ms / 60 = 17ms). Only when you do some heavy advanced stuff like AI pathfinding, you might find some remarkable differences between those languages even in seconds range. However in Lua (and in BlitzMax of course too) you can then use a external DLL written in C++, and it's faster again.

All languages will be always supported. The most popular languages like C/C++, C#, BlitzMax, Lua, Delphi/Object Pascal, have also ready-to-use headers, for other languages you need to write them yourself, or write a converter which does it automatically each time the C/C++ headers change.

Program in the language you like most. The documentation and engine commands are the same for all languages.

The volume gets gradually lower until it reaches 0 at the distance which is set with the range parameter. You must use mono sounds, since stereo sounds are only 0D (they are always hearable, no matter where you are), mono sounds are 3D and 4D.

Yes, but isReference is only true when Sound is initialized with an entity in its constructor, or assigned an entity with the = operator. But I don't think the problem is with the Sound class, but with C++'s random destructors. I have to find a hack how to prevent C++ from calling destructors at random times. The easiest would be of course to use always .Create() and .Free() manually, but some people don't like that either. Here's a demo to demonstrate the C++ bug: #include <stdio.h> #include <vector> #include <string> using namespace std; class myClass { public: string name; inline myClass(){name="fail";printf("constructor\n");} virtual ~myClass(){printf("destructor for %s\n",name.c_str());} virtual void Load(const string& s){name=s;printf("loading sound %s\n",name.c_str());} }; int main() { myClass myC; printf("creating vec\n"); vector<myClass> vec; printf("pushing 1\n"); myC.Load("abstract::gunshot.ogg"); vec.push_back(myC); printf("pushing 2\n"); myC.Load("abstract::reload.ogg"); printf("C++ BUG: there should be no destructor called here,\ besides there are not even 4 objects, but only 3!\n"); vec.push_back(myC); printf("array has %d elements\n",vec.size()); for(int i=0;i<vec.size();i++)printf("%d: %s\n",i,vec.at(i).name.c_str()); printf("end of prog, all 3 destructors should come next:\n"); }

LEO's Sound class is doing FreeSound() in its destructor, which is normally not wrong, but when using it with a vector, it seems the temporary object's (which is used to feed to vector) destructor is called for no apparent reason. C++ should not call any destructors before the object is released from memory.

Well, I tried it, and the destructor is called once after the 2nd push_back, which makes no sense, so destructors have completely illogical behaviour. And then you have another mistake, which also called FreeSound(): Sound myClass::GetSound() { return sound; } Here you return a copy of the Sound class, so the copy is destroyed after the function returns, thus it calls also the destructor of the Sound class. To fix this, always return references to attributes: Sound& myClass::GetSound(void) const { return sound; }

The problem is your MyClass destructor, which calls FreeSound(). Don't put any code into constructors and destructors, since they will be called at unwanted times.

We are a product from verypdf to run automatic html to pdf conversion on servers: http://www.verypdf.com/pdf2htm/index.html It's a command line tool, which has all the needed options, including user authentication and recognition of login redirection pages. And the support is very friendly and helpful.

Like I said, you need to copy it from gamelib, or use gamelib anyway: http://www.leadwerks.com/wiki/images/3/32/Gamelib.cpp

Hey, that looks pretty nice, especially with all the moving lights and shadows. The clean environment brings its own feeling to the game also. The game has immersion, party coming from the music too, which makes it a joy to play. The only disturbing thing I found was that your programmer completely forgot to use animation blending, which is very simple to do with a single floating point variable which resets and increases slowly from 0 to 1 over time when changing animation sequences. I think there should be a tutorial for this, since it's so simple to do with LE and adds a huge quality boost to the animations. Also smooth turning of the mesh is very easy to do using Curve() or TurnEntity() with smoothing parameter.

Seems that a C++ 2.32R5 OOP version is inevidable I started also to support earlier than 2.3 version in gamelib, but then I didn't care anymore. It may still work, but I test it only with 2.32R5+.

That is bad bmx code, but let's do it anyway: PositionEntity(player, StringToVec3(GetEntityKey(scene,"cameraposition")) ); The one who wrote that could have done the same in bmx, so there would be no conversion needed. The StringToVec3() function for C++ can be found in gamelib, just copy paste it from there or use gamelib anyway.

There's 2 types of multiple inheritance: parallel and sequential. In most cases sequential inheritance should be the right thing to do, since that's how nature works too. In your case, sequential inheritance will work fine, since Actor should inherit from Vertex, so Tower needs only to inherit from Actor. Or then the design of your Vertex class is wrong, which causes your dilemma. The Vertex class should only contain a 3D coordinate, and maybe some other general vertex related abilities.

There shouldn't be tons of different icons, since that also lowers readability (well, or recognizability in the case of graphical icons). A set of standard icons will be the best. The idea of fast visual recognition is a bit like the entity commands: you have a few entity commands, but you can apply them on any entity and do everything with a few standard commands. The public icon signs you see on airports and other public places share the same idea: there's a standardized set of icons, which are composed of standard symbols and sub-icons, which everyone can recognize very fast without speaking any language.

Most important are graphical icons for navigation. Tree view's can't do that so they are useless. However, you can simulate a tree view with ordinary pages too. Breadcrumbs are like the summary of a tree branch, so they are always good to have on top.

There's more to it. First people who have no idea of programming want to code in C++, because all the pros do it too! Then they find out it's too difficult and go back to a BASIC style language, like BlitzMax. Then, if they are really good and actually have learned to program, they start to write games and notice that BlitzMax takes forever to start in Debug mode, and start using C++ again, but this time with success.

"No Lessons", LOL, that doesn't look very good for the BlitzMax people Just remove the C++ word and everyone is happy for now, later on you can think of more advanced language options, but fix the engine bugs first (terrain height modification, skycam rotation, model viewdistance settings, and refraction emitter on water). People are trying to publish games here, and those are quite showstoppers.

There could be a preferred language option in each user's profile, which is then used to choose the documentation, API or tutorial according to his language. He can still switch to another language of course, it would be only the default choice for him. Then the tutorials don't need a seperate category for language, and it's less to click.

The language selection is already implemented in the API documentation pages. What's missing is only the feature to automatically convert from pseudo to target language, but it can be done manually also, like it is done now (tutorial authors can use an external tool if they want, to make their conversion work easier).

They don't need to understand the pseudo language, since they can choose their own language to view it. The pseudo language is like HTML, and users don't always choose "View Source" on webpages either, but they read the webpage as it's presented, and can also often choose different languages like English and German (which are both generated by the same HTML source, just using dynamic fields to lookup the phrases from a database).