Re: The gory Xconq kernel

[Hans Ronne <hronne@comhem.se>]

>I have no interest in rewriting the entire Xconq kernel.  That kind of
>project is what I call a Complete Waste Of Time.  If you can't
>incrementally modify it, better to write a new game from scratch!

Sure you can incrementally modify it. That's what we do all the time. But
it's written in C, like it or not. Did I take your statement about never
touching C too literally?

>That last sentence is rather disturbing.  Are you saying that no matter
>what one's skill level, the Xconq kernel is such spaghetti that modules
>of it simply cannot be untangled?  I can see myself doing Python in
>kernel, for bits and pieces here and there, as I think of a feature I
>want / need.  Particularly for AI stuff.  Are you saying this ain't
>likely to be feasible in practice?

Not at all. All I'm saying it's hard work. You won't do it in a weekend,
irrespective of your skill level.

That being said, I think the Xconq kernel could benefit from a rewrite in
an object oriented language and I encourage any such attempts. But so far
they have remained attempts :-/.

>Caveat: I have yet to attempt to understand the Xconq source code or
>read any docs about it.  Getting it to even build on Windoze was the 1st
>priority, and I still don't have a working build.

I don't understand this problem.  As Juergen Ruehle said, it's pretty
straightforward to build it under MSVC (or CodeWarrior). Didn't take me
many minutes to get a working Windows build, though I am not a Windows
developer. All you need in addition to the runtime C stuff are five
libraries: tcl84.lib, tk84.lib, kernel32.lib, user32.lib and wsock32.lib.
Replace tcl84.lib and tk84.lib with SDL.lib and SDLMain.x86.lib to build
the SDL interface.

Hans