 |
|
MrBaggins
|
|
A couple of the changes I'm making require a couple of new files, for a new class. I'm not sure if this has been done before, its not apparent from a brief scan of the altered source files.
If we add new files to the project (or workspace), then we should also distribute the workspace file, right? Anyone see any issue with this?
|
|
|  |
 |
|
MrBaggins
|
|
Looks like you need both files... dsp & dsw.
|
|
|  |
 |
|
ctplinuxfan
|
|
Hi,
i also intented to add some files (e.g. a plugin replacement more portable).
Unfortunately, VC++ screws up dependencies, e.g. files were removed within the clean rules of gs/newdb, that's why i didn't post these additions yet, and these changes cover all projects except dbgen...
quote: So I would need to change the file manually again. |
My VC++ has the same problem. I replaced $(CDKDIR)\ by $(WkspDir)\..\..\bin\ in the workspace files. Unfortunately, i had to do this within VC++ for each target file and each target, because VC++ does not load workspace files you changed with unix tools like sed 
quote: replace the old database |
If you mean gs/newdb i don't think that's a good idea. The main advantage of this implementation is a common codebase, i.e. decreased bug possibility. O.k., it's annoying if you have the authors edition of vc++ and need to confirm a popup coming up for each .cdb file... ;-)
For redesign, you can consider a lot of things, to either reduce bugs/bug possibility or increase performance:
- reducing use of objects
- stopping to pass temporary objects around
- event manager (using non pod-types for va_list args)
- avoid changing method parameters (passed by call by value)
- instance lifetime model (fixing memory leaks, etc.)
- reducing inter-class dependencies
- removal of changes to const char *& references
- using references where possible
- avoid unique names (like GUID GUID...)
- centralize initialization (sound/cd/legal cd check etc.)
- removal of dead code
However, if you consider a bigger redesign, a #ifdef ACTIVISION_ORIGINAL guard scheme tends to become impractical, maybe confusing
Ciao
Holger
|
|
|  |
 |
|
MrBaggins
|
|
The main advantage for switching the rest of the old constant data records to the new style is that the parsers would be dynamically generated.
Right now... you can't change constdb without rewriting the parser, for instance, which is a little bit of a PITA.
I believe the big bit of missing functionality, and why they (maybe) didn't switch the other records over was that the old classes had serialization functions.
If we implement them for the new style then we should be able to switch them over without too many issues.
|
|
|  |
All times are GMT. The time now is 05:33. Apolyton Time is 00:33. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|