Canardia

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(); }

Actually Flexman is right, the gravitational pull makes heavier object fall faster. In addition there is no such thing as vacuum, as 90% of the universe is dark matter. Dark Matter has just the same kind of resistance as air, but of course much lower, so the shape and size of bodies matters also when they fall through dark matter.

I was just adding wheels to my airplane, and noticed how much time the realtime LUA programming saves me when I was adjusting the positions of the wheels to their exact position. Having the airplane model positioned and zoomed on my screen, I added some code to load and position the wheels, and after each character change in code (like finding the value Vec3(0,0.125,2.01) for the front wheel), I pressed Ctrl-S and saw the result immediately on the screen. Using C++ or any other compiled language this would have taken me a lot more time, with all compiling and restarting between each adjustment. Even if I still need some C++ code for time critical things and 3rd party libraries, all the execute-once-at-startup code done with LUA reduces the amount of C++ code and programming time incredibly much. An industrial programmer who's getting paid for his work per hour, would probably save the company 50% of unnecessary expenses without that the programmer gets less salary, and the programmer would also get more motivated and have more time to focus on quality, since he is now so productive with Entity Oriented Realtime 3D Programming.

I added the following lines to base.lua, and got body elasticity working via the properties dialog, but I would like the commands to be OOP style, and GetElasticity() is missing: Each line was added after the corresponding line with "sweptcollision": group:AddProperty( "Elasticity", PROPERTY_FLOAT ) elseif key=="elasticity" then return 1 --feature request: entity.model:GetElasticity() elseif key=="elasticity" then SetBodyElasticity(entity.model,value) --feature request: entity.model:SetElasticity(value)

It means comparison for equality. A single = would be an assignment.

From my experience how mass==1 objects behave in LE, it's very similar to 1kg objects in real life.