All posts by Matthias

Surfaces and Textures

Last updated on August 8th, 2018

This chapter treats some basics you should know to understand the way SDL2 works.

Briefly: The Basics of Graphics Programming

Loading and the movement of images in a game (or other applications) is a major concept in (game) programming. These images are then refered to as sprites, usually. Let’s have a look at a simple example:

left: ball and paddle erased between each frame; right: ball and paddle not erased between frames
Left: Window is cleared between each new drawn frame. Right: Window is not cleared.

Here are two screenshots from a simple game. The player has to move the yellow-green paddle up- and downwards to prevent the blue ball from getting through to the right side. The game uses two sprites, the blue ball sprite and the yellow-green paddle sprite (see left screenshot). The background color is set to black. The left screenshot is how the game usually appears to the player, here between each frame that got drawn, the former frame has been cleared. The right screenshot demonstrates what happens if the former frame hasn’t been erased before the next one is drawn. – Now it is clearly visible that the sprites are redrawn again and again with sligthly different coordinates, and that is how (game) graphics work (even for the most sophisticated 3d games):

  1. Draw the frame
  2. Show the frame (in a window on screen)
  3. Clear the frame (and go back to step 1)

Briefly: The Relation between Graphic Objects (e.g. Sprites) and Hardware

Actually there are just three locations where these images are stored in your computer system. All images (photo images, drawings, sprites for 2d games, textures for 3d games) are stored on your harddrive somewhere. If you start a photo viewer, a paint program, a 2d game or a 3d game, in all cases the corresponding images need to be loaded from your harddrive to RAM (Random-Access Memory) since displaying and manipulation (e.g. rotation of a photo image by 90°) of images loaded to RAM is much, much faster. Especially for games a fast access to the image data is highly important! And finally there isn’t just one RAM but two, a CPU controlled one located on the motherboard used by every program/application that needs some RAM. The second RAM is located right at your graphic board and controlled by the so-called GPU (graphics processing unit). This is what we want to use if we develop games since it is dedicated, optimized and just hungry for tasks related to fast image processing.

Many games and applications do not only target at common computer systems, but for mobile devices, e.g. smart phones. The principles described are also true for these devices even though there may be differences in detail.

The SDL2 Surface

The SDL2 surface allows you to represent graphic objects like sprites. Every SDL2 surface has a width and height, a pixel format and other properties. Nevertheless, it is a concept which originates from the outdated SDL 1.2 and therefore should not be used anymore. Still, there are reasons why we need to introduce it here. This will be clear soon.

The SDL2 Texture

The SDL2 texture allows you to represent graphic objects just like the SDL2 surface does, although there is a major difference: It is hardware accalerated. So the graphic object is stored in the graphic board’s RAM and any manipulation is done by the graphic board’s GPU.

So as a rule,

always use SDL2 Textures to store your graphic objects (sprites) for SDL 2.0,

then you go for high performance!

Three ways to SDL_Texture

So, how to get a SDL_Texture? In principle there are three ways to create SDL2 textures. For way 2 and 3 the flow diagram may illustrate how it works.

Way 1: From Scratch

You create a SDL_Texture from scratch, so you set a pixel format and texture access format and have to fill in your texture data manually. This is the most sophisticated way and is usually not necessary, unless you work with raw pixel data.

Way 2: The path from the file to the surface, to the texture and to the screen. Way 3: The path rom the file to the texture and to the screen.

Way 2: From SDL2 Surface

2) You have or create a SDL_Surface from an image file first and then you create the SDL_Texture from the SDL_Surface. This way is shown in the diagram but it means two steps.

Way 3: Directly from Image File

3) You create a SDL_Texture from and image file directly. This is shown in the diagram, too. This is the simplest way to create a SDL_Texture.

← previous Chapter | next Chapter →

Window and Renderer

Last updated on November 20th, 2021

Every SDL2 program that shall show some graphic output has to have at least one SDL2 window and a SDL2 renderer. The window is the entity that is showing the graphic output and the renderer is the “machine” that is generating the output to be shown in the window. The code to set up a window and a renderer is as follows.

program SDL_WindowAndRenderer;

uses SDL2;

var
  sdlWindow1: PSDL_Window;
  sdlRenderer: PSDL_Renderer;

begin

  //initilization of video subsystem
  if SDL_Init(SDL_INIT_VIDEO) < 0 then Halt;

  // full set up
  sdlWindow1 := SDL_CreateWindow('Window1', 50, 50, 500, 500, SDL_WINDOW_SHOWN);
  if sdlWindow1 = nil then Halt;

  sdlRenderer := SDL_CreateRenderer(sdlWindow1, -1, 0);
  if sdlRenderer = nil then Halt;

  // quick set up
  {
  if SDL_CreateWindowAndRenderer(500, 500, SDL_WINDOW_SHOWN, @sdlWindow1, @sdlRenderer) <> 0
    then Halt;
  }

  // render to window for 2 seconds
  SDL_RenderPresent(sdlRenderer);
  SDL_Delay(2000);

  // clear memory
  SDL_DestroyRenderer(sdlRenderer);
  SDL_DestroyWindow (sdlWindow1);

  //closing SDL2
  SDL_Quit;

end.  

Let’s have closer look at the var clause.

var
  sdlWindow1: PSDL_Window;
  sdlRenderer: PSDL_Renderer;

The SDL2 Window

In SDL 2.0 you can create as many windows as you like, and each window is adressed by its PSDL_Window variable. We just need one window for now, let’s call it “sdlWindow1”. It defines the window’s properties, e.g. size, appearance, border, title name and so on. And it holds the content it shows.

Creation of a Window

  // full set up
  sdlWindow1 := SDL_CreateWindow('Window1', 50, 50, 500, 500, SDL_WINDOW_SHOWN);
  if sdlWindow1 = nil then Halt;

The creation of a SDL2 window is simple as using the function SDL_CreateWindow(title, x, y, width, height, flags) or more specific:

SDL_CreateWindow(const title: PAnsiChar; x: SInt32; y: SInt32; w: SInt32; h: SInt32; flags: UInt32): PSDL_Window

In our example the window is titled “Window1”, it is located at position x = 50 and y = 50 pixels (relative to your screen). It has a width and height of 500 pixels respecitvly. And we have used the flag SDL_WINDOW_SHOWN. More about these flags later. First let’s get an understanding of the coordinate system in SDL2.

The Coordinate System in SDL 2.0

This rule applies:

The origin from where to count to place a window is always the left upper corner of your screen.

So if you choose (0/0) as coordinates the window’s left upper corner will be placed right at the left upper corner of your screen. The diagram below may help to understand this. You may try SDL_WINDOWPOS_CENTERED for each or both coordinates which will lead to a centered window with respect of the screen. If you choose SDL_WINDOWPOS_UNDEFINED you don’t care for the window’s position.

SDL2 window and coordinates diagram
Creative Commons License This image by https://www.freepascal-meets-sdl.net is licensed under a Creative Commons Attribution 4.0 International License.
The window is placed with respect to the left upper corner of the screen.

SDL 2.0 windows and their properties

Now let’s talk about the flags. They decide for the properties of the window. Look at the following table (source) of possible flags and you may get an idea what they do.

Flag
Description
SDL_WINDOW_FULLSCREENfullscreen window
SDL_WINDOW_FULLSCREEN_DESKTOPfullscreen window at the current desktop resolution
SDL_WINDOW_OPENGLwindow usable with OpenGL context
SDL_WINDOW_SHOWNwindow is visible
SDL_WINDOW_HIDDENwindow is not visible
SDL_WINDOW_BORDERLESSno window decoration
SDL_WINDOW_RESIZABLEwindow can be resized
SDL_WINDOW_MINIMIZEDwindow is minimized
SDL_WINDOW_MAXIMIZEDwindow is maximized
SDL_WINDOW_INPUT_GRABBEDwindow has grabbed input focus
SDL_WINDOW_INPUT_FOCUSwindow has input focus
SDL_WINDOW_MOUSE_FOCUSwindow has mouse focus
SDL_WINDOW_FOREIGNwindow not created by SDL
SDL_WINDOW_ALLOW_HIGHDPIwindow should be created in high-DPI mode if supported (available since SDL 2.0.1)

As you can see, these flags determine different properties of  the window. E.g. SDL_WINDOW_FULLSCREEN will create a fullscreen window and SDL_WINDOW_BORDERLESS will create a borderless window. You may combine several flags by OR (if appropriate). For our purpose SDL_WINDOW_SHOWN is a good choice because we just create a shown window without any further restrictions.

The SDL2 Renderer

In computer graphics rendering means the process of synthesizing the final image on your screen from the individual basic data structures. To draw some content to the window, we need therefore a renderer. The PSDL_Renderer (which we declared in the var clause) is responsible for synthesizing all the content in a window, be it some lines, a flat background, a texture, a 3d object, or whatever. We call our PSDL_Renderer “sdlRenderer”.

Creation of a Renderer

  sdlRenderer := SDL_CreateRenderer(sdlWindow1, -1, 0);
  if sdlRenderer = nil then Halt;

The creation of the renderer is as simple as one function call of SDL_CreateRenderer(window, index, flags) or

SDL_CreateRenderer(window: PSDL_Window; index: SInt32; flags: UInt32): PSDL_Renderer

First we need the renderer to know where to render the finished/rendered output. That will be “Window1” in our case. Next the shown function asks for a cryptic “index”. Well, each driver which is capable of rendering (e.g. OpenGL, Direct3d, Software,…) is indexed in SDL 2.0. In principle you could choose one specific driver here by choosing the corresponding index. Since we don’t know too much about the drivers at the moment the best choice is -1. -1 means that the first driver which is supporting the chosen flag(s) is chosen. Talking about flags, there are four flags you may choose:

  1. SDL_RENDERER_SOFTWARE
  2. SDL_RENDERER_ACCELERATED
  3. SDL_RENDERER_PRESENTVSYNC
  4. SDL_RENDERER_TARGETTEXTURE

You should always prefer SDL_RENDERER_ACCELERATED because this means the graphics board is responsible for rendering, SDL_RENDERER_SOFTWARE in contrast means, the CPU has to do the rendering. As discussed before for best performance the graphic board is the best choice for rendering/graphic related tasks. SDL_RENDERER_PRESENTVSYNC allows for so called vertical synchronization which means that the display of the rendered image is synchronized with the refresh rate of the monitor. SDL_RENDERER_TARGETTEXTURE allows for rendering to a texture. You may have noticed that none of these flags but 0 was used in the example code. This automatically gives priority to hardware accelerated renderers.

Quick Creation of a Window and a Renderer

 // quick set up
  {
  if SDL_CreateWindowAndRenderer(500, 500, SDL_WINDOW_SHOWN, @sdlWindow1, @sdlRenderer) <> 0
    then Halt;
  }

Instead of creating the window and the renderer separately as demonstrated, you may use SDL_CreateWindowAndRenderer(width, height, window flags, window pointer pointer, renderer pointer pointer). This has the advantage that you just need one line to set up a window and a renderer, though setting a window title, a window position or specific renderer flags have to be done afterwards if necessary.

Just remove the curly brackets and enclose the “full set up” -part to try it.

SDL_CreateWindowAndRenderer(width: SInt32; height: SInt32; window_flags: UInt32; window: PPSDL_Window; renderer: PPSDL_Renderer): SInt32

This function returns 0 on success and -1 on failure.

Rendering a SDL2 Scene

The actual rendering is achieved by SDL_RenderPresent(renderer). As a sidenote for people coming from SDL 1.2, this is what formerly has been achieved by SDL_Flip().

SDL_RenderPresent(renderer: PSDL_Renderer)

Freezing (delaying) a running program in SDL 2.0

SDL_Delay(time in milliseconds) is a simple, yet powerful and important procedure to stop the program running for a certain time in milliseconds. 2000 milliseconds are two seconds. This is kind of a twin of Pascal’s Delay procedure.

Clean up the memory in SDL 2.0

Now the final lines of code are discussed. One of the most important rules for sophisticated programming is followed here:

Always clean up the memory on program finish.

For nearly any pointer type generated by SDL 2.0, there is a destroy procedure to remove it from memory. These procedures are comparable to Pascal’s dispose procedure to remove pointer types from memory. Make sure to destroy the objects in the opposite sequence of their generation. We first created a window, then a renderer. So now we go the opposite way, first destroy the renderer and then the window by the procedures SDL_DestroyRenderer(renderer) and SDL_DestroyWindow(window) respectively.

Here we go:

  // clear memory
  SDL_DestroyRenderer(sdlRenderer);
  SDL_DestroyWindow (sdlWindow1);

Do not forget to quit SDL2 finally (which we don’t).

That’s it. And now things are going to get really interesting :-).

← previous Chapter | next Chapter →

Viewports

Last updated on November 20th, 2021

SDL2 allows for viewports. Have a look at the following screenshot of a SDL2 game (Battle for Wesnoth).

Modified screenshot of Battle of Wesnoth. (Original source image, as found in the Wesnoth Wiki by Wesnoth developers. Image license: GFDL.)

This is a classical situation to use viewports. The game screen is clearly parted into three distinguished areas. The main screen is the large part left with the mountains and the castles. Then there is the minimap in the right-upper corner. And a statistics overview under the minimap. These areas and the corresponding viewports are highlightened in the following screenshot.

Modified screenshot of Battle of Wesnoth. (Original source image, as found in the Wesnoth Wiki by Wesnoth developers. Image license: GFDL.)

The advantage of viewports is that each of them behaves like an own window, so if you draw to the right outside of viewport 1 in the screenshot above, the texture will just be clipped and there is no overlap into viewport 2 oder 3.

SDL2 window and viewport coordinates diagram
The relation of your screen, a SDL2 window and a viewport within this window are outlined here.

Let’s have a look at the code.

program SDL2_Viewport;

uses SDL2;

const
  Viewport1: TSDL_Rect = (x: 0;   y:   0; w: 400; h: 500);
  Viewport2: TSDL_Rect = (x: 400; y:   0; w: 100; h: 300);
  Viewport3: TSDL_Rect = (x: 400; y: 300; w: 100; h: 200);

  BlackDot:  TSDL_Rect = (x: 10;  y:  10; w:   3; h:   3);

var
  sdlWindow1: PSDL_Window;
  sdlRenderer: PSDL_Renderer;

begin

  //initilization of video subsystem
  if SDL_Init(SDL_INIT_VIDEO) < 0 then Halt;

  SDL_CreateWindowAndRenderer(500, 500, SDL_WINDOW_SHOWN, @sdlWindow1, @sdlRenderer);
  if (sdlWindow1 = nil) or (sdlRenderer = nil) then Halt;

  // fill every viewport with background color and draw a black dot into it
  SDL_RenderSetViewport(sdlRenderer, @Viewport1);
  SDL_SetRenderDrawColor(sdlRenderer, 255, 0, 0, SDL_ALPHA_OPAQUE);
  SDL_RenderFillRect(sdlRenderer, nil);
  SDL_SetRenderDrawColor(sdlRenderer, 0, 0, 0, SDL_ALPHA_OPAQUE);
  SDL_RenderFillRect(sdlRenderer, @BlackDot);

  SDL_RenderSetViewport(sdlRenderer, @Viewport2);
  SDL_SetRenderDrawColor(sdlRenderer, 255, 255, 0, SDL_ALPHA_OPAQUE);
  SDL_RenderFillRect(sdlRenderer, nil);
  SDL_SetRenderDrawColor(sdlRenderer, 0, 0, 0, SDL_ALPHA_OPAQUE);
  SDL_RenderFillRect(sdlRenderer, @BlackDot);

  SDL_RenderSetViewport(sdlRenderer, @Viewport3);
  SDL_SetRenderDrawColor(sdlRenderer, 0, 255, 0, SDL_ALPHA_OPAQUE);
  SDL_RenderFillRect(sdlRenderer, nil);
  SDL_SetRenderDrawColor(sdlRenderer, 0, 0, 0, SDL_ALPHA_OPAQUE);
  SDL_RenderFillRect(sdlRenderer, @BlackDot);

  // render to window for 2 seconds
  SDL_RenderPresent(sdlRenderer);
  SDL_Delay(2000);

  // clear memory
  SDL_DestroyRenderer(sdlRenderer);
  SDL_DestroyWindow (sdlWindow1);

  //shutting down video subsystem
  SDL_Quit;

end.  

The result will look like this:

Creative Commons License This image by https://www.freepascal-meets-sdl.net is licensed under a Creative Commons Attribution 4.0 International License.
There are three viewports with different background colors and a black dot in the left upper corner.

First we set up some SDL2 rectangles by

const
  Viewport1: TSDL_Rect = (x: 0;   y:   0; w: 400; h: 500);
  Viewport2: TSDL_Rect = (x: 400; y:   0; w: 100; h: 300);
  Viewport3: TSDL_Rect = (x: 400; y: 300; w: 100; h: 200);

  BlackDot:  TSDL_Rect = (x: 10;  y:  10; w:   3; h:   3);

“Viewport1” represents the red viewport (left), “Viewport2” the yellow (upper-right) and “Viewport3” the green (lower-right) viewport in the result image.

Notice how we just prepare one “BlackDot” rectangle for a black dot of 3×3 px dimension at location (10/10).

After setting up SDL2, a renderer and a window as known, we start to set up the first (red, left) viewport.

  // fill every viewport with background color and draw a black dot into it
  SDL_RenderSetViewport(sdlRenderer, @Viewport1);
  SDL_SetRenderDrawColor(sdlRenderer, 255, 0, 0, SDL_ALPHA_OPAQUE);
  SDL_RenderFillRect(sdlRenderer, nil);
  SDL_SetRenderDrawColor(sdlRenderer, 0, 0, 0, SDL_ALPHA_OPAQUE);
  SDL_RenderFillRect(sdlRenderer, @BlackDot);

It is simple as that. Use the function SDL_RenderSetViewport(renderer, rectangle pointer) to set up a viewport. This function returns 0 on success or -1 on failure.

SDL_RenderSetViewport(renderer: PSDL_Renderer; const rect: PSDL_Rect)

After we set up the viewport, we set the draw color by SDL_SetRenderDrawColor(renderer, red, green, blue, alpha) to red (255/0/0/no transparency). Then we use SDL_RenderFillRect(renderer, rectangle pointer) to fill the whole viewport by not specifying a rectangle (nil). Both functions are known from a previous chapter.

Then the color is set to black and a tiny 3×3 rectangle is drawn at location (10/10).

This procedure is repeated for the other two viewports. Notice again, how we use the same rectangle for the black dot though and where it is shown in the result image. The black dot is always drawn at location (10/10) relative to the respective viewport’s location!

As general rule it applies:

The coordinates are always relative to the currently set viewport.

Well, the remaining parts of the code provides nothing new, just the rendering for 2 seconds and some clean up.

Let’s close with some helpful remarks.

No SDL_RenderClear for Viewports!

Do not use SDL_RenderClear(renderer). It will ignore the viewports and clear the whole window with the set drawing color.

Resetting the Viewport

The resetting is done simple by SDL_RenderSetViewport(renderer, nil) as one would expect.

← previous Chapter | next Chapter →

A Custom Mouse Cursor

Last updated on November 20th, 2021

Any good game has a custom mouse cursor. You may think it would be a good idea to have a SDL2 surface or SDL2 texture and render it as any other sprite right at the mouse position to simulate a mouse cursor. DO NOT do this! The mouse cursor is handled separatly from the other rendering to have it smooth and working in critical situations. 

The following code shows how to set up a custom mouse cursor with SDL2 the correct way.

program SDL_MouseCursor;

uses SDL2, SDL2_image;

var
  sdlWindow1: PSDL_Window;
  sdlRenderer: PSDL_Renderer;
  sdlSurface1: PSDL_Surface;
  sdlMouseCursor: PSDL_Cursor;
  sdlEvent: TSDL_Event;
  ExitLoop: Boolean = False;

begin

  //initilization of video subsystem
  if SDL_Init(SDL_INIT_VIDEO) < 0 then Halt;

  SDL_CreateWindowAndRenderer(500, 500, SDL_WINDOW_SHOWN, @sdlWindow1, @sdlRenderer);
  if (sdlWindow1 = nil) or (sdlRenderer = nil) then Halt;

  sdlSurface1 := IMG_Load('Cursor.png' );
  if sdlSurface1 = nil then Halt;

  // create and set new mouse cursor
  sdlMouseCursor := SDL_CreateColorCursor(sdlSurface1, 8, 8);
  if sdlMouseCursor = nil then Halt;

  SDL_SetCursor(sdlMouseCursor);

  while ExitLoop = False do
  begin

    // exit loop if mouse button pressed
    while SDL_PollEvent(@sdlEvent) = 1 do
      if sdlEvent.type_ = SDL_MOUSEBUTTONDOWN then
        ExitLoop := True;

    SDL_SetRenderDrawColor(sdlRenderer, 128, 128, 128, SDL_ALPHA_OPAQUE);
    SDL_RenderClear(sdlRenderer);

    SDL_RenderPresent(sdlRenderer);
    SDL_Delay( 20 );
  end;

  SDL_FreeCursor(sdlMouseCursor);

  SDL_FreeSurface(sdlSurface1);
  SDL_DestroyRenderer(sdlRenderer);
  SDL_DestroyWindow (sdlWindow1);

  //shutting down video subsystem
  SDL_Quit;

end.

To have a custom mouse cursor we need a variable of type PSDL_Cursor. We call it “sdlMouseCursor” here.

The result looks like this:

Custom Mouse Cursor in SDL2
Creative Commons License This image by https://www.freepascal-meets-sdl.net is licensed under a Creative Commons Attribution 4.0 International License.
The blue cross with the yellow outline is the mouse cursor on the grey canvas/window. 
  sdlSurface1 := IMG_Load('Cursor.png' );
  if sdlSurface1 = nil then Halt;

  // create and set new mouse cursor
  sdlMouseCursor := SDL_CreateColorCursor(sdlSurface1, 8, 8);
  if sdlMouseCursor = nil then Halt;

  SDL_SetCursor(sdlMouseCursor);  

This is the interesting part of the code with regard to creating a custom mouse cursor. The cursor’s image is defined by a SDL surface. We create the SDL surface as known from a previous chapter from a png image file to “sdlSurface1” here.

The custom mouse cursor is created by the following function, which returns nil on error.

SDL_CreateColorCursor(surface: PSDL_Surface; hot_x: SInt32; hot_y: SInt32): PSDL_Cursor

It needs the surface to use as cursor image and two coordinates (hot_x/hot_y) as arguments. They determine where the actual hitting point for this cursor is. Since the example cursor image is of dimensions 16×16 px and represents a cross, the “hot” (hitting) coordiates are (8/8), hence the cross’ center is used for hitting a button or something. In contrast you may imagine a typical arrow shaped mouse cursor, where the hitting point has to be adjusted to be right on the tip of the arrow in the arrow’s image.

If the cursor creation has been successful, it is necessary to set it to be the actual cursor. You may have created many different cursors, so tell SDL which one to use by the following procedure.

SDL_SetCursor(cursor: PSDL_Cursor)

The remaining part of the code is just rendering a 500 by 500 pixels window with a grey (128, 128, 128) background that is updated as long as no mouse button has been pressed.

Finally do not forget to free the mouse cursor by SDL_FreeCursor(mouse cursor) as shown.

← previous Chapter | next Chapter →

Which SDL2 unit to choose?

Last updated on October 6th, 2019

Right now I’m aware of these translation projects that provide SDL2 units (if you know a further one, let me know):

Project
Link
Description
Tim Blume's SDL 2.0 units Pure translation of SDL 2.0 source files. The original, modular structure of the header files is preserved, so the SDL2.pas is composed of many include files. Translations of SDL2_mixer, SDL2_ttf and SDL2_image are available, SDL_net seems to be missing so far. It provides MacOS X support.
p_daniel's (or danpla's or de-signer) SDL 2.0 units Pure translation of the SDL 2.0 source files. All the header files of the original SDL 2.0 source code are combined into one large SDL2.pas (similar to JEDI-SDL's SDL.pas for SDL). Translations of SDL2_mixer, SDL2_ttf, SDL2_image and SDL2_net are available. The MacOS X support is unproven.
Imants Gulis' SDL 2.0 units Heavily modified SDL 2.0 units to allow for dynamic loading of the library.
Bare Game Library Bare Game is a game library which is put on top of the SDL2 library. It also allows for easy combination of SDL2 with Lazarus, which is a great plus. [Official website (baregame.org) is down, is the project dead?]

Now we go for a detailed discussion of them.

Modified header translations

Well, the Bare Game Library is a great project and I like the idea to provide an easy-to-use game development library  very much but it isn’t suitable to learn pure SDL 2.0. Many functions are wrapped by new function names, you would learn much about the usage of Bare Game, fewer about SDL 2.0 itself. Also, the ease of use is traded for flexibility, e.g. there is just support for Windows and Linux, no Mac support, and you are more or less forced to use Lazarus IDE (which is an excellent choice, no question!) but for some reason you might not want to use Lazarus. The usage of libraries always trades ease for flexibility. And finally you are dependent upon a second project. If SDL 2.0 is updated, will Bare Game have updates, too? Bare Game is a great project at all, but for learning SDL 2.0 and if you keep the downsides in mind, it is not the best choice here.

Imant’s Gulis units allow for dynamic loading of SDL 2.0, hence your application decides during run-time if SDL 2.0 has to be loaded. This led to heavily modified unit files compared to the original header files. Also it is expected to use Lazarus. Although there are numerous cases where dynamic loading can be a great plus, for the tutorial and a wide variety of applications this is not necessary.

Pure header translations

The unmodified header translations of the original SDL 2.0 headers is the best choice when it comes to learning SDL 2.0.

The beauty of p_daniel’s SDL 2.0 units is the fact that there are exactly five files you need. They contain all the translations for basic SDL 2.0 and the official extensions SDL2_mixer, SDL2_ttf, SDL2_image and SDL_net. Unfortunately, the original comments are cut out. This is a major drawback to my mind. Sometimes you need just a quick look at the implementation of a function in the source to get how it works or what is wrong. Also the MaxOS support is unproven.

In contrast Tim Blume’s SDL 2.0 units kept the comments. The unit names differ slightly from the original names (e.g. SDL_audio.h got sdlaudio.inc instead of SDL_audio.inc ), which I don’t like, but it is acceptable. This allows for a better understanding in how SDL 2.0 works. Also it allows for better flexibility with regards to later projects.

Conclusion

This said, to my mind, the best choice to start with SDL 2.0 and Free Pascal: Go for Tim Blume’s SDL 2.0 units. For other purposes, other units may be the better choice.

Android News Cover Image

About SDL2, Free Pascal and… Android

Since the rise of SmartPhones, many wonder if Free Pascal/SDL2 development  is possible for them, too. The good news is, yes it is possible! The bad news is, it is kind of toilsome to set up a development environment for Android (one of the two major operating systems of many SmartPhones).

Imants Gulbis informed me that he set up a Lazarus package (LazSDL2Design) which makes development of SDL2 applications with Free Pascal for Android fairly simple and integrates with the Lazarus IDE. Check out the instructions to make Lazarus/SDL2 ready for Android. The LazSDL2Design package relies on an own translation of SDL2 headers (LazSDL2) by him.

I put together some useful resources for Android development in the FAQ.

Thanks to reader Paul for letting me know about an unclear statement in Chapter 8 Part 1.

The website uses HTTPS now.

Android, SDL2 and Pascal?

Recently, I get more and more questions and requests regarding the development of Android applications with SDL2 and Free Pascal. Since I’m not planning to do a tutorial chapter on this in the near future, I would like to share some resources which may help you to set your system up. – Contact me, if you are interested in sharing a tutorial on how to set up a SDL2/Free Pascal/Android development environment (or if you know further resources which should be covered here).

  1. This step by step tutorial describes very detailed the setup of a SDL2/Android development environment under Window, though it aims for C++ development rather than Pascal development: 

http://lazyfoo.net/tutorials/SDL/52_hello_mobile/android_windows/index.php.

  1.  This is a short introduction how to setup your system and Lazarus (Free Pascal) to develop Android Apps:

http://wiki.lazarus.freepascal.org/Android_tutorial.

  1. These links lead you to a Lazarus package that allows for SDL2 and simple Android development and a configuration of it:

https://sourceforge.net/projects/lazsdl2.
https://sourceforge.net/p/lazsdl2/wiki/LazSDL2Design%20configuration.

 

 

 

Linux Tutorial News Cover Image

New Linux Installation Chapter

A new Chapter 2 has been added. In contrast to the classical Chapter 2 which explains the installation of SDL2 and Free Pascal for the Windows operating system, the new Chapter 2 explains the installation and configuration of SDL2 and Free Pascal/Lazarus in Linux. Initially I was trying to check for some troubles which got mentioned. Finally I ended up with a short, new installation chapter. A few minor changes have been added to the other chapters which are basically hints for Linux users.

A few new great and interesting Free Pascal/SDL projects have been added to the project page. These are namely GearHead: Arena, GearHead 2, Dungeon Monkey Unlimited, Monsterland and DoomRL. The former three are open source by the way.

DoomRL

Short description

DoomRL is based on ID’s famous Doom game. The RL means roguelike.

Showcase and Basic Data

Developer granted permission to use these screenshots.

  • Project name: DoomRL (a.k.a Doom, the Roguelike)
  • Author: Kornel Kisielewicz (Code/Design), Derek Yu (art)
  • Latest version: 0.9.9.7
  • Release date: 2001 (initial version), 19 March 2013 (latest version)
  • Pascal compiler: FPC 3.0
  • SDL Version: 1.2
  • Further libraries: Lua, OpenGL, FMOD
  • License: Donationware
  • Open source: no
  • Official website: http://doom.chaosforge.org

Interview with Kornel Kisielewicz

Why did you decide to choose Pascal as a programming language and SDL as a library for your projects?

Kornel Kisielewicz: Pascal was my first language, and in those days C++ was quite messy. I liked the clean syntax of Pascal and it’s default strong type system. SDL was a no brainer, we wanted a platform independent layer for OpenGL context creation and Input handling, and SDL was the only reasonable choice in that regard at the time.

What do you think is the most interesting Pascal/SDL/SDL2 project out there (besides your own, of course :-D)?

Kornel Kisielewicz: I have been out of touch with the Pascal scene for a long time now.

Are there any new projects planned?

Kornel Kisielewicz: We’re currently working on Jupiter Hell, a spiritual successor to DoomRL, but it’s in full 3d, and written in C++.

Chapter 2 – Installation and Configuration (Linux version)

Last updated on July 22nd, 2020

This chapter illustrates quickly how to set up a Free Pascal and SDL2 development environment within a few minutes under Linux.

Attention: The following instruction particularly work for many Debian and Ubuntu based Linux distributions (like Linux Mint used here). In general it outlines the way to go, though.

The distribution and software I used:

  • Linux Distribution: Linux Mint 19.3 (Ubuntu/Debian based)
  • Desktop: Cinnamon Desktop
  • Lazarus 2.0.6 (installed from .deb file)
  • FPC 3.0.4 (installed from .deb file)
  • FPC 3.0.4 Source Code (installed from .deb file)
  • Tim Blume’s SDL2 units (header translation)
  • SDL2, SDL2_image, SDL2_ttf shared object files (from distro’s package manager)

Download and install FPC, FPC sourc code and Lazarus

The first step is to install the Free Pascal compiler (version 3.0.4 or higher), the Compiler’s source code (same version as the compiler) and the Lazarurs IDE (version 2.0.6 or higher). To get the most recent, stable environment, download these three files from the official Lazarus website: https://www.lazarus-ide.org/index.php?page=downloads.

Important: Do not intermix FPC or Lazarus installs from the package manager. This will lead to troubles because these installs are not compatible. Purge any of these installs. Use, e.g.:

dpkg --list (show all installed packages)
sudo apt-get --purge fp-compiler.... [exact package name] (remove package incl. config files) 

Choose one of the “Linux DEB Releases” according to your system (32 bit or 64 bit). Most probably your running on a 64 bit system, which is the standard case for Linux.

In case of a 64 bit system download these three files:

  • fpc-laz_3.0.4-1_amd64.deb
  • fpc-src_3.0.4-2_amd64.deb
  • lazarus-project_2.0.6-0_amd64.deb

The download page looks somewhat like this:

Install Packages for Linux FPC SDL2 environment with Lazarus
SourceForge download page for all three files necessary. The original description is kept in the image.

If you downloaded these three files successfully, you run them in the same order! First FPC, then FPC’s sources and finally Lazarus.

If everything went right, Lazarus can be started up by typing “startlazarus” in the terminal or by finding the program in the application menue.

Start up Lazarus the first time

On start up of Lazarus the directories for FPC and the FPC source code were found and set already. As a hint I show where these are located on my system:

  • FPC: /usr/bin/fpc
  • FPC Source code: /usr/share/fpcsrc/3.0.4 (because $(FPCVER) equals the version number, see screenshot)

The configurations screen may look somewhat different to the screen of the following screenshot, but that is because the screenshot is outdated a bit.

Path FPC and FPC Source code
Either detected automatically or can be manually added by Tools > Options …

Before proceeding, my suggestion is to simply compile the project (press F9 in Lazarus) which is presented to you. It should compile and show the form.

Get the SDL2 units

Get the latest version of the translated SDL2 units.

Download SDL2 units on GitHub
Choose the master branch (1), click on “Clone or download” (2) and click on Download ZIP (3).

Make sure you have the master branch chosen and then click on “Clone or download”, then “Download ZIP”.

After extracting the ZIP file I suggest to rename the new folder into “sdl2” or “SDL2” and place it at any location, perhaps your development folder, e.g.:

  • ~/projects/sdl2 (a.k.a /home/[username]/projects/sdl2)
  • (DO NOT use the suggested folder in the screenshot)
Path to SDL2 units
This folder is suggested as a place for the SDL2 units (DO NOT use this folder!). By the way, “Chap7” is just a random name for this project and you may have anything else there instead (I was trying out Chapter 7 tutorial code).

Get the SDL2 shared object files

If you are looking for the most recent pre-compiled SDL2 dynamic link library files (e.g. libSDL2.so) on the official SDL2 website, you just find a remark that reads like this:

Linux:
Please contact your distribution maintainer for updates.

Since SDL2 is very widespread it is very likely that your distribution maintainer already included the files.

Find SDL2 and all necessary libraries in your distribution’s package manager, here it is the synaptic package manager. Look for libsdl and install every package shown in the screenshot:

Synaptic package manager shows installed sdl2 shared object packages.

Find all necessary libraries and install them. These you should install:

  • libsdl2
  • libsdl2-dev
  • libsdl2-gfx
  • libsdl2-gfx-dev
  • libsdl2-image
  • libsdl2-image-dev
  • libsdl2-mixer
  • libsdl2-mixer-dev
  • libsdl2-net
  • libsdl2-net-dev
  • libsdl2-ttf
  • libsdl2-ttf-dev

The dev-packages are necessary to compile SDL2 applications. The other packages are necessary to run SDL2 applications.

The version of these libraries does not necessarily need to be the most recent unfortunately. If you really need the most recent versions here, you may try to contact the maintainer to ask to update the version.

Congratulation! After that, everything should run smoothly :-)!

← Chapter 1 | Chapter 3 →