Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

FPSC Classic Product Chat / FPSC Source Code Thread

Author
Message
dpharaoh
18
Years of Service
User Offline
Joined: 2nd Nov 2005
Location: SouthEast MA
Posted: 21st Nov 2005 17:17
This thread is intended for anyone doing mods or changes via DBPro to the FPSC source code. I'd like know what the crowd is that is making changes, and what's on the plate. I know Cellbloc has done quite a bit.

I have only made 1 successful change to add support for invisible explosions, I am thinking of some more changes now. I was encouraged by how easy it was to make the change, even if it only worked fine on my PC.

One of the things I'd like to toss up and epxlore is the whole frame rate issue. People are complaining of low frame rates in unexplained areas, I know some preliminary research has been done with poly counts. Has anyone examined the source screen draw routines in detail to pinpoint a bug?, or does anyone have some ideas for optimization?
BULLSHOCK 2
Retired Moderator
19
Years of Service
User Offline
Joined: 14th Jun 2005
Location: Shocking Bulls
Posted: 21st Nov 2005 17:26
well...it really depends on what riker 9 will bring...

i would like to gut out the engine and make separate exes for multiplayer and single player...i think that alone would help framerates....

dpharaoh
18
Years of Service
User Offline
Joined: 2nd Nov 2005
Location: SouthEast MA
Posted: 21st Nov 2005 17:32
Riker9 is an awesome intitiative, I am trying to get a feel for who else is capable of making changes, we could help cellbloc out.

Hmmm... I will check. I would think that the multiplayer stuff does not impact things too much in SP mode because it should be screened out via if statements.

But then again, maybe not. Also, getting rid of the debug code for release .exe's might help too.
BULLSHOCK 2
Retired Moderator
19
Years of Service
User Offline
Joined: 14th Jun 2005
Location: Shocking Bulls
Posted: 21st Nov 2005 17:39
it might not impact much...but there is basically 2 engines in there...and all the other code isnt needed..so i gues i have to estimate the task...

it could be very simple...or it could be incredibly impossible...i havent really looked at it yet...

Conjured Entertainment
AGK Developer
19
Years of Service
User Offline
Joined: 12th Sep 2005
Location: Nirvana
Posted: 21st Nov 2005 17:54 Edited at: 21st Nov 2005 18:04
Seperating the engine into two is an excellent idea.
It should be very beneficial.
It is possible, but would be extremely time consuming.
I'm not good enough at DBPro, nor do I have the time.

Combining the single-player and multi-player engines was logical.
You will have redundant code by seperating them.

However, all of those if statement to determine which could be removed.
Also all specific code for the other is eliminated.

While the two seperate engines files sizes combined would be greater than the old one, each engine would be smaller and out perform the old one.

In theory.

I think each engine would be less confusing to edit or modify as well.
This task is worthy of being done before any other modifications are attemped.
Great idea.




Whatever you can imagine, you can animate. --- Walt Disney
All too easy. --- Darth Vader
Just do it! --- Nike
dpharaoh
18
Years of Service
User Offline
Joined: 2nd Nov 2005
Location: SouthEast MA
Posted: 21st Nov 2005 18:04 Edited at: 21st Nov 2005 18:06
it is so far pretty easy to coment out the MP sections, they are all preceded with a gmultiplayergame. I am blowing through them now, just to see how much I can get done on my lunch break.

Once that is done maybe we can also remove the multiplayer data types

I am also going to recommend immediately exiting out of the debug functions, debugviewtext is a couple hundred lines of code that shouldn't be needed in release .exe
Conjured Entertainment
AGK Developer
19
Years of Service
User Offline
Joined: 12th Sep 2005
Location: Nirvana
Posted: 21st Nov 2005 18:07 Edited at: 21st Nov 2005 18:52
I was thinking more of removing them completely.

Start with two copies.

In one copy remove all the multiplayer parts. (anything not needed for single-player)

In the other copy remove all the single-player specific parts.
(anything not needed for multi-player)

Resulting in two brand new engines.
Both being trimmed to their own specific needs.
I just think that both would be easier to read if they were separate.


Bullshock is right.
There are two separate engines there.
They create separate and very different types of games.
Why should we edit both every time we make a change to one?
If the change applies to both, then we could edit them both.

They should be separate.

Then we could have two or more development teams, with each team working on a separate engine.
Sharing all new ideas of course with each other, but working independantly.
Each team's workload would be cut in half as they could ignore the other aspects.
Both modifications could be developed faster.
And since they were developed as separate engines, the teams' work can't clash.
Both engines are compatible with the editor.





Whatever you can imagine, you can animate. --- Walt Disney
All too easy. --- Darth Vader
Just do it! --- Nike
BULLSHOCK 2
Retired Moderator
19
Years of Service
User Offline
Joined: 14th Jun 2005
Location: Shocking Bulls
Posted: 21st Nov 2005 20:39
ya...after overlooking it...i dont think im good enough either...

i will try though...

see i wanted to wait for riker 9 though, because cellbloc might do that, and even if he doesnt, i would gut out riker 9...not fpsc original...

but thats for my benifit...it would benifit FPSC users as a whole to gut out the original...maybe i will do that as practice, if i can that is.

dpharaoh
18
Years of Service
User Offline
Joined: 2nd Nov 2005
Location: SouthEast MA
Posted: 21st Nov 2005 21:22
I screened out all the mp code and unfortunately it didn't seem to have any real effect on speed. I suspected as much, because most if not all mp code was surrounded with gmultiplayer=1 flag.

Also, removing the debugging code did not speed things up too much either.

I did notice some interesting areas while in the source code however.
I think the area which could be optimized more is _entity_controlelements, which runs the ai, positioning, etc of all dynamic entities.

I am still looking for the theoretical drawing-of-polys-which-should-not-be-drawn-bug. I suspect some logic changes are in order.

Login to post a reply

Server time is: 2024-10-06 21:30:41
Your offset time is: 2024-10-06 21:30:41