Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Faster than 40d, no problems

42 (26.1%)

Faster than 40d, problems

72 (44.7%)

No slower than 40d, no problems

14 (8.7%)

No slower than 40d, problems

16 (9.9%)

Slower than 40d, no problems

2 (1.2%)

Slower than 40d, problems

3 (1.9%)

Doesn't work (please explain)

12 (7.5%)

Total Members Voted: 160

[Baughn]

music_and_sound.cpp is deprecated; its functionality is duplicated by music_and_sound_fmodex.cpp, which is the newer version. It shouldn't be in the project file in my repository, either.

[Baughn]

Also, using the project-local copy of SDL is rather the point; the entirety of SDL is bundled with the project.

[darksaiyan]

It runs really well for me, and the game is cool too, making DF some kind of rome total war war game. I get OVER 9000! in the menu and anything, mouse over and anything (I put the limit on 10000 and it never got under that in the menu and map). Lowest ever was about 2500 when I had about 10 armies attack a region. Lots of green stuff there, I couldn't really figure out anything but some kind of quick matrix screensaver at that speed.

Windows XP Professional SP3 32bit
Intel Core 2 Duo 4400 2GHz
2,5GB RAM
GeForce 9600GT 512MB

It hanged once though. When I tried to move about 9 armies from one region to another, when I pressed enter to pass the turn, it hanged (not responding).

Either way, it makes me dream of Nascar speed Dwarves around the central circle of my fort. I doubt I'd be able to catch them that way, not even paused (jk). Great code. Toady might the best programmer when it comes to his game, but he's not the master of other engines. Some help might make the best DF yet.

[isitanos]

Works fine with default settings on my computer:

Core 2 Quad Q6600 @ 2.4 GHz
Radeon HD 4800
Windows XP 32 bits

I can get to 9999 fps on default settings, it's more around 800-900 during a battle with a 125:50 grid (windowed).

I'll test on linux (ubuntu intrepid 64 bits) too if I have time. Do you have a 64 bits build? Otherwise, I guess I'll try and compile from source.

By the way, this is a nice Risk-like game. With some tweaks and added multiplayer, it could become really fun.

[Jurph]

... on this machine:
Athlon XP 1800+
nVidia GeForce 6600GT
WinXP patched/updated

Running fine under all but the heaviest loads.  I'm using the Mayday tileset, and smashing the computer easily.  At 15-on-1 with no sound, my frame rate drops from 10,000 FPS (ceiling in INIT) down to 210, and then crashes out when I inevitably win the battle.  At 4-on-1 I was barely dropping the framerate to 3,500.  If it would be useful data for you, I can run a few test cases and provide data like

Code: [Select]

Army 1 - 2503
Army 2 - 1401
Army 3 - 1799
FPS = ~2700

Army 1 - 2503
Army 2 - 1401
Army 3 - 1799
Army 4 - 2034
FPS = ~2500

So you can plot performance drop-off vs. number of entities being simulated.  If that's not useful to you, then I think I'll go back to Dorfing.  Thanks for putting this together!  I can't wait to see performance increases in OpenGL handling. 

[Baughn]

Works fine with default settings on my computer:

Core 2 Quad Q6600 @ 2.4 GHz
Radeon HD 4800
Windows XP 32 bits

I can get to 9999 fps on default settings, it's more around 800-900 during a battle with a 125:50 grid (windowed).

I'll test on linux (ubuntu intrepid 64 bits) too if I have time. Do you have a 64 bits build? Otherwise, I guess I'll try and compile from source.

A 64-bit build is out of the question, I'm afraid. There are way too many 32-bitisms in the code.

Use the 32-bit compat libraries. That's what they're for.

[Baughn]

No real point, no. At this point, unless BC outright fails to work for anyone (ignoring the MSVC++ runtime thing), I'm just sitting around, waiting for 40d-r2.

[darksaiyan]

Also, concerning the game, what does the number beside the army in the map screen indicate? Like H1, B4 or something. I saw that the number increments with the number of battles fought. Is that it?

[jaked122]

this could be the beginning of DF becoming open source... at least with individual modules, maybe pathfinding...

[Veroule]

I got this compiled on my system.  I had to use the NO_FMOD define to disable that code as the .lib you supplied didn't make sense to my compiler.  I wasn't about to spend time playing around with hunting down a current version of that library.

One very odd thing I had to do to make my compiler happy was to adjust the definition of "main" in enabler_sdl.cpp.

Spoiler (click to show/hide)

#ifdef WIN32
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
 LPSTR lpCmdLine, int iCmdShow) {
#else
int main (int argc, char* argv[]) {
#endif
#if !defined(__APPLE__) && defined(unix)
  gtk_init(&argc, &argv);
#endif
  keyMap();
   
  // Initialise all SDL subsystems.
  int retval = SDL_Init(SDL_INIT_EVERYTHING);
  // Report failure.
  if (retval != 0) {
    report_error("SDL initialization failure", SDL_GetError());
    return false;
  }

  string cmdLine;
#ifndef WIN32
  for (int i = 1; i < argc; ++i) {
    char *option = argv;
#if !defined(NO_FMOD) && defined(linux)
    /*
     * The sound_output switch allows users to switch the sound system used.
     * Possible values are ALSA, OSS, ESD. musicsoundst.initsound cannot be called
     * before this point or this will have no effect.
     */
    if (strcmp(option, "-sound_output") == 0) {
      if (++i >= argc) {
   std::cerr << "sound_output switch given, but no sound system specified. Default is ALSA.\n";
   continue; // Break out of the for loop.
      }
      char *argument = argv;
      if (strcmp(argument, "ALSA") == 0) {
   musicsound.set_sound_system(musicsoundst::ALSA);
      } else if (strcmp(argument, "OSS") == 0) {
   musicsound.set_sound_system(musicsoundst::OSS);
      } else if (strcmp(argument, "ESD") == 0) {
   musicsound.set_sound_system(musicsoundst::ESD);
      }
      continue;
    }
#endif
    cmdLine += option;
    cmdLine += " ";
  }
#endif

As you can see I completely disabled argument handling, it was a quick and dirty hack.

I decided to eliminate the use of GLU32.dll by commenting out the LookAt and Perspective lines (they never seemed to be used), and replacing the gluOrtho2d with a glOrtho.  This completely elimnated the usage of that extension library.

I will be putting in my normal optimisation set next and posting some results.

[darksaiyan]

I doubt DF is going to become Open Source. Toady lives on our donations and is working full time on his game. I don't want it Open Source either. Besides, the game is going to become so moddable that anyone with a piece of mind would be able to get into the raws and do something of their own.

[bhelyer]

I got this compiled on my system.  I had to use the NO_FMOD define to disable that code as the .lib you supplied didn't make sense to my compiler.  I wasn't about to spend time playing around with hunting down a current version of that library.

One very odd thing I had to do to make my compiler happy was to adjust the definition of "main" in enabler_sdl.cpp.

Spoiler (click to show/hide)

#ifdef WIN32
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
 LPSTR lpCmdLine, int iCmdShow) {
#else
int main (int argc, char* argv[]) {
#endif
#if !defined(__APPLE__) && defined(unix)
  gtk_init(&argc, &argv);
#endif
  keyMap();
   
  // Initialise all SDL subsystems.
  int retval = SDL_Init(SDL_INIT_EVERYTHING);
  // Report failure.
  if (retval != 0) {
    report_error("SDL initialization failure", SDL_GetError());
    return false;
  }

  string cmdLine;
#ifndef WIN32
  for (int i = 1; i < argc; ++i) {
    char *option = argv;
#if !defined(NO_FMOD) && defined(linux)
    /*
     * The sound_output switch allows users to switch the sound system used.
     * Possible values are ALSA, OSS, ESD. musicsoundst.initsound cannot be called
     * before this point or this will have no effect.
     */
    if (strcmp(option, "-sound_output") == 0) {
      if (++i >= argc) {
   std::cerr << "sound_output switch given, but no sound system specified. Default is ALSA.\n";
   continue; // Break out of the for loop.
      }
      char *argument = argv;
      if (strcmp(argument, "ALSA") == 0) {
   musicsound.set_sound_system(musicsoundst::ALSA);
      } else if (strcmp(argument, "OSS") == 0) {
   musicsound.set_sound_system(musicsoundst::OSS);
      } else if (strcmp(argument, "ESD") == 0) {
   musicsound.set_sound_system(musicsoundst::ESD);
      }
      continue;
    }
#endif
    cmdLine += option;
    cmdLine += " ";
  }
#endif

As you can see I completely disabled argument handling, it was a quick and dirty hack.

I decided to eliminate the use of GLU32.dll by commenting out the LookAt and Perspective lines (they never seemed to be used), and replacing the gluOrtho2d with a glOrtho.  This completely elimnated the usage of that extension library.

I will be putting in my normal optimisation set next and posting some results.

There's a windows SDLmain library you're supposed link against that modifies the main for you.

[Veroule]

Well it looks like I did something wrong since it doesn't play at all after I start play.  I will see if I can find some time to play with tommorrow.  I would like to post a working exe for all those that couldn't test due whatever build issue Baughn had.

I will take a look at that SDL_main.h.  I hadn't examined it yet, since digging through things is always done after they don't work right.

The only result I can post so far is
10000+FPS at the main and intial play screens
with init settings of
G_FPS at 20
MOUSE:NO
WINDOWED:YES
sizes all default

System specs (laughable and ancient)
1GHz Athalon
324MB Ram
Radeon7200 32MB onboard AGP2x
Windows XP SP2

[Razordw]

Everything appears to run fine with the new BC and the original, which is great since it alleviated my only concern of not being able to run DF if this is implemented (6 year old computer and all). For my computer though it doesn't appear any faster compared to the original with the same tileset, graphics, init and whether partial printing is on or off (Setup: GFPS is set to 25, Windowed, 80x50 tiles in a 1280x960 window). So I'm guessing my old graphics card is either running great already or it's just not running properly at all.

Specs and brief Results (for the curious):

Spoiler (click to show/hide)

Specs:
AMD Atholon XP 2200+ (1.8GHz)
 Nvidia GeForce 4 TI 4600 with 128MB VRAM
1GB of RAM
 Windows XP

Results:
Quick tally of my testing results. FPS Cap set to 10k
Menu screens: New - 10K. Original - 2k
During low troop battles I've seen the original spike above 2k temporary then return (not sure whats up with that).
Battles involving around 11-12k (4 Sasquatch lead armies) of troops ~3k opposing(Barbarian) the FPS hang around 500 with Partial Print Off and On.

My approximation on the Opposing army is just based on what I've seen armies of mine lead by Barbians tend to average out to (which was between 3k-3.5k).

[savanik]

Okay, poked around a lot with various things:

Changing font, window size, etc: No problems.

[WINDOWED:PROMPT] selecting Windowed mode works perfectly. Selecting Fullscreen flicks screen black for a second and then makes it a window with distorted fonts due to fullscreen settings.

[WINDOWED:YES] flicks to fullscreen black for a second and then switches to windowed mode with fullscreen resolution.

[WINDOWED:NO] flicks to fullscreen black for a second and then switches to windowed mode with fullscreen resolution!!

[GRAPHICS:YES] Segfaults, regardless of other settings.

Spoiler (click to show/hide)

E: shm.c: shm_open() failed: Read-only file system
E: shm.c: shm_open() failed: Read-only file system
E: shm.c: shm_open() failed: Read-only file system
E: shm.c: shm_open() failed: Read-only file system
Asked to clone nonexistent texture!
Using OpenGL output path with client-side arrays
Segmentation fault

Just to clarify - the 'most current' file is the one currently on the first page, correct? Because that's the one I've been re-downloading and using every time I run things.

Savanik