Ayla wrote:So I watched the whole video. It's good to see progress, but I wonder how stuff will work on the Dreamcast, provided you are already using shaders and 3D sound, as well as expensive pathfinding and lots of LUA. Also, as far as I can see the music is tracked; it would eat much less CPU time to playback tracked music on the Dreamcast instead of OGG streams, especially if you playback multiples streams in parallel (the Dreamcast's CPU seems to handle decoding Vorbis at up to ~600Kbps).
(ups sorry, that post was meant for the other thread)
These are things I have been conscious of during development.
Obviously there will be no effects requiring shaders on the Dreamcast, and our underlying hardware abstraction library (libGyro) ensures that these distinctions require no modification to application-layer engine code. Dynamic shadows aren't going to work in hell on the Dreamcast, as they are implemented in a fragment shader. The lighting is possible to pull off per-vertex on the Dreamcast, as is the dot3 bumpmapping, although I sincerely doubt we will have enough VRAM to store the normal maps for bump mapping.
I will not be using true 3D sound on the Dreamcast, I will just be emulating it by adjusting the stereo volume on both speakers. As for the simultaneous ogg streams, I mentioned in great detail in the video that this would not even be attempted on the Dreamcast, and the underlying driver would fade out one track completely before fading into the other for these kinds of transitions. The DC will only ever have to decode one stream, and this is completely abstracted away from the engine.
As for Lua, I specifically designed our scripting framework with the Dreamcast in mind, and am going to great lengths to keep as much logic in the engine and as little logic in Lua as possible. The entire Lua scripting behavior framework extends from a C++ behavior framework with the exact same triggers and interfaces in the engine, meaning that porting behaviors between C++ and Lua is a fairly trivial and straightforward task.
Lua is being (ab)used a lot more in the early stages of development than it will be later on. It is extremely easy for us to prototype ideas in without spending a large amount of time doing things in C++ that are ultimately going to change. The pathfinding will absolutely wind up being moved over to being statically compiled after it is done being ironed out, and I imagine this is the same approach we will wind up using with several other subsystems during the development of ES.
