Forem: Shawn Holland

Developing A Game Engine with Perl: Part 8 - Vim

Shawn Holland — Mon, 06 Dec 2021 07:41:20 +0000

As Always... I DO NOT KNOW WHAT I AM DOING.

If you want to start reading from the beginning. Check out the first article in this series

Let's step back from typing code for a moment and talk about how that code is typed. There are many options for a developer to code with, and we all have a preference. It's not so much a matter of right and wrong, as it is of comfort and enjoyment. For me, I code in Vim.

...and Coding in Vim is fun

I was introduced to Vim back in college. Our school used AIX for their server OS and we were taught to use Vim. This was also my first introduction to a Unix environment. Coming from a home Dos/Windows environment and entering the Unix world came with challenges.

Using Vim twisted my brain and took a bit to get use to. But today, after using it for many years, it often feels very rhythmic and fun to code. Also, not gonna lie, it kinda makes me feel that sense of "coolness" I got when watching Hackers for the first time.

Hahaha... That movie does NOT hold up well! Teenager me was so impressionable.

$me->hides_face_in_shame();

We can verify my shame level using this code:

use strict;
use warnings;
use Shameful::movies;

my $movie  = shift;
my $me     = new Shameful::movies();
my $shame  = $me->watched($movie);
my $return = "Great Movie!";

if ($shame) {
    $return = $me->hides_face_in_shame($movie);
}

print $return;
exit;

Running that code prints out the following.

localhost:~/Fake_But_Should_Be_Real_Scripts/ # 
perl i_loved_watching.pl Hackers

Hack the planet!... More like Hide your face bro!

ANSI in Vim

Working with ANSI codes directly in Vim I see a lot of ^[.

Now this ^[ isn't the same as shift+6 and [. No, this represents the escape character and is highlighted blue in my Vim. If it was shift+6 and [ it would be coloured the same as regular text. Something very useful to know, you can type the escape character in Vim by pressing ctrl+v and then the escape key.

I split Vim up to open multiple files

I use the :split and :vsplit command in Vim often to load in other files. Using split will stack files above/below each other (split horizontally) and vsplit does side by side (vertically). Sometimes I need to combine split and vsplit to have 3 files at once. Switching between each file in (v)split can be done with ctrl+w+w

So Colourful

Vim supports colour schemes. It's something I don't change often, so I always forget and have to look it up. Since I just did it recently after upgrading the dev/test server, I'll share here with you all. You can change it with the :colorscheme command. The one I'm using is :colorscheme peachpuff. I also have syntax highlighting turned on with the :syntax on. I made it permanent by adding the commands to ~/.vimrc I code in OpenSuSE Linux, Vim config files may vary with your OS.

Don't try this at work

Running a bulk search and replace can cause unexpected results if you're not careful. I know I'm thankful for whoever invented undo.

There are many ways to search and replace the contents of a file in Linux and Perl. However, when I'm in Vim, I often find it quickest to use the :%s command. Typically when I need to apply a search and replace to a whole file I use a command like this:

:%s/\^[//g

The format is :%s/search_pattern/replace_with/g The search pattern I used in the above example is to find the escape character ^[ I mentioned earlier and replace every occurrence with nothing //g. I have to precede ^[ with \ so the regular expression search pattern knows it's a literal escape character. I type ^[ using ctrl+v and pressing escape.

How about you?

Do you code in Vim? What sort of tricks and tips have you learned? What colorscheme do you prefer?

If you have any suggestions or comments please share constructively. Also please visit our social media pages for lots of fun videos and pictures showing the game engine in action.

ANSI Game Engine on Instagram
ANSI Game Engine on Facebook

Prev << Part 7 - Fork
Next >> Coming Soon

Developing A Game Engine with Perl: Part 7 - Fork

Shawn Holland — Fri, 03 Dec 2021 23:34:45 +0000

Pssssst... I DO NOT KNOW WHAT I AM DOING.

If you want to start reading from the beginning. Check out the first article in this series

Continuing from our last post, I talked about how ANSI Game Engine is a colourful telnet server. We left off with needing to fork the engines telnet server.

Player 2 has joined the game!

Time to level up our telnet server and make it multi-player with some knify forky.

I've added in the strftime identifier from Perl's POSIX module to help with time stamping the output. The setsid identifier is for starting a new session and group ID for each forked process. A.K.A, the child process. :sys_wait_h is for returning without wait after the child process has exited, using the WNOHANG flag when calling waitpid(). This provides non-blocking wait for all pending zombie children.

Zombie Attack!!!

You see, when a process dies (exits), it becomes a zombie and needs to be reaped. This will be done when our parent process calls waitpid after receiving a CHLD signal, indicating the child has stopped or terminated.

Ok, I hope that will give you enough information to work with while dissecting the code:

#!/usr/bin/perl
use strict;
use warnings;
use IO::Socket::INET;
use POSIX qw(setsid);
use POSIX qw(strftime);
use POSIX ":sys_wait_h";

sub timestamp {
    my $epoc_seconds = time();
    my $time = strftime "%H:%M:%S", localtime($epoc_seconds);
    my $date = strftime "%m/%d/%Y", localtime;
    my $return = $date . " " . $time;
    return ($return);
}

sub logmsg { print timestamp . " -> $0 -> PID:$$: @_ \n" }
logmsg "Begin";

my $socket = new IO::Socket::INET (
    LocalHost => '192.168.1.15',
    LocalPort => '27777',
    Proto => 'tcp',
    Listen => SOMAXCONN,
    ReuseAddr => 1
);

my $waitedpid = 0;
my $player_data;
my $player_socket;

sub REAPER {
    local $!;   # don't let waitpid() overwrite current error
    logmsg "Ending Player's Game";
    while ((my $pid = waitpid(-1, WNOHANG)) > 0 && WIFEXITED($?)) {
        logmsg "Closed Game ID:$pid : WaitPid:$waitedpid : " . ($? ? " with exit $?" : "");
    }
    $SIG{CHLD} = \&REAPER;  # loathe SysV
}
#if we get the CHLD signal call REAPER sub
$SIG{CHLD} = \&REAPER;

logmsg "Ready and waiting for connection";
while(1)
{
    next unless $player_socket = $socket->accept();
    logmsg ("Incomming Connection");
    logmsg ("Spawning Player A Game");
    my $pid = fork();

    next if $pid; #NEXT if $pid exists (parent)

    #As Child
    setsid();
    my $proc = $$;

    logmsg ("Game ID:$proc -> Ready");

    # get information about a newly connected player
    my $player_address = $player_socket->peerhost();
    my $player_port    = $player_socket->peerport();
    logmsg "Game ID:$proc -> Connection from $player_address:$player_port";

    my $response = "Welcome Player: $player_address:$player_port. Press any key to disconnect.";
    $player_socket->send($response);

    while ($player_socket->connected()) {
        $player_socket->recv($player_data, 1024);
            if ($player_data) {
                logmsg "Player Disconnecting $player_address : $player_port";
                $socket->close();
                logmsg "Player Disconnected";
                last;
            }
    }
    last;
}
exit;

Running this code and connecting with two players via SyncTERM, our client of choice, shows the following:

localhost:~/ANSIGameEngine # perl forking_telnet_server.pl 
12/03/2021 18:16:58 -> forking_telnet_server.pl -> PID:15978: Begin 
12/03/2021 18:16:58 -> forking_telnet_server.pl -> PID:15978: Ready and waiting for connection 
12/03/2021 18:17:04 -> forking_telnet_server.pl -> PID:15978: Incomming Connection 
12/03/2021 18:17:04 -> forking_telnet_server.pl -> PID:15978: Spawning Player A Game 
12/03/2021 18:17:04 -> forking_telnet_server.pl -> PID:15979: Game ID:15979 -> Ready 
12/03/2021 18:17:04 -> forking_telnet_server.pl -> PID:15979: Game ID:15979 -> Connection from 192.168.1.9:33422 
12/03/2021 18:17:08 -> forking_telnet_server.pl -> PID:15978: Incomming Connection 
12/03/2021 18:17:08 -> forking_telnet_server.pl -> PID:15978: Spawning Player A Game 
12/03/2021 18:17:08 -> forking_telnet_server.pl -> PID:15980: Game ID:15980 -> Ready 
12/03/2021 18:17:08 -> forking_telnet_server.pl -> PID:15980: Game ID:15980 -> Connection from 192.168.1.9:33428 
12/03/2021 18:17:11 -> forking_telnet_server.pl -> PID:15979: Player Disconnecting 192.168.1.9 : 33422 
12/03/2021 18:17:11 -> forking_telnet_server.pl -> PID:15979: Player Disconnected 
12/03/2021 18:17:11 -> forking_telnet_server.pl -> PID:15978: Ending Player's Game 
12/03/2021 18:17:11 -> forking_telnet_server.pl -> PID:15978: Closed Game ID:15979 : WaitPid:0 :  
12/03/2021 18:17:13 -> forking_telnet_server.pl -> PID:15980: Player Disconnecting 192.168.1.9 : 33428 
12/03/2021 18:17:13 -> forking_telnet_server.pl -> PID:15980: Player Disconnected 
12/03/2021 18:17:13 -> forking_telnet_server.pl -> PID:15978: Ending Player's Game 
12/03/2021 18:17:13 -> forking_telnet_server.pl -> PID:15978: Closed Game ID:15980 : WaitPid:0 :

How it all works

The main (parent) process that accepts new incoming telnet requests is PID:15978 in the above example. After it sets up the listen server, it waits for a connection request and creates a forked process when a new player connects (child). The code distinguishes the parent (main waiting telnet server) process from the child (player) process with the value fork() returns. The parent process receives the child's (player) PID as the return value of fork(), so it loops back up and waits for another player to connect. The child (player) process receives a value of 0 from fork(), so we continue downward in the code. In Perl doing if($pid) does NOT evaluate TRUE if $pid == (0 || undef), which is what the child (player) process will receive as the returned value from fork(). We give the child (player) process a new session, record it's PID ($$) and wait for them to press any key. When the player presses a key the socket is closed and the child (player) process exists and becomes a zombie. This is when the parent (main) process receives the CHLD signal ($SIG{CHLD}) and calls REAPER

How about you?

Have you worked with fork before? Have you unleashed a zombie apocalypse forgetting to reap? Comment about your experience, I'd love to hear your stories.

If you have any suggestions or comments please share constructively. Also please visit our social media pages for lots of fun videos and pictures showing the game engine in action.

ANSI Game Engine on Instagram
ANSI Game Engine on Facebook

Prev << Part 6 - A Colourful Telnet Server
Next >> Part 8 - Vim

Cheers!
Shawn

Developing A Game Engine with Perl: Part 6 - A Colourful Telnet Server

Shawn Holland — Thu, 02 Dec 2021 09:06:57 +0000

I'll stop reminding you that... I DO NOT KNOW WHAT I AM DOING.

If you want to start reading from the beginning. Check out the first article in this series

What is ANSI Game Engine?

Well, at it's core, ANSI Game Engine is a very colourful and interactive telnet server.

Why telnet!?

I know, right!? I still ask myself the same question today, but at this point, I'm kinda committed. Initially, it all came down to my decision NOT to code the client side. I looked into it, and it just wasn't something I wanted to do. And honestly, it seemed too far outside my comfort level with Perl. I feel much more comfortable, and interested in, working with server side code, as may be true for other Perl dev's out there. That's where Perl is quite prolific. Since I was going with ANSI graphics, they are best known these days, for me at least, to be used in telnet/terminal clients and BBS's, which are mainly telnet based now. This being said, it wasn't long searching google before I came across SyncTERM. SyncTERM is, in my opinion, the best available choice for cross-platform rendering of ANSI graphics over telnet. I've tried many different clients, on Mac, Windows, and Linux. SyncTERM works the most consistent across these platforms, it's been around for a long time and is still actively being developed. So telnet it is!

Telnet.... Fork me...

The engine has to be multiplayer. Depending on the specific game requirements, this does not necessarily mean players interacting with each other, but at least having multiple players connected at the same time to the same server. This is a minimum initial requirement. To me, this is a great opportunity to work with Fork. I really like the idea of creating multiple processes with fork that can interact with each other. This is an area I have little experience with and a great opportunity to learn.

Have you heard of Perl's CPAN?

If you are a Perl dev, obviously yes. If you code in another language, perhaps you've heard of it. Comprehensive Perl Archive Network, or CPAN, is Perl's repository of code modules. If you want to do something, chances are someone has already made a module for that. As of writing this article, CPAN currently has 208,034 Perl modules written by 14,179 authors. It's absolutely amazing!

This is where I found the modules to develop a telnet server. A forking telnet server, can you believe it? Fork yah! Okokok.... I'll stop making that joke, I promise!

Let's get to coding!

The first step was to get a telnet server that could accept multiple simultaneous connections. I read up on how to make a telnet server with Perl and from that reading I quickly learned about IO::Socket::INET. It wasn't long after I had working code for a telnet server!

use strict;
use warnings;
use IO::Socket::INET;
print "\nBEGIN\n";

print "Setting up listen socket\n";
my $socket = new IO::Socket::INET (
    LocalHost => '192.168.1.15',
    LocalPort => '27777',
    Proto => 'tcp',
    Listen => SOMAXCONN,
    ReuseAddr => 1
);

my $player_socket;
my $player_data;

print "Waiting for connection ...\n";
while(1) {

    next unless $player_socket = $socket->accept();
    print "Incomming Connection!\n";

    my $player_address = $player_socket->peerhost();
    my $player_port    = $player_socket->peerport();

    my $response = "Player Connection Info: $player_address : $player_port. ";
    print "$response\n";

    $response .= "Press Any Key To Disconnect...\n";
    $player_socket->send($response);

    print "Waiting for player to press a key and disconnect...\n";
    while ($player_socket->connected()) {

        $player_socket->recv($player_data, 1024);
        if ($player_data) {
            print "Player Disconnecting $player_address : $player_port\n";
            $socket->close();
            print "Player Disconnected\n";
            last;
        }

    }
    last;
}
print "Good Bye!\n";
exit;

Running this code and connecting with SyncTERM shows:

localhost:~ # perl telnet_server.pl 

BEGIN
Setting up listen socket
Waiting for connection ...
Incomming Connection!
Player Connection Info: 192.168.1.9 : 55414. 
Waiting for player to press a key and disconnect...
Player Disconnecting 192.168.1.9 : 55414
Player Disconnected
Good Bye!

I read my Linux OpenSuSE server's man page for listen(2), and the best I can understand is that the value for SOMAXCONN in Listen => SOMAXCONN will allow me to have up to 4096 connections!? I think this is correct. It says the value can be found in /proc/sys/net/core/somaxconn and doing a cat of that file shows 4096.

localhost:~ # cat /proc/sys/net/core/somaxconn 
4096

Now we just need to fork!

This process turned out to be a bit more difficult to understand (for me) and a few more lines of code then did the telnet portion. I'll pick up from here in the next article.

Have you done any telnet programming before? If so, what modules have you found useful? (CPAN or otherwise)

If you have any suggestions or comments please share constructively. Also please visit our social media pages for lots of fun videos and pictures showing the game engine in action.

ANSI Game Engine on Instagram
ANSI Game Engine on Facebook

Prev << Part 5 - 32bit -> 64bit & Perl's Storable
Next >> Part 7 - Fork

Cheers!
Shawn

Developing A Game Engine with Perl: Part 5 - 32bit -> 64bit & Perl's Storable

Shawn Holland — Wed, 01 Dec 2021 03:14:32 +0000

If you haven't heard already... I DO NOT KNOW WHAT I AM DOING.

If you want to start reading from the beginning. Check out the first article in this series

Continuing on with the last article let's talk about changing system architecture and how that can affect Perl code, specifically Storable.

Mouse Input Support
Hardware Failure
Server Upgrade
UEFI vs OpenSuSE Installer
32bit -> 64bit & Perl's Storable

After the old server had HDD failures and finally managing to upgrade to the new server, I eagerly began getting all the services and software installed to test the engine on new hardware. I was quickly meet with an error I have never seen before.

Byte order is not compatible at /usr/lib/perl5/5.34.0/x86_64-linux-thread-multi/Storable.pm

After doing some quick reading, I came to understand that Perl uses architecture specific ways to save content to files when using Storable. Specifically if you use lock_store and store. These are part of Perl's core system and what I use throughout the engine for working with the file structure.

I had to carefully re-read the perldoc's to discover that you can avoid architecture incompatibility by simply using nstore and lock_nstore The method you use for retrieving the stored files doesn't matter, only when storing the data into files does it matter.

I tried to find ways of being able to convert the stored files from 32bit architecture to 64bit, but ultimately the only real option was to use the old server to re-store the files with lock_nstore.

Luckily the old PC was still working, and I was able to modify the code and re-store all the files. The change and usage was simple:

I had to change my use statement from:
use Storable qw(lock_store lock_retrieve);
to
use Storable qw(lock_nstore lock_retrieve)

And to re-store I changed my code from this:
lock_store($data_ref, $dir_location);
to
lock_nstore($data_ref, $dir_location);

Have you ever had to write code for architecture compatibility? Or fix code migrated from one architecture to another? What do you prefer for storing data to files in Perl?

If you have any suggestions or comments please share constructively. Also please visit our social media pages for lots of fun videos and pictures showing the game engine in action.

ANSI Game Engine on Instagram
ANSI Game Engine on Facebook

Prev << Part 4 - UEFI vs OpenSuSE Installer
Next >> Part 6 - A Colourful Telnet Server

Cheers!
Shawn

Developing A Game Engine with Perl : Part 4 - UEFI vs OpenSuSE Installer

Shawn Holland — Wed, 01 Dec 2021 02:34:10 +0000

I'm still learning so remember... I DO NOT KNOW WHAT I AM DOING.

If you want to start reading from the beginning. Check out the first article in this series

Continuing on with the last article let's talk about old hardware with UEFI. It can be difficult (for me) to know how to get Linux OpenSuSE installed properly.

Mouse Input Support
Hardware Failure
Server Upgrade
UEFI vs OpenSuSE Installer
32bit -> 64bit & Perl's Storable

A small computer and almost destroying it...

The last server's hard drive died, and I happen to have this old, but better, computer. It was in pieces, sitting in a box for a long time. Putting it back together was not easy. This Aspire X1470 is a small form factor design, meaning there is no room to spare. Also meaning if your computer has been sitting around in a box, in pieces for a long time, and its' frame gets bent... well that means it's going to be very difficult to get it back together. I managed to rip off a chip heatsink in the process. I tell ya, my stomach turned right over... but luckily it went back on and seems to be holding and working fine.

UEFI vs OpenSuSE Installer

This is where things get interesting. After finally getting the computer together, I downloaded the OpenSuSE ISO for 64bit. I went with Tumbleweed again. It worked well with the last server, so I'll just go with what I know. Tumbleweed is a rolling release linux, which means I shouldn't have to reinstall when a new version is released and I should still stay up to date. I created a bootable USB from ISO in Ubuntu 20.04 (My Desktop). Booted the new computer, installed OpenSuSE, and was happy... until I tried to reboot.

When I rebooted, I pulled out the USB stick and the BIOS said no boot drives. I knew of UEFI, and started reading. I found that in /boot/efi/ there was no EFI directory. If you don't know anything about UEFI (No worries, neither do I) ..apparently there is supposed to be a Fat32 partition marked as type EFI. The BIOS checks for this location and attempts to load the OS this way as apposed to using the MBR for booting like in the old days.

Here is what it looks like now in the server using fdisk to look at the partitions and tree to look at the directory structure:

localhost:/ # fdisk -l
Device          Start        End    Sectors  Size Type
/dev/sda1        2048    1050623    1048576  512M EFI System
/dev/sda2     1050624 2893709311 2892658688  1.3T Linux filesystem
/dev/sda3  2893709312 2930277134   36567823 17.4G Linux swap

localhost:/ # tree /boot/efi/
/boot/efi/
└── EFI
    ├── boot
    │   ├── MokManager.efi
    │   ├── bootx64.efi
    │   └── fallback.efi
    └── opensuse
        ├── MokManager.efi
        ├── boot.csv
        ├── grub.cfg
        ├── grub.efi
        ├── grubx64.efi
        └── shim.efi

You may need to scroll right to see the partition type EFI.

Well, this is what was NOT happening when I installed. I tried several different ways to get it to do an EFI install, but it kept doing it MBR style. The difficult thing is I didn't know what to ask google, and every time I had to try a new install method, it took about an hour to do the install, just to check and find out that it was wrong.

I knew that the installer wasn't loading in EFI mode and was running in legacy mode, but I didn't know how to switch it manually, and why it was choosing legacy in the first place. I checked the BIOS for booting options, and there just wasn't anything that would force it to boot from a HDD's MBR. I also didn't want to do a firmware update, I just wanted to code and get this install done.

Finally.... the answer was the BIOS just sucks. For some reason it prioritizes legacy mode on USB booting and I could only get it to chose an EFI boot from USB by manually loading it in the boot menu with F12. Allowing it to choose the USB for booting always resulted in legacy mode, regardless of the settings specified in the BIOS. Of course OpenSuSE's installer will not allow you to switch to EFI if you are in legacy mode. Also it does not make it obvious for the uninitiated to know that it is in legacy (MBR) mode.

I managed to find an obscure article that said "If you see the options for pressing F keys at the bottom of the install screen, then it's legacy mode" That one little piece of information is all I needed to understand what was happening. I saw that every time I booted into the OpenSuSE installer there were F key options at the bottom. That's when I realized that the BIOS wasn't booting from the USB's EFI partition. After realizing this, I used a manual BIOS boot, picked the correct USB boot drive (of course the BIOS displays both EFI and Legacy USB boot drives with the same name) I got the correct install screen, the EFI boot options were all there. The install went really easy at this point and is up and running now for a few days with no issues.

Have you ever worked with small form factor computers? What sort of disaster stories, or success stories have you had? Also what about installing an OS with UEFI vs MBR, what sort of experiences have you had?

If you have any suggestions or comments please share constructively. Also please visit our social media pages for lots of fun videos and pictures showing the game engine in action.

ANSI Game Engine on Instagram
ANSI Game Engine on Facebook

Prev << Part 3 - Hardware Failure & Server Upgrade
Next >> Part 5 - 32bit -> 64bit & Perl's Storable

Cheers!
Shawn

Developing A Game Engine with Perl: Part 3 - Hardware Failure & Server Upgrade

Shawn Holland — Wed, 01 Dec 2021 01:03:41 +0000

Remember... I DO NOT KNOW WHAT I AM DOING.

Continuing from the last article, let's talk about the hardware failures and server upgrade.

Mouse Input Support
Hardware Failure
Server Upgrade
UEFI vs OpenSuSE Installer
32bit -> 64bit & Perl's Storable

All your bad sectors are belong to us.....

Ugh, seeing these sort of log errors screams panic to me

Nov 25 03:44:25 Dev smartd[627]: Device: /dev/sda [SAT], Self-Test Log error count increased from 3 to 4
Nov 25 03:44:25 Dev smartd[627]: Device: /dev/sda [SAT], previous self-test completed with error (read test element)
Nov 25 03:44:25 Dev smartd[627]: Device: /dev/sda [SAT], Failed SMART usage Attribute: 184 End-to-End_Error.
Nov 25 03:44:25 Dev smartd[627]: Device: /dev/sda [SAT], 136 Offline uncorrectable sectors
Nov 25 03:44:25 Dev smartd[627]: Device: /dev/sda [SAT], 136 Currently unreadable (pending) sectors

My Dev/Test server's hard drive is going bad and I need to deal with this ASAP! It's one of those all in one PC's Acer makes You can see it far right, tucked behind the laptops in this pic of my setup.

It's been a while since I've had to look at system logs in Linux OpenSuSE. I used to remember just doing a tail -f /var/log/messages or what ever log file you wanted to watch. I guess at some point since then they switched to using systemd journal service and you can now view everything using journalctl

We can rebuild it, we have the technology...

This is actually OK. I back up my code, so I'm not worried about data loss. Aaaand... I just so happen to have another Acer computer that has been sitting in a cardboard box in pieces for a long time. Aaaand... this other computer is much better spec'd.

Here you can see a neofetch comparison of the 2 servers side by side. Left is the "new" server, right is the old server with the bad HDD.

Notable upgrades:

32bit -> 64bit Architecture
2 Core -> 4 Core CPU
4 GB -> 6 GB RAM
A Very Slow 1 TB -> Much Faster 1.5 TB HDD

I'm excited mainly for the extra core count for forking and the working hard drive, that is exceptionally faster.

Running an fio test shows dramatic differences in results.

fio --name=randwrite --ioengine=libaio --iodepth=1 --rw=randwrite --bs=4k --direct=0 --size=512M --numjobs=4 --runtime=240 --group_reporting

Old server write speeds are around 6789kB/s and took a few minutes to run. The new server performs @ 109MB/s and finished the test in a few seconds. I'd say we should see a huge performance increase, and we do!

The engine can do a lot of writing to the hard drive at times, and I used to see the lag, now... no lag from the hard drive! Nice and quick! Also no bad sectors.

I've read somewhere that you may not want to perform randwrite against a device that is in use... So, be careful. I did it with no apparent problems, and the bad sectors were already happening well before ever running the fio command.

Let me know if you have any experience with hard drive failure diagnosing and testing write speeds with fio.

If you have any suggestions or comments please share constructively. Also please visit our social media pages for lots of fun videos and pictures showing the game engine in action.

ANSI Game Engine on Instagram
ANSI Game Engine on Facebook

Prev << Part 2 - Mouse Input
Next >> Part 4 - UEFI vs OpenSuSE Installer

Cheers!
Shawn

Developing A Game Engine with Perl : Part 2 - Mouse Input

Shawn Holland — Tue, 30 Nov 2021 23:43:03 +0000

Let me start by saying.... I DO NOT KNOW WHAT I AM DOING.

Literally, developing a game engine is not on my resume... yet! So any code or ways of doing anything you read here, is just what I've figured out and works for me, which by no means should suggest to you that it is the proper way to do what ever it may be. Please consult your local guru first.

OK, now that we have that established... Please consider the following as entertainment and should you learn along the way with me, that's wonderful!

Now, by the time of writing this article, I am several months into this undertaking. I'll describe in future posts what the engine is capable of, but for today, let me tell you about what happened over the last 2 weeks. I will likely break them up into separate posts for easier consumption.

Here's a quick list of the accomplishments, disasters and discoveries.

Mouse Input Support
Hardware Failure
Server Upgrade
UEFI vs OpenSuSE Installer
32bit -> 64bit & Perl's Storable

Mouse Input Support

Yes, that's right, ANSI Game Engine games will be able to use a mouse. Seems like such a simple concept, that a game engine should have mouse support. And as it turns out, it is. I just hadn't gotten to it until now. You see, my mind-set up to now has been on the idea of BBS door games So keyboard only input was something I never questioned.... until I started developing the engine's Editor

At some point I realized the only way to have the capabilities I wanted in the engine, was to design a graphics & meta editor. Which so far turns out to be basically an MSPaint program that draws in ANSI and contains game meta information. Up until now, I have been relying on procedural code / command line utilities (jp2a, img2txt) to convert jpeg's, gif's & png's images into ANSI, or 3rd party ANSI drawing programs like Moebius ANSI Art Editor

These tools are great for what they can do, unfortunately, they were never intended for such uses as a game engine. So a purpose built ANSI graphics editor that can also store meta and game information was needed.

I very quickly realized that editing graphics and meta information by keyboard alone was slooooooooooooow!!! Not gonna work, I thought. I mean, yeah, it could be done, but even a single scene image is 132x57 "pixels". And to edit 7,524 cells with just arrow keys... nah son, that aint gonna happen. So time to start reading about mouse input via telnet/terminal.

As it turns out, it's quite a simple process. All you need to do is send/print one of a few ANSI Escape Codes to the telnet/terminal client and you can get varying levels of detailed mouse input information in return.

For my application, I needed the most detail, which includes mouse movement, button press, button release and X/Y coordinate information.

Sending/printing these ANSI escape codes to the telnet/terminal client enables/disables exactly (almost, see limitation on Mouse Button 3 below) what I need.

my $turn_mouse_on = "\033[?1003h";
my $turn_mouse_off = "\033[?1003l";

In Perl, \033 is the escape key. The return I started getting from enabling this was perfect.

It looked something like this:

input: ^[[M 5<
Mouse Button: 0, Line: 28, Column: 21

input: ^[[M!5<
Mouse Button: 1, Line: 28, Column: 21

input: ^[[M"5<
Mouse Button: 2, Line: 28, Column: 21

input: ^[[M#5<
Mouse Button: 3, Line: 28, Column: 21

input: ^[[M<80>5<
Mouse Button: 96, Line: 28, Column: 21

First character ^[ is escape (\033) followed by [M followed by the mouse button number and X/Y coordinates, all offset by +32.

What this offset +32 means is, if you take the first example:
input: ^[[M 5<
you see the first character after [M is a space. If we look up what space is in Dec from an ASCII chart we find space is Dec 32. If we adjust for offset, by subtracting 32, it is a 0. Mouse button 0 is the main left mouse button on my mouse.

Mouse Button 0: Left Mouse Click
Mouse Button 1: Middle Mouse Click
Mouse Button 2: Right Mouse Click
Mouse Button 3: Mouse button release
Mouse Button 96: Mouse Move

Not sure if you see the limitation, but Mouse Button 3 is all we get to let us know that a mouse button was let go. Not which mouse button was let go, just that one was. Unfortunately, this is the best I have been able to discover, and works good enough for now.

Here is a quick snip of code I use to extract the necessary information. Sometimes they come in a string with multiple mouse inputs back to back, especially on mouse movements when buffered over telnet. So I split the string on \033[M first to get an array of mouse inputs, then split each mouse input on every character to get the mouse button and coordinate information. I use ord() to get the Dec value of each ASCII character, then adjust for the offset:

input: ^[[M<80>3<^[[M<80>4<

my @mouse = split(/\033\[M/,$input);
foreach my $mouse_input (@mouse) {
    my @button_and_coords = split(//, $mouse_input);
    my $mouse_button = ord($button_and_coords[0]) - 32;
    my $column       = ord($button_and_coords[1]) - 32;
    my $line         = ord($button_and_coords[2]) - 32;
}

I've read somewhere in a man page that you shouldn't put terminal controls into code, and should opt for using a library, such as ncurses. I probably should as well, but I'm still learning and enjoy working directly with the codes today.

Let me know if you have had any experience coding for using mouse in a terminal and if you've used a library like Curses cpan module for Perl.

If you have any suggestions or comments please share constructively. Also please visit our social media pages for lots of fun videos and pictures showing the game engine in action.

ANSI Game Engine on Instagram
ANSI Game Engine on Facebook

Prev << Developing A Game Engine With Perl
Next >> Part 3 - Hardware Failure & Server Upgrade

Cheers!
Shawn

Developing A Game Engine with Perl

Shawn Holland — Tue, 30 Nov 2021 03:49:56 +0000

Perl? What... really?

To most in the know, coding a game engine with Perl would be a surprise. I've certainly been asked, "Why Perl?". You see, unlike C++, C#, Java and others, which are well established languages in game engine design, Perl is not (well) known for it's role in the development of games. Especially not as a game engine language. You are much more likely to see Perl managing the network infrastructure for the gaming industry then you are to see it powering your favourite video games.

So why use Perl then?

Because It's what I know. It's that simple. I've spent many years using Perl to solve many problems throughout my career. I've been fortunate to write Perl code that interacts with a wide variety of hardware, Linux servers and network services. But never a game engine. So I answer "Why Perl?" with "Why not Perl?"

Why design another game engine? Why not just use an existing engine to make games?

I had to ask myself these questions early on. You see, I've always wanted to create games and for most of my life I've been tinkering with other peoples game code.

Do you remember Gorillas? The QuickBASIC game that came installed on Dos back in the early 90's. I sure do. That was one of the first memories I have opening up and messing around with game code.

What about Bulletin Board Systems? The Internet before the Internet, using 16 colour ANSI graphics with a 80x25 "Pixel" resolution. That's OK if you've never heard of a BBS. Or ANSI graphics. But for me, that was my first introduction to hosting a game server, and also where I wrote my first online game. I got to see people logging onto my server and playing my door game for the first time. They are called door games for BBS systems, don't ask me why. I coded it in QuickBASIC (pre Perl days for me) and it ran on my Renegade BBS I was running my own multi-node dial-up BBS with 14.4Kbps modems. That's right, online gaming at 14.4 kbit/s. Can you imagine the ping times!

One of the things about me is that I prefer to do things myself if I can. This extends into my programming life as well. So fast forward many years later, me still tinkering in various game code / modding along the way, using Perl extensively in my career, I came to the conclusion that I was just gonna do it. I was going to make my own game (engine). But I didn't go to school for it and have little to no actual knowledge in this field. Sure I've written lots of Perl code, but I don't know much more than a casual hobbyist at best when it comes to writing a game. Buuuut.... I DO know how to code in Perl, I DO know a little bit about ANSI Graphics and I DO know about telnet. That's the Language, The graphics (and audio, ANSI codes can be used for producing sounds) and I can make it online play for Windows, Mac and Linux using SyncTERM as the telnet ANSI client and Linux OpenSUSE as the server.

And that's where it all begins.

I know just enough to get started. So I did, and I've made great progress, but I still have much much more to do. Which is why I decided to create a blog, to share what I learn along the way as I journey for the first time in making ANSI Game Engine

>>Watch the first trailer here<<

If you have any suggestions or comments please share constructively. Also please visit our social media pages for lots of fun videos and pictures showing the game engine in action.

ANSI Game Engine on Instagram
ANSI Game Engine on Facebook

Next >> Part 2 - Mouse Input

Cheers!
Shawn