DEV Community: Patrick O'Dacre

Variables, Data Types, and Functions - Learn to Code Part 2

Patrick O'Dacre — Fri, 06 Jan 2023 10:48:28 +0000

Compiler: a program to turn your code into something your computer can understand and execute.
Variables: a variable is a construct that allows you to store and use data throughout your program.
Data Types: data types help your program understand the type or kind of data you use in your program.
Functions: a construct that wraps or contains a set of instructions for the computer.

Compiler

The Odin compiler, itself a program, turns your written Odin code into something the computer can understand. The computer cannot understand your program as you have written it. The compiler must turn it into "machine code."

Type odin run main.odin -file into your console to "build" and "execute" your program.

Variables

Variables are "names" you give a piece of data in your program.

first_name : string = "Patrick"

In this example, we have a variable named "first_name," and the value of that variable is "Patrick."

Instead of typing "Patrick" everywhere in our program, we can use the variable. Then, if we need to change the first name to something else, we only need to change the value once.

Variables can be assigned to a value once or multiple times.

first_name : string = "Patrick"

first_name = "Not Patrick"

If you update a variable with a new value, that value must be of the same "type."

What is a data type?

Data Types

Data types describe what "type" of data you have. They are necessary for your compiler to understand what your program can and cannot do.

This video covers three different data types:

1) strings
2) integer
3) floats

These types help the compiler understand that you can perform arithmetic on numbers and floats, not strings.

Strings

Strings are text in double quotations. Odin distinguishes between double and single quotation marks, so make sure your strings are in double quotation marks.

Strings can contain letters, numbers, and symbols.

When you write numbers in double quotation marks, they are considered a string, not a number. Some languages automatically convert numbers in quotation marks (a string) into a number type to perform arithmetic, but thankfully Odin doesn't do that. Unfortunately, automatic conversion can be problematic -- it doesn't teach you to think carefully about your data types.

Integers

Integers are whole numbers. There are different types of integers -- some small, others large; some can be negative, and others only positive.

When first learning, you will likely use int most often. It is the default integer type. Depending on your system, int with either be 32-bits or 64-bits in size.

64-bit numbers are larger than 32-bit numbers.

The maximum number allowed in 64 bits of memory space would be 9,223,372,036,854,775,807, allowing for negative numbers, or (2^64)-1 (inclusive), allowing for only positive numbers.

If your machine is a 32-bit machine, the largest would be 2,147,483,647, allowing for negative numbers, or 4,294,967,295, allowing for only positive numbers.

In game programming, x and y positional coordinates will be an integer type because positions on a screen are pixels, and you cannot have less than a whole pixel.

Floats

Floats are similar to integers, but they allow for decimals. If you require more precision in your arithmetic, floats are the type you want to use.

In game programming, fine movement speed calculation will be in floats and later rounded to whole numbers to determine x and y positioning.

Functions

In this video, we practice writing some new functions. Our functions accept arguments. Arguments are pieces of data we can pass to our function, so it can use that data to do its work.

Notice that we specify the data type for each function argument because Odin cannot infer the data type of an argument.

Odin often can infer a data type by the value assigned to a variable, but it is different with function signatures.


// Odin infers that str is of type "string"
str := "Hello, World"

// Odin must be told that the my_arg argument is of type "string"
my_print_str :: proc(my_arg: string)
{}

Practice

This video contains examples of printing different data types to the console. Take a look at the Odin Documentation to examine other data types. Practice creating variables of different types and print those to the console.

Learn to Code with Odin Programming Language - Introduction

Patrick O'Dacre — Fri, 06 Jan 2023 10:35:50 +0000

I started learning to code back in 2015. I started with PHP and JavaScript, and I had a great time.

This is my attempt to explain programming to my younger self using a lower-level language -- Odin.

Odin is a modern, systems-level programming language that is simple to use and easy to learn.

Programming simple games using Odin is a lot easier and less complicated than webdev, hence a great way to learn to program.

Introduction to Programming

Before we start, we must go over a few new terms.

Package - a collection of .odin files within a given folder in your program.
Function - a construct that wraps or contains a set of instructions for the computer.
Program Entry Point - the first function ran or called by the computer when executing your program.

Package

A Package is a folder or directory that contains .odin files for your program.

Consider the following folder structure:

-> my-program/main.odin
-> my-program/types.odin
-> my-program/map.odin
-> my-program/entities/player.odin
-> my-program/entities/enemy.odin

In this example, the root folder of your program has three files -- main.odin, types.odin, and map.odin. All of these files are in the same Package. You can name Packages anything you want, but all three files must share the same Package name. We'll use "main" because that is what you see in the Odin documentation.

The sub-folder "entities" has two files. These files also share a Package, but this Package is distinct from the "main" Package. Therefore, we must give this Package a different name. We'll call this sub-folder / Package "entities."

Our files will look like this:

// main.odin

package main

main :: proc()
{

}

// types.odin

package main

// code

// map.odin

package main

// code

// entities/player.odin

package entities

// code

// entities/enemy.odin

package entities

// code

The next thing we must understand is the "function."

Functions

Functions contain one or more instructions for the computer to run, and they are "run" or "called" by typing the function name, followed by brackets: somefunction().

You can write functions in different ways. Here are some examples of how you can write somefunction:

1) some_function()
2) Some_Function()
3) someFunction()
4) some_function()
5) some_function_2()

And many more. Except for the underscore, function names cannot contain any other special symbols or punctuation, nor can they begin with a number.

Program Entry Point

Every program your computer runs has an Entry Point. The entry point to your odin program is the main() function. Your program may only have one main() function. It is the first function that runs, and your program will end when this function has finished executing all of its code.

Many programs you use -- games, photoshop, a web browser -- stay open for a long time. They stay open for a long time because their main() functions don't end until you tell them to end. In a later part, we'll look at how games continue to run indefinitely.

Using Other People's Code with "import"

Programming languages have a "standard library" or "core library." A "library" is code written by someone else and intended for others to use. A "standard" or "core" library is a library of code that comes with the programming language and contains functions and other things needed in most programs. For example, one such library or Package in Odin is "fmt."

We use other Packages by "importing" them into our file. Here is an example of importing the "fmt" package into our main.odin file.


package main

import "core:fmt"

main :: proc()
{
}

The "fmt" package defines a function called println(). println() allows us to print data to the console screen. Since println() is in the "fmt" package and now our "main" Package, you must prefix the function with the package name like so fmt.println().

Type the following in your main.odin file:


package main

import "core:fmt"

main :: proc()
{
    fmt.println("Hello, World")
}

Now in your console, type odin run main.odin - file in the project's root folder, and you will see "Hello, World" printed on the console screen.

Practice

Practice printing different things on the screen. You can change the text or even try printing some numbers. How about some arithmetic like fmt.println(2+2).

Experiment and see what happens.

Space Shooter Game with SDL2 and Odin - Part 8 - Enemies Attack!

Patrick O'Dacre — Thu, 05 Jan 2023 07:33:45 +0000

In this guide we'll go through the following steps:

Create && Fire Drone Lasers
Show Entity hitboxes

Create && Fire Drone Lasers

We'll create a fixed number of lasers for the drones to use. Much like with our own laser, a drone laser won't fire unless it is available -- health == 0.

We need to implement two separate timers -- one master timer, and another for each individual drone. These two timers help us control the number of drone lasers firing at the player.

We'll add a ready field to the Entity struct to control the laser fire-rate of individual drones, and the drone_laser_cooldown field to the Game struct as our master timer.


NUM_OF_DRONE_LASERS :: 5

Game :: struct
{
    /// Other stuff ^^^
    /// new
    drone_laser_tex: ^SDL.Texture,
    drone_lasers: [NUM_OF_DRONE_LASERS]Entity,
    drone_laser_cooldown : f64,
}

Entity :: struct
{
    source: SDL.Rect,
    dest: SDL.Rect,
    dx: f64,
    dy: f64,
    health: int,
    ready: f64,
}

create_entities :: proc()
{
    /// create drones ^^

    // drone lasers
    game.drone_laser_tex = SDL_Image.LoadTexture(game.renderer, "assets/drone_laser_1.png")
    assert(game.drone_laser_tex != nil, SDL.GetErrorString())
    drone_laser_w : i32
    drone_laser_h : i32
    SDL.QueryTexture(game.drone_laser_tex, nil, nil, &drone_laser_w, &drone_laser_h)

    for _, idx in 1..=NUM_OF_DRONE_LASERS
    {

        game.drone_lasers[idx] = Entity{
            dest = SDL.Rect{
                x = -100,
                y = -100,
                w = drone_laser_w / 8,
                h = drone_laser_h / 6,
            },
            dx = DRONE_LASER_SPEED,
            dy = DRONE_LASER_SPEED,
            health = 0,
        }
    }


    ///
}

The drone lasers aren't shaped quite like I want, so I skew the image by changing the w and h a bit to get it as close to round as I can.

Fire Lasers

We'll allow drones to fire when within certain boundaries and the cooldown timer has expired:


if drone.dest.x > 30 &&
drone.dest.x < (WINDOW_WIDTH - 30) &&
drone.ready <= 0 &&
game.drone_laser_cooldown < 0
{
    // fire
}

We check this each time we render a drone.

If the drone's individual timer has expired, ie: drone.ready < 0 then we'll look for the first available drone laser to "fire":

// find a drone laser:
fire_drone_laser : for laser, idx in &game.drone_lasers
{

    // find the first one available
    if laser.health == 0
    {
        // fire
    }
}

Drones need to shoot towards our player, so we'll have to calculate a dx and dy value that will lead the laser from the position of the drone to the current position of the player:

// fire from the drone's position
laser.dest.x = drone.dest.x
laser.dest.y = drone.dest.y
laser.health = 1

new_dx, new_dy := calc_slope(
    laser.dest.x,
    laser.dest.y,
    game.player.dest.x,
    game.player.dest.y,
    )

if !game.is_paused
{
    laser.dx = new_dx * get_delta_motion(drone.dx + 150)
    laser.dy = new_dy * get_delta_motion(drone.dx + 150)
}

// reset the cooldown to prevent firing too rapidly
drone.ready = DRONE_LASER_COOLDOWN_TIMER_SINGLE
game.drone_laser_cooldown = DRONE_LASER_COOLDOWN_TIMER_ALL

Of course, we're also careful to reset our timers.

Now, each time this active laser is rendered, it will move according to the calculated dx and dy:

// Render Drone Lasers -- check collisions -> render
for laser, idx in &game.drone_lasers
{

    if laser.health == 0 do continue

    // check collision based on previous frame's rendered position
    // check player health to make sure drone lasers don't explode
    // while we're rendering our stage_reset() scenes after a player
    // has already died.
    if game.player.health > 0
    {
        hit := collision(
            game.player.dest.x,
            game.player.dest.y,
            game.player.dest.w,
            game.player.dest.h,

            laser.dest.x,
            laser.dest.y,
            laser.dest.w,
            laser.dest.h,
            )

        if hit
        {
            laser.health = 0

            if !game.is_invincible
            {
                explode_player(&game.player)
            }
        }
    }

    if !game.is_paused
    {
        laser.dest.x += i32(laser.dx)
        laser.dest.y += i32(laser.dy)
    }

    // reset laser if it's offscreen
    // checking x and y b/c these drone
    // lasers go in different directions
    if laser.dest.x <= 0 ||
    laser.dest.x >= WINDOW_WIDTH ||
    laser.dest.y <= 0 ||
    laser.dest.y >= WINDOW_HEIGHT
    {
        laser.health = 0
    }

    if laser.health > 0
    {
        when HITBOXES_VISIBLE do render_hitbox(&laser.dest)
        SDL.RenderCopy(game.renderer, game.drone_laser_tex, &laser.source, &laser.dest)
    }

}

Show Entity hitboxes

To help with visualizing how our collisions are working, let's add a little utility to outline our collision areas.

We'll add a flag that will be checked at compile time:


HITBOXES_VISIBLE :: false

Next, we'll add this helper function to render a red rectangle at a given destination SDL.Rect:


render_hitbox :: proc(dest: ^SDL.Rect)
{
    r := SDL.Rect{ dest.x, dest.y, dest.w, dest.h }

    SDL.SetRenderDrawColor(game.renderer, 255, 0, 0, 255)
    SDL.RenderDrawRect(game.renderer, &r)
}

Now we can pass in any entity SDL.Rect to get an outline of their collision boundaries:


if laser.health > 0
{
    when HITBOXES_VISIBLE do render_hitbox(&laser.dest)
    SDL.RenderCopy(game.renderer, game.laser_tex, nil, &laser.dest)
}

Space Shooter Game with SDL2 and Odin - Part 7 - Shooting Drones

Patrick O'Dacre — Wed, 04 Jan 2023 20:51:37 +0000

Shooting drones involves these 4 steps:

Fire Laser
Respawn Drones
Iterate Lasers -- Detect Collisions, Move, and Render
Iterate Drones -- Move and Render

While the collision detection code is what decides what has been hit, I found I had to complete these 4 steps in the proper way to make the collision detection work as I expected.

I was careful to move entities only AFTER collision detection is completed. If collisions are checked against positions not yet rendered, then it looks like the drones are being destroyed too early. In other words, I based my collisions on the positions last visible to the player.

Fire Laser

We finished this portion of the code in a previous part of the series.

Firing a laser means resetting its position from RIGHT offscreen to the player's position, so it will be rendered in a straight path from this new starting position.


// FIRE LASERS
if game.fire && !(game.laser_cooldown > 0)
{
    // find a laser:
    fire : for laser in &game.lasers
    {
        // find the first one available
        if laser.health == 0
        {

            laser.dest.x = game.player.dest.x + 20
            laser.dest.y = game.player.dest.y
            laser.health = 1
            // reset the cooldown to prevent firing too rapidly
            game.laser_cooldown = LASER_COOLDOWN_TIMER

            break fire
        }
    }
}

Respawn Drones

This was also completed in a previous part of the series.

Spawning a drone means resettings its position from the LEFT offscreen to the RIGHT where it can begin a new flight path moving towards the LEFT again.


// Spawn Drones
respawn : for drone in &game.drones
{

    if drone.health == 0 && !(game.drone_spawn_cooldown > 0)
    {
        drone.dest.x = WINDOW_WIDTH
        drone.dest.y = i32(rand.float32_range(120, WINDOW_HEIGHT - 120))
        drone.health = 1

        game.drone_spawn_cooldown = DRONE_SPAWN_COOLDOWN_TIMER

        break respawn
    }
}

Once we fire our weapon and respawn drones, we need to move onto updating laser and drone positions.

Iterate Lasers -- Detect Collisions, Move, and Render

For every laser in flight we need to check each active drone to see if their positions overlap. If their positions overlap, then we know the laser has hit the drone. For now we'll consider a single hit a kill shot, but later we can experiment with multiple hits.

Our collision detection looks like this:


collision :: proc(x1, y1, w1, h1, x2, y2, w2, h2: i32) -> bool
{
    return (max(x1, x2) < min(x1 + w1, x2 + w2)) && (max(y1, y2) < min(y1 + h1, y2 + h2))
}

We're checking the dimensions of 2 rectangles to see if any portion overlaps. If there is an overlap, then we have a collision.


// Check collisions and render lasers
for laser in &game.lasers
{

    if laser.health == 0
    {
        continue
    }

    detect_collision : for drone in &game.drones
    {

        if drone.health == 0
        {
            continue
        }

        hit := collision(
            laser.dest.x,
            laser.dest.y,
            laser.dest.w,
            laser.dest.h,

            drone.dest.x,
            drone.dest.y,
            drone.dest.w,
            drone.dest.h
            )

        if hit
        {

            drone.health = 0
            laser.health = 0

            break detect_collision
        }

    }

    if laser.health > 0
    {
        laser.dest.x += i32(get_delta_motion(laser.dx))
        SDL.RenderCopy(game.renderer, game.laser_tex, nil, &laser.dest)
    }

}

If our laser doesn't collide with any drone, we can move and render the laser.

Iterate Drones -- Move and Render

As before, all surviving drones are moved and rendered in a single step.


for drone in &game.drones
{

    if drone.health > 0
    {
        drone.dest.x -= i32(get_delta_motion(drone.dx))
        SDL.RenderCopy(game.renderer, game.drone_tex, nil, &drone.dest)
    }

}

Challenges

Implement more interesting flight behavior for the drones.
Only destroy drones once they've been hit numerous times.

How to Render Dynamic Text with SDL2

Patrick O'Dacre — Thu, 29 Dec 2022 20:47:08 +0000

The Code :: https://github.com/patrickodacre/sdl2-odin-examples/tree/master/render-dynamic-text

This is a method I came up with for rendering dynamic text.

By "dynamic" I mean text that isn't known at compile time -- text that comes from keyboard input events.

This is a fairly simple example -- things like word-wrapping and line breaks aren't handled.

If you haven't already read the guide on Rendering Static Text, please do so before reading this one.

Texture Map

First, we create a map so we can lookup textures for numbers, letters, and other symbols.


// create a map of chars that be used in make_word
create_chars :: proc()
{

    chars := " ?!@#$%^&*();:',.@_0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"

    for c in chars[:]
    {
        str := utf8.runes_to_string([]rune{c})
        defer delete(str)

        game.chars[c] = create_text(cstring(raw_data(str)))
    }

}

Our map and related Text struct are defined and initialized like so:


Text :: struct
{
    tex: ^SDL.Texture,
    dest: SDL.Rect,
}

Game :: struct
{
    // existing code..

    chars: map[rune]Text,
}

game := Game{
    chars = make(map[rune]Text),
}

To create the Text objects stored in our game.chars map we use the create_text function from the last guide:

COLOR_WHITE : SDL.Color : {255,255,255,255}

// create textures for the given str
// optional scale param allows us to easily size the texture generated
// relative to the current game.font_size
create_text :: proc(str: cstring, scale: i32 = 1) -> Text
{
    // create surface
    surface := SDL_TTF.RenderText_Solid(game.font, str, COLOR_WHITE)
    defer SDL.FreeSurface(surface)

    // create texture to render
    texture := SDL.CreateTextureFromSurface(game.renderer, surface)

    // destination SDL.Rect
    dest_rect := SDL.Rect{}
    SDL_TTF.SizeText(game.font, str, &dest_rect.w, &dest_rect.h)

    // scale the size of the text
    dest_rect.w *= scale
    dest_rect.h *= scale

    return Text{tex = texture, dest = dest_rect}
}

This map of Text objects helps us when it comes time to render the text we capture from the TEXTINPUT event.

We render our captured text in our game loop:


game_loop : for
{

    if SDL.PollEvent(&event)
    {
        if end_game(&event) do break game_loop

        handle_events(&event)
    }


    // START update and render

    char_spacing : i32 = 2
    prev_chars_w : i32 = 0

    starting_x : i32 = 100
    starting_y : i32 = 100

    // iterate characters in the string
    for c in game.text_input
    {
        // grab the texture for the single character
        char : Text = game.chars[c]

        // render this character after the previous one
        char.dest.x = starting_x + prev_chars_w
        char.dest.y = starting_y

        SDL.RenderCopy(game.renderer, char.tex, nil, &char.dest)

        prev_chars_w += char.dest.w + char_spacing
    }

    // END update and render

    draw_scene()
}

Our render code goes through each character in a string -- game.text_input, finds its corresponding texture in our texture map, then renders that texture next to the previous one. Using prev_chars_w allows us to keep track of where to place our current character as we iterate through all characters in the string.

But how do we capture the text input from the keyboard?

Taking Keyboard Input


handle_events :: proc(event: ^SDL.Event)
{

    scancode := event.key.keysym.scancode

    if event.type == SDL.EventType.TEXTINPUT
    {
        input := cstring(raw_data(event.text.text[:]))
        game.text_input = strings.concatenate({game.text_input, string(input)})
    }

    if scancode == .BACKSPACE
    {
        //
    }

}

In our handle_events() function we handle all TEXTINPUT events to grab the text from event.text.text. It's necessary to transform the text slice to a cstring to strip out any odd characters -- cstring(raw_data(event.text.text[:])). We then concatenate the current string with the new input. strings.concatenate({game.text_input, string(input)}).

If we make a mistake, deleting the last character is easy. We take a slice of the current string being sure to leave off the last character in the string.


handle_events :: proc(event: ^SDL.Event)
{

    scancode := event.key.keysym.scancode

    if event.type == SDL.EventType.TEXTINPUT
    {
        //
    }

    if scancode == .BACKSPACE
    {
        if len(game.text_input) > 0
        {
            input := game.text_input[:len(game.text_input) -1]
            game.text_input = input
        }
    }

}

StartTextInput(), StopTextInput(), and SetTextInputRect()

Solid information on these functions is hard to find. They don't seem necessary for running this on Windows, though perhaps they are necessary for running a program on a phone, or accepting non-English text.

If you have more information to shed some light on these functions, please share.

How to Render Static Text with SDL2

Patrick O'Dacre — Thu, 29 Dec 2022 20:44:45 +0000

The Code :: https://github.com/patrickodacre/sdl2-odin-examples/tree/master/render-static-text

To render the text to the screen we still require our game loop. I've tried to move as much of that boilerplate / secondary code outside of the main function so you can focus on what is necessary for rendering text.

Initializing the SDL TrueType Font Library

As with all SDL libraries, we need to initialize the TTF library before we can use it, and this includes chosing the font we want to use for the text textures we want to render. For our example we'll use the Terminal font.


init_font := SDL_TTF.Init()
assert(init_font == 0, SDL.GetErrorString())
game.font = SDL_TTF.OpenFont("Terminal.ttf", game.font_size)
assert(game.font != nil, SDL.GetErrorString())

Creating Textures from Our Chosen Text

Next we'll create a helper function for creating our text textures:


// create textures for the given str
// optional scale param allows us to easily size the texture generated
create_text :: proc(str: cstring, scale: i32 = 1) -> Text
{
    // create surface
    surface := SDL_TTF.RenderText_Solid(game.font, str, COLOR_WHITE)
    defer SDL.FreeSurface(surface)

    // create texture to render
    texture := SDL.CreateTextureFromSurface(game.renderer, surface)

    // destination SDL.Rect
    dest_rect := SDL.Rect{}
    SDL_TTF.SizeText(game.font, str, &dest_rect.w, &dest_rect.h)

    // scale the size of the text
    dest_rect.w *= scale
    dest_rect.h *= scale

    return Text{tex = texture, dest = dest_rect}
}

With the exception of the text itself and the sizing, the code is the same for creating each texture. Using this helper function allows us to avoid typing the same code again and again.

The Text Struct

Notice the create_text function returns a new object -- Text


Text :: struct
{
    tex: ^SDL.Texture,
    dest: SDL.Rect,
}

This struct holds a reference to our texture and the SDL.Rect used to render the texture to the window.

What is a texture? It is the object we render to the window in the rectangular space designated by the SDL.Rect created. It is created from the cstring text we want to display in our chosen font.

We're creating these textures before our loop. We only need to create our texture once for a given size; there's no need to recreate these textures on each game loop iteration.


game.texts[TextId.Title] = create_text("Testing", 3)
game.texts[TextId.SubTitle] = create_text("One, Two, Three")

TextId Enum

To help keep track of our Text objects we're storing each in an enumerated array with easy-to-read lookup keys that are enum variants.

Enums, or Enumeration Types, define a new type with the values we choose. In our case we have a type of TypeId with possible values Title and SubTitle.

When we want to render one of our text textures, we just have to get it from our array and tell SDL where to render it:


title := game.texts[TextId.Title]
// render roughly at the center of the window
title.dest.x = (WINDOW_WIDTH / 2) - (title.dest.w / 2)
title.dest.y = (WINDOW_HEIGHT / 2) - (title.dest.h)
SDL.RenderCopy(game.renderer, title.tex, nil, &title.dest)

Changing Font Size

There are two ways we change the font size after we set it with SDL_TTF.OpenFont():

Re-setting the font_size using SDL_TTF.SetFontSize() and recreating any textures.
Scaling our destination SDL.Rect to which we render our texture.

How to Do Things With SDL2

Patrick O'Dacre — Fri, 09 Dec 2022 11:29:19 +0000

Today I started a new project for sharing concise examples on how to do things with SDL2 and the Odin programming language.

I'm on a mission to help others program games from scratch. I publish content for complete beginners to programming, and those just new to game programming.

Beginners Learning to Code

Most people interested in learning how to code end up learning to program in the context of web development.

While web development can be fun, it is complex, and beginners are usually forced to learn a lot of secondary technology before they can start writing interesting programs.

In the earlier days of computing, many skilled programmers got their start by programming their own games. It is a fun, creative, challenging, and very effective way to learn how to code.

Learn to Code by Making Games

If you'd like to learn how to code, follow me on YouTube and Twitter. I'm really busy making a mix of beginner and intermediate-level content to help you learn programming in a unique and fun way.

Space Shooter Game with SDL2 and Odin - Part 6 - Spawning Enemy Drones

Patrick O'Dacre — Fri, 09 Dec 2022 11:03:30 +0000

Part 6 :: Spawning Enemies

In this part we'll focus on spawning some enemy drones. For now, they'll have unrestricted access to the galaxy, but later on we'll be sure to change that.

The logic to spawn the enemies isn't too complicated, and it gives us an opportunity get more familiar with Odin's Math library. The Rand package will allow us to make our enemies a little more interesting.

We'll have to make some changes to our Entity struct again. The changes will allow us more fine control over how our enemy drones move.

Now let's complete the following tasks:

Add new constants and Game struct fields for our drones
Create Drones
Spawn Drones
Give Drones variable speeds

Drone Struct Fields and Constants

It's best to follow the same ordering of the constants and Game struct fields added for our lasers. I often try to stick to conventions / ordering like this to make it easier on my eyes to read through the code.

LASER_SPEED : f64 : 700
LASER_COOLDOWN_TIMER : f64 : 50
NUM_OF_LASERS :: 100

// NEW
DRONE_SPEED : f64 : 700
DRONE_SPAWN_COOLDOWN_TIMER : f64 : 700
NUM_OF_DRONES :: 10
// END NEW

Game :: struct
{
    // ...

    laser_tex: ^SDL.Texture,
    lasers: [NUM_OF_LASERS]Entity,
    fire: bool,
    laser_cooldown : f64,

    // NEW
    drone_tex: ^SDL.Texture,
    drones: [NUM_OF_DRONES]Entity,
    drone_spawn_cooldown: f64,
    // END NEW
}

With these settings we limit the number of drones that may appear on the screen at the same time to 10. We also use a cooldown timer to make sure drones don't spawn too quickly. We decrement the cooldown timer using our delta multiplier.


// TIMERS
game.laser_cooldown -= get_delta_motion(LASER_SPEED)
// NEW
game.drone_spawn_cooldown -= get_delta_motion(DRONE_SPEED)
// END NEW

You can play around with these settings until you get the number of enemies and speeds you like. In the future, these settings can be dynamically changed based on game level changes or other events.

Creating our Enemy Drones

In the create_entities() procedure we create our drones after creating our lasers. Again, we try and follow the same pattern as with creating our lasers.


// drones
drone_texture := SDL_Image.LoadTexture(game.renderer, "assets/drone_1.png")
assert(drone_texture != nil, SDL.GetErrorString())
drone_w : i32
drone_h : i32
SDL.QueryTexture(drone_texture, nil, nil, &drone_w, &drone_h)

game.drone_tex = drone_texture

for index in 0..=(NUM_OF_DRONES - 1)
{
    destination := SDL.Rect{
        x = -(drone_w),
        y = 0,
        w = drone_w / 5, // drone image is also a bit too large
        h = drone_h / 5,
    }

    game.drones[index] = Entity{
        dest = destination,
    }
}

Spawning Drones

Now that we have our fixed array of drones, we are free to spawn them. We'll spawn them on the far-right side of our window, and have them fly towards us on the left until they disappear. Our lasers are spawned once we hit the spacebar, but our drones will just spawn as soon as they become available after disappearing on the left side.

for l in &game.lasers
{
    if l.dest.x < WINDOW_WIDTH
    {
        l.dest.x += i32(get_delta_motion(LASER_SPEED))
        SDL.RenderCopy(game.renderer, game.laser_tex, nil, &l.dest)
    }
}


// NEW
// Spawn Drones
for drone, idx in &game.drones
{

    if drone.dest.x <= 0 && !(game.drone_spawn_cooldown > 0)
    {
        drone.dest.x = WINDOW_WIDTH
        drone.dest.y = i32(rand.float32_range(120, WINDOW_HEIGHT - 120))

        game.drone_spawn_cooldown = DRONE_SPAWN_COOLDOWN_TIMER
    }

    steps := i32(get_delta_motion(DRONE_SPEED))
    drone.dest.x -= steps

    if drone.dest.x > 0
    {
        SDL.RenderCopy(game.renderer, game.drone_tex, nil, &drone.dest)
    }

}

// END NEW


// TIMERS
game.laser_cooldown -= get_delta_motion(LASER_SPEED)
game.drone_spawn_cooldown -= get_delta_motion(DRONE_SPEED)

This is our first look at the Odin Rand library. Look above at the rand.float32_range() procedure call. It takes two arguments -- a min and a max value. We use it to choose a random location on the y plane so our drones don't all fly along the same path on our y-axis.

Variable Drone Speeds

Having the drones all fly at the same speed isn't very interesting. Let's make each drone fly at a slightly different speed.

To accomplish this, we'll have to add some new fields to our Entity struct.


Entity :: struct
{
    dest: SDL.Rect,
    // NEW
    dx: f64,
    dy: f64,
    // END NEW
}

These dx and dy fields will capture the speed at which the Entity should travel.

By adding these to the Entity struct, we'll have to update our game.player and lasers to use these fields, as well. While we don't strictly need them to use these fields right now, it's nice to be consistent, and eventually we may want to dynamically manipulate their speeds, anyway.

We'll have to update code in our create_entities() procedure, as well as wherever we use get_delta_motion() to get delta movement amounts for each entity.

Entity Creation


game.player_tex = player_texture
game.player = Entity{
    dest = destination,
    // NEW
    dx = PLAYER_SPEED,
    dy = PLAYER_SPEED,
    // END NEW
}

// ...


game.lasers[index] = Entity{
    dest = destination,
    // NEW
    dx = LASER_SPEED,
    dy = LASER_SPEED,
    // END NEW
}

// ...


// NEW
// randomize speed to make things more interesting
max := DRONE_SPEED * 1.2
min := DRONE_SPEED * 0.5
random_speed := rand.float64_range(min, max)
// END NEW

game.drones[index] = Entity{
    dest = destination,
    // NEW
    dx = random_speed,
    dy = random_speed,
    // END NEW
}

Here we see Odin's Rand library again. rand.float64_range() also takes two arguments -- a min and a max value. For now we're making the random speed multiplier the same for both horizontal and vertical movements along the x and y axes.

Of course we now have to update the code where we handle entity position changes -- the update and render portion of our game loop.

Entity Updates

// 3. Update and Render

// update player position, etc...
// NEW -- changing our PLAYER_SPEED for the dx and dy on the player entity
delta_motion_x := get_delta_motion(game.player.dx)
delta_motion_y := get_delta_motion(game.player.dy)

if game.left
{
    // NEW
    move_player(-delta_motion_x, 0)
}

if game.right
{
    // NEW
    move_player(delta_motion_x, 0)
}

if game.up
{
    // NEW
    move_player(0, -delta_motion_y)
}

if game.down
{
    // NEW
    move_player(0, delta_motion_y)
}


// ...

for l in &game.lasers
{
    if l.dest.x < WINDOW_WIDTH
    {
        // NEW -- changing our LASER_SPEED for the l.dx setting on this single laser entity
        l.dest.x += i32(get_delta_motion(l.dx))
        SDL.RenderCopy(game.renderer, game.laser_tex, nil, &l.dest)
    }
}

// ...


// Spawn Drones
for drone, idx in &game.drones
{

    if drone.dest.x <= 0 && !(game.drone_spawn_cooldown > 0)
    {
        drone.dest.x = WINDOW_WIDTH
        drone.dest.y = i32(rand.float32_range(120, WINDOW_HEIGHT - 120))

        game.drone_spawn_cooldown = DRONE_SPAWN_COOLDOWN_TIMER
    }

    // NEW -- changing our DRONE_SPEED for the drone.dx setting on this single drone entity
    steps := i32(get_delta_motion(drone.dx))
    drone.dest.x -= steps

    if drone.dest.x > 0
    {
        SDL.RenderCopy(game.renderer, game.drone_tex, nil, &drone.dest)
    }

}

For now we're just moving our drones horizontally, but in future parts we'll give them a little bit of vertical movement, as well. Be sure to keep an eye on this series to catch that update!

Suggested Challenges

In the next part we'll give our player the ability to destroy these drones -- they've been terrorizing the galaxy for far too long!

See if you can figure out the basic collision detection needed to make that happen.

If you get something working, share it in the comments beneath this video!

Learn to Code by NOT Doing What Everyone Else Does

Patrick O'Dacre — Mon, 28 Nov 2022 22:41:24 +0000

Space Shooter Game with SDL2 and Odin - Part 5 - Firing MANY Lasers

Patrick O'Dacre — Thu, 03 Nov 2022 07:08:16 +0000

Part 5 :: Firing Many Lasers

We left Part 4 with a challenge to discover a way to fire more than one laser. If you haven't yet attempted this update, please do so before going through Part 5.

In this part we'll cover how to fire many lasers.

Some Simple Upkeep
Store a finite number of lasers in a fixed array.
Reload our laser cannon once a laser goes offscreen.
Balance laser speed with the number of lasers so we always have plenty of ammo.

Some Basic Upkeep

Before we get started I want to highlight some minor fixes made to the code.

Fixing Our Frame Rate

Previously we calculated our TARGET_DELTA_TIME like so:


TARGET_DELTA_TIME :: 1000 / 60

This constant defaulted to a int type, and so our target frame rate was truncated to 16 milliseconds. That resulted in an FPS of 62 frames per second. That was a mistake.

Rather, the code to calculate our target delta time should have been:


TARGET_DELTA_TIME :: f64(1000) / f64(60)

This would give us an f64 and an accurate frame time of 16.667 milliseconds, which would give us our desired 60 FPS.

Our new get_delta_motion() procedure would then have to be updated:


get_delta_motion :: proc(speed: f64) -> f64
{
    return speed * (TARGET_DELTA_TIME / 1000)
}

A Fixed Array of Lasers

To keep tight control over the number of lasers we have to keep track of, we'll start with using a fixed array.


NUM_OF_LASERS :: 100

Game :: struct
{
    // ...

    lasers: [NUM_OF_LASERS]Entity,

    // ...
}

Adjusting the laser limit and the laser speed will take some trial and error to ensure the player never feels like they don't have enough lasers. In other words, we want to make sure lasers reach the end of the screen and replenish quickly enough so we rarely meet the end of our laser supply.

We'll create our lasers at game startup, filling in our array with our now-simplified entities.


laser_texture := SDL_Image.LoadTexture(game.renderer, "assets/bullet_red_2.png")
assert(laser_texture != nil, SDL.GetErrorString())
laser_w : i32
laser_h :i32
SDL.QueryTexture(laser_texture, nil, nil, &laser_w, &laser_h)

game.laser_tex = laser_texture

for index in 0..=(NUM_OF_LASERS-1)
{
    destination := SDL.Rect{
        x = WINDOW_WIDTH + 20, // offscreen means available to fire
        w = laser_w / 3,
        h = laser_h / 3,
    }

    game.lasers[index] = Entity{
        dest = destination,
    }
}

Notice the changes to the Game struct and the Entity struct:


Game :: struct
{
    perf_frequency: f64,
    renderer: ^SDL.Renderer,

    // player
    player: Entity,
    player_tex: ^SDL.Texture, // NEW
    left: bool,
    right: bool,
    up: bool,
    down: bool,


    laser_tex: ^SDL.Texture, // NEW
    lasers: [NUM_OF_LASERS]Entity, // NEW
    fire: bool,
    laser_cooldown : f64, // NEW
}

Entity :: struct
{
    dest: SDL.Rect,
}

laser_tex and player_tex are added to the Game struct and the tex fields are removed from the Entity struct.

Why?

We're creating 100 lasers, and there is no need to create 100 textures -- only one texture is needed.

We also removed our health field from the Entity struct. We can track laser lifetimes by checking their x position. (NOTE :: I went back to using Health later on. It was better.)

Reloading our Laser Cannon

Each time a player "fires" a laser we need to iterate through our array of lasers and find the first one whose x position is greater than the width of the window, i.e.: is offscreen. That one laser that is offscreen is then "reloaded" by having its x and y position reset.

Choosing the Right NUM_OF_LASERS, LASER_SPEED, and LASER_COOLDOWN_TIMER

We have 100 lasers available to us, and our laser cooldown timer counts down each frame by an amount relative to the frame rate and the LASER_SPEED. With the timer set to 50, a laser will move approximately 50 pixels before another can be fired.


// FIRE LASERS
if game.fire && !(game.laser_cooldown > 0)
{
    // find a laser:
    reload : for l in &game.lasers
    {
        // find the first one available
        if l.dest.x > WINDOW_WIDTH
        {

            l.dest.x = game.player.dest.x + 20
            l.dest.y = game.player.dest.y
            // reset the cooldown to prevent firing too rapidly
            game.laser_cooldown = LASER_COOLDOWN_TIMER

            break reload
        }
    }
}

for l in &game.lasers
{
    if l.dest.x < WINDOW_WIDTH
    {
        l.dest.x += i32(get_delta_motion(LASER_SPEED))
        SDL.RenderCopy(game.renderer, game.laser_tex, nil, &l.dest)
    }
}


// decrement our cooldown
game.laser_cooldown -= LASER_SPEED * (TARGET_DELTA_TIME / 1000)

Our cooldown timer is reset each time we fire a laser. We cannot fire a laser until our cooldown timer goes below ZERO.

With the settings we have right now I don't feel like we run out of ammunition too quickly, but you should feel free to change these settings to match your tastes.

Suggested Challenges

In the next part we'll cover adding enemies to the window. By now you should understand how to render images to the screen, so you should try adding a few enemies that our player must battle.

Good luck!

Space Shooter Game with SDL2 and Odin - Part 4 - Firing a Laser

Patrick O'Dacre — Fri, 28 Oct 2022 07:07:13 +0000

In this part of the series we tackle the following:

add a new procedure - create_entities()
creating a new "laser" entity
firing a single laser with the spacebar key

create_entities()

Our main procedure is getting a little large, so let's move all of code for creating new entities to a dedicated procedure. Normally, I would not be so quick to move things to a dedicated procedure, but this isn't code we need to look at again and again, so I don't mind getting it out of the way.

Our Laser Entity

Our Laser Entity is very similar to our main Player Entity:

it's a png
it's not a sprite sheet but a single image
it's a little large, and it needs to be scaled down

You can download the laser image here.

We'll load our .png in the same way we loaded our player image, and we'll resize it to better match our main player spaceship.


    laser_texture := SDL_Image.LoadTexture(game.renderer, "assets/bullet_red_2.png")
    assert(laser_texture != nil, SDL.GetErrorString())
    SDL.QueryTexture(laser_texture, nil, nil, &destination.w, &destination.h)
    destination.w /= 3
    destination.h /= 3

    game.laser = Entity{
        tex = laser_texture,
        dest = destination,
        health = 0,
    }

Notice the new "health" field added to the Entity struct. health gives us a simple way to track whether or not our laser should be rendered to the screen.

Firing our Laser

Each time the player hits the spacebar, we'll fire our laser.


game.fire = state[SDL.Scancode.SPACE] > 0

To enforce single shots, our laser will only fire if the health is 0. Once fired, the laser health is reset to 1 and its position is set to just beyond the current position of the ship, so it appears to be firing directly from the ship.


if game.fire && game.laser.health == 0
{
    game.laser.dest.x = game.player.dest.x + 30
    game.laser.dest.y = game.player.dest.y
    game.laser.health = 1
}

Once our laser disappears offscreen, we reset the health to 0 so we can fire it again.


if game.laser.dest.x > WINDOW_WIDTH
{
    game.laser.health = 0
}

We only want to render our laser to the screen if it has been fired and hasn't yet disappeared offscreen.


if game.laser.health > 0
{
    game.laser.dest.x += i32(get_delta_motion(LASER_SPEED))
    SDL.RenderCopy(game.renderer, game.laser.tex, nil, &game.laser.dest)
}

To decide how quickly we should move our laser we use a new constant LASER_SPEED. As with our player, we want our laser to move at the rate we choose irrespective of the frame rate, so we need to calculate its delta motion. Since this operation is now performed on both the player and the laser we can create a new procedure get_delta_motion()


get_delta_motion :: proc(speed: f64) -> f64
{
    return speed * (f64(TARGET_DELTA_TIME) / 1000)
}

get_delta_motion() is similar to another procedure we wrote get_time() -- both procedures return a value. In Odin return values are specified using this arrow syntax ->.

Suggested Challenge

Try and find a way to fire more than one laser at a time.

I came up with a way using one of Odin's array types - a Fixed Array.

Odin has Fixed Arrays and Dynamic Arrays. Fixed Arrays have a set length that cannot be changed; whereas, Dynamic Arrays can grow dynamically to suit runtime requirements.

Try to give your ship a fixed number of lasers to fire using a Fixed Array. Once a laser goes offscreen, it should be made available again to fire.

Good luck!

Space Shooter Game with SDL2 and Odin - Part 3 - Keyboard Input and Delta Time

Patrick O'Dacre — Mon, 17 Oct 2022 20:17:36 +0000

There are numerous ways to handle keyboard input for player movement.

The easiest method I have found so far consists of the following parts:

SDL.GetKeyboardState() or SDL.PollEvent() for KEYDOWN / KEYUP events
(Delta Time or Enforced Frame Rate) * target_pixels_per_second

SDL.GetKeyboardState()

This function allows us to check which keys on the keyboard are pressed. In our code we set 4 booleans based on the state of the 4 movement keys we're interested in -- WASD.

The other way to set these boolean flags is to set them to true on the appropriate KEYDOWN event and false on the corresponding KEYUP event. KEYDOWN means the key has been pressed. KEYUP means the key has been released.

This second method, though, requires us to also check if the KEYDOWN or KEYUP event is either a repeated event, or the initial pressing / releasing of that key. If we do not distinguish between the two we could get some strange behavior as we poll the event queue.


state := SDL.GetKeyboardState(nil)

game.left = state[SDL.Scancode.A] > 0
game.right = state[SDL.Scancode.D] > 0
game.up = state[SDL.Scancode.W] > 0
game.down = state[SDL.Scancode.S] > 0

// versus ...

if event.type == SDL.EventType.KEYDOWN
{
    // not repeated
    if event.repeat == 0
    {

        if event.key.keysym.scancode == SDL.Scancode.A
        {
            game.left = true
        }
        /// ...
    }
}

if event.type == SDL.EventType.KEYUP
{
    // not repeated
    if event.repeat == 0
    {

        if event.key.keysym.scancode == SDL.Scancode.A
        {
            game.left = false
        }
        /// ...
    }
}

I think you'll agree that checking the keyboard state is much nicer to look at. This second option is too verbose for what we need.

delta_time and Delta Motion

Delta Motion is the incremental movement calculated for the present frame based on the time it took to complete the previous frame -- the delta time. In practice, this delta time is multiplied by the desired travel distance measured in pixels per second. This ensures that movement doesn't speed up or slow down when the frame rate changes from machine to machine.


delta_motion := PLAYER_SPEED * (f64(TARGET_DELTA_TIME) / 1000)

if game.left
{
    move_player(-delta_motion, 0)
}

if game.right
{
    move_player(delta_motion, 0)
}

if game.up
{
    move_player(0, -delta_motion)
}

if game.down
{
    move_player(0, delta_motion)
}

I would also like to point out a handy Odin function for ensure the player doesn't move off screen:


move_player :: proc(x, y: f64)
{
    game.player.dest.x = clamp(game.player.dest.x + i32(x), 0, WINDOW_WIDTH - game.player.dest.w)
    game.player.dest.y = clamp(game.player.dest.y + i32(y), 0, WINDOW_HEIGHT - game.player.dest.h)
}

clamp() returns the given value provided it is between the given min and max arguments; otherwise, it will return the min or the max value provided.

In other games I've used a combination of min() and max() that work well for basic collision detection, but for now clamp() does a good job.

SDL.RenderCopy()

Once we're done updating the player position, it is time to render that player to the window. Keep in mind that we're not displaying the updated player position, yet. We're rendering the image in the background, drawing the scene that will be displayed when we next call SDL.RenderPresent().

Odin Highlights

Variable Declarations

In Odin, the colon : is used for variables and other type declarations.

When we declare a constant for the player's speed, we specify an f64 type rather than allow the constant to default to an int


PLAYER_SPEED : f64 : 500 // pixels per second

Notice how our struct and procedure declarations follow the same pattern:


Entity :: struct
{
    tex: ^SDL.Texture,
    dest: SDL.Rect,
}

main :: proc()
{
    //
}

Package Naming

In the first parts of this series we named our package "main", but this is just an arbitrary name -- we can name our "main" package anything we want, so I renamed it "game".


package game

import "core:fmt"
import SDL "vendor:sdl2"
import SDL_Image "vendor:sdl2/image"

Notice also that we gave custom names to our imported packages.

Had we not chosen SDL and SDL_Image, we would reference these imported packages with sdl2 and image prefixes like so:


assert(sdl2.Init(sdl2.INIT_VIDEO) == 0, sdl2.GetErrorString())
assert(image.Init(image.INIT_PNG) != nil, sdl2.GetErrorString())
defer sdl2.Quit()

Nice and simple!

Suggested Exercises

Player movement is an interesting subject, and I have published a few videos documenting my search for a deeper understanding.

Perhaps you will find it helpful to download my movement tool visualization tool detailed here in this video.

To practice, you should experiment with the different ways to handle movement. Perhaps you can figure out how to use SDL to handle input from a game controller.

Be sure to post about your progress in the comments for this video.

Good luck!