Red Ring Rico's Game Programming Web Zone

Back to where I was

Sat, 19 Sep 2026 11:34:12 +0100

It took a while, but I’ve managed to get the root<->G2 transactions working with what should be correct clock domain crossing (CDC). Now I’m back to where I was about a year ago. Most of the assumptions made with the previous method were relying heavily on the G2 clock lining up with the board’s system clock. Naively, an attempt was made to detect when the G2 clock was toggling to allow for the data to be transferred. This would work most of the time, but it would fail every few minutes or a few times in a short period of time.

Board bringup

Sun, 16 Aug 2026 02:04:35 +0100

After 16 or so hours of soldering and testing, the board may be working.

Every new step was quite exciting. First came the power delivery. Connecting a Schottky diode from the G2 side to the target. This may not be absolutely necessary, however, it makes me feel slightly better when it comes to connecting the USB programmer (which didn’t make it into this round of testing). Confirming that 3.3V was coming through on the test points. Next was the power good indicator, this worked as anticipated. 2.5V came after that, followed by 1.1V. The 3.3V dropped to around 3.0V, which is concerning. I have no idea why this is the case and I have yet to investigate it. After connecting the 1.1V power regulator it seems like the cathode side of the power good LED is receiving ~!V. I’m still scrutinising the circuit to determine where I messed up.

First practical PCB

Tue, 28 Jul 2026 01:30:00 +0100

It’s far too quiet around here.

I had intended to design a usable PCB after realising that the clock domain crossing (or lack thereof) was incorrect. All of Autumn and Winter was spent working on Shambler, mostly tools. In late January and early February, I wrote a tool to convert the Ninja models from an early Katana SDK into glTF, which I still need to commit the source code for. From April to early June, I had an itch to reverse engineer the European version of Resident Evil for the GameCube. There’s a lot left to do with that, which I may return to this year depending on how far I get with this hardware project.

Reading TF card information

Thu, 20 Mar 2025 02:54:59 +0000

After playing around for a while with the Wishbone interface and trying to work out how the modem and Ethernet MAC will interact with each other, the TF card information is present and can be acquired at will. The ULX3S doesn’t have the full TF card lines enabled so it’s not possible to refresh the information when a card is inserted. This shouldn’t be a problem, as the final unit would be disconnected from the Dreamcast to change the TF card.

G2 DMA writing

Tue, 18 Feb 2025 18:19:19 +0000

Much like the DMA read, the write follows the same rule of every access address must be 32-byte aligned except for the last one, which is the address plus one.

G2 DMA reading

Sun, 16 Feb 2025 03:36:48 +0000

The timing is still off and the output doesn’t seem as clean as I’d like. That hasn’t stopped the DMA from working.

I’m starting to think that the falling edge of the G2 clock is when the data is acquired from the line. Setting the logic analyser to 500MHz, it looks like the FR#, BH#, and BL# signals are going down after the rising edge and before the falling edge. I’ve updated my previous post about the G2 bus to reflect that.

G2 IRQ

Tue, 04 Feb 2025 04:33:17 +0000

Before acquiring the 32-channel logic analyser, I decded to write a G2 bus plugin for it. It’s not perfect and the waveforms seem to be hit-or-miss coming from the logic analyser. The G2 clock seems to get lost sometimes. A day after the plugin was written, the Kingst LA5032 arrived and the results were mostly usable. I might be using the wrong approach by relying on the clock.

I’ve learnt that while there are three lines which appear to be dedicated to external devices (external device 0, 1, and development), none are used. I knew that the Broadband Adapter (BBA) didn’t have connections for them and used the IREXT# signal. It makes me wonder if the Zip drive+USB device were going to use them. Since it wasn’t released, there’s no way of knowing.

Some G2 bus details

Wed, 01 Jan 2025 01:46:13 +0000

I haven’t made time to explore the G2 bus further. I have, however, been busy working on the FPGA side of things, reading specifications for days-on-end, and figuring out a more flexible content pipeline for the Dreamcast game.

The least I can do is provide some documentation here for what I’ve leant about the G2 bus. Due to the sixteen channels available on the logic analyser I’m using, some assumptions are made on the bits of AD that can’t be read at the same time as the rest of the signals. Also, documentation is outside my usual day-to-day work, so this post may evolve over time. I’m tempted to use LaTeX for this instead, but I digress.

First message from G2 device

Sat, 24 Aug 2024 15:16:28 +0100

About a week or two after the previous entry, I decided to take a stab at getting started with the G2 device which I’m tentatively calling the Dreamcast Data+Network Adapter. To get the signals, I designed a set of PCBs to allow for a logic analyser to be attached during a known good device’s operation. In this case, it’s the Broadband Adapter.

Still being relatively new to HDL, I am making the mistake that a lot of software developers probably do when starting out with any HDL project. Treating it like software. There’s a lot still to learn and I don’t think that I have a good grasp on the timing issues yet. Initially, I wanted to run the FPGA at 100MHz and use the built-in PLLs to create that clock from the G2’s 25MHz bus. It seems as though there are timing issues that I don’t understand and had to drop it to 50MHz. Maybe I’ll figure out the problem with the PLL (if there is one) and get it back to 100MHz. 50MHz may be enough for at least the BBA and SD card side of things. The modem could be a different story. It doesn’t have to do any real processing at 56MHz like the MDP on an original Dreamcast unit so it should be okay.

Water rendering

Thu, 06 Jun 2024 10:07:27 +0100

Since the last update, I’ve been moving into a new place. The time it’s taken has had an adverse impact on planning for the year. Originally, it wasn’t supposed to happen until the New Year, but it was accelerated and now here I am.

For the past month, I was curious about rendring water from the Game Programming Gems book (Chapter 5.11 Refraction Mapping for Liquids in Containers). Most of the time went into converting the OpenGL code into a left-handed version. Changing the chirality led to taking another pass over the operations being performed and once again checking that the outcome is correct. More tests should be written to quash these uncertanties. There was also the reliance on OpenGL’s texture coordinate generation functions that took longer than anticipated to figure out how they work. I failed to understand it well enough from the OpenGL standard, so turning to the OpenGL wiki’s Mathematics of glTexGen made everything much clearer. 3D Games: Real-time Rendering and Software Technology and Real-time Rendering were very useful for the environment mapping, too.

PixelCity update 1

Sun, 12 Nov 2023 12:56:18 +0000

In the last entry, I forgot to include the progress made so far. I’ll dump that here then move on to the progress this week.

First up is the texture generation. Starting with windows:

Nothing too fancy to begin with. I later discovered that there was an issue trying to push too many vertices. Reducing the texture memory helped, but I don’t like how fast-and-loose I’ve become with the project so far. The source code for it is quite unsightly.

Exception handling

Sat, 04 Nov 2023 08:42:07 +0000

Between the last entry and this one, I’ve mostly been working on the GUI editor for Anvil. It’s very slow going. To switch things up, two weeks ago I started working on a procedural city demo. It’s based on the same one that Shamus Young created in 2009. It’s always tempted me to try and make the demo work on as many platforms as possible. That probably won’t happen any time soon, so I’m just going to stick with a Dreamcast version.

Beginning bumpmapping

Fri, 05 May 2023 19:11:36 +0100

I’ve been busy for the past month, trying to fit in the time to create a bumpmapper. Mine is heavily based on ATi’s Normalmapper from their Tools page in 2002. Here are some of the results from it, with my very simple box model that has a low-polygon, 12-triangle mesh and a high-polygon, 30,000 triangle mesh.

This is a baseline test, a slightly scaled up box was used:

The next two are the first attempt at a high-resolution model that’s just a face on the front side:

Networking fun

Thu, 16 Mar 2023 19:53:09 +0000

It’s been far too long since the last entry. I spent December working on the scripting system, which is coming together but I think there’s a lot more work to be done before I can even begin to use it in any form. Some new books have arrived, mostly rendering related, that have been a great source of information. The hardest thing to balance is the technology side of things. I’m trying to get as close to June 30, 2001, without going beyond it. Some wonderful references exist in books written either just after, or sometimes years later, that are period-correct. The ECS is a good example of this. It’s taking heavy inspiration from something that Scott Bilas had presented during GDC 2002 but would have existed at the time of Dungeon Siege’s early development cycle.

Shadowmapping woes

Thu, 27 Oct 2022 19:51:14 +0100

I think that shadowmapping may be cut in the end, however, I want to at least try it out. I couldn’t resist. Seeing as I’m running behind already, what’s another two weeks?

So far, I’ve spent 13 days on it and am incredibly close to resolving the last issue of projecting angled lights. If a light is facing the caster from one side, it’s okay. Extending it to be a light which is above and to one side breaks it completely. I’m not sure if I’ll have it fixed by the weekend, but I’ll certainly try. Two major issues presented themselves, which I’m forever in debt to Game Programming Gems, vterrain.org, and Real-time Rendering Tricks and Techniques in DirectX for having solved. The first was getting the shadowmap projected. I had it rendering into a texture with no problems, but the projection was off. I combined two chapters from Game Programming Gems and Real-time Rendering Tricks and Techniques in DirectX to get to the correct result. The texture would project onto the surface but it was way off. The next issue was how to determine if a triangle is in the shadowmap camera’s frustum. It was way simpler than I thought. Using six bits to represent if a point is in front of a plane, then seeing if the bits were zero (all in), matched with all three (completely outside), or otherwise (intersecting). With all of that I got the following results:

Mesh skinning fixed

Fri, 14 Oct 2022 15:40:33 +0100

After many, many wasted hours, I finally fixed an issue I didn’t realise I had with the mesh skinning. In an effort to optimise processing the vertices at runtime the vertices were pre-multiplied by the inverse bind matrix, which I thought was a sensible thing to do. For some reason that I haven’t yet figured out, this was a mistake. I’ve deferred that stage to the model update function. Now instead of a vertex with an influence of one joint transforming just the positions and normals, it’s the case that the inverse bind matrix is used for both alongside the other transform. It was already a heavy operation that I wanted to optimise later, but now it’s even more of a processing hog.

Lightmapping on Dreamcast

Tue, 20 Sep 2022 06:38:40 +0100

It’s not much, but it is working. Annoyingly, it does require using transparency for the lightmap polygons, which is a pain as it reduces the render time significantly. I’ll look into ways around it. Now I’m interested in getting static props and animated characters added to the scene to see what happens to the performance. Also, the lightmap is ARGB4, so it’s not the best quality. I’m thinking of using either 565 or YUV422 textures.

Lightmapper first pass

Thu, 15 Sep 2022 07:36:20 +0100

This time I’m way behind schedule. The lightmapper was always going to be a huge task. It didn’t help that I didn’t have as much free time as I’d hoped. By the schedule, I should have shadow mapping working already. If I can really push myself for the next three weeks, I may be able to get shadow mapping in by mid-October.

In its current state, the lightmapper is very limited. Point lights only, lambert shading, poor layout of the UVs, one lumel per world unit, and only axis-aligned polygons are really supported. The results are fine and it was a struggle to get to this point, but I think the path forward for the future of the lightmapper work is clearer. Below, I’ve uploaded some screenshots from the editor after getting the UV mapping working as well as some images of the lightmap itself.

On to the lightmapper

Sat, 13 Aug 2022 08:29:48 +0100

A slightly early start, which I think will be needed for this stage. My main concerns with the lightmapping process is that I won’t have the time to bake shadows. I don’t know why this bothers me or why I think it won’t be feasible in a two-week period, but it’s something that I keep thinking about.

I don’t have a way to immediately export the CSG from the scene, either. The option is there, but I need to expose it and it, like the rest of the editor, won’t be pretty. The plan is to export the CSG, save it as a Maya scene with some way of indicating that the geometry is to be considered for lightmapping (with the final editor, this will be something on a per-model basis) and import it into the editor then bake the lighting information.

Stage loading

Wed, 03 Aug 2022 05:49:23 +0100

Now I’m slightly ahead of where I thought I’d be. I think the lighting may be broken for animated models, however, so I’ll need to see if it is. For now, I’m happy.

Here’s the initial test:

With some basic diffuse lighting from a point light. Earlier, I only had directional lighting working. It’s tempting to add phong and other models, but I’ll leave it at this basic level for now and may start on some of the tasks for next week.

Catching up

Mon, 01 Aug 2022 00:55:45 +0100

Very close to getting back to where I should be. I only need translation at the moment and it works but has some issues. Lights are not yet a part of scenes but should be in today with some brute force.

One thing I didn’t specify was loading the stage data, just resource dependencies. This is a large oversight as it seemed clear when I wrote down the list of tasks that it was “obvious” at the time of writing so I didn’t think to add it. I’ll be adding it in the week and have updated the roadmap with notes about it.

Resource management loading

Fri, 29 Jul 2022 06:50:38 +0100

While this may not seem impressive, it shows that the resource manager is doing what it should.

This was just one call to get the model, which also loaded the material, which loaded the texture. Right now it will just load in reverse order (texture, material, model), which isn’t great. The order should be material->model->texture, based on the location on the disc. I’m happy with how it is for now. A priority queue for doing this correctly will be something I’ll try and implement before the teaser releases.

Running behind

Wed, 27 Jul 2022 00:34:38 +0100

I’m about a week out from where I should be. There were issues with the change journal and DAG which I still needed to address and I’m sure there are more issues that I haven’t yet uncovered. A fair bit of time was sunk trying to get fancy with making outlines for selected objects that scaled correctly and didn’t pay off. Right now the main focus is getting the content loaded in order from the disc, driven by dependency information.

Music playback

Sun, 10 Jul 2022 17:50:19 +0100

I just finished writing some of the worst code for getting music streaming working. I need to go back and fix it here-and-there during the next few weeks but I can’t afford the time to not have it hard-coded and incredibly flaky.

If the audio I was using fell exactly on 2048-byte boundaries, there’d be no issue. However, as this is the real world where timing can be off, I’m very glad what I sampled was as imperfect as possible.

Teaser demo one roadmap

Thu, 30 Jun 2022 02:33:50 +0100

Month	W/B	Tasks
June	27	Initial setup/API organisation , sound effect playback
July	4	Music playback , volume control
July	11	Binary conversion of stage data
July	18	Queue content loading on Dreamcast
July	25	Selection , transform tools , lights
August	1	Load stage data , light objects , vertex-based lighting
August	8	Four-way view , camera placement
August	15	Lightmapper
August	22	Lightmapper
August	29	Lightmap blending , optionally convert CSG
September	5	Shadow maps
September	12	Shadow maps , walking character
September	19	Floorboards , wall with doorframe , tablecloth , blue light
September	26	Music
October	3	Music , footsteps

Colour legend

RSA SHA-1 signature validation works

Thu, 30 Jun 2022 02:13:57 +0100

A very specific route through Crypto++ allows for the digital signature verification to work. I think I’ll need to revisit it later down the line. I definitely need to get to writing tests for more things.

It’s making me think about how to handle the public key. Since I started down the route of implementing this, my thought was to use the third partition (P2) of the Flash memory to store it. The fifth (P4) seems to always be blank. If nothing else uses it, I’d really like to suggest some kind of standard for using it. Maybe not like how P2 handles it, more like P3 by allocating storage sequentially. It’s very hard to determine how to go about this, as there will absolutely be the case of overwriting something that some other game relies on down the line if taking the first-come, first-served method.

64-bit number support

Sun, 19 Jun 2022 10:32:28 +0100

I finally got around to adding 64-bit number support into Shambler. It’s mostly necessary now due to the digital signature verification. While writing all this code (more like transliterating from Crypto++) I did think that it was silly because I’m not even going to use it for years at this point. It was something I wanted to do.

So far I’ve used about two or three weeks on it. Hopefully I can speed up and finally get something out by the end of this year. Like I say every year.

Creating brushes in the editor

Thu, 26 May 2022 11:28:02 +0100

This was a frustrating one. Mostly because I thought I had come up with a clean way to position the planes after creation. Unfortunately, I’m not quite smart enough for that so I resorted to a much simpler method of adding each plane and moving it instead of afterward.

Here are some of the images showing the process:

This one was close, the first image is the wireframe, followed by the brush creation:

CSG to Wavefront Object

Sat, 14 May 2022 09:24:29 +0100

Two things are now mostly done. CSG brushes can be exported to Wavefront Object files. There’s no material support, normals, or UVs at this time. I also don’t currently export it to anywhere other than the fixed location of D:\csg.obj. For testing, this is okay but I’d prefer to be able to export each section as its own group in the tree for better organisation when dealing with it in Maya. Also, handling the workflow of refreshing the CSG back to Maya may be a challenge.

Basic CSG union done

Sat, 07 May 2022 13:55:34 +0100

Almost there, now. After the morale-sucking experience that was drive failure amidst what was a haphazard slapping together of code to get me to where I needed to be. In a way, I’m glad it happened as it forced me to recall what I had done without the dead-ends left in. It’s not 100% complete. The faces for one set of the polygons appear to be orientated in the wrong direction. I’m sure once it’s exported as a Wavefront Object file it will be easier to see where I’m going wrong.

Drive failure

Sat, 23 Apr 2022 18:02:55 +0100

About a week after my last entry, one of the drives in the workstation’s RAID started having issues. It would refuse to boot with both drives present, if one or the other were powered on it was fine. I’m still using the same fault drive at the moment, so I’m bracing for another failure soon while I wait on another drive. I wouldn’t mind so much if it weren’t for the fact that I had been doing planes incorrectly and had to fix up a few files. I could have possibly reclaimed the data if I had known ahead of time that the RAID would be useless on the next reboot after messages appeared concerning writing journal entries. This is a RAID0 on purpose, as there’s no data of worth on there in case of a failure it should have been as simple as checking the source and data out again. The code quality wasn’t the best and I still wasn’t convinced that I was going down the right track of correcting my mistakes with the planes. At the least I’m now much less stressed about the quality and more concerned about hardware dying.

Beginning CSG

Tue, 08 Mar 2022 17:34:55 +0000

Some progress on the CSG front. I’ve built up brushes from a series of planes. I don’t plan on doing more than addition, subtraction, and union of brushes for exporting as Wavefront Obj files to use as a outline to detail later.

I don’t have much in the way of screenshots, but here’s the first attempt after I got the “final” mesh built:

Here’s the fancified version:

Microthreads

Mon, 21 Feb 2022 23:37:09 +0000

One of the more difficult things that I’ve been attempting to figure out during all this is how to go about using threads on the Dreamcast. Initially, I was looking into the fiber interface that SEGA’s Shinobi library offers. There’s no documentation and it seems like it was added late for everyone else to use. It seemed promising, but after reading an article in Game Programming Gems 2 on implementing a lightweight thread system for x86, I figured; why not?

Software breakpoints in CodeScape

Sat, 05 Feb 2022 19:12:19 +0000

I’ve been busy. Not in the way that I want to be (i.e. time working on Shambler), but at my job. We’re winding down on work for the launch and I should get some more time in two months than I’m currently getting to work on Shambler in my spare time.

With that out of the way; breakpoints! For those who have done any kind of a DebugBreak function for x86, it’s very simple. Just add an int 3 and you’re done. Other architectures have quirks to implement breakpoints in software. I spent a while combing through the Katana documentation until I realised that what I wanted wasn’t anywhere to be found. Instead, I turned to the SH4 Hardware Manual (thanks to Marcus, yet again). Section 20 on User Break Controller is what I needed. It’s simple, but involves a bit of setup. There’s the address, ASID, mask, and how to break to set. CodeScape will pick up the breakpoint and stop as expected. I use the PR register when entering the debug break function as the target address for break channel A (I may get fancy later on and add conditions as well as use channel B). It’s one of those things that I thought was going to take several days to figure out because I thought it may only be viable to use CodeScape to set hardware breakpoints and software breakpoints would be ignored.

Automation notes

Tue, 04 Jan 2022 05:45:58 +0000

I’ve just spent the vast majority of yesterday writing a script that amounts to less than 50 lines in order to get GD Workshop ready with an emulated disc. It would have taken much less time if the documentation was accurate and the samples worked. It may be because I’m using Windows 2000, but I doubt it. The issue was that when the drive door was closed after the script which describes the layout of a GD-ROM was loaded, it throws up an error about a possible caching issue. Caching in what context? Memory? Mass storage? No idea. It wasn’t very specific. I ran one of the sample scripts which worked. It would populate a GD script file and then the drive would close without issue. I thought it was my GD script. After double-checking that, I ran a version of the script which should, according to the sample itself, work when launched from CodeScape. This was an exaggerated truth.

Test framework in place

Sun, 02 Jan 2022 14:34:04 +0000

After about two days of work, I have a test framework. It’s incredibly basic at around 600 lines of code or so. All I need is to be able to determine if unit tests are working at the moment. Things like function, integration, and other testing is going to be further down the road. It’s still only useful locally. Now I need to spend some time writing all the unit tests I should have had from the start. GD Workshop must be manually set up right now, which isn’t very convenient. Luckily, there is a great set of scripting functions that should do what I need. The output from the unit testing is not in a readily readable state. A utility to convert the .tests files into a nicely formatted web page would be ideal.

Automation

Thu, 30 Dec 2021 21:12:56 +0000

I’m not sure how long this next stage will take, as I want to get a mostly-working solution up-and-running rather than something 100% complete.

I’m starting with a test framework, then moving on to writing the test suites (possibly in tandem), and finally the automated build server. Having not used Java for a while, I think the build server will take the longest. Also, it’s quite an involved side-side project.

General update

Sat, 18 Dec 2021 19:32:41 +0000

I’ve been incredibly unproductive in my month off. Mostly playing Death Stranding for a few days at the beginning, then reading and researching more than actually progressing at the workstation.

That said, I have made minimal progress on the hardware front, so there’s that at the least. Mostly just around the controller and getting more information on what to do for the modem and Ethernet.

For Shambler, I’ve just now tried converting the CVS repository to Git as the amount of security concerns for CVS are many. Of course this is much like Epic’s approach with Unreal Engine, moving from Perforce to Git for GitHub and I honestly don’t know how they manage. It must be a nightmare going back-and-forth like that.

Timed out

Tue, 16 Nov 2021 19:20:46 +0000

I have good and bad news. The good news is that I’ve figured out how to synchronise the time and not have the Dreamcast prompt for a new date and time on reboot. Bad news is that it involves writing to the Flash memory. I’m not sure how to best handle this. If the time is syncd up and the difference is more than 29+ days worth, it would make sense to set it then-and-there, but if it’s 29 days, 23 hours, and 50 minutes, it might allow for 10 minutes of play time before the bug appears. I’m curious if there’s a way to force the Dreamcast not to bother with what the AICA reports? It’s definitely something I want to try out and see if running a game for 30 days will trip this issue.

Timing

Tue, 16 Nov 2021 06:21:24 +0000

I may have found a very serious bug with the Dreamcast’s real-time clock. It will reset itself after a while. By a while, I mean 29 days, 59 minutes, and between 40-50 seconds.

This came about during implementing an NTP client. I thought that the problem was calculating the time, but it was due to setting it too far into the future or past. I’ve only been focusing on the future time, so I’m not certain what the limit is for rolling back.

New obsession

Sat, 23 Oct 2021 03:35:32 +0100

Ever since I acquired my Katana in 2014, I’ve always wanted to try doing some kind of Online game. The ultimate path to the end was hazy at first, especially when it came to available SDKs and whatnot. A big issue with the Dreamcast is that there’s no good way of updating the game executable. Not only updating it, but doing so with at least data integrity in mind. Also, now I have the limitation of what was available at the time and that isn’t great. The other thing is that this is sort of like closing the gate after the horse has bolted. Attempting to add something to the Dreamcast that it really wasn’t designed for (unlike the Original Xbox) is a challenge.

Bandersnatch

Thu, 21 Oct 2021 00:39:36 +0100

I’m starting to feel as if this project is becoming my own personal Bandersnatch. The hardware that I’m also developing is definitely setting that kind of a bar. Understanding the G2 bus’ way of handling expansion devices as well as if the method I’m thinking of using will even work with the official broadband adapter is a concern. I haven’t touched the hardware side of things for a while and I really need to get back on it to not allow that skillset to dull.

Stalled again

Sat, 16 Oct 2021 14:27:29 +0100

More and more I find other things to do to work on that don’t provide immediate, visible results. This time it’s the file system and adding a basic packed data format for the GD-ROM. It’s so specific that it will be useless for the storage expansion. I’m still unsure if I’ll keep it around or rework it to be compatible with both storage options. File read times are definitely improved. Not by much, but it also means that I don’t have to worry about changing directories (which is pretty expensive) or recalculating the file sizes and starting locations. Asynchronous file loading is made far simpler by using the packed files, though. So that’s a bonus.

About that Agartha demo

Fri, 27 Aug 2021 18:54:05 +0100

A little detour before the shadow work begins.

I finally played the Agartha demo. It’s one of those holy grail of unreleased games that I’m glad made it out into the wild in one form or another. The control scheme is pretty neat, kind of like how Shenmue can use the analogue trigger to go from a walk to a run but that’s how you move forward. I couldn’t figure out how to pick up items dropped. Visually, it’s a very impressive game for as early as it was in development. Such a shame that streaming 3D worlds weren’t there at that point in time and we still had levels/areas of the world periodically loaded in. Then again, I don’t think many Dreamcast owners would have wanted their GD drives seeking constantly.

Real-time changes

Wed, 25 Aug 2021 11:07:45 +0100

Again, another long gap between entries.

Tools are as important as the game itself. Getting it right is important. I’ve thrown together a lot of code with minimal planning so far. Because this is a brand new area for me, there isn’t much that I draw from past experience to quicken the pace or foresee issues as intuitively as when writing the game code. Plenty of dead-ends have been encountered while writing the tools.

Slow tool progress

Sun, 27 Jun 2021 22:48:13 +0100

It’s taken a while to get to this point and there doesn’t look to be much to show for it, but there’s a lot more going on under-the-hood. A Maya scene can be loaded in, the meshes, materials, skeleton, and animations all get extracted into an intermediate CVS directory. This information is used to render the model in the editor. Each mesh is stored as a separate binary file, all meshes are referenced in an XML file that represents the model and refers to the materials as well. The materials are stored as XML files, too. Along with the textures in (currently) TIFF format. Right now the textures are TIFF conversions of the source textures. I want to either automatically generate the target textures from the TIFF and store it with the intermediate files for conversion later or generate the textures as they are loaded. Obviously the latter would be far more processor intensive, however, it would save on storage space.

Client side prediction

Sun, 11 Apr 2021 21:29:47 +0100

I’ve spent about a week working on the client side prediction implementation. It’s very rough but it’s much, much better than the slideshow it appeared to be before. There’s a lot for me to learn as not everything works quite how I’d expect. Server-side monitoring needs to be improved and I think it’s almost time to work on a UI to make that process easier. Right now I don’t want to do any involved CURSES work, but it would appear to be required.

ECS networking works

Sat, 03 Apr 2021 21:21:50 +0100

Getting back to the networking side of things, I spent a few hours trying to debug an issue related to a pointer not being initialised to null which isn’t a problem with the debug build or running the release build on the dev kit. Annoying, but at least it was easy to track down. Just took a while.

Here’s the fruits of my recent labour. It takes about thirty seconds to get going and I also forgot to start the server which is why there’s a delay between starting to send data and receiving:

Single joint animations working

Thu, 01 Apr 2021 09:32:28 +0100

Almost. Normals are messed up at the moment, but it’s a definite improvement.

The first attempt resulted in just the first joint being considered as I messed up the exporter and was saving the joint index as a float instead of an unsigned int.

After that, and before I fixed the exporter, I was curious to know if the rotations are working at all so I bound the whole object to joint 2.

Wiggling about

Tue, 30 Mar 2021 10:10:34 +0100

Success. Another productive morning. I had some issues due to not including the correct headers so some of the math functions being called were not the correct ones for sinf and atan2f while performing the quaternion slerp. Next: transforming the vertices.

Jumping around

Mon, 29 Mar 2021 08:32:43 +0100

Finally, after a good few hours and a lot of incredibly poorly-written code with the exporter (I really have to clean it up) I have the animation clips exported and working. The second animation, wiggle, doesn’t appear to animate yet as it’s pretty much all rotations. The next stage is to support slerp-ing rotation keyframes. After that, it should be a case of getting the vertices to move with the skeleton. I need to make a more complex smooth skinned model to show the system off. There’s no blending between animation clips at the moment. Also, the exporter isn’t only exporting one mesh, it’s doing both the input and output mesh to the skin cluster for Maya. Another thing to fix that I really should do after cleaning up the exporter’s code.

Positioning joints

Sat, 27 Mar 2021 04:32:06 +0000

I have to apologise in advance. It wasn’t until I viewed the screenshots after-the-fact that I realised how hard it is to see the points and connections. I didn’t reset the size of the points to 4x4 after trying to figure out if the points were converging into one point or if they were tightly spaced apart. To see the points (they’re all green) you may need to view the images separately and zoom in.

Bones

Sat, 27 Feb 2021 05:23:54 +0000

Exciting. I have a skeleton exported. The next phase is getting the animations out, playback, and then combining that with the skinning information which has yet to be exported.

To give you an idea of how many polygons are involved:

Originally, I had used a 1x1x4 cube split into 32x32x32 segments. That quickly turned out to be a bad idea. The final split is 16x16x16.

A really dumb buffer overflow

Wed, 17 Feb 2021 22:41:49 +0000

About ten minutes ago I fixed a really stupid bug in the code that I’m currently working on. A lot of what I’m writing recently isn’t great and has been cobbled together rather hastily. The bug is a buffer overflow that occurs when writing to a temporary buffer for display to the VMU. On the server the Y position is decremented every update step, which counts up pretty quick. By default the output was displaying the number to five decimal places. No problem for numbers up to -99.00000 seeing as the line was printed as “Y: -99.00000” the issue is that there are only twelve characters total for each line. This quickly resulted in going beyond the bounds of the array and corrupting other things in the stack. The main thing I was concerned with during that particular debugging session was the number of entities. This was stored close to the print buffer and ended up being wildly too large for normal operation. A lot more items than the lone entity, at any rate.

System part of ECS working over network

Mon, 15 Feb 2021 09:07:35 +0000

It took a while, but I finally have at least one player’s position being sent over the network with the ECS and processed by a debug cube rendering system. Some of the time was spent performing some rudimentary performance testing, which was not promising. I’m aiming to get back to the same state which the game object system reached in the next week. After that, saving and loading game data will be next as the player names and colours are still being assinged to the same value from the server. This will probably be a bigger chunk of work due to the need to make a menu system. In the meantime I could just show a basic menu with simple name and colour entry fields.

ECS and networking progress

Mon, 08 Feb 2021 09:28:54 +0000

It took some doing, but the act of creating entities and giving them components via the network is pretty much there. Systems are still WIP.

I’ve been reading a fair amount of articles on how to handle sending secured network traffic recently. I’m really unsure about implementing it for Shambler. Mainly because I have no idea exactly how expensive it will be. I guess the good thing is that it can always be applied later if performance is looking good. Either way, I’ll keep investigating securing the network traffic, just in case.

GNU Make dependencies

Wed, 20 Jan 2021 08:38:45 +0000

Since the start of this project, I’ve always had to make sure that any source files that inadvertently depend on a header file are rebuilt when either that header file’s function signature or structure arrangement/contents change. It took about two hours and around 200 lines of thrown-together code to fix. I think a large amount of headache could have been avoided if I did this right from the start.

It was quite fun to take a break and do something else that benefitted the game. It’s pretty dumb, not accounting for comments or headers with quotation marks instead of chevrons but it works for my purposes.

Getting back to it

Sun, 10 Jan 2021 03:00:23 +0000

It’s been another long stretch of silence. I’ll try to get back into the swing of making these entries.

Over the past month I’ve been working more and more on some hardware-related stuff. Bouncing around from one thing to the next to get started in earnest on the three hardware projects that I’m aiming to achieve sometime in the near-future. All of them are Dreamcast-related and I don’t know at all if I can achieve them but I’ll give it a good shot. These have been rolling around in the back of my mind for somewhere close to a decade. Pretty sure I’m also not the only one to have thought of them, too.

Working on materials

Tue, 22 Dec 2020 11:25:08 +0000

Recently I’ve playing way too much Death Stranding and not spending enough time on Shambler. Today I finally got started in earnest on the material system. Last night I spent a few hours learning how to get StudioPaint to assign one texture to multiple meshes as well as “properly” unwrap the UVs. There are many things left to learn in that field. When I started painting on the model, I knew that the UVs were all messed up by using planar projection and lazily unwrapped them after the fact which results in very ugly looking UVs.

Maya and StudioPaint

Sun, 29 Nov 2020 18:40:35 +0000

Before I started working on getting a UV exporter tool up-and-running for Maya, I decided to investigate other tools that may be able to texture models because I found it strange that there wasn’t a way to get the UVs out of Maya, yet there were clearly well textured models that had been made for games and films. On my journey, I discovered StudioPaint. Specifically, version 9.5. This was the last verison of StudioPaint and the last version of Maya that StudioPaint integrates with is 3.0, 4.0 introduced exporting UVs in an image. Though I haven’t investigated how textures were painted on 3D models outside of using something like StudioPaint at the time. Assuming that things such as Substance Painter were relatively new tools and artists relied on using image manipulation tools like PhotoShop, GIMP, or PaintShop.

Moving pictures

Sat, 07 Nov 2020 21:45:48 +0000

It’s been a busy month. Not much progress on the game has been made, however, I finally got hold of a capture card. Unfortunately, the best I could find is an S-Video capture card. Still on the lookout for VGA capture cards. The video just shows me moving the light around while the cube spins about. I’ve set the dev kit to the North American region to allow for 60Hz instead of 50Hz, giving a video output of 30Hz when interlaced.

Happy birthday, Dreamcast

Wed, 14 Oct 2020 16:16:55 +0100

I don’t really have anything to write for this. I’m just always surprised when the American release date gets a bunch of excitement around it and the Japanese/European launch days aren’t remembered much.

Regretfully, I didn’t get the demo up-and-running in time for today. Soon, I promise.

Here’s to you, SEGA!

Lit

Mon, 12 Oct 2020 04:56:35 +0100

Hoo, boy, that was annoying. I’ve been trying to get lighting working for a little while and kept shooting myself in the foot multiple times by not going back and carefully checking what I wrote. To begin with, I was transforming the normals I had by the world matrix for the purposes of debugging and stored them in a separate debug normals array. Unfortunately, I didn’t double-check that I was modifying the actual normals… This led to the normals behaving strangely, to say the least. From the first screenshot, you can see the result of this. In the second one, I made things a bunch worse by calculating the position of the normals with the World*View matrix. A few hours after trying to fix what I thought was broken, I stopped.

Normals exported

Thu, 08 Oct 2020 11:36:01 +0100

Normals are now able to be exported with the mesh. I still need to add in multiple mesh support. With the default face-based normals per-vertex, the size ballooned pretty quickly and it was pretty much the same as rendering n strips per side of the cube.

Face normals per-vertex:

Averaged normals per-vertex:

One side-effect is that for the face-based normals the last edge doesn’t get its line rendered due to there not being any need to consider it as it should be covered by the next strip’s first and second vertices. This can be seen on the right side of the face with the number ‘5’ on it. I’m not sure if I’ll fix it. It’s a few lines of code to implement, but it prevents redundant line drawing.

Line rendering done

Mon, 05 Oct 2020 12:59:15 +0100

After an hour, I now have lines being rendered. There seems to be an issue with the slope on a few occasions, but it’s good enough. I’m just using the standard Bresenham’s line algorithm, nothing fancy or optimised.

The first attempt yielded some… interesting results. The issue was that the Y coordinate was always moving down the screen rather than in the correct direction depending on if the first Y coordinate was less than the second or not.

Rendering things that can't be rendered on a Dreamcast

Sun, 04 Oct 2020 22:04:14 +0100

One thing I’ve been wanting to do for a very long time is add point and line rendering for debugging. This is very easy today. You just set up your graphics pipeline to render with points, lines, or solids. Unfortunately, the PowerVR chip on the Dreamcast only supports solid rendering of triangle strips. This makes a lot of things pretty hard. Not only can you not render triangle lists, you also can’t just render a point or a line!

Textured cube

Sat, 03 Oct 2020 23:12:25 +0100

After a few hours of extending the editor to take a Maya file and convert it into a form that Shambler will much more readily consume, I now have a textured cube. Right now the texture coordinates need to be flipped on both axes, otherwise it’s rendered incorrectly. That should be a simple enough fix to implement from the exporter side.

Next, I’ll fix the UVs and export the normals to get this thing lit. After that, I think I’ll either get started on skeletal animation or switch back to the network optimisation. There’s also saving and loading player information so that there’s no need to rely on the player’s ID from the server side to set the colour and name.

Rendering static meshes

Mon, 28 Sep 2020 09:05:15 +0100

I’ve had this working for quite a while, now. The model loader is hard-coded to handle a single mesh and hasn’t changed since it was touched in almost a year (October 13, 2019). The mesh stripification was also hard-coded in the editor (processing one model at a time). It’s a basic format consisting of a specific vertex specification, no support (yet) for skeletons, textures, or lighting. The different colours indicate which strip the triangles belong to.

On the many colours of the Dreamcast swirl

Tue, 22 Sep 2020 11:11:40 +0100

I see this every now-and-then. Either the Dreamcast has three coloured swirls (orange, red, and blue) or two (either red or orange, and blue) when it boots up. Even I used to think there were three colours; orange for Japan, blue for Europe, and red for North America. There was some reason that I came across about it being the shifting colour of the sky throughout the day.

Anyway, that isnt the case at all. There are two colours for at least the five regions the Dreamcast development kit supports. Here they are, along with their colours:

Unintentional break

Tue, 15 Sep 2020 03:33:51 +0100

Every now-and-then I take a stab at learning Vulkan. It appeals to me on a very low level as it reminds me of both Saturn and Dreamcast development with how it works. Usually I try and do something with it for about two or three weeks then stop and work on something else. I have many, many personal projects…

Nevertheless.

I started working on a new engine about six weeks ago. The goal is to create a simple, modular, idiot-proof, legacy-free, and efficient engine. Mainly I chose that because then I could call the engine SLIME as an acronym. I have a love for bespoke hardware so I get my kicks by programming for the Saturn and Dreamcast. I also really love new technology. Which is why the engine won’t support anything that has come out before when I started working on it. There are a bunch of GPUs, motherboards, hard drives, memory, CPUs, and other components that I have which are decades old. As much as I want to support all of them, it creates a dilemma of needing to use many different compilers and APIs to do so.

Let's play

Mon, 24 Aug 2020 13:52:45 +0100

Finally. It took a few lines of code on the client to “fix” the issue of clients not being able to move and be visibly replicated to each other. It’s a terrible hack that just sends the most recent input thirty times a second. It’s terrible and I will be rectifying it. For now, I’m just ecstatic to see two players moving around and that being reflected by what’s on screen. I printed out the server source code which I usually find helps with tracking down issues as the pages can be annotated and organised to get a better handle on the whole picture. As the codebase increases in size, this becomes more difficult, of course.

Cubes render just fine

Sat, 22 Aug 2020 17:59:56 +0100

I also learnt a bit about shutter speed and how to take pictures of monitors. Investing in a frame grabber of some sort might be useful for the retail units. I should note that the “basic renderer” milestone is probably misleading. There was a focus on the 3D content creation pipeline at first which shifted over to networking very early on. It’s been months since that string was last updated…

That was fast

Fri, 21 Aug 2020 07:38:35 +0100

I figured out what the issue was with the memory manager. Sometimes the amount of data being stored is just short of what is possible. With one of the memory blocks, it had a total sie of 68 bytes that it could store and after alignment, trying to store 41 bytes became 69 bytes. The way the total was being calcualted meant that it ended up trying to subtract 69 from 68. Nothing wrong from the standpoint that it should be possible. It doens’t meant it’s correct. Before the adjusted amount of memory available is returned, I check to see if the aligned size is enough to fit in the wanted size. After alignment the wanted bytes becomes 72 and the memory block isn’t considered for trying to hold the data.

Bugs, bugs, bugs

Thu, 20 Aug 2020 12:25:34 +0100

Oh my.

Sometimes even the simplest of things break. After compiling a release version of Shambler, I pressed the start button to quit to the BootROM and CodeScape complained that a general exception occurred. Turns out that it was a simple case of link order. The Shinobi library had to be linked last.

Server-side, it’s a mess. I do not like it one bit. It’s very much so cobbled together and not at all well designed. I have another week off, which I should use to fix the server code at the very least. It’s a jumble of defining what a client is, how to replicate state, and there’s even a whole list of game objects that are outside of everything else.

I can see you

Tue, 28 Jul 2020 14:19:42 +0100

Since starting on this whole venture, I haven’t yet tackled getting more than one player connecting to the server and, in doing so, connecting with other players. A few days ago I had two Dreamcast’s able to request the world state and thus able to see one another. It’s not pretty and it doesn’t yet show anything on the retail kit, but it’s a start.

At the moment, I can at least test with a development kit and a retail kit wihout needing to burn more CDs. The next step is to get an ODE to allow for another Dreamcast to join in. I think that having the mix of different methods to play the game may help track down inconsistencies or bugs that could be introduced when using one format over another.

Debugging with a VMU

Fri, 03 Jul 2020 02:27:08 +0100

The Visual Memory Unit (VMU), which is also known as VM or VMS (Visual Memory and Visual Memory System, respectively), is a very neat and unique feature of the Dreamcast. A while later, Nintendo would do a great job of continuing on with the second screen gameplay via the GameCube to Game Boy Advance link cable, but I digress.

I’m not planning on using the VMU stand-alone as I don’t have any idea on what could be done as a mini-game with Shambler. Currently, I don’t yet know what to display on there in-game, either. For the time being, it’s used to display debug information on a retail unit. It’s not impossible to draw text on the screen, however, it’s also not something that I want to clutter up with debug information if possible. That’s what debuggers and development kits are for. There are the odd occasions where it’s necessary to try to catch a bug that’s only appearing on a retail unit that doesn’t warrant more than a handful of characters.

Connection established

Fri, 19 Jun 2020 03:49:07 +0100

Finally. After a lot of waiting and work, the internal access server is now up and running!

Unexpectedly, the Portmaster 3 boards that are T1-based arrived a month early. I received them three days ago and my first attempt was to just throw in the T1 card into the E1 unit and use that rather than flash the NAND chip that holds the user configuration on the T1 unit. As fate would have it, the card did not seem to work at all in the E1 unit. It was recognised, but as an E1 card for some reason. This was after troubleshooting why the E1 unit didn’t boot properly and kept complaining about the NAND being corrupt in some form. I ended up desoldering the sockets that took so much time to install as the joints just weren’t any good and opt for soldering the NAND chips back on directly. I need to revisit PLCC sockets and try to solder them in a more reliable way in the future. The E1 mainboard has been so overworked that I just didn’t want to risk damaging the pads.

Reading and writing NVRAM chips

Wed, 03 Jun 2020 23:30:33 +0100

After waiting a while for the chip programmer, hot air rework adapter for 15mm QFPS, some PLCC32 sockets, and some Kapton tape, I finally managed to take the NVRAM chips off the PortMaster 3 and erase the configuration, keeping the OS intact.

Mostly it consisted of a bunch of waiting around and hours of trying to solder the PLCC32 sockets without needing to snip the plastic in the centre to do it without damaging the socket. I tried two methods to not damage the sockets. The first was to use a fine tip and flow the solder like any other SMD part. I ended up warping the centre plastic and the joints were not great. The second attempt was to wrap the socket up in Kapton tape and hope that it wouldn’t need to be exposed to the hot air for too long before the plastic would start to melt. This wasn’t successful at all and I think the main issue was that I couldn’t see the pins clearly under the tape. It still ended up damaging the socket.

PortMaster 3 woes

Thu, 28 May 2020 18:07:50 +0100

When I bought the PortMaster 3 from eBay, there was one huge oversight. The model I bought was a PM3A-1E. This designation indicates that there’s a single E1 port. The Adtran TSU 600 only accepts a T1 connection. I have no idea how this major detail slipped from me. I assumed that the T1/E1 labelling on the diagram provided by the PDF I referenced in the previous post meant that either a T1 or E1 connection could be used. No matter, I bought a T1 motherboard along with an additional T1 card (which could be used with the board I already have) and the required modems which my unit didn’t ship with. To be fair; I wasn’t expecting modems and waited until it arrived before moving forward.

Why I don't just use a DreamPi

Mon, 25 May 2020 03:18:30 +0100

Up to this point, I’ve not mentioned the DreamPi for this whole networked game thing I’m doing. The reason is pretty straightforward; I have more than one Dreamcast to test with. DreamPi is a great solution for a single unit, though trying to scale it to more than two is troublesome. I’d like to see someone create a HAT for the Pi to do this with support for four units at once, but it would be an incredibly niche thing. I digress.

Replacing a dozen capacitors on the FSX modules of an Adtran 600(e)

Tue, 19 May 2020 22:19:44 +0100

Since acquiring the Adtran 600, discovering the six capacitors which had long since ruptured across the installed modules wasn’t entirely welcome. Nevertheless, they’ve since been replaced (along with the other six which seem fine) and the unit is as operational as it can be until the PortMaster 3 arrives.

I’ll follow up with a post covering the network as soon as possible; for now, trust that the Adtran 600 is an important part of it.

Old hardware, old software, new game

Sun, 17 May 2020 00:59:45 +0100

For a long time I’ve been accruing a lot of different hardware and software running up until the year 2001. May 31 2001, @999, more specifically.

I have this very specific time period in mind as a hard limit for getting together the hardware and software for a period-correct Dreamcast game. Of course, the Dreamcast’s production run stopped during February 2001 before SEGA became a software company. There was a promise of software still to come, which was true for Japan going all the way until 2007. Europe and the Americas didn’t fare as well.

get in touch

Mon, 01 Jan 0001 00:00:00 +0000