Resolved Issues for Legend of Tux

From LD Smith Games Wiki
Jump to navigation Jump to search
  • Enemies get "stuck" at the open space to the previous room Fixed!
  • Blue orbs are invisible on Linux Fixed! The img_orb array should have had a size of 4 instead of 3 (no_orb.bmp, red_orb.bmp, green_orb.bmp, blue_orb.bmp)


  • The first time after downloading the zip from the website, extracting, and running, the program exited after the title screen. Subsequent attempts have not had the problem
    • Seems to have been an isolated case... I haven't seen this problem again, so it may have been related to the memory leak or other problems that I fixed
  • Need unique enemies for each stage
    • Astro - aliens
    • Bolt - sparks
    • Desert - Cacti
    • Flame - Devils
    • Frost - Snowmen (the current default enemy for all levels) "SNOWMOBS"
    • Jungle - Iguanas
    • Stone - Golems
    • Mech - Robots
  • Just noticed that it is possible to walk through horizontal moving snowmen, if the snowman moves through the middle of your body. The collision algorithm doesn't detect when a smaller object moves through a larger object, without intersecting any of the bounding box vertices.
    • Fixed in version 0.6
  • Need unique background music for each stage
    • Added in version 0.6
  • Add sound effects
    • Sword Swing
    • Enemy killed
    • Level select: selected level changed, invalid level selected
    • Orb pickup
    • Player hit
    • Boomerang
    • Sword swing, orb pickup, and enemy killed sounds added in version 0.6
  • Tried running Legend of Tux on a Windows XP system, but the game screen ran slowly; The Task Manager reported 98 to 99% CPU usage. Maybe the problem is because I compiled under Vista, but my Vista is running 32 bit. On the other hand, there was barely any loading time to get to the title screen; On my Windows Vista machine, the CPU usage was about 50% on the title screen, and varied between 18% to 27% on the game loop screens; Increasing the TICK_INTERVAL from 33 to 100 reduced the CPU usage on the game loop screen to between 6% and 11%, however it was only running at 10 FPS; I also found that I was missing SDL_Delay statements in my Title screen and Level Select screen; Adding delays in those loops seemed to bring the overall CPU usage down to the 20-30% range on the Vista machine.

Removed the drawBlocks code, and reran on the Windows XP system, and it was still running at around 13 fps. I thought that the multiple block blits may have been slowing things down, since the framerate appears to go down in rooms with many blocks

Adding SDL_RLEACCEL to the createImage code on SDL_SetColorKey helped reduce the CPU usage on my main development machine from 20-30% down to 5%-10%, so I'm thinking this will help resolve the frame rate issue on my Windows XP machine. However, it causes the room to not scroll anymore when the player transitions form one room to the next... there is just a long pause, then the game speeds up for a few seconds and returns to normal

Tried the new build on the Windows XP machine, but it still runs around 19 FPS using 99% of the CPU. I was a little frusterated since other SDL games run at 40+ FPS, but I learned that those games are using OpenGL to render frames, even though they are 2D based. After some reasearch, I learned that graphics processing will only be delegated to the graphics card if the screen is rendered using OpenGL. That could be the reason why the build runs so slowly on that machine, which has a decent graphics card (6600GT I believe), but the CPU is quite old.

I guess I need to make a decision whether to continue to develop using the standard SDL libraries and ignore support for older machines, or reimplement the rendering code to use OpenGL so that the program will run on older machines with graphics cards

Spent a few hours still trying to improve the framerate on the Windows XP system. I ended up basically disabling all images, fonts, event handlers, etc. However, I couldn't get the frame rate above 24 FPS at 1024x768 resolution. I decreased the resolution, and got the frame rate up to around 40 FPS for 800x600, and 60 FPS for 640x480. I would really hate to have to make the program run at such a low resolution, but I've noticed other SDL applications (non-OpenGL) running at 800x600.

Spent some time trying out and looking at the source code for other other non-OpenGL games on SourceForge; From the three I tried, they all ran a 640x480 resolution. So maybe there just isn't any way to get an SDL app to run at 60 FPS at 1024x768 resolution on a 1.5 GHz (single CPU)

I guess it makes sense (assuming that I'm drawing the entire screen each frame, and not just updating "dirty" rectangles):

  • 640x480 = 0.31 million pixels to draw to the screen
  • 800x600 = 0.48 million pixels
  • 1024x768 = 1.33 million pixels

So there is more than 4 times as many pixels that must be drawn to the screen

Working on adding a low-resolution (640x480) in addition to the standard resolution (1024x768), so that older machines can play a less CPU intensive version of the game.

  • Convert BMP files to PNG and add the SDL image library code to read PNG files, so that the amount of disk space used to store images is reduced