I wrote a response 2 days ago and apparently it didn't take so now I'm here typing it again. sigh. at least I have a real keyboard this time (typed last one on touch screen keyboard phone)  I agree if it were to use real 3d and textures and poly counts were carefully managed a full 3d fps should be "easy". I put easy in quotes because writing a 3d game engine is a rather large under taking.  portal would have to be a slightly longer range goal for the engine. one would build an fps first then modify the physics and rendering engines to manage portals.  portals represent a difficult rendering challenge valves portal as I understand source may have to render the world up to 5 times (default render depth of 2) in various resolutions to get an image so if possible a better way should be found (the engine has a hell of a time trying to render multiple sets of portals that are in the same room. there is a reason only one set of portals is allowed at a time. again that's if i understand correctly.)

Though the engine would have the advantage of only having to render in 4-bit grey-scale on a 32 bit processor and there for with some careful register games work addition on 5 pixels at a time and multiplication of 3 in single ops. (rough guess haven't worked it out yet I need to do some looking up on the architecture.) rendering still will represent likely over 60% of the CPU time and will have to be hand optimized in many places (because you can't always trust compilers to tile the best way possible.  Memory is also a little bit of a problem because modern day engines tend to get their speed by having half of the stuff pre-rendered by the developer and pre-rendering can make things gigantic fast. listening to developer commentaries valve seem like their jumping through rings of fire bare-foot backwards on a unicycle while playing a piano and a harmonica to so that they don't blow their memory space. I exaggerate only slightly. (they really wear shoes. those petals are ruff on the feet.)

I would like to note that this is not an undertaking I think anyone should try to solo this should be worked on by a team of the best coders on this site and a good high level design before they start. I know I'm not willing to take this on alone

As a final note: I only used portal as an example because i thought it would get the best community response. I just really what to see a 3d game engine once that code base is in place it can be easily built off of to make many games.

you are totally wrong about the way the DS it does ALL of its 3d rendering on an ARM9 clocked at 67 MHZ the N-spire is running an ARM9 clocked at 90 MHZ
from Wikipedia:

Quote

CPUs: Two ARM processors, an ARM946E-S main CPU and ARM7TDMI coprocessor at clock speeds of 67 MHz and 33 MHz respectively. The ARM946E-S CPU processes game play mechanisms and video rendering while the ARM7TDMI processes sound output, Wi-Fi support and additionally, when in Game Boy Advance mode, processes what the other processor used to do.

The DS has no vector coprocessor to speak of sorry to disappoint its just got an efficient engine.

the DS and n-spire use 2 different breeds of the ARM9 the N-spire using the highest end that has special instructions for JAVA optimization and the DS uses the second to highest end that may have more cache.  I'm almost positive this can be done.

as a note:I mentioned the ray caster because it showed that such things could be done.  To do portal one would of course need to optimize the hell out of the current ray caster or write a rasterization rendering engine

I quote Wikipedia:

The system's 3D hardware performs transform and lighting, texture-coordinate transformation, texture mapping, alpha blending, cel shading, and z-buffering

The DS definitely has 3D hardware. Good 3D graphics on the Nspire would really be pushing it. If calc84 could only get 70 FPS on an untextured, unsorted trivial scene, I doubt we can get an acceptable framerate with real scenes.

you still have to render an entire scene that may consist of upwords of a few 100 polys (those 10 and 20 poly objects add up fast)
but with good real time rendering techniques you should never have to re-render the entire screen at once but then the question becomes memory because you might need to pre-render frames (source defaults to 8 I say that max for calc)

Also if it's a team project, I think the source/files should be put somewhere all members can access, and backed up elsewhere in case a member went nuts or stole everything. I say this because in the 9 years I've been doing calc stuff (almost), I saw many team projects die because one member vanished completly, taking his portion of the code (or files) with him and the team member and his work was irreplaceable. Also each team members needs to agree on the project goals. Else it ends up in an endless debate. This is why nowadays you barely see any team project anymore in the TI community.

Hm... does that mean that the Hnefatafl game was the first team project in a long time to make a release? =P

Honestly, I'd love to see more team projects and be a part of them and I'm sure we could work things out between the members here. Several of us have been around for a LONG time and aren't planning on disappearing anytime soon. =)

Well, a version of it was finished. =P
The game can be played without the AI just fine.

But yeah, I guess that means that Escheron will be the first huge team project done in a long time. Regardless, I still say that we should definitely start a new team project with an even bigger team than just 2 people. I'm kinda tired of doing everything alone. It was great being able to rely on someone for part of the work. ^^

Aren't there sites now too that can help with storing everything in one place for people to access?

Ah ok.

Btw, how good is the Nspire C compiler? Does it produce compiled code that can be as good as ASM code written by an expert ASM programmer or does it produces much slower code? If the later is the case, it might be a good idea that somebody writes some 3D routines in ASM that can be used by C programmers in their programs.