Project History

2002-07-22:

Changed deployment - the class files are now stored in a JAR-file. Simply double click the JAR-file to start the application.

2002-07-15:

Updated the web page for a new release of the software, updated the tutorial to match the changes and ammended and corrected the PSDLFormat page according to new findings.
Changed the name of Vertex Neighbour to Perimeter - much better word.

Cleaned up the block attribute 0x00b0, The last two vertices are also kept in the list. Removed the separate input fields.
Tried to work around a bug using split panes, the divider behaves strangely. The situation has improved a lot due to these changes. Still not good, though.

2002-07-13:

Now the option dialog works, the name and dimension of all views can be altered.

2002-07-11:

Tested large PSDL terrains, a 400 by 400 kilometer terrain posed no problems as long as the block count was kept around 2000.

Conclusion from this is that size does not matter, but quantity does.

Created separate application that generates a square PSDL terrain curved by a mathematical function (cos (r) + 1 / r)).

2002-07-08:

Added tabs for each view type in the options dialog.

Changed some layout issues.

2002-06-30:

No longer uses split panes - all lists are displayed in internal frames instead.

2002-06-21:

Dropped my attempts to incorporate a heavyweight 3DCanvas in a ligthweight environment - a 3D view is now opened in a separate window.

2002-06-16:

Reads options from an XML-file.

Added support for more than one 3D view.

Added option dialog. As well as options for drawing mode, colouring mode, lighting mode and the function to display block indices.

2002-06-11:

When selection a vertex in the list of neighbouring blocks the vertex list scrolls to the selected vertex.

Added error handling in the 3D view - if a block has insufficient data for generating a shape it will not be rendered. Prevoiusly this caused an uncontrolled exception.

2002-06-02:

Changed colouring of the blocks in the 3D view, now assigns a random colour to each block.

2002-06-02:

Moved the control buttons of the 3D view to allow larger movements.

Added wireframe rendering in the 3D view.

2002-05-27:

Added support for displying the block index in the 3D view, unfortunately the billboard effect I wanted does not work.

Added menu item enabling import of vertices from an ascii file.

Broke out the project history listing to a separate page on the web site.

Updated PSDLFormal.html to current knowledge.

2002-05-26:
Added possibility to load a list of vertices from a text file containing lines of x, y, z coordinates.

2002-05-23:
Realized that the "neighbour list" of a city block also define the bounding box for the collision system. The vertices make out a clockwise fan around the first vertex.

Realized that city block attribute 0x00b0 defines a fan. The reason for the incorrect triangles drawn by MM2 in my tutorial was that my vertices and the order of them didn't define a clockwise triangle fan. When correcting this, by creating a new vertex that could act as the pivot of a fan and reordering the vertices all artifacts disappeared.

Updated the tutorial to create clockwise triangle fans.

2002-05-20:
Added edit function for unknown lists.

2002-05-09:
Vertices and Attribute 0x00b0 can now be edited, new city blocks can be added. Started to add drag'n drop support between the lists.

2002-05-05:
Realized that it would be nice if other people could help me analyzing the semantics of the block attributes. For this I figure that the easiest way would be to create an easy way to experiment with the PSDL files. Hence I started to turn the viewer into an editor even though I don't know enough about the format yet. The main idea is that you should be able to add, remove and change the order of the vertices given in the various block attributes. And of course you have to be able to save the file as PSDL. After that it is just a matter of placing the PSDL file in an .ar with the corresponding city information files and see what happens in MM2.

2002-05-02:
Identified 14 new attributes.

Changed the program to reflect "city blocks", not "polygons".

2002-04-28:
Knowing that the texture on the sides of the road segments in city.psdl is swalk_f I listed all texture indices with this texture and started to figure out where they are referenced from the road polygons attributes. I found a candidate in attribute 0x0080. But unfortunately this appears not to be it.

2002-04-20:
It seems that I was incorrect while the french list was correct once more - Digging in to these repeating patterns made me think that it would be strange to start a list of general attributes with two texture indices. No, it is more likely that the first attribute in most polygons is attribute 0x0050. This attribute assigns a texture to this polygon. Then a mystery that remains is how there can be two or even three textures on some polygons... Most likely some other attribute include a reference to the other textures. In fact I have found polygons in sf.psdl that actually have two attribute 0x0050, whatever that means...

Today I have spent some time re-building the PSDL Viewer to reflect these attributes instead of "user data". I must do some more work before I release a new version though.

2002-04-18: I no longer believe that the unknown in each polygon is a simple list of texture coordinates. I have identified several repeating patterns in this data making me believe that this data is a set of attributes that make up a material for the polygon. Each attribute is identified by a short and each attribute has a specific number of arguments. For example polygon 1 of city.psdl appears to have two attributes defined, the first one identified by 0x0031 has three arguments of type short. The second attribute, identified by 0x00b0, appears to have 12 arguments of type short.

2002-04-18: Setting the connecting polygons to zero removes all references to other polygons - this means that once this was done I could start to fiddle with the number of polygons. Simply setting nPolygons to 2 (number of polygons + 1) and excluding all polygons except polygon 1 creates a working terrain with only one polygon. Driving off any edge of this polygon causes the car to fall off the map.

2002-04-18: One thing I thought was incorrect in the french PSDL list was that it claims that the short following the vertex index in the polygon definition is an index to a connecting polygon. I couldn't see the use of this so I thought this was incorrect. But experimental testing revealed that this is probably true! Each vertex is attached to another polygon unless the value is zero. Setting all of these values to zero on all polygons in city.psdl makes all polygons invisible except the one you are currently driving on.

2002-04-17: Excluding the unknown at the end of city.psdl has no apparent effect in MM2!

2002-04-14: Now I started to make wild more or less random manipulations to the file to see what happens when MM2 tries to load the file. Changing the first unknown, now called "targetSize" to zero in city.psdl caused MM2 to crash reporting an error saying "Wrong target size -- use a different SDL class to load this file."

2002-04-11: Following a tip from MM2C I contacted PC425, she told me that there was a description of the PSDL file format on "http://www.mm2.free.fr/". I checked this out but unfortunately that list did not tell me anything new. In fact I believe that some assumptions made there are incorrect, I have not included any of these assumptions in my own description of the format. An interesting point is that the french list covers exactly the same parts of the PSDL file that I have uncovered, I take that as a bad omen - maybe the rest is too difficult to understand without more knowledge about the game engine itself... But I won't give up just yet... ;)

2002-03-27: After coming this far I started to build my PSDL Viewer application and telling people about it at the "Midtown Madness 2 Central".

March 2002: The "unknown" shorts in the polygon definitions looks very much like a list of vertex indices. I would like to believe that these are indices into an array of texture coordinates. But if that were so, wouldn't the nData always be two plus two times nVertices? Two for the texture indices and two for each vertex and texture. Unfortunately this appears not to be the case.

March 2002: The fact that there are two textures per polygon was a bit unexpected, but this is highly likely. Taking a look at city.psdl tells me that there aren't enough separate polygons to make up the sidewalks. And in addition to that both of the texture indices point to the correct textures! The pavement of the road is r_alley_f.tex and the sidewalk is swalk_f.tex just as indicated by these two values.

March 2002: After this the real guesswork started, finding the texture indices was a bit awkward. I tried to change the numbers to get another texture but this mostly caused MM2 to crash on loading my PSDL. Then I took another approach, I changed the filenames in the list of texturenames for those indices I thought was the texture indices and voil�, i got grass all over city.psdl!

February 2002: To find the polygons was a little harder, again using the guidance of the PSDL Editor, I matched the number of polygons and the indices into the vertex array.

A long time ago: The first thing I did was to track down and download "PSDL Editor" a software made by PC425 and associates. Examining the lists in this program gave me helpful hints of the number of vertices and number of polygons to expect in the files. The presentation of vertices as large integers didn't quite fit - especially since changing the values matching the displayed integers caused unexpected results. Because of these strange results I started to believe that the values were in fact IEEE single presicion floating point values.

2002-07-22:	Changed deployment - the class files are now stored in a JAR-file. Simply double click the JAR-file to start the application.
2002-07-15:	Updated the web page for a new release of the software, updated the tutorial to match the changes and ammended and corrected the PSDLFormat page according to new findings. Changed the name of Vertex Neighbour to Perimeter - much better word. Cleaned up the block attribute 0x00b0, The last two vertices are also kept in the list. Removed the separate input fields. Tried to work around a bug using split panes, the divider behaves strangely. The situation has improved a lot due to these changes. Still not good, though.
2002-07-13:	Now the option dialog works, the name and dimension of all views can be altered.
2002-07-11:	Tested large PSDL terrains, a 400 by 400 kilometer terrain posed no problems as long as the block count was kept around 2000. Conclusion from this is that size does not matter, but quantity does. Created separate application that generates a square PSDL terrain curved by a mathematical function (cos (r) + 1 / r)).
2002-07-08:	Added tabs for each view type in the options dialog. Changed some layout issues.
2002-06-30:	No longer uses split panes - all lists are displayed in internal frames instead.
2002-06-21:	Dropped my attempts to incorporate a heavyweight 3DCanvas in a ligthweight environment - a 3D view is now opened in a separate window.
2002-06-16:	Reads options from an XML-file. Added support for more than one 3D view. Added option dialog. As well as options for drawing mode, colouring mode, lighting mode and the function to display block indices.
2002-06-11:	When selection a vertex in the list of neighbouring blocks the vertex list scrolls to the selected vertex. Added error handling in the 3D view - if a block has insufficient data for generating a shape it will not be rendered. Prevoiusly this caused an uncontrolled exception.
2002-06-02:	Changed colouring of the blocks in the 3D view, now assigns a random colour to each block.
2002-06-02:	Moved the control buttons of the 3D view to allow larger movements. Added wireframe rendering in the 3D view.
2002-05-27:	Added support for displying the block index in the 3D view, unfortunately the billboard effect I wanted does not work. Added menu item enabling import of vertices from an ascii file. Broke out the project history listing to a separate page on the web site. Updated PSDLFormal.html to current knowledge.
2002-05-26:	Added possibility to load a list of vertices from a text file containing lines of x, y, z coordinates.
2002-05-23:	Realized that the "neighbour list" of a city block also define the bounding box for the collision system. The vertices make out a clockwise fan around the first vertex. Realized that city block attribute 0x00b0 defines a fan. The reason for the incorrect triangles drawn by MM2 in my tutorial was that my vertices and the order of them didn't define a clockwise triangle fan. When correcting this, by creating a new vertex that could act as the pivot of a fan and reordering the vertices all artifacts disappeared. Updated the tutorial to create clockwise triangle fans.
2002-05-20:	Added edit function for unknown lists.
2002-05-09:	Vertices and Attribute 0x00b0 can now be edited, new city blocks can be added. Started to add drag'n drop support between the lists.
2002-05-05:	Realized that it would be nice if other people could help me analyzing the semantics of the block attributes. For this I figure that the easiest way would be to create an easy way to experiment with the PSDL files. Hence I started to turn the viewer into an editor even though I don't know enough about the format yet. The main idea is that you should be able to add, remove and change the order of the vertices given in the various block attributes. And of course you have to be able to save the file as PSDL. After that it is just a matter of placing the PSDL file in an .ar with the corresponding city information files and see what happens in MM2.
2002-05-02:	Identified 14 new attributes. Changed the program to reflect "city blocks", not "polygons".
2002-04-28:	Knowing that the texture on the sides of the road segments in `city.psdl` is `swalk_f` I listed all texture indices with this texture and started to figure out where they are referenced from the road polygons attributes. I found a candidate in attribute 0x0080. But unfortunately this appears not to be it.
2002-04-20:	It seems that I was incorrect while the french list was correct once more - Digging in to these repeating patterns made me think that it would be strange to start a list of general attributes with two texture indices. No, it is more likely that the first attribute in most polygons is attribute 0x0050. This attribute assigns a texture to this polygon. Then a mystery that remains is how there can be two or even three textures on some polygons... Most likely some other attribute include a reference to the other textures. In fact I have found polygons in `sf.psdl` that actually have two attribute 0x0050, whatever that means... Today I have spent some time re-building the PSDL Viewer to reflect these attributes instead of "user data". I must do some more work before I release a new version though.
2002-04-18:	I no longer believe that the unknown in each polygon is a simple list of texture coordinates. I have identified several repeating patterns in this data making me believe that this data is a set of attributes that make up a material for the polygon. Each attribute is identified by a short and each attribute has a specific number of arguments. For example polygon 1 of `city.psdl` appears to have two attributes defined, the first one identified by 0x0031 has three arguments of type short. The second attribute, identified by 0x00b0, appears to have 12 arguments of type short.
2002-04-18:	Setting the connecting polygons to zero removes all references to other polygons - this means that once this was done I could start to fiddle with the number of polygons. Simply setting nPolygons to 2 (number of polygons + 1) and excluding all polygons except polygon 1 creates a working terrain with only one polygon. Driving off any edge of this polygon causes the car to fall off the map.
2002-04-18:	One thing I thought was incorrect in the french PSDL list was that it claims that the short following the vertex index in the polygon definition is an index to a connecting polygon. I couldn't see the use of this so I thought this was incorrect. But experimental testing revealed that this is probably true! Each vertex is attached to another polygon unless the value is zero. Setting all of these values to zero on all polygons in `city.psdl` makes all polygons invisible except the one you are currently driving on.
2002-04-17:	Excluding the unknown at the end of `city.psdl has no apparent effect in MM2!`
2002-04-14:	Now I started to make wild more or less random manipulations to the file to see what happens when MM2 tries to load the file. Changing the first unknown, now called "targetSize" to zero in `city.psdl` caused MM2 to crash reporting an error saying "Wrong target size -- use a different SDL class to load this file."
2002-04-11:	Following a tip from MM2C I contacted PC425, she told me that there was a description of the PSDL file format on "http://www.mm2.free.fr/". I checked this out but unfortunately that list did not tell me anything new. In fact I believe that some assumptions made there are incorrect, I have not included any of these assumptions in my own description of the format. An interesting point is that the french list covers exactly the same parts of the PSDL file that I have uncovered, I take that as a bad omen - maybe the rest is too difficult to understand without more knowledge about the game engine itself... But I won't give up just yet... ;)
2002-03-27:	After coming this far I started to build my PSDL Viewer application and telling people about it at the "Midtown Madness 2 Central".
March 2002:	The "unknown" shorts in the polygon definitions looks very much like a list of vertex indices. I would like to believe that these are indices into an array of texture coordinates. But if that were so, wouldn't the nData always be two plus two times nVertices? Two for the texture indices and two for each vertex and texture. Unfortunately this appears not to be the case.
March 2002:	The fact that there are two textures per polygon was a bit unexpected, but this is highly likely. Taking a look at `city.psdl` tells me that there aren't enough separate polygons to make up the sidewalks. And in addition to that both of the texture indices point to the correct textures! The pavement of the road is `r_alley_f.tex` and the sidewalk is `swalk_f.tex` just as indicated by these two values.
March 2002:	After this the real guesswork started, finding the texture indices was a bit awkward. I tried to change the numbers to get another texture but this mostly caused MM2 to crash on loading my PSDL. Then I took another approach, I changed the filenames in the list of texturenames for those indices I thought was the texture indices and voil�, i got grass all over `city.psdl`!
February 2002:	To find the polygons was a little harder, again using the guidance of the PSDL Editor, I matched the number of polygons and the indices into the vertex array.
A long time ago:	The first thing I did was to track down and download "PSDL Editor" a software made by PC425 and associates. Examining the lists in this program gave me helpful hints of the number of vertices and number of polygons to expect in the files. The presentation of vertices as large integers didn't quite fit - especially since changing the values matching the displayed integers caused unexpected results. Because of these strange results I started to believe that the values were in fact IEEE single presicion floating point values.