creating a opensource 3d engine graphics library

[Zensunni]

[MirekCz]

[Zensunni]

[jim]

[GeoffSulcer]

Oh I forgot...<br><br>We should definitely build on top of EasyCE.  Jacco has already done a good job on this and it provides a good foundation.<br><br>What I've been doing is using EasyCE and then replacing the primitives with my own functions when I need to.<br><br>-Snork

[GeoffSulcer]

I'm in too.<br><br>I have a casio so I can give some assistance on MIPS testing.<br><br>open source and free is vital of course.<br>3d engine and maybe some additional sprite support for 2d games.<br><br>I've started on a 3d engine for a game i'm working on.  i haven't got very far yet and I'd love to replace it with this new effort.<br><br>I've got a good background in OOP and C++, but I don't know if that should really be a requirement.  Let's shoot for functional and readable. <br><br>What ideas do you all have for the functions the API should provide?<br><br>-SnorkLast modification: Snork - 12/13/01 at 11:57:16

[Zensunni]

easyCE is the way to go, because if there is one thing that i dont want is having to take the different platforms into consideration too much <br><br>but first i have to get that working on my 3850<br><br>it also has grown too big to just be 2 files i think, it could do with some major redesign, making it nicely modular and stuff<br><br>I wouldn't mind doing that, but well, it's jacco's library soo he should have his input as well<br><br>Kind regards, <br>Willem

[Zensunni]

snork: background not really required, lets just do this for, fun, learning, and resume-building

[GeoffSulcer]

Sorry, I meant i didn't think that OOP should be a requirement for the 3d engine.  we could do it that way, but i tend to think that non OO code is a bit easier to read and follow.<br><br>-Snork

[Zensunni]

well, it really doesn't have to<br><br>i don't really mean oop as in extensively using classes, you can write perfect oop code in plain c<br><br>it is more style of coding, keeping things modular and small<br><br>each subsection is then easier to understand, easily replacable with a more efficient/ optimised for certain platform  part<br><br>and it really should make everything as a whole more comprehensible

[Dan East]

Hi. A couple suggestions right off.<br><br>Create a seperate project within the EasyCE workspace for the 3D portion, that way a seperate lib is generated for the 3D library. That library could then use the main EasyCE library for its display output (assuming it will even blit directly to the screen).<br><br>The OOP is a good idea, but can raise additional issues. First off, you don't need to restrict yourself rigidly to it within the engine itself (IE every vector represented by a class, etc). You could just expose the various user-accessible objects as Classes, so it would be more for interface functionality. One potential problem is that a lot of source out there is in C, which would raise compatibility issues. Take Pocket Quake for example. If it were to be modified to use this new 3D library, a substantial amount of extra effort would be required to convert the Quake C sources to C++ so they could call your library. So perhaps offering parallel interfaces (like MFC enhances the Windows API) would be the best overall.<br><br>Good luck! <br><br>Dan East

[Zensunni]

well, like i said, programming oop is not restricted to a specific language <br><br>the interface to all the rasterization routines will be c, and on top of that i intend to build some classes that handles for animated models etc  (stuff you'll never backport to pocketquake if you're sane <br><br>but you still have the possibility to acces teh rasterization routines if you want.<br><br>i doubt that'll bring you alot though <br><br>and yeah, i'm currently thinking how to fit in easyCE, because there is no way that I am going to do all the device abstraction myself <br><br>but I really would like to see some added features to easyCE, for instance "native" landscape support..<br><br>then you can request an orientation, and easyCE then gives you either a 320*240 or 240*320 buffer<br><br>this has the added advantage that you can return the actual hardwarebuffer on the iPAQ if you are in the correct mode.<br><br>right now i am really doubting what to do<br><br>branch of the current easyCE, and redesign it to my wishes seems the most appropriate, then people can always backport it if they find things usefull..<br><br>still thinking what to do though <br><br>

[MirekCz]

Zen:easyce gives you either 240x320 or 320x240 buffer... haven't we spoken about it already? a 320x320 buffer would be much better, because you won't have to implement all drawing routines twice, at the expense of some (not much) memory space, which could in the end be regained by not compiling twice a bunch of graphic routines into the exe file

[Phantom]

I don't think I can participate a lot on the coding front; I'm going to work for a VR company and I don't want to mix things up too much (I'll be doing a 3D engine for them as well). I do have some code to donate however; I've developed a rapid 3D engine that you might want to take a look at. The interesting stuff is a fixed point matrix class (includes most of the common operations, including transformations / translations of 3D vectors), and quite fast sub-pixel / sub-texel correct texture mappers.<br><br>Besides that I can only donate knowledge. <br><br>- Jacco.

[MirekCz]

Phantom:hey, that's a lot already. It would be great if we could include it in our codebase.<br>