Forum archive

ydimgame fuckups

Return to forum index

• Kyoufu Kawa at 2005-08-15 02:41
  I have no idea where this came from, but for some reason the ydimgame value in my Unkillable project is all wonky. The startup resolution-choosing window is too, defaulting to blank if not 640x400.
  
  From the startup log:
  

  WARNING: About to call LoadSetup(). By now, ydimgame = 400 (default)
  
  LoadSetup: ydimgame = 480
  
  WARNING: Returned from LoadSetup(). By now, ydimgame = 0 (omgwtfbbq)
  
  Startup: Initialising engine...
  
  Initialising Windows DirectX/GDI system interface
  
  Loading OPENGL32.DLL
  
  Initialising DirectDraw...
  
    - Loading DDRAW.DLL
  
    - Enumerating display devices
  
      * Primair beeldschermstuurprogramma
  
    - Creating DirectDraw object
  
  Detecting video modes:
  
    - 640x480 8-bit fullscreen
  
    - 480x360 8-bit fullscreen
  
    - 512x384 8-bit fullscreen
  
    - 640x400 8-bit fullscreen
  
    - 320x200 8-bit fullscreen
  
  ...
  
    - 320x240 32-bit windowed
  
    - 320x200 32-bit windowed
  
  WARNING: About to call DoLaunchWindow(). By now, ydimgame = still 0
  
  Startup: ydimgame fuckup. Assuming 400.
  
  PopulateVideoModeLists: by now, ydimgame = 400
  
  <<< At this point, I choose to cancel >>>
  
  Uninitialising DirectDraw...
  
    - Releasing DirectDraw object
  
    - Unloading DDRAW.DLL

  
  
  Relevant lines in game.cfg:
  

  fullscreen = 0
  
  xdim3d = 640
  
  ydim3d = 480
  
  bpp = 8

  
  
  From game.c:
  

  long xdimgame = 640, ydimgame = 400, bppgame = 8, xdim2d = 640, ydim2d = 480;   // JBF 20050318: config.c expects to find these

  
  
  Note how ydimgame is indeed 400 at the start, LoadSetup reads it as 480, so far so good, then it goes bad. Didn't even touch the damn thing aside from adding these debug PrintFs and two extra values for the player's name and pants, which by the way works fine. Any ideas?
• JonoF at 2005-08-15 08:32
  Step 1: delete all object files and remake them afresh. See if that fixes it. If not, proceed to step 2.
  Step 2: use a debugger to put a watchpoint on ydimgame and single-step through your startup code from a point where you know ydimgame is ok, and watch for when it changes.
  
  These sorts of silly behaviours are often caused by certain pieces of the project being built on different revisions of certain interfaces, which causes memory offsets to change. This happens when dependencies in makefiles aren't properly constructed. It also happens when you overrun an array or pointer and start writing into other parts of memory. Just two fun reasons why C can be a bitch sometimes and a legend most others.
  
  Jonathon
• Kyoufu Kawa at 2005-08-17 03:22
  Well, I have OSD_Printf() scattered all around, I guess I could increase their numbers a bit more, and I've completely rebuilt the game on many an occassion, but thanks for the hints anyway.
  
  And then there's the matter of the mysterious "shot through the player" bug... should I waste a new thread on that?