Julian

Super Moderators
  • Content count

    3146
  • Joined

  • Last visited

About Julian

  • Rank
    Forum Staple
  1. Julian, come back. I miss you. :(

  2. I made this video a long time ago with old screenshots of the project. There's some stunning hell stuff in the end.
  3. Very nice midi collection.
  4. It's post like this that makes me proud of this community. Anyway, I too thought of the problem like Graf Zahl did and I'm afraid a language will not be enough. You'd need an OS that actually acts as the intermediate to assembly code translater of today's compilers. All apps on this OS would have to be written in a very high-level language with a degree of abstraction much more important than what we have today (don't ask me in which form, I have no clue, but probably exhibiting properties similar to Haskel) and an equally high-level standard library. The idea is that the more high-level your program concerns are, the more opportunities for optimizations there is (somehow counter-intuitive but I think we, coders, tend to confuse having control and writing efficient code). Oh well, anyway, just wanted to contribute to this fine discussion :)
  5. Yeah, I see you do ;)
  6. So glad to hear it's going that well, Q :) Gratz are in order.
  7. 17 years?!? Man, time flies.
  8. Yep. I find that the only way to judge code is from a maintenance point of you. Over-architectured OOP is no better than the hackaton mess the Doom code ended up to be.
  9. Q, we had this conversation a looooong time ago. I still think converting the code progressively to C++ is the way to go. Start with the parts which you know will cause problems with the new C standard then continue on. I never understood the idea that the Doom source code needed to stay in C and that pseudo-OO was a necessity. It's not. I'm always amazed to see how deadfully redirection-heavy (in function calls terms) the original code is while it is perfectly feasible to go the "object with inline methods way" 99% of the time... which would make the source code that much more maintainable and, paradoxically, more optimized (anyone still pretending C++ is slower obviouly has no idea how to code in it properly from a performance point of view). The only issue I see turns around backward compatibility (ie. demos) but it's nothing you can't tackle provided you have a set of maps and assiciated demos to use as "unit tests". God, I wish I had more time on my hands. Best of luck with whatever decision you take, Eternity is still the source port I'm most in love with ;)
  10. Could we get back to the OP's point and stop philosophing about what's "right" and "wrong" all the time? Or go right into drama for the sake of drama?
  11. fp!
  12. Yeah, I remember this version. Glad you found it finally, Simon. And the translations are as painful as it gets to a french ear :)
  13. OR, if you're totally new to programming and you're good at gfx (I concur with Torn on the quality of the sprite sheet you linked to), you could consider pairing up with an experienced coder.