Homesource Forums

Homeworld Source Editing Talk
It is currently Thu Sep 21, 2017 2:33 pm

All times are UTC - 5 hours




Post new topic Reply to topic  [ 25 posts ] 
Author Message
 Post subject: No-RGL branch
PostPosted: Mon Dec 20, 2004 6:14 pm 
Offline
coder

Joined: Mon Dec 20, 2004 5:26 pm
Posts: 11
I'm fed up with RGL, so I started a branch to remove it in Homeworld SDL. The branch is at http://homeworld.dnsalias.net/svn/homew ... es/no-rgl/

What issues have people run into or anticipate running into? There seems to be a lot of code for dealing with RGL implementations that don't support certain features. Should we try to keep that code, or just assume everyone's OpenGL drivers support them now?


Last edited by Aaron on Wed Dec 22, 2004 4:52 am, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Mon Dec 20, 2004 6:53 pm 
Offline
coder
User avatar

Joined: Tue Dec 14, 2004 3:24 pm
Posts: 324
Location: UK (UTC+0)
It's a shame the old forum got blasted as there was a thread beginning to explore this issue. RGL is an abstraction layer that allows different graphics implementations to coexist in the game. The game does not need to know what technology is currently running, it just hands off to something else that does. Originally the abstraction was to allow any of the following renderers:

- DirectX
- OpenGL
- software renderer

Now SDL is meant to be just this kind of abstraction layer too, so ripping out RGL makes sense on the face of it. (We would definitely lose the software renderer but I doubt that actually matters now that graphics cards are now installed as standard.) However, what this does mean is that everyone is tied to SDL. If it gets behind in supporting feature X of technology Y we are stuck (see later for caveat). Someone in the previous forum was suggesting we might be better off adding SDL to the supported RGL technologies. It might be a bit of a pain writing an RGL wrapper for a SDL call but it would mean that we could better cope with (i.e. work around) any issues that crop up in SDL.

The counter-argument would be that since SDL is open source we should be fixing any problems directly anyway for the benefit of the wider community. As a larger project though, SDL is bound to (hopefully?!) have higher standards of code review and testing leading to a slower release schedule which may detrimentally affect us. Also, there may be a design decision taken in SDL that means we are simply not allowed to make the changes we might want and then we would be back to requiring an alternative abstraction layer solution.

So, finally getting to my question: what is it about RGL that makes it so evil that it needs to be completely gutted from the code rather than being enhanced to support SDL?

(NB: if you did not know, SDL 1.2.8 was released on December 15th)

_________________
MacHomeworld | HomeworldSDL.org


Top
 Profile  
 
 Post subject:
PostPosted: Mon Dec 20, 2004 8:57 pm 
Offline
Site Admin
User avatar

Joined: Tue Dec 14, 2004 12:41 am
Posts: 326
lmop wrote:
It's a shame the old forum got blasted as there was a thread beginning to explore this issue. RGL is an abstraction layer that allows different graphics implementations to coexist in the game.


Give me a sec and I'll dig that out of the old db now.

.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Dec 20, 2004 9:07 pm 
Offline
Site Admin
User avatar

Joined: Tue Dec 14, 2004 12:41 am
Posts: 326
zapkitty wrote:
Give me a sec and I'll dig that out of the old db now.


Much talk about how rgl is old 'not-ogl' multi-graphics engine kludge.

Most explanation was in this post, in which the unknown author caveats against removing rgl:

Unknown wrote:
They probably made a wrapper for their graphics subsystem so they could use more then one api/graphics subsystem.\r\nThe main reason for that was that at the time of release the graphics cards all had different performance with opengl and direct3d. Some cards had superb opengl support and bad direct3d support, and other cards had superb direct3d support and bad opengl support. They also made their own software renderer for cards with no 3d-support. They made their own wrapper to have all the different api\'s transparant to the game code. I'm strongly suggesting to not remove rGL because of the same reasons. The best way is to extend rGL and to optimize/rework opengl and direct3d support. Also for the sdl release, add it as another graphics driver in homeworld. Windows users can then choose if they want to use sw, opengl, d3d or sdl for the graphics subsystem. Linux and mac users can only choose sdl.


That's all, folks :)

.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 22, 2004 4:19 am 
Offline
coder

Joined: Mon Dec 20, 2004 5:26 pm
Posts: 11
RGL is completely unnecessary as far as I can tell, and everything is just a lot simpler without it, although I suppose a "don't fix it if it ain't broken" philosophy is problably the way to go.

In other news, my no-RGL version works! Unfortunately, only the Khar-Selim has textures. :?


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 23, 2004 12:53 am 
Offline
coder

Joined: Wed Dec 22, 2004 10:48 pm
Posts: 5
Well, the software renderer is broken, the Glide renderer hasn't been ported, and the Direct3D renderer is only useful for Windows where the difference in the game's performance on most video cards nowadays is negligible, so it's probably a good idea to use the no-RGL branch for releases, at least for the time being. I still think it would be nice (although not necessary) to get the software renderer working again at some point, but I've been spending most of my spare time outside of work working on another game project, so I have yet to get around to finding out what I screwed up porting the renderer over to Linux.

Switching between RGL and OpenGL right now is real twitchy. Basically, the code that handles creating and destroying the game window was based around creating the window at one point and initializing the renderer-specific stuff afterwards. With SDL, creating a window for OpenGL and setting up the OpenGL context are all handled in SDL_SetVideoMode(), so we can't create a window at one point and then set up OpenGL afterward (unless we make two separate calls to SDL_SetVideoMode(), but I'd rather avoid that). I basically just hacked around this when first porting the code, so the window management code should probably be rewritten regardless of whether or not the RGL stuff is shelled out to better suit how SDL handles things. :|


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 14, 2006 12:01 pm 
Offline
Site Admin
User avatar

Joined: Tue Dec 14, 2004 12:41 am
Posts: 326
From the new Glossary: an inaccuracy

Quote:
RGL
-------------------------------------------------------------------------------
Relic Graphics Layer

A graphics API wrapper which allows the exact nature of how the graphics are being rendered to be "hidden" from the main game. It wraps the APIs for software, Direct3D and OpenGL renderers. Does the same job as SDL and could be removed; the only caveat is that we would then lose the possibility of using a software renderer.


OpenGL has a built-in software renderer.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 14, 2006 3:44 pm 
Offline
coder
User avatar

Joined: Tue Dec 14, 2004 3:24 pm
Posts: 324
Location: UK (UTC+0)
Rereading this thread again I think I've changed my mind. We should rip out RGL and be done with it. Yes, there's a cost in removing it but there's also a cost in continuing to maintain it too. It can only be more stable/less problematic with fewer abstraction layers.

NB: I'm somewhat prejudiced since the Mac OS X version doesn't use any RGL code at the moment anyway... Having said that, it proves the removal can be done and still work properly.

_________________
MacHomeworld | HomeworldSDL.org


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 15, 2006 12:32 am 
Offline
coder
User avatar

Joined: Wed Oct 04, 2006 8:13 pm
Posts: 94
Location: UTC -0500
i'd welcome a norgl branch.

_________________
http://againsttcpa.com/what-is-tcpa.html
http://google.com/search?q=c+programming+faq
http://research.att.com/~bs
acronyms.ch, neworder.box.sk


Top
 Profile  
 
 Post subject: norgl branch.
PostPosted: Wed Nov 15, 2006 4:44 am 
Offline
coder

Joined: Tue Nov 07, 2006 4:40 am
Posts: 236
I have no idea how work is involved with removing the rgl, but I think it can only be a good idea.

Aunxx.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 15, 2006 7:16 am 
Offline
Site Admin
User avatar

Joined: Tue Dec 14, 2004 12:41 am
Posts: 326
Hmm... My poll seems superfluous, as I just realized that there is no one left among the coders who wants to keep rgl. Still, it's good to audit opinions :)

I don't think there'll be a "no-rgl" branch... just a dropping of rgl at this point and leaving it behind.

Opengl can handle 3D accelerated graphics for all three platforms under development for SDL as well as providing a working software renderer.

And while someone may start up a d3d branch in the future I don't think holding on to rgl will be any favor to them... while MS prides itself on backwards compatibility d3d has not stood still either.

My two cents... :)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 15, 2006 6:17 pm 
Offline
coder
User avatar

Joined: Tue Dec 14, 2004 3:24 pm
Posts: 324
Location: UK (UTC+0)
zapkitty wrote:
I don't think there'll be a "no-rgl" branch... just a dropping of rgl at this point and leaving it behind.

There already is a branch (see first post): "no-rgl". It's woefully out of date though: r57 vs r271. Nice. I'll have a go at doing a merge tonight but given the likelihood of non-trivial conflicts it may simply be easier to start from scratch...

_________________
MacHomeworld | HomeworldSDL.org


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 16, 2006 6:30 pm 
Offline
coder
User avatar

Joined: Tue Dec 14, 2004 3:24 pm
Posts: 324
Location: UK (UTC+0)
Well the merge was as horrendous as I thought it would be so I'm for starting from scratch. We have two choices:

1) delete the current no-rgl branch and branch from trunk again
2) delete references to the RGL code gradually on trunk and then delete RGL completely

Since we're not in a situation where we need to guarantee that there is always a code branch that compiles - although that's always nice! - I'd opt for (2). It also means that if something does break there will be more eyes to notice/fix it closer to the time it happens. For reference, this is what Aaron originally did:

Code:
svn diff -r55:56 svn://www.homeworldsdl.org:3692/homeworldsdl/homeworld/branches/no-rgl

Code:
svn log -v -r56 svn://www.homeworldsdl.org:3692/homeworldsdl/homeworld/branches/no-rgl
------------------------------------------------------------------------
r56 | aaron | 2004-12-23 00:02:11 +0000 (Thu, 23 Dec 2004) | 1 line
Changed paths:
   M /homeworld/branches/no-rgl/configure.in
   D /homeworld/branches/no-rgl/include/glide2
   M /homeworld/branches/no-rgl/src/Game/Animatic.c
   M /homeworld/branches/no-rgl/src/Game/AutoLOD.c
   M /homeworld/branches/no-rgl/src/Game/BTG.c
   M /homeworld/branches/no-rgl/src/Game/Clipper.c
   M /homeworld/branches/no-rgl/src/Game/Clouds.c
   M /homeworld/branches/no-rgl/src/Game/ColPick.c
   M /homeworld/branches/no-rgl/src/Game/ConsMgr.c
   M /homeworld/branches/no-rgl/src/Game/Damage.c
   M /homeworld/branches/no-rgl/src/Game/Dock.c
   M /homeworld/branches/no-rgl/src/Game/ETG.c
   M /homeworld/branches/no-rgl/src/Game/ETG.h
   M /homeworld/branches/no-rgl/src/Game/FEFlow.c
   M /homeworld/branches/no-rgl/src/Game/FEReg.c
   M /homeworld/branches/no-rgl/src/Game/Gun.c
   M /homeworld/branches/no-rgl/src/Game/HS.c
   M /homeworld/branches/no-rgl/src/Game/HorseRace.c
   M /homeworld/branches/no-rgl/src/Game/KAS.c
   M /homeworld/branches/no-rgl/src/Game/LaunchMgr.c
   M /homeworld/branches/no-rgl/src/Game/Mesh.c
   M /homeworld/branches/no-rgl/src/Game/NIS.c
   M /homeworld/branches/no-rgl/src/Game/NavLights.c
   M /homeworld/branches/no-rgl/src/Game/Nebulae.c
   M /homeworld/branches/no-rgl/src/Game/Options.c
   M /homeworld/branches/no-rgl/src/Game/Particle.c
   M /homeworld/branches/no-rgl/src/Game/PiePlate.c
   M /homeworld/branches/no-rgl/src/Game/PlugScreen.c
   M /homeworld/branches/no-rgl/src/Game/ResearchGUI.c
   M /homeworld/branches/no-rgl/src/Game/ScenPick.c
   M /homeworld/branches/no-rgl/src/Game/Select.c
   M /homeworld/branches/no-rgl/src/Game/Sensors.c
   M /homeworld/branches/no-rgl/src/Game/Shader.c
   M /homeworld/branches/no-rgl/src/Game/ShipView.c
   M /homeworld/branches/no-rgl/src/Game/TradeMgr.c
   M /homeworld/branches/no-rgl/src/Game/Transformer.c
   M /homeworld/branches/no-rgl/src/Game/Tutor.c
   M /homeworld/branches/no-rgl/src/Game/UIControls.c
   M /homeworld/branches/no-rgl/src/Game/UnivUpdate.c
   M /homeworld/branches/no-rgl/src/Makefile.am
   M /homeworld/branches/no-rgl/src/SDL/Makefile.am
   M /homeworld/branches/no-rgl/src/SDL/Subtitle.c
   M /homeworld/branches/no-rgl/src/SDL/debugwnd.c
   M /homeworld/branches/no-rgl/src/SDL/font.c
   D /homeworld/branches/no-rgl/src/SDL/glcaps.c
   D /homeworld/branches/no-rgl/src/SDL/glcaps.h
   D /homeworld/branches/no-rgl/src/SDL/glcompat.c
   D /homeworld/branches/no-rgl/src/SDL/glcompat.h
   D /homeworld/branches/no-rgl/src/SDL/gldefines.h
   D /homeworld/branches/no-rgl/src/SDL/gldll.c
   D /homeworld/branches/no-rgl/src/SDL/gldll.h
   D /homeworld/branches/no-rgl/src/SDL/glext.h
   D /homeworld/branches/no-rgl/src/SDL/glinc.h
   M /homeworld/branches/no-rgl/src/SDL/light.c
   M /homeworld/branches/no-rgl/src/SDL/main.c
   M /homeworld/branches/no-rgl/src/SDL/mainrgn.c
   M /homeworld/branches/no-rgl/src/SDL/mouse.c
   M /homeworld/branches/no-rgl/src/SDL/prim2d.c
   M /homeworld/branches/no-rgl/src/SDL/prim3d.c
   M /homeworld/branches/no-rgl/src/SDL/render.c
   D /homeworld/branches/no-rgl/src/SDL/rglu.c
   D /homeworld/branches/no-rgl/src/SDL/rglu.h
   M /homeworld/branches/no-rgl/src/SDL/rinit.c
   D /homeworld/branches/no-rgl/src/SDL/sstglide.c
   D /homeworld/branches/no-rgl/src/SDL/sstglide.h
   M /homeworld/branches/no-rgl/src/SDL/texreg.c
   M /homeworld/branches/no-rgl/src/SDL/trails.c
   M /homeworld/branches/no-rgl/src/SDL/utility.c
   M /homeworld/branches/no-rgl/src/Ships/DFGFrigate.c
   M /homeworld/branches/no-rgl/src/Ships/DefenseFighter.c
   D /homeworld/branches/no-rgl/src/rgl

Rip out RGL, glc, and glcaps entirely.  Modify the build system to link against libGL and libGLU.  Also remove include/glide2 while I'm at it.

_________________
MacHomeworld | HomeworldSDL.org


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 16, 2006 7:22 pm 
Offline
Site Admin
User avatar

Joined: Tue Dec 14, 2004 12:41 am
Posts: 326
lmop wrote:
Well the merge was as horrendous as I thought it would be so I'm for starting from scratch. We have two choices:

1) delete the current no-rgl branch and branch from trunk again
2) delete references to the RGL code gradually on trunk and then delete RGL completely

Since we're not in a situation where we need to guarantee that there is always a code branch that compiles - although that's always nice! - I'd opt for (2). It also means that if something does break there will be more eyes to notice/fix it closer to the time it happens. For reference, this is what Aaron originally did:
.............
Snip...
............

Rip out RGL, glc, and glcaps entirely. Modify the build system to link against libGL and libGLU. Also remove include/glide2 while I'm at it.


That sounds like it... I'm not exactly an uber-coder but I was annoyed when I started trying to fix the linux install and kept running into stuff that wouldn't even be relevant to Homeworld nowadays... much less Homeworld SDL.

So I vote for 2: dropping rgl as we go.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 16, 2006 7:31 pm 
Offline
coder

Joined: Wed Nov 15, 2006 8:15 am
Posts: 100
I also think number 2), is the best solution :)


Top
 Profile  
 
 Post subject:
PostPosted: Fri Nov 17, 2006 11:44 am 
Offline
coder

Joined: Tue Nov 07, 2006 4:40 am
Posts: 236
#include "2p"

Phase it out. :)

Aunxx.


Top
 Profile  
 
 Post subject: r291 - Removed 3Dfx code
PostPosted: Mon Nov 20, 2006 7:13 pm 
Offline
coder
User avatar

Joined: Tue Dec 14, 2004 3:24 pm
Posts: 324
Location: UK (UTC+0)
I've removed the 3Dfx code in r291 as part of the RGL deprecation. This is about as much as I dare do on this front given that I have no good way of testing these changes. Please check I haven't broken the video options screen. If I've cocked something up (sorry) please can you try and fix it in a way that moves us forward with the RGL deprecation. Thanks.

_________________
MacHomeworld | HomeworldSDL.org


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 21, 2006 2:42 am 
Offline
coder
User avatar

Joined: Wed Oct 04, 2006 8:13 pm
Posts: 94
Location: UTC -0500
"Please check I haven't broken the video options screen"

r291, seems to work ok in kubuntu.

_________________
http://againsttcpa.com/what-is-tcpa.html
http://google.com/search?q=c+programming+faq
http://research.att.com/~bs
acronyms.ch, neworder.box.sk


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 22, 2006 3:28 pm 
Offline
Site Admin
User avatar

Joined: Tue Dec 14, 2004 12:41 am
Posts: 326
Apparently you broke the palletized textures.... I happened to have that set as part of my install researches and such textures didn't load and according to Niece #1 I had the original "Great White Fleet". :)

Code:
(null) (0): Warning-
trPalettedTextureCreate: aspect overflow in texture of size 64 x 4
(null) (0): Warning-
trPalettedTextureCreate: aspect overflow in texture of size 64 x 4
(null) (0): Warning-
trPalettedTextureCreate: aspect overflow in texture of size 4 x 128
(null) (0): Warning-
trPalettedTextureCreate: aspect overflow in texture of size 4 x 64
(null) (0): Warning-
On and on and on... :)


r291 worked fine here after I switched palletized textures off.

Am currently wrestling with makefiles in r294...


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 22, 2006 6:39 pm 
Offline
coder
User avatar

Joined: Tue Dec 14, 2004 3:24 pm
Posts: 324
Location: UK (UTC+0)
branches/no-rgl deleted in r298. Now it's up to you guys to whittle RGL down to nothing...

_________________
MacHomeworld | HomeworldSDL.org


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 22, 2006 7:08 pm 
Offline
coder
User avatar

Joined: Tue Dec 14, 2004 3:24 pm
Posts: 324
Location: UK (UTC+0)
zapkitty wrote:
Apparently you broke the palletized textures... r291 worked fine here after I switched palletized textures off.

Possibly something to do with this:

Code:
Modified: homeworld/trunk/src/SDL/glcaps.c
@@ -766,18 +757,6 @@
-    if (RGLtype == GLtype)
-    {
-        //3dfx is the only vendor currently known to properly
-        //support paletted textures
-        if (strstr(GLC_VENDOR, "3dfx") == NULL &&
-            strstr(GLC_VENDOR, "3Dfx") == NULL)
-        {
-            //3dfx is not the vendor, no palette support
-            trNoPalettes = TRUE;
-        }
-    }
-

but since I doubt you have a 3Dfx card I'm not sure how. Check the setting for trNoPalettes; it's set to FALSE (i.e paletted textures are OK) by default so something else must be flipping it to TRUE for some reason.

_________________
MacHomeworld | HomeworldSDL.org


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 22, 2006 8:17 pm 
Offline
Site Admin
User avatar

Joined: Tue Dec 14, 2004 12:41 am
Posts: 326
lmop wrote:
Possibly something to do with this:
....
but since I doubt you have a 3Dfx card I'm not sure how..


Because I'm experimenting with the broken linux install trying to get the game to set the switches right :)

So if linux folks are using a 'reg' file that already had the proper settings... and don't have a 3dfx card... they wouldn't have noticed.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 28, 2006 3:45 pm 
Offline
coder
User avatar

Joined: Tue Dec 14, 2004 3:24 pm
Posts: 324
Location: UK (UTC+0)
Now we haven't ripped RGL out yet and here's a possible reason why we shouldn't...

RGL has been declared superfluous since it does the same job as SDL which is a cross-platform library. If it's cross-platform then it will support all the major platforms, right? Well as it happens, no. There are a few platforms where getting SDL on it will be quite hard (by design) because the official API is DirectX. I am of course talking about Microsoft's XBox and XBox 360.

Now real-time strategy games don't fit particularly well on consoles, true but there's nothing to stop someone from trying. I thought about it myself when I heard about Microsoft's XNA API ("just a simple recompile" to migrate between Windows and the XBox platforms). Anyway, I just came across this guy attempting to port Homeworld to the XBox so it's not just a theoretical situation...

So... Keep and maintain RGL in order to support two platforms that aren't immediately suited for the game? Find/write an SDL -> DirectX wrapper to support the XBox platforms? Other?

Discuss. (Again.)

_________________
MacHomeworld | HomeworldSDL.org


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 28, 2006 4:20 pm 
Offline
coder
User avatar

Joined: Wed Oct 04, 2006 8:13 pm
Posts: 94
Location: UTC -0500
I'm still for removal of RGL.

"to support two platforms that aren't immediately suited for the game"
if the xboxes came standard with a keyboard and mouse, cool maybe, but they don't.

if someone wanted to do an xbox port, they could still get some version of HWSDL with RGL, and then could try adapting the game/gameplay to the xbox.

_________________
http://againsttcpa.com/what-is-tcpa.html
http://google.com/search?q=c+programming+faq
http://research.att.com/~bs
acronyms.ch, neworder.box.sk


Top
 Profile  
 
 Post subject:
PostPosted: Sun Dec 03, 2006 7:19 pm 
Offline
Site Admin
User avatar

Joined: Tue Dec 14, 2004 12:41 am
Posts: 326
nova wrote:
I'm still for removal of RGL.


RGL must go... :)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 25 posts ] 

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group