Peter Serwylo

Comprehensive tips for generating PDFs in the browser

2022-01-14T00:00:00+00:00

Recently, as an associate at Cognizant Australia, I have found myself diving much deeper into the world of “Print to PDF” than I ever thought neccesary. This is a summary of my learnings in the hope it may help others.

WARNING: Work In Progress

This post is a work in progress. There are still sections left to complete, screenshots to add, proof reading to be done.

However, it may be some time before I am able to complete it, and I hope someone can find the information here useful in the meantime.

Summary

Your web app has users, sometimes they just want a PDF copy of what they are looking at on the screen.

Sure, they could copy and paste the URL, you could provide a “share” button, they could bookmark the page, etc. However, what happens when:

The content at the URL changes?
They want to attach it to an email?
They need an offline copy for archival purposes?
They want a hard copy?

When building a PDF export feature for a webapp, you are typically faced with a few options:

Generate the PDF on the backend and serving to the browser (e.g. PrinceXML, itext, etc)
Dynamically create a PDF in JavaScript (e.g. JsPDF, react-pdf, etc)
Write the DOM to a canvas and include as an image in the resulting PDF (e.g. using html2canvas + JsPDF)
Prompting the user to save page as a PDF via the browser print dialog (by calling window.print())

There are plenty of great articles elaborating on these options.

Generating PDFs in the browser using `window.print`

The rest of this article will focus on utilising the browser print dialog, and some gotcha’s that you should consider if doing so.

The primary reason to opt for this approach is that you can benefit from a single code base for both displaying information to users from the web browser as well as exporting a PDF.

The main pitfall is that you have much less control over exactly when page-breaks will appear, and in general less control over the layout of the resulting PDF.

We will consider all of the following:

Making the print dialog as transparent as possible to the users (so it feels as much a part of your application UX rather than part of the browser chrome)
Adding headers + footers to each page
Fitting complex user generated content to your PDF page (in particular tables + images) that we have little or no control over (not withstanding XSS)
Ensuring all styles and images are loaded prior to initiating a print
Page sizing
Page breaking (and tables/headers)
Isolating styles from the application
Managing cross browser quirks

Overall user experience

A naive approach would be: “Just ask the user to print the page”.

This experience is a sub-par for many reasons, especially since browsers dropped the notion of a standard “File -> Print” menu in favour of weird little hamburger mystery menus some time ago, making it less likely users actually knwo where the print functionality is found.

Instead, we can trivially invoke window.print() from JavaScript to trigger the same functionality. This should be done by a nice noticable button somewhere in your web app.

TODO: do and don’t images. Don’t is screenshot of hamburger menus and “Print” option. Do is a styled button in the webpage (with icon).

If, for reasons we will discuss below, we opt to render content into a new window for printing, then this button should:

Trigger window.print()
Call window.open() and render into the new window
Size the window to almost hide it behind the modal print dialog
Listen to window.onafterprint and close the window when done

The new window can be made almost transparent by sizing it such that the only thing the user sees is the print dialog. Without appropriate sizing, users may get confused as to why they are seeing two previews of the content (one from the underlying webpage DOM, and one from the print preview).

TODO: do and don’t images. Don’t is a window too large showing two previews, Do is a popup covered by the print dialog.

Render into a new window

The promise of CSS media queries is that we can print a complex web app with only changes to CSS.

Sometimes, this just doesn’t cut it and we need much more control, such as:

Specific HTML structures to aid with headers and footers
Manually manipulating DOM nodes to fit on the screen appropriately

These can be destructive operations that break the web app. For these reasons, it can be helpful to render your DOM for printing into a new window that can be disposed of once printed.

We still get to share rendering code, e.g. by rendering the same React components used by your web app into the new window, but we have the freedom of mangling it as we see fit to lay out appropriately on a the page.

Headers and footers

This will be simple once CSS Paged Media Module Level 3 is ratified and made avaialble in major browsers. Until then, we are stuck with ugly workarounds.

Sidenote: There are rendering engines which understand advanced CSS Paged Media declarations, such as PrinceXML. However our goal is to utilise the users browser, which means as of writing, we don’t have access to these features.

Goals:

Show content repeated across the top and bottom of each page
Support artibrary number of pages (we normally don’t know how many pages there will be in the resulting document)
Prevent obstructing any actual content behind our headers/footers

After searching around, the best approach is embodied in this blog post and variations appear throughout stackoverflow too.

Solution:

Add 2 x position: fixed elements for the header and footer respectively, and each will be repeated on each page by the browser when printing.
To prevent them overlapping other content, reserve space at the top and bottom of each page.
Reserve space by warpping content in a <table> where the <thead> and <tfoot> have a fixed height and are repeated on each page, and the content is within a <tbody>

HTML

<table>
  <thead>
    <tr>
      <td class="header-space">
        <!-- Empty. Just to reserve space for the <header> -->
      </td>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        <!-- Actual page content goes here -->
      </td>
    </tr>
  </tbody>

  <tfoot>
    <tr>
      <td class="footer-space">
        <!-- Empty. Just to reserve space for the <footer> -->
      </td>
    </tr>
  </tfoot>
</table>

<header class="header-content">
  <!-- Actual header content goes here -->
</header>

<footer class="footer-content">
  <!-- Actual header content goes here -->
</footer>

CSS

.header-content, .header-space,
.footer-content, .footer-space {
  height: 100px;
}

.header {
  position: fixed;
  top: 0;
}

.footer {
  position: fixed;
  bottom: 0;
}

Hopefully you can already see why it may be a good idea to render your printable pages in a new window. Although possible to use the above HTML in your regular website layout, it will quickly start to cause issues, and we are just getting started!

Fitting user generated content

Many systems that require exporting PDFs are enterprise systems, often with user generated content. Such content is normally pasted into a WYSIWYG editor from MS Word.

Security Warning: We will leave the notion of protecting against XSS attacks for another day.

Goals:

Fit complex tables, large images, and weird divs with fixed and large widths to our PDF pages (yes, these do get pasted regularly from weird and wonderful sources by users).

Assumptions:

We don’t know the structure of these user generated tables.
We can’t mess with the layout of the tables (often in enterprise systems, the table layouts can have semantics which change as we resize and shuffle columns around).

One potential solution is actually implemented by webkit itself, called the “shrink factor”. It is transparent to web developers, but the print dialog will attempt to shrink the entire document until it fits, but give up after a certain point and then truncate the rest of the content off the page.

We will build something similar in JavaScript, but instead of shrinking the entire document (unneccesarily making all text small and harder to read), we will just resize the problematic elements.

Solution:

Figure out how many pixels wide the resulting document will be (depends on the DPI of the current users screen).
Find all <table> (and potentially <img> or other) nodes are bigger than this.
Resize these until they are no larger than the page width.
Allow word breaking to prevent large strings of characters from disappearing

Use word-break: all to prevent long strings of characters from flowing off the page.

Without this, large lines of text such as aaaaaaaaaaaaaaaaaaaaaaa... will end up off the page. By allowing the browser to wrap words midway through, we trade off the chance of breaking some words in inopportune places with the benefit of actually getting all our content on the page.

Find all tables which wider than the PDF page, and shrink them.

Gotchas

Windows defaults to Microsoft Print to PDF. This outputs images. Chrome’s is better.

Tempest: Basic 3D

2021-08-03T00:00:00+00:00

Prior to adding enemies, I thought it best to get a working proof of concept third dimension for Tempest.

Allowing for perspective

This was mostly fine, except for the minor hiccup that retrowars assumes all games want an OrthographicCamera.

I’m not very happy with my solution of passing in a flag if you want perspective, and will likely refactor that later, but for now it works well. Here is a discussion on why flag arguments are normally not the solution to a problem you face.

Here are the results:

Offsetting the perspective

After patting myself on the back about how it mostly looked like the YouTube videos of original Tempest, I quickly noticed that the perspective in the original game is actually offset a little. The camera doesn’t look directly down the centre of the level, but starts a bit below centre.

After accounting for this by translating the camera in my version down slightly, it really is starting to shape up nicely.

Next steps

Next I will tighten up some of the measurements (currently the depth is just arbitrarily chosen as a fixed value). After that, I think shooting from the players current position, then the addition of enemies.

Tempest: Basic progress

2021-08-02T00:00:00+00:00

In order to start making progress on this game, the initial work will:

Ignore the third dimension
Ignore enemies
Focus on the break down of levels into segments in a loop
Allow the player to move around these segments

I must confess that I’ve never actually played before, but I do really like the videos I’ve seen, so please go easy on me :) My reference point for how the levels look and how the game is played is this YouTube video:

First three levels

The first three commits were to add the first three levels.

Each level is broken into a list of Segments, where each Segment represents a start and an end point on the screen using a pair of libgdx Vector2s:

class TempestGameState {
    val level: Level
}

data class Level(
    val segments: List<Segment>,
)

data class Segment(
    val start: Vector2,
    val end: Vector2,
) 

And then each level is hand crafted using whatever necessary (e.g. hard coded start and end points for each segment in the rectangular second and third levels, but trigonometry in the first “round” level).

Player position and movement

By recording which segment the current player is on, it becomes straightforward to:

Highlight this segment differently during rendering.
Respond to input by changing the segment to the next one (with the exception that we need to support wrapping around the loop).

The player segment is recorded in the game state as a reference to one of the level segments. We could equally store an index to the segment in question, but this worked well for the Snake game and made a lot of comparisons much simpler.

class TempestGameState(private val worldWidth: Float, private val worldHeight: Float) {
    val level: Level = makeThirdLevel(worldWidth, worldHeight)

    var playerSegment = level.segments[0]
}

The input handling is taken from the tetris game, whereby we need to ensure that only one keypress is registered each frame. Otherwise, on faster devices, the game will respond too quickly.

Therefore, instead of asking whether a button is pressed at the start of each frame (as we do with Asteroids), we instead record a button status when the button is first pressed, and then clear that status each frame after processing it:

class TempestGameState {
    ...
    var moveCounterClockwise = ButtonState.Unpressed
    var moveClockwise = ButtonState.Unpressed
}

class TempestGameScreen {
    ...
    controller!!.listen(
            TempestSoftController.Buttons.MOVE_COUNTER_CLOCKWISE,
            { state.moveCounterClockwise = if (state.moveCounterClockwise == ButtonState.Unpressed) ButtonState.JustPressed else ButtonState.Held },
            { state.moveCounterClockwise = ButtonState.Unpressed })

    controller!!.listen(
            TempestSoftController.Buttons.MOVE_CLOCKWISE,
            { state.moveClockwise = if (state.moveClockwise == ButtonState.Unpressed) ButtonState.JustPressed else ButtonState.Held },
            { state.moveClockwise = ButtonState.Unpressed })

    override fun updateGame(delta: Float) {
        ...
        movePlayer()
        resetInput()
    }

    private fun movePlayer() {
        val currentIndex = state.level.segments.indexOf(state.playerSegment)

        if (state.moveClockwise == ButtonState.JustPressed) {
            state.playerSegment = state.level.segments[(currentIndex + 1) % state.level.segments.size]
        } else if (state.moveCounterClockwise == ButtonState.JustPressed) {
            state.playerSegment = state.level.segments[(state.level.segments.size + currentIndex - 1) % state.level.segments.size]
        }
    }

    private fun resetInput() {
        state.moveCounterClockwise = ButtonState.Unpressed
        state.moveClockwise = ButtonState.Unpressed
    }

Next steps

Next will either be the addition of firing from the players current position, or the addition of a 3rd dimension (which will make it easier to see if the firing logic is working as expected).

Tempest: Initial skeleton

2021-08-01T00:00:00+00:00

First steps: Adding a blank game skeleton

Before getting into the specifics of Tempest, I thought I’d quickly review what is involved in adding a new game.

This can be seen in commit 4d7d89d2.

This is the minimum required to get to this point:

Code review of these changes

I’m a big fan of code reviews. It is a wonderful way to mentor others, and an even better way to learn yourself. Although reviewing your own code kind of defeats the point, I hope that doing so in a public forum like this will let me be a bit more reflective, critical, and constructive.

First thoughts

I don’t like the size of that commit.

Well, it isn’t so much the size, but rather the random locations with which code needs to be added. If it is non-obvious to myself as the original author, it does not bode well for others in the community attempting to implement games.

Here are some of the things I find odd and should perhaps refactor in the future…

Adding a controller

Most games require a controller to be shown on screen. The steps to add a controller for Tempest are:

Adding an actor to OptionsScreen.kt

addActor(
    IconButton(skin, Games.tempest.icon(sprites)) {
        Gdx.app.postRunnable {
            game.screen = ControllerSelectScreen(
                game,
                Games.tempest,
                TempestSoftController.layouts,
            ) { index -> TempestSoftController(index, game.uiAssets) }
        }
    }
)

Why do we need to call addActor on OptionsScreen? Why do we need to create a button? Why do we need to hard code a reference to Games.tempest twice and TempestSoftController twice? Why does every game that wants to have a controller need to call Gdx.app.postRunnable { game.screen = ControllerSelectScreen(...) }?

Create a controller and manually add to HUD in TempestGameScreen

private val controller = TempestSoftController(Options.getSoftController(Games.tempest), game.uiAssets)

init {
    addGameOverlayToHUD(controller.getActor())
}

Proposed improvement

The base GameScreen base class should have an open function which optionally returns a controller:

open fun getController(): SoftController? = null

The OptionsScreen can then query the (already present) list of Games.allSupported (which we had to populate as part of the initial game adding process) and ask each one for a controller. Those that return a controller will end up with an entry in the options screen.

The GameScreen can then use the fact that a controller exists to decide whether or not to add one to the HUD instead of relying on the base class to have to call addGameOverlayToHUD(controller.getActor()) at some point.

This may require refactoring the SoftController class hierarchy so that it can be created and queried without having to instantiate an actor or specify which controller layout to use. That is to say, the options screen should be able to know that a game has a controller without having to create a specific instantiation of one.

Displaying a message at the start of the game

Call showMessage() during init

init {
    showMessage("Shoot the enemies", "Don't let them touch you")
}

This is easy to do, and only needs a single line to be added. However, people adding new games have to remember to do this.

Proposed improvement

Force the implementing game to provide these messages to the constructor. That way, the compiler will tell the game designer that these are required pieces of information to make the game behave like all other games.

Next steps

I will have a go at implementing the proposed feedback prior to starting Tempest properly. Hopefully it shouldn’t take too long and then we can progress with getting the next game done.

Let the community decide the next retro game

2021-08-01T00:00:00+00:00

Let the community decide

The retrowars project began with me implementing the games I was personally most interested in seeing: clones of Asteroids, Missile Command, Tetris, and Snake. Once these were completed, I had no preference over what to implement next (though I’m very keen to keep adding games!).

To encourage those in the community to participate and perhaps even grow a little community, the game includes a built-in link for “More games”.

This directs the player to a GitHub link where they can view proposed games, and vote for the game they would like to see next.

Furthermore, people are encouraged to recommend their own favourite game to be implemented by submitting a New Game Proposal for others to vote on.

Next game: Tempest

Now is the time where I am available to begin contributing a new game to retrowars. At the time I decide this, Tempest was the game which had the most votes (even though that is no longer the case).

The next post will go over what is required to get an initial skeleton of the game up and running. Following that, subsequent posts will document the journey to getting a working version of Tempest into retrowars.

WebSocket game server in Kotlin using Ktor

2021-07-28T00:00:00+00:00

Free vs commercial software infrastructure

As explained in a previous post, free software games that have infrastructure requirements are slightly different then their commercial counterparts. Normally, free software projects don’t cost anything other then the time (and sometimes sanity!) of the contributors. However, as soon as there are requirements on infrastructure, such as a multiplayer game, this normally results in a financial cost. Given that these projects are usually a labour of love and don’t earn money other than donations, this cost can be significant, depending on the popularity of the project and therefore the traffic involved. Commercial games can cover this cost, but free software projects often cannot.

Preparing retrowars for online multiplayer

The retrowars project is a free software multiplayer Android game. Earlier versions only supported local network multiplayer, which has no infrastructure requirements, but the goal was always to support true multiplayer via the public internet. This requirement naturally means server infrastructure is required (or elaborate P2P setups which is beyond the scope of this game).

Porting of the local network server to a public internet server was very straightforward, the same code worked essentially as is without modification.

Specifically, it made use of the KryoNet library which does a great job of:

Serializing and deserializing Java objects using an efficient binary protocol.
Discovering servers on the local network

A desire for HTTP (via WebSockets)

Given the goal of letting people run their own server, the thought process was to make sure that the server can be deployed on commonly available infrastructure as a service. A popular approach for deploying Java apps is Heroku, which allows people to deploy with a single command, and not have to worry about setting up a virtual machine, installing Java, etc.

When trying to deploy the KryoNet version of the server, it was immediately apparent that using non-HTTP traffic for networking would not work with Heroku. Furthermore, this experience also made it clear that deploying the server to non-Heroku environments may also cause issues, as many firewalls only allow HTTP traffic through.

This resulted in a refactoring of the retrowars server to use HTTP and websockets instead of KryoNet.

WebSockets, JSON, Ktor, JmDNS, and Coroutines

Converting the server from KryoNet meant replacing:

Kryo serialization -> GSON
KryoNet networking -> Ktor WebSockets
KryoNet local network discovery -> JmDNS
KryoNet threads -> Ktor coroutines

This was my first experience with Kotlin coroutines, which took a lot of reading and experimenting with before making substantial progress (and I’m still not 100% happy with my usage of them at this point - though I’m sure it will improve with experience).

WebSocket performance

Many game development blogs discuss best practice with regards to networking technologies. TCP is a bit slower than UDP, and there is not much discussion of using WebSockets other than for web-based HTML games. In practice, it seems that other than the overhead of establishing a HTTP connection and upgrading it to a WebSocket connection, the actual sending of messages should be the same as sending bytes directly down a socket. The retrowars game does not have high performance networking requirements that something such as an FPS may require, so this is even less of an issue. In practice, the performance of WebSockets is perfectly sufficient for the retrowars game.

Sustainable server infrastructure for open source games

2021-07-03T00:00:00+00:00

Lets design an open source multiplayer game server arcitecture that is:

Resiliant to the main developer being unable to perpetually maintain an online server.
Able to scale up as demand increases, by allowing community members to contribute and run game servers.

Specficially, this is for the Super Retro Mega Wars game. Even more specifically, I want people to be able to play retro games in realtime against eachother long after I have the capacity or finances to maintain an online server to facilitate multiplayer gameplay.

v1.0 - Basic multiplayer via a local network

Multiplayer can be as simple or difficult as we want. Lets assume simple, because this article is not about minimizing latency, detecting and preventing cheaters, etc. In our case, lets assume the game design doesn’t care all that much about latency, and it doesn’t really care about preventing cheaters.

These assumptions mean that we can create a proof of concept whereby one player opens up a server socket, and another connects a client socket to this.

Although it will work well on a LAN, this doesn’t allow people around the world to connect to eachother due to NAT and other considerations. For that, we’ll need one or more publicly available servers on the internet.

v2.0 - Central internet based game servers

The local networking code can be extracted into a server-side application with little modification. Hosting this is not particularly difficult either, we deploy the server-side application on a VPS somewhere and embed the URL of this server into the application.

However, what happens if the server goes down? The IP changes? The domain is not renewed? The maintainer gets hit by a bus? Under each of these scenarios, we are left with a game that has a perpetually broken multiplayer feature. Every person who discovers this game and installs it, will find that they can only play single player and when they try to play multiplayer, it will error.

v3.0 A more robust open source multiplayer architecture

v3.1 - Players manually enter server details

The simplest technical solution is to let people run their own servers and let players manually enter details of a server to play. How the player gets the server details is not our problem. Perhaps there are wiki pages or forum posts that enumerate game servers.

While technically simple, this is not a plesant user experience.

v3.2 - Hard code a list of servers in the game

To improve the user experience, we want players to be able to open the game and play online with the click of a button. For this, the game needs to know which servers are available. This can be done by hard coding a list of servers in the game. When new servers become available or others are decomissioned, a new version of the game is published.

The problem here is that those who have not updated the game will have a stale list of servers.

v3.3 - Online list of servers managed by game maintainers

Instead of hardcoding a list of servers, the game can refer to a URL that contains a list of servers. As new servers are brought to the attention of the maintainers, the list can be updated.

This ticks almost all the boxes, but the single point of failure is still the game maintainers. If they stop maintaining the list of servers, then the game will very quickly stop working.

v3.4 - Online list of servers managed by the community

Finally, we want this online list of servers to be maintainable by the community, so that in the case that the maintainers are no longer able to manage it, community members can do so.

This not only solves the key point of failure issue, but also fits very well with the ethos of free and open source software projects.

Community maintained server list

The way we will do this for Super Retro Mega Wars is to have:

A JSON file with details of publicly available servers.
Host this on a GitHub Pages URL associated with the repository (e.g. https://retrowars.github.io/servers.json).
Encourage community contributors on the GitHub Pages repository.
Document a process for proposing changes to the server list.
Automatically publish the server list when merge requests are accepted.

This way, if the original maintainers of the game are unable to continue maintaining the server list, then the community is stil able to ensure that multiplayer games are supported.

Community run servers

In order for the community to be able to ensure continued online play is possible, it needs to be as simple as possible to run your own game server. Some of the decisions Super Retro Mega Wars is making in this area will be discussed in a separate blog post.

LCA 2018: F-Droid: The private, secure, free and open app store for Android

2018-01-25T00:00:00+00:00

To quote F-Droid’s Licaon Kter:

The 45 minutes long talk covers how F-Droid come to be, focussing on the client, its security model, and how it is being used to ensure everyone (look out for the “collateral freedom” bit) is able to access high quality open source apps, using tools developed to make it easier for anybody to setup and run their own curated app store.

This is a great primer for new users giving them a behind the scenes view on how apps come to be, from a source code repo to their Android devices.

Video of Presentation

YouTube link

Slides used in Presentation

Slides are available at https://pserwylo.gitlab.io/fdroid-lca-2018.

PhD: Eliciting Bayesian Networks via Online Surveys: A New Approach to Knowledge Elicitation

2016-04-01T00:00:00+00:00

In April 2016, I was awarded a PhD in computer science for my dissertation entitled “Eliciting Bayesian Networks via Online Surveys: A New Approach to Knowledge Elicitation”.

For those interested, you can download the (cc-by-sa) PDF.

Make your writing beautiful

2013-08-12T00:00:00+00:00

This is a seminar I gave to fellow research students about some things you should consider when writing articles, to make them look visually beautiful. It was given for the first “HDR Lunchtime Seminar” at Caufield Monash. Apologies for any typos or other errors, I did it in a short amount of time because I was busy with some other stuff around the same time.

If you are interested in this topic, you may also be interested in the talk I gave at the Open Source Developers Conference, “Please, no more gauges: How NOT to visualize data” (video and slides are available).

Slides

You can view the slides online.

Cheatsheet

You can download the cheatsheet as a pdf or view it online.

Software

After the talk, a few people asked about the software I used when writing. Here are some links for anybody who is interested. All the software is open source, and cross platform.

As is often the case with new/different software, you may be familiar with existing alternatives:

LyX -> Microsoft Office
Inkscape -> Adobe Illustrator
GIMP -> Adobe Photoshop

Due to the fact we are talking about pretty complex pieces of software, you may find these alternatives clunky at first. I strongly believe that this is related to familiarity with other “ways of doing things”. I have met professional graphic designers who use Inkscape and GIMP instead of their Adobe alternatives. Also, I was trained in Photoshop and Illustrator in high school and uni, but am now pretty good in GIMP and Inkscape. Now I’ve learnt how to use them (though not as well as professionals would), they are just as powerful and intuitive as the alternatives for the tasks I use them for.

LyX (word processor)

A “What You See Is What You Mean” word processor, which outputs articles to PDF via LaTeX. I think this is a good introduction to the beautiful output of LaTeX for Microsoft Word or Libre/OpenOffice users. It is cross platform, and has great documentation. This is the software I am writing my thesis and all of my articles in, and although every now and then I’ll find one or two things a little tricky, it is by and large a much more pleasurable experience than writing in Word or LibreOffice.

Download LyX

Lyx Documentation: LyX is different in that the best documentation is not on a webpage, but rather in a LyX document accessible from the Help menu. You can either view it in LyX, or output it to a PDF once you’ve opened it.

Inkscape (vector graphics editor)

Inkscape is the open source alternative to Illustrator. It may not seem as powerful at first, but it has all of the features that I used in illustrator, and is great for making beautiful diagrams for your writing.

Download Inkscape

The GIMP (bitmap photo editor)

The GIMP is the open source alternative to Photoshop. I found the transition from Photoshop -> GIMP much easier than Illustrator -> Inkscape, because it shares a very similar paradigm for working.

Download The GIMP

OSDC 2012: Building a free(ish) MAME cabinet

2012-12-11T00:00:00+00:00

This year I again attended the Open Source Developers Conference. The talk I gave was another light hearted one, this time about building a MAME Cabinet using reclaimed rubbish. A huge props to the organising team for an awesome conference.

Slides used in Presentation

Please click the image below to view the presentation in your browser (made using Landslide).

Resources

These are the resources I placed on the final slide.

Wireless controller client/server
Tutorial on building a MAME cabinet (one of many)
Completed cabinets (Hall of fame)
What not to do (language warning)

OSDC 2011: Wii Homebrew: Running and writing software for the Wii

2011-11-21T00:00:00+00:00

I spoke at the OSDC 2011 in Canberra, Australia. The talk was about writing and using homebrew software on the Wii. I got some great feedback after the talk, and was happy to see so many people interested in the idea. I was also pleased to see how many people already have a modded Wii. Hopefully I was able to give a few people some tips.

Video of Presentation

YouTube link

Presentation Software

Part of my preparation for the talk was to hack together some presentation software to run on the Wii. This allowed me to give the actual presentation on the Wii. I called it Priijector (because every piece of software for the Wii has to have a double ii somewhere, and everything homebrew related has to include a pun). It will read a pres.txt file in a custom (and hacky) markup to define slides and transitions.

You can get the code from GitHub (GPLv3 license).

Slides used in Presentation

Please click the image below to download the PDF of the presentation (3mb). The quality is a little poor, because I had to take screenshots of each slide from within the Dolphin emulator at a resolution of 640×480.

PhD confirmation seminar

2011-08-01T00:00:00+00:00

If this is of interest to you, it is worth noting this is not the topic of my final PhD. That pivoted quite substantially between this presentation and the final thesis in 2016.

During July of 2011, I presented to the confirmation panel at Monash. This is mandatory for PhD students at the one year mark in their research. The goal is to present the current status of the project, and where it aims to go. The panel then decides whether or not you should revise what you are doing, and whether you can keep your scholarship and continue researching. Needless to say it is a little bit nerve racking, but it ended up going quite well. I’d like to thank my supervisors Grace Rumantir and Frada Burstein for their feedback on numerous revisions of my proposal, as well as the confirmation panel for the feedback they gave me after the presentation.

Proposal Document

Download the PDF of the proposal for which this confirmation presentation is based.

Video of presentation

Vimeo Link

Slides used in Presentation

Please click the image below to view the presentation in your browser (~2.5mb, doesn’t seem to work in Internet Explorer).

ISCRAM 2011: PhD colloquium

2011-05-22T00:00:00+00:00

If this is of interest to you, it is worth noting this is not the topic of my final PhD. That pivoted quite substantially between this presentation and the final thesis in 2016.

At ISCRAM 2011, Tung Bui organised the PhD Colloquium which I (in addition to several other students) attended. The talk outlining the focus of my PhD (at the time of the conference) is available below.

Please click the image below to view the presentation in your browser (3mb, doesn’t seem to work in Internet Explorer).

ISCRAM 2011: Predicting patient rates

2011-05-19T00:00:00+00:00

Below you will find my presentation at ISCRAM 2011, entitled “Predicting Patient Presentation Rates at Mass Gatherings using Machine Learning”. It was for an article co-authored by Paul Arbon, Grace Rumantir and I. It was accepted in the “Planning and Foresight” track chaired by Murray Turoff. I like to think that the talk went pretty smoothly, and am looking forward to when they publish the videos.

Video of Presentation

Vimeo Link

Slides used in Presentation

Please click the image below to view the presentation in your browser (~5mb, doesn’t seem to work in Internet Explorer).

OSDC 2010: Bad visualisation

2010-12-30T00:00:00+00:00

I was lucky enough to be accepted to talk at OSDC 2010, which was a well organised conference of like minded Open Source developers and enthusiasts in Melbourne. My talk was not directly related to any open source technology, but rather some general guidelines about what not to do when visualising data. It is a commentry on the works of people like Edward Tufte and Stephen Few. The talk was well received, and I was very pleased with how it went.

Video of Presentation

Unavailable. Unfortunately it was hosted at http://blip.tv/play/AYKQpVsC which is now defunct.

Slides of Presentation

Please click the image below to view the presentation in your browser (3mb, doesn’t seem to work in Internet Explorer).

Peter Serwylo

Comprehensive tips for generating PDFs in the browser

WARNING: Work In Progress

Summary

Generating PDFs in the browser using window.print

Overall user experience

Render into a new window

Headers and footers

Fitting user generated content

Tempest: Basic 3D

Allowing for perspective

Offsetting the perspective

Next steps

Tempest: Basic progress

First three levels

Player position and movement

Next steps

Tempest: Initial skeleton

First steps: Adding a blank game skeleton

Code review of these changes

First thoughts

Adding a controller

Displaying a message at the start of the game

Next steps

Let the community decide the next retro game

Let the community decide

Next game: Tempest

WebSocket game server in Kotlin using Ktor

Free vs commercial software infrastructure

Preparing retrowars for online multiplayer

A desire for HTTP (via WebSockets)

WebSockets, JSON, Ktor, JmDNS, and Coroutines

WebSocket performance

Sustainable server infrastructure for open source games

v1.0 - Basic multiplayer via a local network

v2.0 - Central internet based game servers

v3.0 A more robust open source multiplayer architecture

v3.1 - Players manually enter server details

v3.2 - Hard code a list of servers in the game

v3.3 - Online list of servers managed by game maintainers

v3.4 - Online list of servers managed by the community

Community maintained server list

Community run servers

LCA 2018: F-Droid: The private, secure, free and open app store for Android

Video of Presentation

Slides used in Presentation

PhD: Eliciting Bayesian Networks via Online Surveys: A New Approach to Knowledge Elicitation

Make your writing beautiful

Slides

Cheatsheet

Software

LyX (word processor)

Inkscape (vector graphics editor)

The GIMP (bitmap photo editor)

OSDC 2012: Building a free(ish) MAME cabinet

Slides used in Presentation

Resources

OSDC 2011: Wii Homebrew: Running and writing software for the Wii

Video of Presentation

Presentation Software

Slides used in Presentation

PhD confirmation seminar

Proposal Document

Video of presentation

Slides used in Presentation

ISCRAM 2011: PhD colloquium

ISCRAM 2011: Predicting patient rates

Video of Presentation

Slides used in Presentation

OSDC 2010: Bad visualisation

Video of Presentation

Slides of Presentation

Generating PDFs in the browser using `window.print`