Whether it is possible where to take 3D a engine?
Or source codes realizing parts of a engine?
Posted on 2005-04-23 12:05:34 by Avalonec
www.3dengines.net
www.3dengines.de
Posted on 2005-04-24 18:46:08 by Ultrano
Thanks, that has answered.
I thought, that nobody has understood me.: (
Posted on 2005-04-25 04:58:58 by Avalonec
Ultrano, you did not meet source codes on the assembler? On masme?
Posted on 2005-04-25 09:40:15 by Avalonec
No, I don't know any complete open-source project, written in asm. EvilHomer2k makes some good DX/OpenGL demos/tutes in masm, but I don't think they're perfectly ready to be used as an engine.
Only a few asm fellows have seen the power of macros to help them get easily to the real game-development (I mean actually making the gameplay). Maybe in a few months there will be such an engine, but now I don't know of any complete similar project in asm.
Posted on 2005-04-25 12:00:05 by Ultrano
I shall write. Not for the first time, to start with zero.
Posted on 2005-04-25 13:28:21 by Avalonec
I have not yet imho created a complete 3D game engine.
What I have done is write a number of the code modules necessary for such a game engine, and in a manner in which they are easily plugged together.
Normally this would be done by a close-working team of programmers, not one poor indy guy.
Thus I have found myself devoting much time to aspects of engine design, which could have been spent coding yet another half-assed and never-to-be-completed engine project.
I've had to learn patience and to reign myself in.

http://www.homer.ultrano.com/Upload/GameDev.txt

A game engine is not just a big blob of code.
It is comprised of a number of parts which work together in harmony, rather like the components of a car engine.

Major components include Timing, Geometric Rendering, General Effects (including alpha overlays, sprites, lens flares etc), Collision Detection and Response, Audio, Disk IO.
Such reusable components are the bread and butter of game developers.

Still, we should avoid the cut-and-paste habits of our C brothers...
Many optimizations lay in wait for keen asm coders which C compilers can't foresee.
For that matter, many logical optimizations can be made in the code itself in many cases.
With a deeper understanding of what we are doing, we can work wonders.
Posted on 2005-04-25 21:43:09 by Homer
And who speaks, what I one? ;)
Patience to receive result is correctly.
Not completed projects are time in empty. But such it happens frequently, unfortunately.
Miracles - it is strongly told!
Posted on 2005-04-26 03:03:36 by Avalonec
Sounds like a typical babelfish translation.

??? ??????????? ?? ??????? ????? ??? ???? ????? ??????, ?????? ????? ???
Posted on 2005-04-26 03:15:23 by SpooK
What offer? I while suggest nothing. If there are to me offers I with interest shall look at them. ;)
Posted on 2005-04-26 08:34:57 by Avalonec
Many optimizations lay in wait for keen asm coders which C compilers can't foresee.


*c++ coder biting tongue*  ;)

Depending on what you're coding, more optimizations lie within improvements of data retrieval & parsing than "straight code". This is especially true where API's like DX are concerned. It's the 80:20 rule.

Posted on 2005-04-26 20:13:18 by defbase