Is it dead enough now?
Moderator: General Discussion Moderators
Are you (officially) a developer? If so, go here and drop a line about it. If you're not officially a developer, ask a mod on this forum to give you access to The Cabal.
Report for duty Slink: here
Well... I'm not really a member of this community... but I monitor you're activity with high interest. I'm in the Nexuiz team (so I have some experience with DP).
I don't see how switching to Q3 would solve your problems.
- crouching won't work with q1bsp. You will have to switch to another format (read: e.g. q3bsp) to have crouching. DP supports q3bsp as everybody knows.
- flickering lights. They are not supported by the q3bsp format. You can use realtime lights for that (they are usually speedy enough if they don't cast shadows). DP has realtime lights, Q3 hasn't.
- netcode: LordHavoc added the new DP7 protocol for Nexuiz - but it of course works fine with every mod. DP7 supports client side prediction of player movement (you will have to stuffcmd some physics values to the client in the QC, though.... 5-6 lines of code in the QC). No more running into walls because your movement is lagged. (well, weapon firing is delayed just as usual - no difference to e.g. QuakeWorld in this aspect). Q3 nonetheless has a very sexy netcode, though.
- QuakeC VM versus the Q3 VM: Well, speed of QC isn't really an issue. It ran fine on Pentium 60 computers in Quake 1 days. Transfusion shouldn't need vastly more CPU horsepower for the gamecode. Quake3 would give more flexibility, though (do you need this?)
Savage
I don't see how switching to Q3 would solve your problems.
- crouching won't work with q1bsp. You will have to switch to another format (read: e.g. q3bsp) to have crouching. DP supports q3bsp as everybody knows.
- flickering lights. They are not supported by the q3bsp format. You can use realtime lights for that (they are usually speedy enough if they don't cast shadows). DP has realtime lights, Q3 hasn't.
- netcode: LordHavoc added the new DP7 protocol for Nexuiz - but it of course works fine with every mod. DP7 supports client side prediction of player movement (you will have to stuffcmd some physics values to the client in the QC, though.... 5-6 lines of code in the QC). No more running into walls because your movement is lagged. (well, weapon firing is delayed just as usual - no difference to e.g. QuakeWorld in this aspect). Q3 nonetheless has a very sexy netcode, though.
- QuakeC VM versus the Q3 VM: Well, speed of QC isn't really an issue. It ran fine on Pentium 60 computers in Quake 1 days. Transfusion shouldn't need vastly more CPU horsepower for the gamecode. Quake3 would give more flexibility, though (do you need this?)
Savage
The support for .MAP based collisions is supposed to be the median solution, when/if DP will support that. There is also a discussion in the Cabal forum about RBSP (Raven BSP) which apparently has more lighting features than vanilla Q3 BSP. LordHavoc said RBSP support is in DP todo list, but that it will be difficult to implement due to several performance related issues it would raise. So, like MAP collisions: not yetSavage wrote:- crouching won't work with q1bsp. You will have to switch to another format (read: e.g. q3bsp) to have crouching. DP supports q3bsp as everybody knows.
As far as I remember, Q3 VM was mostly my request. For instance, around the end of my Lead Programmer's days, I wanted to modify the damage system in our game code to mimic the Blood original system, which is pretty nicely fine grained, more faithfully. And I was confronted with the lack of structures, arrays and pointers in QuakeC. It could certainly be done using functions (I was told fteqcc was just doing that for handling arrays), but it's really tedious. I mean... it's not just the right way to do that. I prefer clean code (of course), and really avoid hacks. And it smelt Evil Hacks badlySavage wrote:- QuakeC VM versus the Q3 VM: Well, speed of QC isn't really an issue. It ran fine on Pentium 60 computers in Quake 1 days. Transfusion shouldn't need vastly more CPU horsepower for the gamecode. Quake3 would give more flexibility, though (do you need this?)
Oh, I see. Well, Q3 won't give you .map collisions anytime soon eitherElric wrote:The support for .MAP based collisions is supposed to be the median solution, when/if DP will support that. There is also a discussion in the Cabal forum about RBSP (Raven BSP) which apparently has more lighting features than vanilla Q3 BSP. LordHavoc said RBSP support is in DP todo list, but that it will be difficult to implement due to several performance related issues it would raise. So, like MAP collisions: not yetSavage wrote:- crouching won't work with q1bsp. You will have to switch to another format (read: e.g. q3bsp) to have crouching. DP supports q3bsp as everybody knows.
Oh, I see. Yes, doing "out of the ordinary" things in QC can be a hack job, yeahElric wrote:As far as I remember, Q3 VM was mostly my request. For instance, around the end of my Lead Programmer's days, I wanted to modify the damage system in our game code to mimic the Blood original system, which is pretty nicely fine grained, more faithfully. And I was confronted with the lack of structures, arrays and pointers in QuakeC. It could certainly be done using functions (I was told fteqcc was just doing that for handling arrays), but it's really tedious. I mean... it's not just the right way to do that. I prefer clean code (of course), and really avoid hacks. And it smelt Evil Hacks badlySavage wrote:- QuakeC VM versus the Q3 VM: Well, speed of QC isn't really an issue. It ran fine on Pentium 60 computers in Quake 1 days. Transfusion shouldn't need vastly more CPU horsepower for the gamecode. Quake3 would give more flexibility, though (do you need this?)
Well, you could use a .DLL approach for DP, too (after intensive hacking) - you'd be a Q1 outlaw then, though
(so no, this wasn't ment serious)
Hmm, well forgive me if I sound bossy, but I think the most important thing for Transfusion, above all else, is to get the gameplay as close as possible to Blood's. Now I'm not sure as to the difficulty of this task, since I have never dabbled in QuakeC before, but I think it should be something that should be near perfect before the project moves on. This isn't an insult to the programmers, merely something that bugs me with Transfusion right now. If you need the help maybe I'll see if I can learn some QuakeC and help out with what I can.