Thread: Source structure

  1. #1
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459

    Unhappy Source structure

    Hello, It's me again

    Okay, I've started the production phase of my game,
    there are 3 main parts. A map editor, the client and a dedicated server (3 binaries).

    I have the source structured as so:
    Code:
    ./source/me
    ./source/cl
    ./source/sv
    ./source/shared
    ./source/shared contains things like SDL font wrappers, SDL image wrappers, config parsers etc. The client and map editor use things from the shared directory, so my question is...
    Should I build everything in the shared directory into an object file and link with the map editor and client, as some things in the shared directory are dependant on-one another. I also set ./source as an include directory, so the map editor only has to #include "shared/font.h" for font support etc.

    Sorry this is hard to explain
    Code:
    auxiliary.c  config.c  console.c  font.c  image.c  niris.h
    auxiliary.h  config.h  console.h  font.h  image.h
    font.c relies on image.c to be built into the project else it won't work. So should I build everything in the shared directory into an object? Then link with the map editor and the client?

    Also, I wrap SDL_TTF, so when you use it you see nothing of SDL_TTF, so I typedef SDL_Font to font so SDL_TTF.h doesn't need to be included. Is it good practice to do that? ie:

    font.h
    Code:
    #ifndef INCLUDED_FONT_H
    #define INCLUDED_FONT_H
    
    #include <SDL/SDL_ttf.h>
    
    typedef TTF_Font font;
    
    int fontInit(void);
    font * fontLoad(const char * name, int pt);
    void fontUnload(font * f);
    void fontPrint(SDL_Surface * dest, font * f, const char * s, SDL_Color clr, int x, int y);
    void fontDeinit(void);
    
    #endif /* INCLUDED_FONT_H */
    font.c
    Code:
    #include <stdio.h>
    #include <string.h>
    
    #include <SDL/SDL.h>
    #include <SDL/SDL_ttf.h>
    
    #include "niris.h"
    #include "image.h" /* SEE ABOVE, font.c relies on image.c being built with it! */
    #include "font.h"
    If you'd rather read the entire source, It's at http://files-upload.com/files/550997/source.zip. I'd really appreciate comments on my source / coding style

    Should I be including 'SDL/SDL_ttf.h' into font.h? Or just assume SDL_Font is already defined? ie, SDL_ttf.h was included before font.h was.

    Thanks in advance
    Sorry it's so long
    Last edited by zacs7; 10-09-2007 at 11:56 PM.

  2. #2
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > So should I build everything in the shared directory into an object?
    You could build it as a library instead, then let the linker figure out the dependencies for the things you actually need.

    As for the font renaming, it's a good idea, but you need to pick a more specific name than just 'font'. Think of the "SDL_" in SDL_Font as being the namespace.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  3. #3
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    Thanks, I've decided to go for a shared library, build ./source/shared into a lib and link it with the map editor, client and server. However, say some parts of the shared library require SDL_net (network.c), so I'd link the server & client with SDL_net and the shared library... but what about the map editor? (Wouldn't need network.c) so can I safely link without SDL_net but still with the shared library?

    I'm calling the library 'libshared', is that wise?

    What's the best way to work with a makefile across several levels of directories? The makefile is ./source/Makefile
    Code:
    auxiliary.o: 
    	$(CC) $(CFLAGS) shared/auxiliary.c -c
    Or should I define, SHAREDDIR=shared/ and use $(SHAREDDIR) in place of shared/ ?
    Last edited by zacs7; 10-10-2007 at 02:58 AM.

  4. #4
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    If the editor doesn't need network, then it won't be dragged into the executable, even if networking is part of your library.

    > I'm calling the library 'libshared', is that wise?
    Lacks imagination IMO

    > Or should I define, SHAREDDIR=shared/ and use $(SHAREDDIR) in place of shared/ ?
    Symbolic names are a good idea, it makes relocating things so much easier later on.

    > What's the best way to work with a makefile across several levels of directories?
    A makefile in the top level which creates all the executables, and branches down into sub-dirs to other makefiles.
    The makefiles in the sub-dirs then make either libraries or objects.

    Depends how big this is going to get really. A single top-level make which is well structured may be enough, and give you the option of splitting up later on.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  5. #5
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    Thanks a lot Salem

    I need more imagination

  6. #6
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    You could certainly call the library "lib<somename>" or "lib<somename>shared", where somename is the name of your actual game (or whatever the end product is).

    If you only produce one library file alltogether, calling it "lib<somename>" is fine.

    Also, I would consider common "splitting guidelines" when it comes to splitting the makefile into multiple makefiles. So, the same as when you are working on a large C-file and decide to split it, you do this when you start to see that it's got so large that it's a but unwieldy. Then you split out some (large-ish?) part(s) of the file into a separate C-file(s). Likewise, when your overall makefile is getting too large, you split off one or more parts of the makefile into subdir makefiles.

    One thing that makes for easier maintenance is to put CC, CFLAGS, LD, LDFLAGS, AR macros and such things in a separate "config.mk" or such. That way, if you decide to swap compilers, or change to a register passing calling convention, you can do this without having to hack around in several different makefiles.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  7. #7
    Dr Dipshi++ mike_g's Avatar
    Join Date
    Oct 2006
    Location
    On me hyperplane
    Posts
    1,218
    If you are looking for speed, using a bitmap font would be quite a bit faster than vector fonts especially if you want to do stuff like wordwrap and justify your text. Writing a simple bitmap font system isent much work at all. If you like I could post a crude SDL example that I made a while back.

    Also why not make you map editor a stand alone application? Its the sort of thing that you could reuse for future games.
    Last edited by mike_g; 10-10-2007 at 09:19 AM.

  8. #8
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    It is a stand-alone application

    For future games I could use the map editor and the shared library...

    I'll stick with SDL_ttf for now, thanks for the offer. If I expirence speed problems I can simply change the font wrapper to load bitmap fonts without changing anything else

  9. #9
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by zacs7 View Post
    Should I be including 'SDL/SDL_ttf.h' into font.h? Or just assume SDL_Font is already defined?
    A header file should never assume that some other header file has already been included. In general, the order of inclusion of header files should never matter. Therefore, if a header requires the definitions provided by some other header, it should include that header. The standard header inclusion guards make it safe to include headers multiple times.

    When in doubt, include it. If you introduce unenforced dependencies between headers, you risk losing your mind, and make it hard for other users of your code. Also, who the heck wants to document all the dependencies when you can completely eliminate the entire problem.

  10. #10
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    Hmm thanks everyone, very helpful

  11. #11
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,057
    I can't download your source code . . . I get the rather bizarre error
    Sorry. You can not download this file today. Download traffic for your country is empty.
    I like to use "SDL_ttf.h" rather than <SDL/SDL_ttf.h>. It makes it easier to adopt your code if you want to use a different set of header files. Not that it matters very often, but hey. Either way is fine.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  12. #12
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    Hmm thanks dwks, here it is: (rename to *.zip)
    Last edited by zacs7; 05-25-2008 at 07:24 AM.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. 'Type' Error on Build of Officially Released Source Code
    By Jedi_Mediator in forum C++ Programming
    Replies: 5
    Last Post: 07-07-2008, 05:28 PM
  2. Open Source and Security
    By DavidP in forum A Brief History of Cprogramming.com
    Replies: 17
    Last Post: 06-17-2008, 01:23 AM
  3. Source file inclusion
    By sh3rpa in forum C++ Programming
    Replies: 7
    Last Post: 10-02-2007, 11:10 AM
  4. Binary Search Trees Part III
    By Prelude in forum A Brief History of Cprogramming.com
    Replies: 16
    Last Post: 10-02-2004, 03:00 PM
  5. Serial Communications in C
    By ExDigit in forum Windows Programming
    Replies: 7
    Last Post: 01-09-2002, 10:52 AM