Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: blackhole on June 12, 2007, 01:58:09 am
-
Well, i'm browsing through the source code (there's a lot of it o.O), and i find this:
Functions.
Structs.
More functions.
Some #defines.
More functions.
More functions.
Apparently, the FS2 programmers didn't like an object-oriented approach to the game... Are there plans to convert a large amount of this code to classes or structs with constructors and methods? Looking at all those functions make my eyes bleed :(
I am happy to report, however, that the majority of the FS2_open code IS object oriented, thank god.
-
Not really, no.
I started some work on making the ship_weapon struct object-oriented friendly and to add the possibility of having as many weapon supertypes as you liked. (Primary, secondary, tertiary, quaternary, etc)
However after 4-5 hours of work there were still so many compiler errors that it gave up after 100 in the AI code alone. Obviously it'd be nice to redesign things so that they work "properly", but it simply becomes a matter of having to spend a hell of a lot of time reworking code that you still can't do completely properly because everything else isn't object-oriented and isn't designed from the ground up with that in mind. For example, it makes more sense to integrate the ship_weapon struct with all of the other weapon and firing point data in the ship and model structs because turrets have the same general function. Alas, doing so would be pure hell and require serious reworking of massive amounts of code that has a high risk of breaking compatibility - assuming it would even be possible to do all that without breaking backwards compatibility for most everything.
If you really want to do things object-oriented style, you're better off finding another project to work on. Not to drive you off, but if you want to make FS2_Open object-oriented, you're basically going to be spending the time and effort it would take to make a new game, even if you don't try to add more functionality.
-
I'd rather work on FS2_open then spend months searching for a non-retarded project to work on that has good code structure. Unfortunatly it doesn't appear that i've really been accepted into the code team nor do i have any idea how to get myself accepted into the code team. I can't really do anything with the code unless i have some kind of clear goal in mind. You guys seem to want more programmers, so here i am. Feel free to tell me to do something when you have something for me to do, until then theres not much i can do but sit and wait.
-
There is always something to do. :p
Right off the top of my head I can name four semiprojects that I've started, but can probably have additional work done on them.
hudparse.cpp (hud_gauges.tbl)
This code takes care of moving around the retail gauges and letting you to set certain text or image fields. I designed with the assumption that somebody else would be taking a crack at it, so it's a little more up-front (I hope) than the rest of the code. Wing Commander Saga has used this already, and probably has "more hud gauges in hud_gauges.tbl" buried in their billion requests. :p
Modular tables
This is a little less immediately useful but would be nice. Taylor implemented a special modular table loading function, but a lot of the parsing code still needs to be updated to take advantage of modular tables. In addition some tables could be made XMT-compliant where they aren't already.
objecttypes.tbl
I forget what file this is stored in. Basically what you do is do a search for SIF_* and move the hardcoded behavior into variables in objecttypes.tbl. You take the original values for whatever-the-behavior-was and stick it in the default objecttybes.tbl located in def_files.cpp
Lua and scripting
I have done very little serious work on making Lua work with the interface. It still works, but there's not enough interactivity to let you substitute something like the options screen with a scripted variation. You could also pick and choose any set of variables or objects to port into the Lua code. I've been very protective of it because I've tried to make it organized well and object-oriented, and safe, and fast, but if you can work on it and make it better I have no qualms about it.
wmcgui.cpp
This is somewhat reaching, but it's still around and it's still object-oriented. This is basically supposed to be a more flexible UI system than the FS2_Open default that also supports skinning. This skinning support wasn't really working at the time, because gr_bitmap wasn't working with OpenGL and D3D had issues of its own. It's only used for the lab right now, but I've been thinking of expanding it into scripting. Taylor is also working on his own UI replacement, which I don't know anything about except it's supposed to have a graphical editor.
Wing Commander Saga Requests
There's 2-3 pages worth of these. Other campaigns have their own requests, but WCS is notorious for making the most outlandish and bizarre (IMHO) and numerous requests. There's a small mountain of those sitting in one of the forums that isn't generally visible to the public. Talk to Starman01 or Tolwyn about WCS requests, I'm not sure who has the final say.
DaBrain runs Shadows of Lylat, a Starfox mod, and has some requests that sound bite-sized. chief1983 would also like auto-gun convergence for the Star Wars mod, which doesn't sound too bad, it would require knowledge of ship flags and/or table variables, as well as 3D math.
Bobboau's code
Bobboau made a big commit a few months ago that contained things like turrets that didn't shoot through their parent ship's hulls, and the ability to mount turrets on the sides of a ship or at any angle you pleased. There's also some defunct damage decal code in there. Basically this code needs to be fixed up and/or made neater.
Mantis
And, of course, there's an eternal pile of bug reports to sort through, diagnose, and fix.
The AI Code
Fabian is working on making the AI code more modular. This would be very useful to have, since it would let us make the AI smarter without breaking every mission already released. You could ask him if he has any specific jobs he wants done.
However, my recommendation would be to start small and look for some minor requests that campaigns have put out there and make some patches of those. That way you don't take on too much all at once, you can get some sample work done, and you learn about the code while doing it. Also, I suggest you apply some critical thinking to requests: is the person asking for it because it just sounds cool, or do they actually plan on making a mission that uses the feature?
Welcome to the SCP, I hope I haven't scared you off. :nervous:
-
Beyond the Red Line has a similarly long list of stuff we want too. And I'm sure IP Andrews could give you a long list of stuff he wants for the Babylon Project.
-
While all of those lists are great, and getting that stuff worked on would be a big help, those lists always leave out one of the biggest problems that we have with the engine: collision detection.
The collision detection code is really our single greatest problem right now, because it absolutely decimates performance. Someone needs to go through and either fix it, upgrade it, or totally rewrite it. I don't have the math skills, or know how a good collision detection system should be setup, so I avoid working on that code except for fixed the most basic bugs. The current code just wasn't designed with hi-poly models in mind, so the more that we add, the worse the performance gets. Right now it's not uncommon for you to get an 80% performance drop in-mission, and that's just the result of the collision detection code. So while this is one of the biggest projects that anyone could take on, it's also probably the most important and would provide a major boost to engine capability.
-
Actually CD was on my list. I remember you mentioning that it was responsible for a lot of the problems in BtRL. :)
-
It would be awesome if a list like this was stickied, or kept up on the wiki. I would volunteer to keep that section up, if you folks will keep me up on what's fixed, what's not, and what status the requests are at :D
-
We've tried request lists before and not had much success. But not having a central go-to person was probably a factor in that.
-
Like I said - I'd be willing.
I'd also like to see about trying to organize a post on Gamedev, or somewhere similar, to get us a few more coders.
A project that is as well-established as the SCP is will do phenomenally well on Gamedev, as far as getting people who really want to do something meaningful. Most of the time, the issue is that noone *knows* about a project like this. I know we've talked about it before, kara - but I wantd to see what the other folks here think.
Especially for projects like collision detection and network coding. Those are specialties you'd be MUCH more likely to find at a place like Gamedev.
-
I'm not yet a developper in the project, i only work on it on my way; until i have something to commit. So my opinion don't really mean something.
But I'm here, so: it's true, a lot of good programmers would come from GameDev; and it's a problem, in my mind.
I see the FS2 project as a big cohesive community, with known coders, who know artists involved; and with lot of people that love THAT great game (as i).
Also, on GameDev, there's lot of awesome programmers, but most are more proficient with C++, which is not the case there.
Involving lot (because there will be a lot !) of programmers from GameDev (or any community like this one) would lead to a lost of the spirit of the project... :(
-
What do you consider "the spirit" that would be lost?
Most folks won't work on a game they don't enjoy. Especially a free one.
One of the biggest issues I've seen is the dearth of programmers to implement the features we all want in our specific mods. Most of the features we want are specific things that will likely only be needed by that specific mod of TC. For those sort of features, I think the TC's are better-served by having internal programmers that concentrate on the features they, in specific, want. Our mod, for example, has 2 coders we're gearing up specifically to look at those feature elements we're going to need. This weekend, we're having a meeting to explain what, exactly, we're looking for - specifically, that we'd like most feature implementations to be flag-oriented. However, what I'm talking about are the larger-scale issues like collision detection and netcode that programmers who specialize in those areas mioght be able to fix more readily.
If, instead of recruiting via a specific mod for these sort of areas, we recruit *for those areas* as the SCP en toto, and ensure they realize what the project guidelines are, we can get quality coders, and keep the "spirit" of the project, imho.
Mod-specific features can often be, and even should be, looked at by coders recruited by that mod - but with the understanding that the goal is to make it compatible with the overall SCP project, as well as incorporate the features we need. For the large-scale projects, I think a bit of SCP-wide recruiting could be extremely valuable.
-
I say bring em over.
*Karajorma prepares brainwashing ray*
Seriously though as long as we explain at the start that we have two main goals
1) Preserving compatibility with FS2 Retail
2) Making the most kick arse multi-platform space combat engine ever
in that order we should be fine. We only really have problems when someone thinks that the first goal is less important than the second.
@Aszarsha : I do see your point but I think that the smart thing to do is get the coders over here. Those who want to work with the project without spoiling the community feeling will carry on and the others will get dispirited and leave.
-
I think I'm going to write up a post in the format GameDev likes.
I'll post it here, first, and let you coder folks sign off on it, add/subtract what you like - and if one of you would rather post it, that's fine with me.
I just want coders, y'know? :D
To fix the issues that will affect the "polish" of my mod, certainly, but also that of every other mod that wants that retail-quality "polish" when they get to release time.
It's important stuff.
-
I could go through and search for possible math optimizations, but my math skills are limited to a sophomore's knowledge of Intermediate Algebra, so i would recommend keeping me away from collision detection :D
I may give the code a bit of a looksee today, after my piano lesson. I have a gut feeling that i might actually be able to do something with collision detection that has nothing to do with math. I'll update you if i get anywhere.
It would be awesome if a list like this was stickied, or kept up on the wiki. I would volunteer to keep that section up, if you folks will keep me up on what's fixed, what's not, and what status the requests are at
Having a list like that would make organization far easier. Espiecally for me :nod:
In the mean time, is there a list of really tiny bugs i could look through?
-
objecttypes.tbl
I forget what file this is stored in. Basically what you do is do a search for SIF_* and move the hardcoded behavior into variables in objecttypes.tbl. You take the original values for whatever-the-behavior-was and stick it in the default objecttybes.tbl located in def_files.cpp
I need to add a caution to this. There are two different property lists in FS2: ship types and ship classes. The flags between the two of them are almost completely disjoint, despite being very similar conceptually. Whoever takes charge of porting the SIF_* flags over is going to need to make sure nothing breaks when the two lists are merged.
-
Well i've been searching through the collision detection code but have been unsuccessful in my attempts to understand it. I assume that somewhere in that mess its iterating through the vertices located on a ship? This is what would start hitting preformance with big models. In this case there are most likely optimizations that could be made to help out, but the main problem is that no physics engine can handle large amounts of polys, its limited by computer power. What lots of engines do is create a second model for collision detection, similar to Freelancer's infamous SUR files. I think that a HUGE preformance gain could be made by simply passing a different model to the collision detection routines. It could be an untextured POV file, or whatever you want, just make sure its not rendered. Then, take the loaded model file (which would basically be a lower-poly version of the high poly models, using one of the high poly model's LODs would be an excellent idea) and pass that to the collision detection routine or otherwise force it to use that model instead of the high poly one. You'll get less accurate collisions, but its doubtful that they will be noticed, espiecally if the collision model is properly done.
Thats my take on it. I'm going to look for something else to work on... *goes bughunting*
-
Here's something that can be a bit easier or a bit harder for you...
Any chance you could add in several flags to FRED and whatnot?
1) FirePrimary (causes target ship to fire primary weapon at normal rate for x number of miliseconds)
2) FireSecondary (causes target to shoot secondary weapon for x number of times and at x target)
3) FireCountermeasure (causes target to shoot x number of dummy countermeasures)
4) FireTurret (causes turret to fire at a specific location)
5) Move-Rotation (causes ship to rotate at a specific angle-- -179 to 180)
6) Move-Flightplan (causes ship to follow a specific flightplan)
7) IgnoreAllButOrders (causes ship to always ignore everything except the current active order strain)
8) UseAfterburner (causes ship to use afterburners for x number of seconds)
9) ForwardShields (causes shields to be augmented forward)
10) RearShields (backward)
11) LeftShields (to the left)
12) RightShields (to the right)
13) TogglePrimary1 (set to fire first primary bank)
14) TogglePrimary2 (set to fire second primary bank)
15) ToggleSecondary1 (set to fire first secondary bank)
16) ToggleSecondary2 (set to fire second secondary bank)
17) ToggleSecondary3 (set to fire third secondary bank)
18) MissionMod (directs the mission to use a specific mod file from the \Freespace2\ directory)
19) MissionModMod (directs the mission to use a specific mod file from the \Freespace2\*modname*\ directory)
20) SetBothPrimary (set to fire first and second primary banks)
21) SetDoubleSecondary (set to fire current secondary bank on double mode)
22) MissleHitsCounter (set to cause dummy countermeasure to take out missiles)
Yes, by several I mean more than 20. I need all of those for some cutscene work. Either that or direct me toward a rendering engine.
Quick question while we are on the programming talk... is it possible to have FS2 do a complete simulation if it is saved correctly? I don't mean using FRED, I mean like using a seperate OGL/DX renderer inside the game.
-
You'll need to be more specific on 6 and 22, but I think all of them are possible except for 18 and 19. While they could be coded, it'd be a mess and extremely prone to failure.
-
Yes, by several I mean more than 20. I need all of those for some cutscene work. Either that or direct me toward a rendering engine.
Have fun. (http://en.wikipedia.org/wiki/Rendering_engine)
-
Perhaps scripting should be enabled for things like cutscenes?
-
Well i've been searching through the collision detection code but have been unsuccessful in my attempts to understand it. I assume that somewhere in that mess its iterating through the vertices located on a ship? This is what would start hitting preformance with big models. In this case there are most likely optimizations that could be made to help out, but the main problem is that no physics engine can handle large amounts of polys, its limited by computer power. What lots of engines do is create a second model for collision detection, similar to Freelancer's infamous SUR files. I think that a HUGE preformance gain could be made by simply passing a different model to the collision detection routines. It could be an untextured POV file, or whatever you want, just make sure its not rendered. Then, take the loaded model file (which would basically be a lower-poly version of the high poly models, using one of the high poly model's LODs would be an excellent idea) and pass that to the collision detection routine or otherwise force it to use that model instead of the high poly one. You'll get less accurate collisions, but its doubtful that they will be noticed, espiecally if the collision model is properly done.
Thats my take on it. I'm going to look for something else to work on... *goes bughunting*
I'm no coder at all but thinking about the game logic I reached the same conclusion. But:
- I wouldn't use any low res LOD from the actual model because retail models, (or in fact any model till nowadays), haven't been built with this factor in mind so maybe you can get weird effects. (You'd need good updated models where there were a good match between LOD0 and the rest, so in other words you are breaking backwards compatibility).
- I'd use an auxiliary xxx-collision.pof model in a similar way as we have -shine or -glow auxiliary maps. If the xxx-collision.pof exists, this model will be used instead of normal one. If it doesn't, you just maintain actual behaviour. In this way each modder would have to build an adequate auxiliary model to improve the performance of the collision detection of every added or modified ship. (And our mighty DaBrain would have to update mediavps with a fully new set of auxiliary collision models).
- Of course, if you can optimize the existing routines to make them faster, that would be extra points.
(Just an idea, don't blame me too much if it is nonsense :cool:)
-
I think the other coders should look into that...
-
You'll need to be more specific on 6 and 22, but I think all of them are possible except for 18 and 19. While they could be coded, it'd be a mess and extremely prone to failure.
6) What I mean is follow a more-smooth flightplan (like you set the waypoints but the ship doesn't make a violent turn toward it, rather it slowly adapts by a more-smooth turn)
22) Using fake countermeasures and making sure that they always destroy the missile in pursuit... so that in a cutscene a countermeasure that should destroy the missile fails to go off (like they sometimes do) and ends up hitting the ship
On 18 and 19, those would both be enormously helpful to creating missions. If you could specify a sub-mod-pack, allowing you to get around some barriers like the ships.tbl limits or separate incompatibles mods without relaunching the game.
-
Well i've been searching through the collision detection code but have been unsuccessful in my attempts to understand it. I assume that somewhere in that mess its iterating through the vertices located on a ship? This is what would start hitting preformance with big models. In this case there are most likely optimizations that could be made to help out, but the main problem is that no physics engine can handle large amounts of polys, its limited by computer power. What lots of engines do is create a second model for collision detection, similar to Freelancer's infamous SUR files. I think that a HUGE preformance gain could be made by simply passing a different model to the collision detection routines. It could be an untextured POV file, or whatever you want, just make sure its not rendered. Then, take the loaded model file (which would basically be a lower-poly version of the high poly models, using one of the high poly model's LODs would be an excellent idea) and pass that to the collision detection routine or otherwise force it to use that model instead of the high poly one. You'll get less accurate collisions, but its doubtful that they will be noticed, espiecally if the collision model is properly done.
Thats my take on it. I'm going to look for something else to work on... *goes bughunting*
AFAIK the engine already uses simplified models for collision detection, called bounding boxes.
One of the reasons why it's hard to convert high poly models to pof - or why such models have problems - is that either the BBox generation routines in pof constructor tools or the BBox code itself wasn't built with such high poly models in mind.
The second problem is that it checks for actual model intersection each and every frame, so things moving really fast tend to slip through. It is also limited in the number of intersections it can track, after a while shots start to ghost through models.
(Beams - hitscan weapons - are handled differently).
-
Right - well i'm not even going to attempt to try anything like that. However, provided i can get the code to compile, i'm going to go ahead and try to replace all the directX 8 rendering code with directX 9.0c updated code using the most recent April 2007 SDK. I'm familiar with DirectX's API so this will be a good way for me to get to grips with the SCP code. If i actually succeed, then well, woohoo, we'll have DX9 stuff. Either way i'll use this to get myself ready for actual assistance for the team :nod:
-
well.. before you start working on DX code.. maybe you should talk to taylor.. and read this: http://www.hard-light.net/forums/index.php/topic,47520.msg967131.html#msg967131
-
Bleh, i don't really care. I'm just doing this for the heck of it. Its not like i'd commit the code or anything.
-
I seem to remember that DX9 was a problem in that people running Win2K couldn't get the SDK to work (or was it Win98).
If you can fix DX that would be very useful though.
-
People shouldn't need the SDK. All they need is that d3dx9_33.dll is either in their system32 folder or in the same folder as the FS2 executable. It shouldn't require the installation of anything.
I almost have the code compiling properly so at that point i should be able to make an assessment of it. DX8 API is very similar to DX9, so it should be easy.
-
You need the DX9 SDK to compile DX9. There's a version that works on Windows 2000 - I linked to it ages ago - but none of the recent versions do.
-
Oh, and Bob-san, I think you have a lot of great ideas for cutscenes, but your approach sucks. I really doubt that you "need" your requests filled any more than any other campaign out there. And we have no obligation whatsoever to you to fulfill those requests.
If you were to phrase your request more as a request and less as a "Give them to me or else", you might actually appear cooperative and some of the other campaigns that are working on cutscenes would dip in and add their support. As it is you didn't even bother to explain what you plan to use them for, so we have no guarantee that whatever time the SCP spends won't be used for your personal amusement and nothing else.
And finally, what you're asking for aren't just flags. All of them require interaction, possibly very complex interaction, with other parts of the code. 18 and 19 are basically impossible without tearing up the lowlevel filesystem, and the rest are just begging for conflicts with the AI code.
-
To compile DX9 you simply need the lib files and include files - they are included in the SDK but you shouldn't have to install the SDK to compile it if you have the include and lib files stored in the FS2 project CVS itself. Course, that might be a pain to people downloading CVS. But windows 2000 was never really designed for DX9... Might it be possible to have a compiler option to simply exclude DX9? Or does DX9 *have* to replace the DX8 driver?
Thats considering that i can ever get this stupid thing to compile. I really think the 2005 project files are either horribly outdated, horribly made, or both. They don't use relative paths and i've encountered no less than 14 items that don't exist anymore, plus i had to totally redo all the reference paths. I just found out that the 2005 version doesn't even have 3 rather crucial projects, and when i tried compiling them with the converted 2003 project and putting them in i just get 320 "unresolved external symbol" errors.
Come on, why are many of those paths using 'C:\'?! the folder is in the CVS!
-
Or does DX9 *have* to replace the DX8 driver?
The current D3D code is dead, so adding DX9 will replace the DX8 code. It's not optional at this point, unless you intend to also fix the horribly broken DX8 code.
There is a compiler option to exclude D3D, but that will have to include both DX8 and/or DX9, we aren't adding a new option just for DX9. That would be nothing but a pain in the ass.
-
Ah, well, if the DX8 code is already broken, i'll just replace it with DX9 code. Nice, working, good looking nextgen DX9 code... mmmmmmmm..............
Although i wouldn't call it broken because DX works better for me then openGL.
-
Although i wouldn't call it broken because DX works better for me then openGL.
The rendering issues that you listed are strictly data related. The only reason that the D3D code doesn't show the same problem is because it doesn't support any of those features. It's so out of date, messy, unoptimized, and feature deficient that it isn't even funny. The only working graphics API that we have is OpenGL, period.
-
If someone would fix the collision detection so as to make conversion easier, they would be my god.
Good luck blackhole :)
-
I tried that, unknowntarget, but failed :( I'm hoping i'll hav emore success with this. I think i will, considering i only got 150 errors after changing all the d3dx8.h references to d3dx9.h and changing all the objects from 8 to 9. Thats a relatively small number considering i just switched APIs :nod:
EDIT: MAke that 107 errors
EDIT2: Make that 32 errors. This is easier then trying to actually compile the source.
-
Oh, and Bob-san, I think you have a lot of great ideas for cutscenes, but your approach sucks. I really doubt that you "need" your requests filled any more than any other campaign out there. And we have no obligation whatsoever to you to fulfill those requests.
If you were to phrase your request more as a request and less as a "Give them to me or else", you might actually appear cooperative and some of the other campaigns that are working on cutscenes would dip in and add their support. As it is you didn't even bother to explain what you plan to use them for, so we have no guarantee that whatever time the SCP spends won't be used for your personal amusement and nothing else.
And finally, what you're asking for aren't just flags. All of them require interaction, possibly very complex interaction, with other parts of the code. 18 and 19 are basically impossible without tearing up the lowlevel filesystem, and the rest are just begging for conflicts with the AI code.
I'm not a programmer so I don't know how this all would go into the code. I don't know if it is an actual "need", but it would definitely be beneficial to some in-mission cut scenes that just don't work properly (some problems with it). I know you are not required to put in any of the requests, but they're just that--requests. If they are put in there, great! If not, well, people who want cut scenes for TSP will be downloading a lot of videos. I don't know exactly how to make my requests "friendly". That's a list of stuff that would definitely make my ideas work a lot better.
As of right now, at the end of a mission of TSP, we have plans for a pretty-complex in-mission cut scene. Cinematic sort of fight, a bit of a tribute to the FS2 Intro movie. That's stuff I'm not sure my system can run as a prerender and store all the uncompressed video. Yes, I know that they all require interaction--possibly very complex interaction. Now, I know 18 and 19 would be so hard to put into place, though they would make many campaigns much easier to get around limits (namely, by allowing you to have everything defined by-mission if necessary).
Now, most of that stuff is stuff that would make a lot of in-game cut scenes easier. Firing for a set number of times, fully-controlled movement without having to plot hundreds of way-points, the ability to change the shields (I'm not sure if this is available, though I think it might be), and have more control over how ships fight. The hard parts are finding what will work and what won't. I don't think that the game will accept rendering instructions without completely massacring this thing we call "compatibility". A render in DX or OGL would be great, but the movie scenes that come from it would be gigantic for a 2-minute battle. Also, sorting and exporting everything from the game would take forever, and importing all necessary stuff to a pre-renderer would be hard.
So, I hope we can get at least some of these implemented--it would definitely make TSP easier to do.
-
ok, nobody explained how collision detection works in FSO, so I should probly do that.
FS uses a BSP/octree, what is has is a tree and every node has a sortnorm, which divides the model in two, and a bouding box. colision detection only uses the bounding box portion of the tree. how it works is simple, if your test point is in a node's bounding box, then test all the children of that node, (and if a node is a polygon test it). so it should have about log2 complexity for finding a colision, the basic idea is prety good, but the implementation is hard to follow, I remember I did a rather huge revamp of the BSP system when I was working on the materials system, but that was a long time ago.. let me see if I can find that copy...
here we go (http://freespace.volitionwatch.com/blackwater/7-7-06_code.zip)
take a look at graphics/materials for what that whole thing was about
and model/bsp.cpp for why it's relivent here (note; I was effectively trying to make my own virtual function system for the bsp nodes), graphics/vertex buffers.h/cpp is still probably usefull to the project today, implementing it in a way similar to how I had in that code base would be a big step in the right direction, those were objects that I had origonaly designed for a totaly new game engine, and they are object oriented.
-
It'd be nice if someone invented a utility to convert function oriented code to object-oriented code. :p