Another Quake 1 Engine Mod? Oh no...
Playing with the original glquake source may be seen as a stupid thing to do nowadays, specially having the latest iteration of the idTech2 available (Quake 2, remember that Quake 1 is 1.x, QuakeWorld is 2.x and Quake 2 is 3.x) and more up-to-date engines as well. (Can you say DarkPlaces, MHQuake, Quake 3, XReal, etc, etc, etc?)
But there are several reasons for me to do this. First, I'm incredibly familiar with the Quake 1 way of doing things. I understand every bit of code from the Quake 1 source code, so it is an ideal starting point if I don't want to truly reinvent the well (i.e. start from scratch.) And since I also like to write my own code to be free of any possible copyright hell, this way what isn't mine is id Software's and vice-versa.
I started like everyone else: cleaning the mess up and fixing bugs. And, speaking of glquake, we are talking about a big mess. You have no idea how the software rendered versions of Quake are truly elegant and beautiful when placed alongside glquake.
I also have little interest in retaining backwards compatibility. This thing is not intended as an general-purpose quake engine. If you want that, there are other engines you can use, like DarkPlaces. My primary goal is to *improve* the engine, sacrificing backwards compatibility where necessary.
With this in mind, I'm gradually moving everything that I consider "game-specific" to the server progs code. Most of sv_user.c and the entirety of sv_move.c are in progs now. I also plan to make a menu progs and a client progs to host things like temporary entities, menus, status bars, etc.
Another goal is to make all the graphics 24 bits (and 32 bits where necessary,) removing the palette entirely. To accomodate changes like this, I'm maintaining my own clean id1 tree, instead of only engine and progs. It will probably be a base game for the engine in the future (without id-copyrighted stuff, I hope.) Files and formats are being updated, unused files (e.g. palette.lmp, colormap.lmp, serial multiplayer graphics) are being deleted, precaches are being taken great care of and I have also created a clean and sensible default.cfg.
Another important change I made was required by the extremely hot summer that stroke the region where I live, causing my CPU to complain a lot about the heat (blame me for setting the warning thresholds to the minimum, heh.) The engine now sleeps when idle, which lets me run Quake using mostly 0% cpu!
That said, I'm deciding wheter to start integrating the Open Dynamics Engine (ODE) physics library into my engine. I'm seriously considering it, but have not decided some things yet.
For example: How should I represent the world? Should I use ODE spaces for each node and have ODE planes for the leaves' faces? Should I use the quake collision interface mostly or should I replace the entirety of world.c for using the ODE collision code, finally getting rid of clipping hulls? Should I make new movetypes and solidtypes for ODE and keep the old ones or rearrange the existing ones, or both? Should I use hierarchical spaces to represent Quake's area nodes with the entities collision boxes into then or reuse quake code? There are so many, many, many things to consider that I've not thought deeply about many of them. Maybe in the future I may decide that some of those considerations were plain stupid, but only time will tell. At least this physics experiment with Quake will give me some fun. :-)
This will delay the renderer complete rewrite! But there are a lot of completely rewrote Quake renderers out there, so I decided to focus a little on a mostly unexplored area (I think that DarkPlaces also has a working implementation of ODE, but I never used it or looked at it.)
But there are several reasons for me to do this. First, I'm incredibly familiar with the Quake 1 way of doing things. I understand every bit of code from the Quake 1 source code, so it is an ideal starting point if I don't want to truly reinvent the well (i.e. start from scratch.) And since I also like to write my own code to be free of any possible copyright hell, this way what isn't mine is id Software's and vice-versa.
I started like everyone else: cleaning the mess up and fixing bugs. And, speaking of glquake, we are talking about a big mess. You have no idea how the software rendered versions of Quake are truly elegant and beautiful when placed alongside glquake.
I also have little interest in retaining backwards compatibility. This thing is not intended as an general-purpose quake engine. If you want that, there are other engines you can use, like DarkPlaces. My primary goal is to *improve* the engine, sacrificing backwards compatibility where necessary.
With this in mind, I'm gradually moving everything that I consider "game-specific" to the server progs code. Most of sv_user.c and the entirety of sv_move.c are in progs now. I also plan to make a menu progs and a client progs to host things like temporary entities, menus, status bars, etc.
Another goal is to make all the graphics 24 bits (and 32 bits where necessary,) removing the palette entirely. To accomodate changes like this, I'm maintaining my own clean id1 tree, instead of only engine and progs. It will probably be a base game for the engine in the future (without id-copyrighted stuff, I hope.) Files and formats are being updated, unused files (e.g. palette.lmp, colormap.lmp, serial multiplayer graphics) are being deleted, precaches are being taken great care of and I have also created a clean and sensible default.cfg.
Another important change I made was required by the extremely hot summer that stroke the region where I live, causing my CPU to complain a lot about the heat (blame me for setting the warning thresholds to the minimum, heh.) The engine now sleeps when idle, which lets me run Quake using mostly 0% cpu!
That said, I'm deciding wheter to start integrating the Open Dynamics Engine (ODE) physics library into my engine. I'm seriously considering it, but have not decided some things yet.
For example: How should I represent the world? Should I use ODE spaces for each node and have ODE planes for the leaves' faces? Should I use the quake collision interface mostly or should I replace the entirety of world.c for using the ODE collision code, finally getting rid of clipping hulls? Should I make new movetypes and solidtypes for ODE and keep the old ones or rearrange the existing ones, or both? Should I use hierarchical spaces to represent Quake's area nodes with the entities collision boxes into then or reuse quake code? There are so many, many, many things to consider that I've not thought deeply about many of them. Maybe in the future I may decide that some of those considerations were plain stupid, but only time will tell. At least this physics experiment with Quake will give me some fun. :-)
This will delay the renderer complete rewrite! But there are a lot of completely rewrote Quake renderers out there, so I decided to focus a little on a mostly unexplored area (I think that DarkPlaces also has a working implementation of ODE, but I never used it or looked at it.)
posted by Eluan CM @ 2:43:00 PM
