Canardia

It's not that simple. I would also need BlitzMax C++ compiler (bcc.exe) source code in order to compile LE with VC++. It was available earlier, but I think it's not available anymore. However, I've played around with converting few functions to C++, but it's a huge job to convert everything to native C++. Meanwhile, I reran all the speed tests again, and Debian GNU C++ wins! I remembered wrong, VC++ was not 2.5 times slower than GNU, but still a lot slower. Currently MinGW is 1.902 times slower than VC++, and VC++ is 1.315 times slower than GNU:

Yeah, I have the benchmark programs still somewhere, but I could rerun them for the current versions of MinGW/VC/GNU to see if anything has changed. I used all possible optimizations also, and got some more speed out of MinGW too than with its default settings.

You can use the same dll with any programming language, so it's the same also which C++ compiler you use. A Linux port would be very interesting, since currently LE is compiled using MinGW C++, which is a GNU C++ port to Windows, but it's much slower than the real GNU C++ under Linux. Under Linux, BlitzMax uses the real GNU C++, which makes about 400% (=5 times) faster code than BlitzMax under Windows, if you do the math: MinGW is 2.5 times slower than VC++, VC++ is 2.5 times slower than GNU C++.

Instead of scaling (=using a scalar factor to multiply each vertex position), couldn't there be a command in LE which actually changes the vertex positions in the mesh and physics shape?

When you export to obj, you must provide the mtl file too. The obj file alone is not the complete model, since half of the information is stored in the mtl file. So, obj+mtl must be always together. In addition, UU3D Pro needs also the textures. If you don't have the textures available when importing and exporting, they will be removed from the model. When you have obj+mtl+dds (or any other texture format) available, then UU3D Pro works fully automatic, and you don't need to do anything else than save as GMF.

The Mac sells well for people who have no clue about computers. They just want some keyboard and screen which works. The consoles are similar in the idea, they have also completely outdated hardware, but they are easy to use, and require no skills of computers. If people would just take the time to learn how computers work, they would get much better quality at lower prices when using a PC. But learning and skills are not in fashion anymore. Everybody just wants to have things without knowing anything about anything.

Well, an external USB Floppy is fine. You still need Floppy disks when you want to play some old Amiga games, or read some old PC floppies, but also some servers with Windows 2003 need additional drivers from USB floppy disk (unless you want to make a custom setup CD).

You don't really need a CD/DVD drive anymore. A BluRay and Floppy disk drive is enough

Framewerk is not only post-processing, but it also provides water with physics, and transparency for windows and other transparent objects. That's quite important for games too. Everyone should use framewerk, else you spend 90% of your time writing your game with things which framewerk already does for you, instead of spending your time on the actual game.

In the gamelib demo you can find a volume trigger. It's used to change the ambient light inside/outside the pyramid, and its placed at the entrance of the pyramid.

Length(GetBodyVelocity(body));

Use TurnEntity to turn an entity. RotateEntity is only used to set a static angle to entities.

It works fine for me. One thing I noticed though with the export from 3DSMax9 is that you need to export 3 loops of each animation to the same gmf, since 3DSMax9 doesn't export the animation frames correctly when you're using some bezier curves in the animation. But with 3 loops, the middle sequence will be complete with all frames.

You could put each frame as a jpg file in a pak file, and then load each pictures into memory. Then you can "playback" the images from memory at any speed you want, along with playing an ogg sound for the soundtrack.

I think linepick radius must be 0, else it won't work at all.

You can use WavePad (normal version is free, possible to buy masters edition also) to convert WAV files to OGG: http://www.nch.com.au/wavepad/masters.html

There's really nothing much to do in order to load a scene with lights, sounds and all scripts. Just a simple LoadScene() is enough: --Register abstract path RegisterAbstractPath("") --Set graphics mode if Graphics(1024,768)==0 then Notify("Failed to set graphics mode.",1) return end --Create framewerk object and set it to a global object so other scripts can access it fw=CreateFramewerk() if fw==nil then Notify("Failed to initialize engine.",1) return end SetGlobalObject("framewerk",fw) camera=fw.main.camera camera:SetPositionf(0,2,-2) scene=LoadScene("abstract::testscene.sbx") while AppTerminate()==0 do fw:Update() fw:Render() Flip(0) end

It was not left out, but dofile() is a native LUA command. LE would have to do it's own DoFile() command which supports abtract paths, or you can use dofile(AbstractPath("abstract::somefile.lua")), theoretically at least.

LOL, that must be the most reference utilizing C++ program I've ever seen. Methods after methods after methods seperated by dots.

What if a black hole is dragged into another black hole, wouldn't there the terminal velocity exceed lightspeed, since space and time is bent, so that no other object could even come close to reaching the same terminal velocity being dragged in either black hole? Newton's formula lacks that component. However, if you use Newton's formula of gravitational force between two masses, and assume the distance is limes 0, you get also very interesting results

The thing is, you don't need to do anything in C++ to let the LUA scripts load their things. They are all called by the first UpdateWorld() call in C++, which you can do also before the main loop once to have some better preloading. My intuition says we should use LUA for all ProcessScene handling, as it's also tied closely to the game development, according to the WYSIWYG principle. If something is not possible in LUA, then gamelib's ProcessScene should kick in and do the rest, but I have to make an option in gamelib to remove it's claws from ProcessScene when LUA is used. Right now it just kills all LUA scripts, which kinda works since it takes care of what it killed

I voted for option 2, it sounds like less duplicate code, and easier maintenance. Although I think that intelligence is too slow for modern needs, and that intuition replaces it completely (referring to your option 4 comment).

Yeah, it's just a simple direct mode OpenGL command after all, but when it's called often, like in speed tests, the fact that the DLL call has to go through many more instructions (BlitzMax GC, C headers) than a C++ inline function (which is stored directly into the loop, not even calling the function internally (thus avoiding the stack, which is slow)), sums up in the speed difference. Sure it's not a bottleneck, as nobody would call thousands of DrawLines per frame

While gamelib's ProcessScene still works with 2.3, I think it's not really needed anymore, since LUA does all the ProcessScene with each Model's own script. With the entity scripts you get much more flexibility into the ProcessScene function (like adding parts from disk to models), although gamelib has lots of stuff already built-in. I don't know yet what is the final solution, as I just need to use them more and write games to see where the benefits and limits of either method show themselves.

If you are using C++, you might consider using gamelib's Line function instead, as it's about 10 times faster than LE's DrawLine: inline void Color(double r, double g, double b, double a) { glColor4f(r,g,b,a); } inline void Line(int x, int y, int w, int h) { glBegin(GL_LINES); glVertex2i(x,y); if(0==w)w=1; glVertex2i(x+w,y+h); glEnd(); }