Jump to content

Let's merge the SP and MP renderers


eezstreet

Recommended Posts

Posted

Let's see.... Start by making the renderer in SP use a pointer, make the common interfaces identical... Implement all features across the board whether used or not... Then what?

 

Qboolean is the tricky part.  Its a #define qboolean int in SP and an enum in MP.  Therefore the interfaces will still likely have issues :D

Posted

Let's see.... Start by making the renderer in SP use a pointer, make the common interfaces identical... Implement all features across the board whether used or not... Then what?

 

Qboolean is the tricky part.  Its a #define qboolean int in SP and an enum in MP.  Therefore the interfaces will still likely have issues :D

Use bool instead.

mrwonko likes this
Posted

Agreed. It's always perplexed me why they were split in the first place. Two different teams back when the worked on Elite Force?

Posted

Well, yes. But at the time nearly every other big game had it all merged into one executable. I remember being baffled when I first brought Elite Force home and it was split. So I suppose more specifically I don't understand why those teams didn't merge the code. Probably came down to time and money like everything else in business does.

Posted

RTCW had SP and MP separated.  And being in same executable doesn't mean they don't have separate teams working on it.

Posted

With all the global variables they use it's nigh impossible to combine MP and SP with their differences into a single executable... They would have had to write cleaner code, which they apparently had no interest in. :P

Posted

Also, as part of this endeavor... I would ask that you coding wizards incorporate the rend2 code into ModView... so we can accurately preview textures & shaders. Thanks!

Can't like this enough. Being able to view shaders on the model without having to load up the game would help so much.

Archangel35757 likes this
Posted

Can't like this enough. Being able to view shaders on the model without having to load up the game would help so much.

 

Cause its too hard to open JK in windowed mode and type vid_restart to check texture updates on models. (I'm just saying) :P

 

@topic merging renderers would be so awesome.

Posted

Cause its too hard to open JK in windowed mode and type vid_restart to check texture updates on models. (I'm just saying) :P

 

@topic merging renderers would be so awesome.

because it is the Ghoul2 model previewer-- to check the model for animations, etc. Plus it's much easier to spin the model around to get different perspectives and check skin weighting mesh deformations, etc. And it would also be easier to check multiple skins in the model G2 Skin file.
minilogoguy18 and Omicron like this
Posted

Cause its too hard to open JK in windowed mode and type vid_restart to check texture updates on models. (I'm just saying) :P

 

@topic merging renderers would be so awesome.

More like way too slow.  Don't want to have to reload even a small map every single time.

Omicron and Archangel35757 like this

JKG Developer

Posted

We shall see what happens if eez is dedicated to do the work.  But the biggest issue really is (above the other complications) is the difference in how SP and MP handle ghoul2 model "handles" between the engine/renderer and the gamecode.

Posted

Ok, so I've started a bit on this. The structure is going to receive some pretty major changes.

All of the renderer code (with the exception of rd-dedicated) is moved to /shared/<rd-type>.

All code in code/ghoul2/ has been moved to shared/ghoul2.

The following files have been moved into shared/qcommon:

 

disablewarnings.h
matcomp.cpp
matcomp.h
MiniHeap.h
q_math.c
q_math.cpp
q_shared.c
q_shared.cpp
q_shared.h
qfiles.h

More files might get moved there as well (huffman.cpp, etc). Basically anything which is like 90% the same on both SP and MP will be moved there.

 

The big question is what will happen with q_shared because a great portion of that is different between SP/MP. I am thinking that maybe the code which is SP dependent will move to sp_shared and the MP dependent stuff will go to mp_shared.

So stuff like forceData_t, playerState_t and entityState_t will likely be moved to those files. But like 70% of q_shared is fine being shared between games.

Posted

Tbh I think it would be less work to add a built in model viewer in OpenJK than to add shader and lighting support to modview. :P

 

What if we could just make ModView use the games renderer or Rend2 through the settings rather than whatever one is built into it? Is that in the realm of possibility?

 

Strip out the code in ModView for it's built in renderer and have it point to an external one that is defined through the settings similar to say how Radiant the first time it's ran it asks to input the game directory.

eezstreet and Archangel35757 like this
Posted

Not sure how feasible that would be.

 

 

---

 

There's other issues I can forsee right now too.  Specifically with the JK2 specific sections in the renderer.  I guess we will need to expose a game being used to the renderer so we can check if game == GAME_JK2SP else if game == GAME_JKASP or if game == JKAMP

Posted

The dlight images are different JK2 uses q3 method, JKA uses an external image.

 

G2 API code has some various differences, JK2 doesn't support asian fonts and has some simpler font rendering.

 

The JK2 Skeleton is used without the warning messages.

 

JK2 doesn't support _off surfaces

 

JK2 Strip SP_* Language

 

JK2 has only 4 frustum planes and 5 in JKA

 

Some fog and surfacesprite differences (IE jk2 doesn't have the global world fog definitions)

  • 2 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...