Exception handling

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.

I have it up to the stage of creating the window textures for buildings, the texture for the sky cylinder (kind of, there’s a rendering issue that seems to be due to too many vertices being pushed at once), and a basic building. Performance tanking and it failed to run on a retail unit. Initially, I thought that it could have been a bad memory access, which led down another rabbit hole of finally tackling exceptions. There are built-in exception handlers that are only really useful for having a debugger attached. That doesn’t help much when there isn’t any debug interfaces present (specifically, the Debug Adapter of a development kit).

For anyone using the Katana SDK, here’s how to assign your own exception handler:

CustomException.c

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

#define	EXP_HOOK( CODE )( ( Uint32 * )(\
	( Uint32 )get_vbr( ) + 0x200 + ( ( ( CODE ) - 0x200 ) >> 3 ) ) )

void EXP_Handler( void )
{
}

void InstallExceptions( void )
{
	void **ppAddr;

	ppAddr = ( void * )( EXP_HOOK( SYD_INT_EVENT_ADRERRR ) );
	( *ppAddr ) = EXP_Handler;
}

For my exception handler, the entry point is written in assembly to get the registers and dump them to the screen with another function written in C.

By the time I had the exceptions set up, it was working as I expected. At least there’s now a mechanism for when something does go horribly wrong. It would be neat to extend it to ship the information over the network, but for now a photograph or screen capture from the end user will have to do.

I think the reason for the performance being as bad as it is (20FPS for only 20,000 triangles) may be due to the way buildings are allocating memory. During the update phase, each one is going around updating the transformations, jumping around and causing a lot of cache misses. The smart thing to do would be to hand out vertices (both Kamui and system-side (position, normal, UV)) from a pool instead of on a as-needed basis. The city planning phase for 1,000 simple buildings takes around 200 seconds to complete, too. With 50 buildings, it’s under one second, so I’m guessing I’m also messing up with how the buildings are getting placed. Procedural generation is fairly new to me and I’ve always avoided it in the past, mostly because I don’t trust myself to do it correctly.

I’m aiming to get this done by the end of the year. As long as no major setbacks are encountered, I think it will be in good shape. I’ll try to make entries as often as something new is added to the demo.