The last 12 months have been very difficult. My Dad passed away suddenly from cancer which meant I had to find a new home for my Mum who relied on him for her day to day care, sell their house and deal with some serious health issues of my own. This was in addition to everything else we have to deal with day to day and a busy job.
I am finally starting to play around with some CRPG game ideas and possible platforms.
I came across raylib recently and I have to say I’m very impressed with it so far. This is a simple and easy to use library for game programming. It’s cross platform and was originally designed to work as a library with standard C code which remains my language of choice, though I am still not very proficient with it. It’s apparently been around 10 years so it appears to be well established and have a strong following though I had not come across it before.
Raylib feels like a good match for my game development needs which remain very much inspired by the 8 and 16bit era of adventure and CRPG gaming. There are lots of examples on the official website and many, many tutorials online and on YouTube. It’s free to use though donations are welcomed.
Following a suggestion on one of my recent YouTube videos I’ve been trying out Turbo Rascal Syntax Error (TRSE) for my Commodore 64 game development and first impressions are very positive. TRSE uses a Pascal style language which I have used previously at University, though I missed out on the famous Borland Turbo Pascal for the PC.
TRSE is a full integrated development environment with many helpful features to make your classic 8bit/16bit coding easier. I understand it was originally developed for C64 coding but it now supports many computer and console systems including the ZX Spectrum, BBC Micro, Commodore Amiga and MS-DOS.
Features include inline assembly language support for when you need that extra speed, large numbers of example code, code profiler to show you which routines or data are taking up the most space and some built in editors for graphics and maps. For the C64 there is specialist support for playing music SID files, raster interrupts for split screen effects or sprite multiplexing and many other features which I’ve not had the opportunity to explore yet.
Moving from CC65 which uses the C programming language, I’ve found some of my earlier code doesn’t work as expected (even when rewritten in Pascal) but with the examples provided I’ve managed to replicate the main code fairly easily and that’s before I consider any optimisations or the use of assembly language.
You can see me using TRSE below with some rough test code for Demon’s Isle.
A couple of years back I did some work on programming the Commodore 64 in C using CC65. I recently took another look at one of these C64 CRPG projects and posted a brief video:
I’ve started working on this again and have lots of ideas about how to expand it next. Not sure I’ll keep the exact graphic style and screen layout but we’ll see. I plan to have another video out in the next couple of weeks. It’s likely that I’ll use another development approach rather than sticking with CC65. I find myself struggling a bit with juggling memory segments for resources such as graphics characters and data files.
One thing I’m still unsure about is whether I would prefer to make it a single character game such as Questron or a party based game like Ultima IV. The style of combat is also something I’m thinking, some games using the same map you move around on with others opting for a dedicated “zoomed in” combat map. What are your thoughts?
Belated Happy New Year. I hope that you, your family and friends are well and keeping safe during these difficult times.
It’s been a long time since I posted even though I have been up to various retro computing activities on and off since I last posted in November 2020. It’s almost 12 months that I’ve been working remotely now which brings with it challenges around space and separating home and personal life but I count myself as very lucky in that I am able to work remotely and still do my job. I know others have not been so lucky.
Since I last posted I began re-working my old Alternate Reality X (ARX) code on the Pi 400. I started to restructure the code to try and make it much tidier especially around the display routines and game loops. So instead of having lots of different display and game loops for different things I was moving code into a single over-arching loop with a number of different states depending on whether you were exploring, in an encounter or at the main menu. I made quite a bit of progress with this but it was hard going moving some very old code around which often broke many other parts of the game. I also added an option to scale the window size with a key press; X1, X2 and so on based on your preference.
I’m not really sure I had a clear endgame with this re-working of ARX such as a public release or whether I would use the reworked framework as the basis for an Alternate Reality inspired game. Part of this was me just wanting to make ARX a lot better organised from a coding perspective – more for personal satisfaction that anything else. I haven’t done any further work on this since the end of 2020 but I’d like to get back into some coding on this soon and try to bring this project to some sort of logical conclusion.
Alternate Realith: The City box art
I’ve done some retro gaming and emulation on the Raspberry Pi 400 and also tried out various alternative operating systems on the Pi 400 such as Twister OS – https://twisteros.com. One problem I have with the Pi is keeping track of what is on each of my MicroSD cards – bring back 3.5” floppy disks! At least you could put a label on them.
As many long time readers may know I’m a Commodore Amiga fan and after my Amiga emulation above I went ahead and bought an Amiga 600 from eBay which I’ve been spending some time working on and trying to get to the point where I can maximise my enjoyment on it gaming and possibly some light development. Not my favourite Amiga model by a long stretch but it does have the smallest physical footprint (important for me just now) and does have some features that make it very useable in 2021. Maybe I should have gone for an Amiga 1200 but they cost a lot more. I’ll post about this separately.
My “new” Amiga 600 running Workbench 2.1Ultima VI – The False Prophet running on the Amiga 600
I plan to post more frequently in the coming weeks and months but feel free to drop me a note if there are any interesting retro gaming / computing things you’ve been up to or think I might be interested in. Take care.
I’ve recently bought a Raspberry Pi 400 which I am planning to use for most of my coding projects going forward. If you’re not familiar with this, it is a Pi single board computer but integrated into a keyboard with the relevant ports accessible at the rear very much like the classic computers that you know I love such as the Commodore 64, Amiga 500 and Atari 800.
I opted for the desktop bundle which includes the main Pi 400 computer / keyboard combo as well as a wired mouse, SD card, micro HDMI to full HDMI cable and a USB C power supply. It also comes with a nice beginners guide book which is in full colour. The keyboard isn’t bad and very compact. The Pi 400 has a faster ARM processor than it’s predecessors and 4Gb of memory as opposed to the 1Gb my Pi 3B+ had so some things which were a bit slow for me are that bit smoother on the Pi 400.
The only slight annoyance just now for me is that the composite/audio jack present on the earlier Pi’s is not included on the Pi 400 so I can’t connect up my recently purchased speakers without a HDMI to VGA splitter which isn’t producing a great picture on my monitor. I’ll maybe just pick up a monitor with an audio out jack for my speakers.
I’ve been very busy with work recently so not had a lot of time for my coding projects but I have a number in progress that I’m really excited about. I’ll not say anything else about these just now until I have a bit more to show.
The easy to use Raspberry Pi Linux environment is working quite nicely for my coding efforts but I’m very focused on ensuring that any coding I do is easily portable to other systems such as Microsoft Windows so I am continuing to use C/C++ with SFML, both of which are very easily set up on the Pi. I found Code::Blocks a little unstable on the Pi 3B+ but haven’t experienced any issues with it on the Pi 400 yet. I’ve also been using the Geany editor which comes pre-installed in Pi OS but requires a little bit more set up for me than Code::Blocks. SFML is extremely easy to set up on the Pi compared to Windows.
I’m looking forward to some enjoyable emulation on this version of the Pi such as some Commodore Amiga and classic DOS games and also in trying out some of the other operating system choices that are available such as desktop release of Ubuntu.
Since I last posted I’ve been doing most of my game development on a Raspberry Pi 3B+ under Raspberry Pi OS . There has been a little bit of a learning curve with getting this set up and some of the utilities I was using aren’t available under Linux but overall it’s working quite well. One of my biggest frustrations was getting a usable version of the Vice C64 emulator running. I failed to compile it successfully from source and ended up installing it using the PiKiss utility (https://github.com/jmcerrejon/PiKISS). Vice doesn’t seem to perform very well on my Raspberry Pi so I would appreciate any suggestions anyone can provide in how to improve its performance.
My Raspberry Pi 3B+
Most of my work on “The Citadel” has involved reorganising memory again. I’ve not successfully managed to move all my graphics into the top 16K of memory. The Commodore 64’s VIC-II chip can only see 16K of memory at a time and this top 16K of memory includes other things including the Kernel ROM. Usually these need to be “switched out” in order to access the RAM underneath but the VIC-II can apparently see the RAM underneath for character sets, the screen, bitmap graphics and sprites – very useful as I can continue to use the C64’s KERNEL routines such as print a character, screen the screen etc but also make use of the RAM underneath for graphics. This means that CC65 can use a contiguous block of RAM, around 50K just for program code and other data. This also means I was able to simplify my linker configuration file (as shown in my previous post) and remove all the segment references which have been a bit of a distraction when I’ve been using CC65.
The C64 Programmers Reference Guide
I’ve moved the other data files such as map and wallset data onto a C64 disk image and I’m loading these into memory when the game starts. This seems to be working well and my program file is now down to around 15K leaving plenty of space for extra game code.
I’ve also added the feature of switching between the 3D view and an overhead map. Currently this just shows the half the map (32×16 locations) regardless of where you have explored but I’m going to modify this so that the map only becomes visible as you explore. So you can now move around the map either in the 3D view or in an overhead view. I need to think this through a bit as both views need to have their purpose and be useful. I thought the game should switch into 3D view when you have an encounter or enter a shop (if you’re not already in this view).
Moving around the map in overhead view
I also plan to make the map more interesting in terms of better use of characters and colour rather than just using simple blocks. I think I can now focus on adding some gameplay and have a brief playable demo out soon with some initial encounters and combat included.
