InsideQC Forums

how come more light weight engines usually run faster than dp on all of the machines iv tested it on.

Chip wrote:You could call it Prydon's Gate Extended, or Prydon's Gate 2.

If PG2 out that it necessarily should contain full GUI
Like in traditional hack'n'slash games

tyrael wrote:And we have CSQC gui like http://forums.inside3d.com/viewtopic.php?t=2540 or like http://forums.inside3d.com/viewtopic.ph ... s&start=30

Tell me please - how to do this? I got sources of Prydon and csqc gui, now can somebody show me the way to connect Prydon inventory (or stats or quests) with csqc gui?

mh wrote:A funny thing about "bloat" is that it doesn't actually use up any extra memory or CPU. Code that's never run is never actually paged in, so executable size genuinely doesn't matter. Size of code has not as much to do with execution speed as you might think - I can show you 600 lines of code that run much faster than 2 lines but yet do the exact same thing.

The whole "bloat" thing is actually a colossal myth (or lie, take your pick).

Not exactly. It's quite common that executables which are bigger than they should be are actually debug versions, filled with useless stuff for final versions or unoptmized but more adequate to debugging versions of runtime functions like malloc() - does it rings any bells to you ?

ceriux wrote:how come more light weight engines usually run faster than dp on all of the machines iv tested it on.

The problem with DP in modest hardware uses to be RTlights. Also, I remember from my Q2K4 times that the colored light code (at least the one from the tutorial on Darkplace's page - dunno if stills the same code) represented a massive frame hit.

never affected me one bit. there's occassions where darkplaces is FASTER than GLquake even on REALLY CRAPPY VIDEO CARDS (like 4mb video memory)- think about that!

I think the perception of all this slowness comes from some ill-realised GDI Generic GL ICD being used. that's all the whining i've seen about or so. My crappy PCs (around 233mhz) with relatively exotic and old video hardware can run Darkplaces just fine, if it doesnt run fine then you are doing something terribly wrong

update your drivers. There is no valid reason why a PSP should run fitzquake better than your computer

Stepping back several posts, a total conversion with new game data like maps, textures, models and sounds that is supposed to be played in one engine only should be optimized 2 ways: the engine should not contain any compatibility for other mods or games and the game data should be optimized for that specific engine's features.

That's why I'm stripping down everything I don't need.

I never said anything about bloatedness and speed and stuff like that. I'm not experienced with engine coding (but I'm learning, mostly by trial and error, and based on the programming concepts I'm familiar with), so I don't know about size vs speed, I only know I have to get rid of useless/compatibility/mods/deprecated stuff in the engine code.

Happy New Year! I'll see you all in 2011!

There is never a reason to get rid of code that you don't have a use for, except some self-deluding goal like a smaller exe, which in the modern age means the difference of a 10 minute download finishing a few milliseconds faster, and computers today have amounts of ram that make it a drop in the bucket as well.

Busywork for the sake of busywork is not in fact work at all, ripping code out doesn't accomplish anything but waste your own time.

The only time I ever remove code from darkplaces is when I deem a feature no longer worth maintaining and it conflicts with other functionality, until these two criteria are met I maintain a feature for the sake of the users and the developers who may depend on it.

To fork an engine for your project is perfectly understandable (although often displeasing users in the process) and I would never speak against the practice, especially if you are adding functionality specific to your game.

I am however strongly advising against the idea of removing code "to make it faster", a blatant self-delusion.

holy necro batman!

LordHavoc wrote:There is never a reason to get rid of code that you don't have a use for, except some self-deluding goal like a smaller exe, which in the modern age means the difference of a 10 minute download finishing a few milliseconds faster, and computers today have amounts of ram that make it a drop in the bucket as well.

Busywork for the sake of busywork is not in fact work at all, ripping code out doesn't accomplish anything but waste your own time.

The only time I ever remove code from darkplaces is when I deem a feature no longer worth maintaining and it conflicts with other functionality, until these two criteria are met I maintain a feature for the sake of the users and the developers who may depend on it.

To fork an engine for your project is perfectly understandable (although often displeasing users in the process) and I would never speak against the practice, especially if you are adding functionality specific to your game.

I am however strongly advising against the idea of removing code "to make it faster", a blatant self-delusion.

I agree. The latest DP engine brings lots of new functionality since my forking, and I'd like to use it. The project is however, in a freeze state, as I don't have the required time.

So, my stripped code will be shelved, and I'll use the latest DP build.