toholio wrote:So "multithreading is OS-specific in the first place, because it's not supported on UNIX" is not related to the implementation details
Yes, it is basically an implementation-specific feature. That's why I did mention it.
Archonix wrote:Now that we've established that, his billness didn't invent threads
No one here said threads were invented by Microsoft, and even then the credit would go to Dave Cutler.
But I'd like to notice that most really innovative things get rarely invented by large companies, but mostly through cooperation with academic scientists (well, except for Xerox PARC
)
I think we can get back to the discussion.
Yes, indeed! So, here's some things I'm personally intersted in taking a closer look at, but no earlier when all the features in the current milestone are finished and some careful rethinking of current code modules could be applied:
1) different GUI concepts: I guess most functionality of current GUI modules can actually be removed to a sorts of "Game Actions" module, so some different input schemes and user interfaces could be tried with ease - someting like a portable pen and joystick UX for handheld users, a different simplified buttons/windows layout that's closer to today's real-time games, maybe some game console ports etc.;
2) different graphics driver: OpenGL/ES 32-bit color accelerated sprite renderer - screen-coordinates only at first, but maybe limited support for a "true" 3D world and graphic effects could be added in the future, to enable features like smooth zoom levels, a different viewpoint perspectives, night/day effects; maybe clouds, smoke, water reflections etc. (the sprite overlay wouldn't require much changes, but 3D world does require some re-modularization);
3) partial conversion of performance-limited code from table lookups to scene-graph like data arrangement (let's call it "enrailment" because something similar is already used for trains
), so that even larger maps and more up-to-scale cities and structures are possible without severe performance degradation;
4) dual monitor support (depends on 1);
5) 3D stereo-friendly; some support for in-game 3D models as a distant goal (depends on 2).
These are the things that would worth code restructuring efforts IMHO.