DieHard Wolfers

[Tricob]

It might be that the SDL version requires a certain amount of video RAM. Maybe the guy's Win98 SE system doesn't have the video RAM required, so it's Copying and Pasting from a non-existent page, thus the blank screen which is described.

Can his system properly run the Freeware game "OMG Kitty"? I know for a fact this game requires a fair amount of video RAM, too.

[Andy_Nonymous]

@AlumiuN: I'll check out that Fraps thing, hope it works.

@Tricob: I'll pass your comments on. Thanks!

@Ripper: Some digi-sound issues:

Currently, the multiple digitized sounds alllow a peculiar situation: if you kill a guard quickly enough as he's saying "achtung", his death scream will overlap his greeting. It would be good to stop his greeting when the death scream starts, without silencing any other sounds.

Another quirk occurs if you convert some adlib sounds to digitized. For instance, on ammo dropped by killed actors, several can drop on a single tile (or very close anyway), and when you go to pick them up, the sound is played at a much higher volume due to the simultaneous playing of all the individual sounds. This also occurs on a digitized bonus sound, for instance when you do the Tab-I and simultaneously trip multiple GiveExtraMan bonuses.

On a rare occasion, a pair of enemies will greet you simultaneously and it will add up to a louder volume single sound rather than sound like 2 separate voices.

Andy

[Ripper]

Quote:

Wolf4SDL v1.5 (released 2008-05-25, revision 215)
- Reduced minimum distance to back of moving pushwall to PLAYERSIZE
- Fixed pushwall rendering when player's eye is in the pushwall back tile (bug reported by Pickle)
- Enable 'End game' menu item also when using --tedlevel
- Removed some unneccessary fade outs (DrawPlayScreen does not call VW_FadeOut anymore!!)
- When using 'End game', 'View scores' does not directly show up anymore
- Fixed quickload/quicksave not working when started with --tedlevel (vanilla bug). This now also only checks for save games once at startup (may speed up entering the menu on Dreamcast)
- Fixed drawing moving pushwalls viewed at acute angles near the level border
- Fixed vanilla bug hiding bonus items on same tile as player, when he cannot pick them up (e.g. medikit at 100% health) (thanks to Pickle for noticing)
- Added GP2X specific code by Pickle
- Reimplemented picture grabber to support all screen resolutions (<TAB>+P in debug mode)
- Added --resf option to force to use unsupported resolutions >= 320x200
- Added support for resolutions being a multiple of 320x240 (thanks for your help, Pickle!)
- Fixed crash when cheat-hurting oneself to death (bug reported by Tricob)
- Cleaned up id_sd.cpp (kept PC speaker stuff for future reference)
- Added move buttons (invalidates config file, only hardcoded yet)
- Added joystick support to US_LineInput used for highscore names and save games
- Added US_Printf and US_CPrintf (works just like printf)
- Fixed wrong surface locks/unlocks
- Added Visual C++ 6 support
- Removed some useless VW_WaitVBLs (Thanks to TexZK)
- Added some asserts in id_vl.cpp to check for screen access out of bounds
- Fixed BJ face popping up in fullsize mode sometimes (Thanks to Andy_Nonymous)
- Rewrote page manager to support pages >= 64kB and to correctly handle sounds >= 4kB
- Improved SOD mission packs support (Thanks to fackue)
- Updated Code::Blocks search paths to ..\SDL-devel\
- Added version.h to Dev-C++ and Code::Blocks project file
- Fixed some files being read in text mode on MinGW

Btw, I told Andy to suggest the --windowed parameter. Perhaps that helps to find the cause of the problems.

@All: Thanks for all the feedback! Without you a version 1.5 wouldn't exist

Time for bed The birds are already awake

[dcbasic]

Dreamcast version is here.

Thanks Ripper!

[TexZK]

Knock knock! My brain suggests me to download it immediately


@ Ripper: with VS2005 I still get "deprecated function" warnings, even if I've seen you've defined _CRT_SECURE_NO_DEPRECATE. I know they're just warnings, but it's annoying to filter all output results when rebuilding the project, just to find the right warnings/errors... Can you please add them in project configurations by default?

[Ripper]

Hm, I am getting only one warning related to a signed/unsigned comparison with VS2005 (I'll fix that, I don't like warnings, too ). Are you sure, you use the current Wolf4SDL.vcproj file? It should contain _CRT_NONSTDC_NO_WARNINGS;_CRT_SECURE_NO_WARNINGS under "Preprocessor Definitions".

Btw, what is the meaning of your signature? I didn't find any esoteric programming language which would fit

[Tricob]

Thanks for the update, Ripper. This is one update I look forward to checking out.

[TexZK]

Ripper wrote:

Are you sure, you use the current Wolf4SDL.vcproj file? It should contain _CRT_NONSTDC_NO_WARNINGS;_CRT_SECURE_NO_WARNINGS under "Preprocessor Definitions".

Strage, I've unzipped the source code in a new folder and compiled it as it is, and I still got all that bunch of STD warnings...
Is it better "_CRT_NONSTDC_NO_WARNINGS;_CRT_SECURE_NO_WARNINGS" or "_CRT_SECURE_NO_DEPRECATE"??? I've always used the latter, even if it still gives me some errors with "strdup()" (strangely, "_strdup()" too!).
As for type comparisons, in the old v1.4 I've added type casting by hand, because it's more portable and its behavior is always known.

The new version looks very very fast compared to the old v1.4, which already worked ok. I haven't tested it yet, but it looks like its fps count has increased!!!
Under Linux (I'm using Ubuntu 8.04) it feels waay better even if Compiz is running, but sometimes fps in fullscreen mode still drop, even when compiled specifically for my AMD64 processor (in the Makefile I've added "-O2" and "-march=athlon64" to "CFLAGS"). Anyway, I remember v1.4 was much slower when in fullscreen mode, so this version is an excellent step to the perfection!

Just a note: it would be better if the mouse is made smoother. I've tried by changing the "ANGLES" constant to 3600 instead of 360, and then adjusting some constants in the source (mouse multiplier and camera rotation on victory tile); with joystick/pad and under Spear I don't know because I don't own them. Movements feel waaay more accurate this way! I think this must be changed, since imho there's no need to keep it at only 360 units...

Ripper wrote:

Btw, what is the meaning of your signature? I didn't find any esoteric programming language which would fit

That's an useless geek code...

[Ripper]

Which version of VS2005 are you using and on which operating system? Today I found out, that VS2008 actually has 8 different C++ compilers among the different versions!
You didn't tell me, whether the defines I mentioned were defined.

The speed improvements should be thanks to you, as I removed some useless delays. Today on a laptop of a friend, I found out, that there is a big speed problem when you have a stricter scheduler (like on FreeBSD): I still have one place, where I do busy waiting (yes, I know, shame on me). Obviously I waits long enough, that the scheduler marks Wolf4SDL as a non-interactive process and reduces its priority. If you have e.g. a Firefox running in the background (even on another desktop), animating its stupid logo becomes more important for the scheduler than running the game
So this is definately something I need to get rid of. Perhaps along the lines, I will be able to improve the demo playback...
Which framerate do you get now and which processor do you have? The maximum framerate is 70 fps.

Just yesterday I thought, it would be nice to have finer turning! Could you send me a patch with the changes you made? I'd like to have a look at whether I can integrate it into Wolf4SDL.

[Tricob]

Ripper - Awesome to see this game in 640x480 ... with a statusbar intact! In hi-res of all things, too!

One thing - does anyone know how to change the default resolution from 640x400 to 640x480? Thanks.

[TexZK]

Ripper wrote:

Which version of VS2005 are you using and on which operating system? Today I found out, that VS2008 actually has 8 different C++ compilers among the different versions!
You didn't tell me, whether the defines I mentioned were defined.

Really??? I'm going to download VS2008 from my University repository, then I'll let you know. As for now, I'm using "Microsoft Visual C++ 2005 Enterprise Edition 8.0.50727.42" (info from the About box).
The definitions are there in the project configuration section, but it looks like my VS2005 doesn't care about "*_NO_WARNINGS", and continues suggesting me to use "_CRT_SECURE_NO_DEPRECATE" in the output window. I know I shouldn't care about warnings so much, but it's really annoying when scrolling down to find the errors... and I think with "*_NO_DEPRECATE" it's more secure, as it redefines automatically all the standard functions with the right ISO name (with an underscore before the function name).

Ripper wrote:

The speed improvements should be thanks to you, as I removed some useless delays. Today on a laptop of a friend, I found out, that there is a big speed problem when you have a stricter scheduler (like on FreeBSD): I still have one place, where I do busy waiting (yes, I know, shame on me). Obviously I waits long enough, that the scheduler marks Wolf4SDL as a non-interactive process and reduces its priority. If you have e.g. a Firefox running in the background (even on another desktop), animating its stupid logo becomes more important for the scheduler than running the game
So this is definately something I need to get rid of. Perhaps along the lines, I will be able to improve the demo playback...
Which framerate do you get now and which processor do you have? The maximum framerate is 70 fps.

Not only by me, because my "hack" works only when the screen is flashing. The game is REALLY more responsive: under WinXP it feels like walking on silk Anyway, under Linux (Ubuntu 8.04) there are still some small issues, despite they got infinately better with v1.5 over v1.4 (which was on Ubuntu 7.10). The FPS counter is at its maximum for most of the time, even if sometimes it drops about a few frames. I haven't used a classic "1000/(new_time-old_time)" fps counter on v1.5, I've tried by writing the counter on the title bar but it slows down. I'll hack the graphical counter a bit to keep it fast.
It looks like problems are related to the OS-SDL interaction, since you say FreeBSD makes it sleep because of its strict scheduler... even if a videogame should "keep it up" by its continuous activity.

Ripper wrote:

Just yesterday I thought, it would be nice to have finer turning! Could you send me a patch with the changes you made? I'd like to have a look at whether I can integrate it into Wolf4SDL.

I thought I published that tutorial, but I realized it's not on the forum... I may have written it on a TXT and then deleted it
I'll make it again for v1.5 while writing the tutorial, so I'll be sure the tutorial works! It's nothing difficult anyway, just a bunch of "magic numbers" redefinitions...

[TexZK]

Ok, I've just done the following changes in v1.5 to make the mouse movements smoother.


WL_DEF.H

from:

::: CODE :::

#define ANGLES          360             // must be divisable by 4

to:

::: CODE :::

#define ANGLES          3600            // must be divisable by 4

================================================================

WL_DRAW.CPP

from:

::: CODE :::

    if (ob->obclass == rocketobj || ob->obclass == hrocketobj)
        angle = (viewangle-180) - ob->angle;
    else
        angle = (viewangle-180) - dirangle[ob->dir];

to:

::: CODE :::

    if (ob->obclass == rocketobj || ob->obclass == hrocketobj)
        angle = (viewangle-VANG180) - ob->angle;
    else
        angle = (viewangle-VANG180) - dirangle[ob->dir];

Not needed, but suggested:
please change all "magic numbers" in AsmRefresh() to their ANG* values, for flexibility.

================================================================

WL_AGENT.CPP

from:

::: CODE :::

#define MOVESCALE       150l
#define BACKMOVESCALE   100l
#define ANGLESCALE      20

to:

::: CODE :::

#define MOVESCALE       150l
#define BACKMOVESCALE   100l
#define ANGLESCALE      ((20*360)/ANGLES)

--------------------------------

from:

::: CODE :::

    player->state = &s_player;
    player->angle = (1-dir)*90;
    if (player->angle<0)
        player->angle += ANGLES;

to:

::: CODE :::

    player->state = &s_player;
    player->angle = (1-dir)*VANG90;
    if (player->angle<0)
        player->angle += ANGLES;

--------------------------------

from:

::: CODE :::

void VictorySpin (void)
{
    int32_t    desty;

    if (player->angle > 270)
    {
        player->angle -= (short)(tics * 3);
        if (player->angle < 270)
            player->angle = 270;
    }
    else if (player->angle < 270)
    {
        player->angle += (short)(tics * 3);
        if (player->angle > 270)
            player->angle = 270;
    }

    desty = (((int32_t)player->tiley-5)<<TILESHIFT)-0x3000;

    if (player->y > desty)
    {
        player->y -= tics*4096;
        if (player->y < desty)
            player->y = desty;
    }
}

to:

::: CODE :::

void VictorySpin (void)
{
    int32_t    desty;

    if (player->angle > VANG270)
    {
        player->angle -= (short)(tics * ((3 * ANGLES)/360));
        if (player->angle < VANG270)
            player->angle = VANG270;
    }
    else if (player->angle < VANG270)
    {
        player->angle += (short)(tics * ((3 * ANGLES)/360));
        if (player->angle > VANG270)
            player->angle = VANG270;
    }

    desty = (((int32_t)player->tiley-5)<<TILESHIFT)-0x3000;

    if (player->y > desty)
    {
        player->y -= tics*4096;
        if (player->y < desty)
            player->y = desty;
    }
}

================================================================

WL_GAME.CPP (updated)

from:

::: CODE :::

#define DEATHROTATE 2

to:

::: CODE :::

#define DEATHROTATE ((2*ANGLES)/360)

[Tricob]

TexZK, what are side effects of this code related to keyboard movement?

BTW, I figured out what the deal was with the saved games in my Wolf4SDL code. I'd tinkered around with ID_PM and ID_SD. Replacing them with the source code files of Wolf4SDL v1.4 should fix the problem. I'm starting over with the v1.5 source, though.

[TexZK]

Tricob wrote:

TexZK, what are side effects of this code related to keyboard movement?

There are no side effects on the keyboard at all, since all multiplications are based on the pre-defined ANGLES constant.
What might be fixed are joystick movements, since I own a Logitech WingMan and a cheap gameport helmet which don't want to work with XP, so I can't test it at the moment.

Edit: I've been able to install my gamepad and works ok.

[Tricob]

Tricob wrote:

BTW, I figured out what the deal was with the saved games in my Wolf4SDL code. I'd tinkered around with ID_PM and ID_SD. Replacing them with the source code files of Wolf4SDL v1.4 should fix the problem.

Except that it doesn't. It doesn't matter anymore though, as my re-patching of the code in Wolf4SDL 1.5 is about half complete already.

[TexZK]

Updated the DEATHROTATE constant, which I forgot to change in the player->angle patch.

I've also noticed that moving the mouse faster won't make the player rotate fast too, but I don't understand where the issue is in the source code (also in vanilla 1.5, without my patch). It looks like the SDL_WarpMouse() isn't all that good; isn't it better to retreive the mouse movements from processEvent()?



Another small issue: when dragging the game window, the tick counter still works, so if you for example keep the window dragging for 10 seconds, the game will go ahead by, say, "10*BASETICKS".

Just for your interest:
With my Wolf3D-like game engine I'm doing it this way, and works perfectly:

::: CODE :::

   // Application loop
   while ( True ) {
      static TInt32   curTicks, pollTicks, oldTicks = SDL_GetTicks() - 1;
      static TFloat   timeStep = 0.0f;
      static TChar   title[ 256 ];
      
      // Poll incoming events
      pollTicks = SDL_GetTicks();
      while ( SDL_PollEvent( &incomingEvent ) > 0 ) {
         ProcessEvent( &incomingEvent );
      }
      pollTicks = SDL_GetTicks() - pollTicks;
      
      // (Processes the whole applicaton here)
      
      // Write the FPS counter on the title bar
      curTicks = SDL_GetTicks();
      timeStep = (TFloat)( curTicks - oldTicks - pollTicks ) * 0.001f;
      l_fTimeStep = timeStep;
      sprintf( title, "Fenrir - %.2f fps", 1.0f / timeStep );
      oldTicks = curTicks;
      SDL_WM_SetCaption( title, NULL );
      
      // Start rendering objects
      StartRendering( True );
      
      // (Draws everything here)
      
      // Finish rendering objects and update the screen
      FinishRendering();
      
      // Let the OS preempt this process
      SDL_Delay( 1 );
   }

[Ripper]

TexZK wrote:

It looks like problems are related to the OS-SDL interaction, since you say FreeBSD makes it sleep because of its strict scheduler... even if a videogame should "keep it up" by its continuous activity.

Interactive processes wake up, do a small task and go back to sleep again. Non-interactive processes do e.g. heavy calculations without ever thinking of voluntarily yielding the CPU. So when the scheduler is set to timeslices of 1 ms and Wolf4SDL does busy-waiting for 13 ms, it's just non-interactive
Thanks for the code, I hope to have time for looking into it soon.

@Tricob: You are applying the Wolf4SDL changes manually?!? There really are better ways to do that with the Linux or Cygwin tools diff and patch (you can also use "svn diff"). Basically you would get the changes from Wolf4SDL v1.4 to v1.5 and apply these as a patch to a backup of your current project which already used Wolf4SDL v1.4. After that there shouldn't be too much left needing manual attention.

[AlumiuN]

One question, slightly OT: I think Dev-C++ has a version updater like SVN in it somewhere. Would it still work with the WolfSDL repository?

[Tricob]

Ripper wrote:

Basically you would get the changes from Wolf4SDL v1.4 to v1.5 and apply these as a patch to a backup of your current project which already used Wolf4SDL v1.4. After that there shouldn't be too much left needing manual attention.

Well, I goofed up the saved games source code somehow, and it's easier and less time-consuming to restart the code with v1.5 then to try and track down the problem bit by bit. I'll admit there were a lot of areas I messed around with in the v1.4 code that I should've just left alone.

[Tricob]

I unveiled another demo-related bug in Wolf4SDL (I seem to specialize in finding such things). In a 640x480 resolution, when BJ is killed in Demo Mode, the statusbar still remains below when the title screen and other such things are still displayed. Here's how to fix the problem.

In WL_MAIN.CPP, search for:

::: CODE :::

#ifndef DEMOTEST
#ifdef SPEAR
            SDL_Color pal[256];
            CA_CacheGrChunk (TITLEPALETTE);
            VL_ConvertPalette(grsegs[TITLEPALETTE], pal, 256);

Change it to look like this:

::: CODE :::

#ifndef DEMOTEST
    if(screenHeight % 200 != 0)
        VL_ClearScreen(0);
#ifdef SPEAR
            SDL_Color pal[256];
            CA_CacheGrChunk (TITLEPALETTE);
            VL_ConvertPalette(grsegs[TITLEPALETTE], pal, 256);