• entries
24
21
• views
17627

# Something Old, Something New

254 views

I actually did some work at work this week. Nothing heavy, I'm still getting used to things, but I should get some more complicated things to do from here on in. It's interesting to be working in a real team environment after so long working solo on projects. The only team coding projects I've done before really were toy projects at uni.

On the mod front I've been looking into the Jasper source code to decipher the Jpeg2000 format. It might sound like a serious case of NIH to be writing my own Jpeg2000 reader, but in reality I only need a very small subset of functionality, so it should be possible to make some serious performance gains. I've made quite a bit of progress on the headers. Now I just need to trace through Jasper properly to figure out how things are setup so I can start decyphering the actual image data. Here's some pseudocode for what I have so far:
{	uint16 marker_segment	assert(marker_segment == 0xff4f)}{	uint16 marker_segment	assert(marker_segment == 0xff51)	uint16 segment_length	uint16 capabilities	uint32 image_width	uint32 image_height	uint32 image_origin_x	uint32 image_origin_y	uint32 tile_width	uint32 tile_height	uint32 tile_origin_x	uint32 tile_origin_y	uint16 number_of_components	assert(segment_length == 38 + (number_of_components * 3))	{bitfield:1, bitfield:7, uint8, uint8} components[number_of_components]; // signedness, precision, horizontal_sampling_distance, vertical_sampling_distance	for_each(component in components)	{		uint8(component.precision) += 1	}}repeat{	uint16 marker_segment	switch (marker_segment)	{		case 0xff52:			uint16 segment_length			uint8 general_coding_style			uint8 progression_order			uint16 number_of_layers			uint8 multicomponent_transform			uint8 number_of_decomposition_layers			uint8 code_block_width			uint8 code_block_height			uint8 code_pass_style			uint8 uses_qmfb		case 0xff5c:			uint16 segment_length			bitfield:3 number_of_guard_bits			bitfield:5 quantisation_style			uint8 stepsizes[segment_length - 3]			for_each(stepsize in stepsizes)			{				assert(stepsize < 32)				uint16(stepsize) = stepsize << 11			}		case 0xff5d:			uint16 segment_length			uint8 component_number			bitfield:3 number_of_guard_bits			bitfield:5 quantisation_style			uint8 stepsizes[segment_length - 3]			for_each(stepsize in stepsizes)			{				assert(stepsize < 32)				uint16(stepsize) = stepsize << 11			}		case 0xff64:			uint16 segment_length			uint16 registration_id			uint8 comment[segment_length - 4]		case 0xff90:			uint16 segment_length			uint16 tile_number			uint32 length			uint8 tile_part_instance			uint8 number_of_tile_parts		case 0xff93:	}}

I also received an e-mail this week from somebody asking for the source to my old Furries Demo from the NeHe Creative contest. Looking through the source as I packaged it up I was a bit shocked to see how bad it was. Looks like at that time I was still transitioning to the SC++L. I ripped out my poorly written Array class and replaced my raw char *s with std::strings among other changes before mailing it off. Hopefully people won't pick up as many bad coding habits as they might otherwise have done so.

Finally, I came across an interesting game design problem this week. How do you design an online multiplayer system for casual gamers for a game which consists of relatively short real-time action segments separated by (potentially non-real-time) setup phases? The aim is to have a persistant "world" in which the player can see real gains and losses over a long period (say a month), yet remain playable by individuals with limited and varied amounts of free time.

?nigma

There are no comments to display.

## Create an account

Register a new account