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.
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.
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).
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.
“Vice doesn’t seem to perform very well on my Raspberry Pi” Could you give specifics? Does it not maintain 60fps and 100% speed, or you are dissatisfied with the % speedup in Warp mode? I’m curious what a Pi can actually achieve with it’s ARM core. I used to have a first generation Core i7 that would only give me 800% on Warp and last year I replaced that monster machine with it’s 5 always-running fans with a fan-less Pentium Silver model that gets 700% on Warp. A little slowdown but I can leave it running 24/7 without a high electric bill and it doesn’t keep me awake at night. This system doesn’t run well in Windows 10 so I switched to Linux and it runs great! It’s just that 90% of the Commodore development utilities are written for Windows. VICE is the only native Linux program for Commodore stuff.
If you try specific games such as Turrican 2 or Uridium Plus, the scrolling is jerky. My C64 Mini doesn’t have this issue. The best Raspberry Pi option for C64 emulation I’ve found is BCM64 – this is a bare metal implementation of Vice for the Pi. It works very well and boots up in about 3 seconds. You can find it at:
https://accentual.com/bmc64/
It works a little differently to Vice but once you’ve set it up and become familiar with it, I think it’s great. It doesn’t really help with developing C64 content though unless you actually want to develop on a C64 directly in which case you’ve got access to SD card and USB storage.
Two thoughts.
First, about the map view vs the 3D view. While 3D view is cooler and surely more work for you so you want people to spend time in it, my personal experience is that in every game I have ever played that offers multiple views very quickly I end up playing the entire game in map view. Visualization of where I am and where I’m going is just soooo much easier that it is worth the loss of pretty graphics to get the increase in accuracy and speed of travel. I’ve ended up making this same choice 100% of the time, even in modern games in Windows that look fantastic. If you want to get use out of both views I recommend allowing viewing the map but not moving about with it up. Let players “check the map” to see where they are going, then have to explore and travel in 3D. It gives the best of both worlds.
Second, a request. I’m also trying to write some 3D view code. I’d like it very much if you’d spend a bit of time explaining the algorithms for visibility in and displaying your 3D view. Ultima style overhead visibility is easy because there is no directionality: you see in 360 degrees around you at all times. But in 3D mode you see what is in front of you, “in front” changes directions based on which compass point you are facing, and what you display is affected by the positions of obstructions. For example a wall in a near or mid depth map fully or only partially block view of a more distant wall, so you must have a complicated algorithm to determine what to draw and what is a waste of time.
I’ll try and post some details of the 3D view code shortly. It’s a simple algorithm but with some serious limitations which I’ll explain in the article (e.g. limited view depth, missing angled left/right walls beyond the immediate left/right columns). It draws the distant walls first into a buffer and then the finished buffer is copied into the screen memory.