PC Engine tile-based quantisation, part 2
Introduction
While exploring PC Engine image quality and quantisation, I found that when loading an image from CD-ROM to VRAM, it took something like 6 seconds for the load to finish.
I thought this was a hardware limitation at the time, and supposed that this was the reason that PC Engine games from back in the day didn’t feature more colourful background graphics.
An unexpected correction
I was very grateful when prolific PC Engine developer Elmer corrected me:
PC Engine tile-based quantisation, part 1
Update, 24 Dec 2024
Check out Part 2, where loading times get much improved!
Introduction
I spend some time in the evenings working on various toy projects. It’s a good way to exercise a programmer brain in a way that a day job generally doesn’t.
Anyway, a while back I bought an Analogue Duo, which is a high quality FPGA clone of the old 8/16-bit PC Engine console.
I say 8/16 rather than just 16-bit, because while the GPU was 16-bit, the CPU was an 8-bit HuC6280 – a derivative of the legendary 6502 CPU, with a bunch of handy extra instructions and so on. Oh, and 4 times the typical speed.
Object Equality
Introduction
One of the first code smells we encounter when working with an object-oriented language where everything is an object, or everything subclasses a common base class, or there are no static methods, is how OOP typically handles equality of objects.
For value types such as integers and floating point numbers, it’s not controversial that we should be able to compare them and decide if they’re equal or not. Integers can be compared by bits, and data structures can be compared by descending into the structure and comparing elements.
Removing Reference Cycles
Introduction
If you are gainfully employed as a programmer, you have probably been forced to accept object-oriented programming into your life. When working with a language like Swift or C++ which doesn’t have garbage collection, you will end up in the debugger, trying to locate a strong reference cycle which has resulted in a memory leak.
Or, you’re reviewing a Pull Request and notice that there is a cyclic relationship between some classes.
Strong and Weak Object References
Introduction
An object maintains a reference/pointer to another object so it can call a method or access a property. References are called strong if the relationship between the objects is one of ownership, and weak or unowned if it the object containing the reference does not own the object being referred to.
In languages like Swift, Objective-C, and C++, it’s required that we don’t create cycles of strong references, or we get memory leaks.
The SOLID Principles
Introduction
In order to guide programmers to effectively apply object-oriented design, the industry settled on what we call the SOLID principles.
I believe that while the SOLID principles were marketed to encourage “good” use of OOP, they just as effectively discourage the use of OOP!
The principles
Single responsibility principle
every module, class or function in a computer program should have responsibility over a single part of that program’s functionality, and it should encapsulate that part.
Object-oriented Programming (OOP)
What is OOP?
First, read Wikipedia.
Characteristics of OOP
Division of the problem into Objects which implement Classes
The programmer is able to model the problem space in terms of objects that talk to each other via messages (method calls.)
I believe this to be a poor approach to most data transformation problems.
Noun-ification
To encapsulate with OOP, you have to invent names (nouns) for the classes which encapsulate the functionality (verbs). In many cases this is quite difficult, and you end up with names that don’t succinctly but completely summarise the functionality being encapsulated.
What is Programming?
Introduction
This page borrows heavily from Mike Acton.
Transformation of data
Writing code is a means to solving a problem, and primarily the problem is that some data (input) needs to be transformed into something else (output).
Examples of inputs:
- Button taps
- Incoming HTTP responses
- Events coming from the OS
- Events coming from 3rd party SDKs
Examples of outputs:
- The view hierarchy
- Audio
- HTTP requests
- Requests sent to 3rd party SDKs
Frequently the output is not only dependent on any particular input, but on some stored state that is maintained as the app runs. Examples of stores: