Canardia

The speed of the game is a very essential part, actually the most important part. Gamelib wouldn't need much of its own LoadMap, if LoadScene would clean up the mess it caused. Plus it doesn't load user made entities anyway, so even if the loading is 2ns slower, its worthless if you don't have all functionality.

Yeah well this is kinda shorter, and works on all platforms: SDL_Surface* screen = NULL; //Set up screen screen = SDL_SetVideoMode( 640, 480, 32, SDL_SWSURFACE ); Or maybe not on all, but on a nice amount of platforms: SDL supports Linux, Windows, Windows CE, BeOS, MacOS, Mac OS X, FreeBSD, NetBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX. The code contains support for AmigaOS, Dreamcast, Atari, AIX, OSF/Tru64, RISC OS, SymbianOS, and OS/2, but these are not officially supported.

No, loop 1: 0.0000001 ms, loop 2: 5 sec, loop 3: 0.0000001 ms, loop 4: game loop: 20 FPS faster.

Not sure why you don't understand the point. LoadScene() takes most time. The rest around it is minimal and not worth to mention, and only to mention since they actually make the game faster. If you want 0 loading times, you don't use LoadScene(), but make your own streaming loader. It's as simple as that.

Yeah, Mumbles should upgrade to 2.4 and get done with Lua

I use it, because it does a lot of things, and it is updated frequently. So if I would rewrite the whole LoadScene(), I would need to update it once in a while, and not really gain any speed benefit either, since the time taking step is to create the terrains on the GPU. The only alternative to LoadScene() would be your own LoadModels() function, which stores the dynamically moved entities into a C++ STL map and also the modified terrainheightmap and then loads/saves them from disk. I've done that also and it's insanely fast, not sure why LoadScene() is slower there, but it might be because of garbage collection of BlitzMax, or some special logic which raw heightmap loading doesn't need (for example no loading of terrain textures).

Actually it is faster than a normal LoadScene(), because gamelib disables some Lua scripts by default, and does them in C++ instead. Anyway, the speed difference is ridiculously small, and the most time wasting thing is still LoadScene(), and then specially loading of a large terrain. So if you really want to speed up the loading, you should rewrite LoadScene() completely and not use SBX at all, but some binary high optimized game map format, like gmf was made for. And you should not use terrains at all, but load each tile from a SQLite3 database, since there is no point to load things which the player doesn't see at that time.

You need to stay realistic. If it loads 0.0001ms faster, but your whole game is 20 FPS slower, then the total speed loss matters. Besides the ProcessSceneInfo() is done in raw C, so it can handle 3GB of data per sec, and which SBX is even near to 3GB?

It's not really faster, since if you don't do a gamelib style ProcessScene() afterwards, you end up with lots of waste entities, which eat memory and slow down the FPS, not to mention about the collision bugs it might cause. And if you don't do the ProcessSceneInfo() before, you end up with missing features So, gamelib is perfect.

I already wrote it First ProcessSceneInfo(), then LoadScene(), then ProcessScene(). And the Scene::Update() has of course also the functionality to update the additional entitites, like nametags, mirrors (not yet implemented), etc... I'm not sure if I should add rain (I have 2 types of rain: physics rain and raycast rain) also to Scene::Update(), because the new trend is to keep the classes of gamelib standalone. So you have to call rain.Update() yourself in your mainloop.

LoadScene().

No, the initial ProcessSceneInfo() only scans for things which LoadScene doesn't load at all, like terrainresolution and terrainsize. ProcessScene() handles only in-memory entities after LoadScene.

The Scene::LoadMap method does first LoadScene which loads the vegetation layers, and gamelib's ProcessScene() after that just handles the entities more elegantly (for example not leaving annoying physics bodies of lights, etc... behind), and of course loads also additional entities, like playerstart, weapons, etc.... Loading screens with progress bars are done via POSIX compliant multithreading, which I will add to the next gamelib (I already published the source of that in the forum earlier).

Sure it does, I'm working on a game with gamelib and the level artist is using vegetation layers only for vegetation.

You can convert or split a stereo sound to mono with WavePad or Audacity. WavePad is better.

Well, if there would be a better engine on the market for under $10000, I would buy it.

What do I need to do, to get LE render into a SDL window? I just get a black window, but LE runs since I can hear sounds. I'm using framework also. CustomBuffer with Framework doesn't work with Masterxilo's standard windows window either (also black screen, but game works), so it must be a problem in framework.

That would only make updates slower to SDL. It's better to use the original SDL with LE.

You can use SDL in Lua, it's the only library which supports PS3 and XBOX controller force feedback.

You must set the entitytype of the car's model body to something which doesn't collide with the vehicle body. The flying is caused by a overlapping collision of two physics bodies.

I use GetFirstEntityByKey("name","sun"); after I have set the name of the directional light to "sun". This is a function in gamelib, which you can copy into your own library, or use gamelib as it is.

PointEntity(pivot,sun); TVec3 direction=EntityRotation(pivot);

No.

If you want to make money only, but no innovation, ideology and technology, then you should go to the wallstreet. Game development is not about money only, indeed money plays a role of maybe 10% in it. And at some point people have enough money, that it's not worth anything anymore. You have a house, smart car, job, internet connection. You don't need anything else, so you spend your money and live on arts, innovation, ideologies.

Mumbles makes a good point: Debian. I didn't understand the point of the rest of her message